HTTP权威指南 8.6分
读书笔记 第4章-4.2 对TCP性能的考虑
安霖镜

HTTP事务的性能很大程度上取决于底层TCP通道的性能。 了解了TCP的某些基本性能特点,有助于更好地理解HTTP的连接优化特性 . HTTP事务的时延,就是由TCP网络时延构成的。 因为,与建立TCP连接、传输请求、响应报文的时间相比,事务处理的时间可能是很短的 除非是客户端or服务器超载 or 正在处理复杂的动态资源 . HTTP事务的时延,有以下几种主要原因: 1.客户端从URI中确定出服务器的IP和端口号 如果最近没有对URI中的主机名进行访问,通过DNS解析将主机名转换成IP地址可能要花费数十秒 注:大部分HTTP客户端都有一个小的DNS缓存,用来保存近期访问的站点的IP地址 因为大多数web浏览器浏览的都是少数常用站点,所以一般都可以很快的将主机名解析出来 2.每条新的TCP连接都有建立时延。这个值通常最多只有一两秒钟。但如果数百个HTTP事务,这个值很快会快速叠加上去。 3.TCP连接建立后,客户端通过TCP管道发送HTTP请求。传输请求报文、服务器处理报文、回送HTTP响应都需要时间。 TCP网络时延的大小:取决于硬件速度、网络、服务器的负载;请求和响应报文的尺寸;客户端和服务器间的距离。 还有TCP协议的技术复杂性。 . . 会影响到HTTP程序员、最常见的TCP相关时延: 1.TCP连接建立握手 TCP建立连接:连接握手时延,传送两个分组 SYN(请求连接) SYN+ACK(请求被接受) ACK(客户端回送确认-连接已成功建立) 注:现代的TCP栈 都允许客户端在最后的确认分组中发送数据 SYN/SYN+ACK握手会产生可测量的时延 所以:小的HTTP事务 可能会在TCP建立上花费50% 或更多的时间 (HTTP如何通过重用现存连接 来减小TCP建立时延所造成的影响) . 4.用于捎带确认的TCP延迟确认算法 为了保证可靠的分组传输,TCP有自己的确认机制来确保数据的成功传输:序列号、数据完整性校验和 由于,确认报文很小,所以TCP允许发往相同方向的输出数据分组中对其进行捎带。 延迟确认算法:会在特定的窗口时间(通常100-200毫秒)内将输出确认存放在缓冲区中,以寻找能捎带它的输出数据分组。 如果等了那么久,都没有要输出数据分组,就把确认信息放在单独的分组中传送。 但是, HTTP具有双峰特征的请求-应答行为,就降低了捎带信息的可能(客户端是客户端,服务器是服务器;一个主要请求 一个主要响应)。 当希望有相反方向回传分组的时候,可偏偏没那么多。 通常,延迟确认算法会引起相当大的时延。[“相当大”?] 根据不同的操作系统,可以调整or禁用延迟确认算法。 . 对TCP配置进行任何修改时,都要小心-一定要清楚地知道自己在干什么。 . 2.TCP慢启动拥塞控制 所以,新连接的传输速度,会比 已经交换过一定量数据的连接慢一些 已调谐连接会更快些,所以HTTP可以重用现存的连接(即HTTP的持久连接) . 3.数据聚集的Nagle算法 因为每个TCP段都至少装载了40个字节的标记和首部 所以,如果TCP发送了大量的包含少量数据的分组,网络的性能就会严重下降[“严重下降”] 注:发送大量单字节分组的行为,称为“发送端傻窗口综合症”:效率低 违反社会道德 也可能会影响其他的因特网流量。 Nagle算法:试图在发送一个分组前,将大量的TCP数据绑定在一起,以提高网络效率。 该算法鼓励发送全尺寸(LAN上最大尺寸的分组大约时1500字节 在因特网上时几百字节)的段。 . Nagle算法会引发几种HTTP性能问题: 首先,小的HTTP报文可能无法填满一个分组,可能会因为等待那些永远不会到来的额外数据而产生时延。 其次,Nagle算法和延迟确认间存在交互问题-Nagle算法会组织数据的发送,直到有确认分组抵达为止, 但确认分组自身会被延迟算法延迟100-200毫秒。 . HTTP应用程序:通常会设置禁用Nagle算法,以提高性能。 如果这么做的话,一定要确保向TCP写入大块的数据,这样就不会产生一堆小分组了。 . 5.TIME_WAIT时延和端口耗尽 TIME_WAIT端口耗尽,是很严重的性能问题 但在现实中相对较少出现。 但是,一旦碰到,性能会变得出乎意料地差。这个问题值得特别关注。 . 2MSL的连接关闭延迟(通常不是啥问题,但在性能基准环境下可能会是一个问题) . 在进行性能基准测试时(?是指的压测么?), 通常只有1台or几台用来产生流量的计算机连接到某个服务器上 这样,就限制了连接到服务器的客户端的IP地址数(即客户端的IP数目很少) . HTTP的默认TCP端口80上进行监听。用TIME_WAIT防止端口号重用时-也就限制了可用的连接值组合 最坏情况下:只有一个客户端和一台服务器时,构建一条TCP连接的4个值 <源IP 源端口 目的IP 80> 客户端每次连接到服务器时 都会获得一个新的源端口(源端口是服务器产生的 还是客户端产生的?) 以实现连接的唯一性 但由于源端口的数量有限(比如 6w个)而且在2MSL秒(约2min)内连接是无法重用的 连接率就被限制了60000个/120s=500次/s . 要修正这个问题:可以增加客户端负载生成机器的数量or 确保客户端和服务器在循环使用几个虚拟IP地址以增加更多的连接组合。 . 即使没有端口耗尽的问题,也要特别小心大量连接处于打开状态的情况 or 为处于等待状态的连接分配了大量控制块的情况。 (此时,有些操作系统的速度会严重减缓) . //TIME_WAIT //端口

0
《HTTP权威指南》的全部笔记 138篇
豆瓣
免费下载 iOS / Android 版客户端