HTTP权威指南阅读笔记四:连接管理

时间:2022-04-10 17:03:48

  HTTP通信是由TCP/IP承载的,HTTP紧挨着TCP,位于其上层,所以HTTP事务的性能很大程度上取决于底层TCP通道的性能。

  HTTP事务的时延

  如图:

  HTTP权威指南阅读笔记四:连接管理

  HTTP事务的时延有以下几种主要原因。

  (1)客户端首先需要根据URI确定Web服务器的IP地址和端口号。如果最近没有对URI中的主机名进行访问,通过DNS解析系统将URI中的主机名转换成一个IP地址可能要花费数十秒的时间。

  (2)接下来,客户端会向服务器发送一条TCP连接请求,并等待服务器回送一个请求接受应答。每条新的TCP连接都会有连接建立时延。这个值通常最多只有一两秒种,但如果有数百个HTTP事务的话,这个值会快速地叠加上去。

  (3)一旦连接建立起来了,客户端就会通过新建立的TCP管道来发送HTTP请求。数据到达时,Web服务器会从TCP连接中读取请求报文,并对请求进行处理。因特网传输请求报文,以及服务器处理请求报文都需要时间。

  (4)然后,Web服务器会回送HTTP响应,这也需要花费时间。

  这些TCP网络时延的大小取决于硬件速度、网络和服务器的负载,请求和响应报文的尺寸,以及客户端和服务器之间的距离。TCP协议的技术复杂性也会对时延产生巨大的影响。

  性能聚焦区域

  会对HTTP产生影响、最常见的TCP相关时延包括:

  (1)TCP连接建立握手:HTTP事务越小,TCP连接建立握手所花时间占的比例就越大。

  (2)TCP慢启动拥塞控制:TCP连接会随着时间进行自我“调谐”,起初会限制连接的最大速度,如果数据传输成功,会随着时间的推移提高传输速度,主要用于防止因特网的突然过载和拥塞。由于存在这种拥塞控制特性,所以新连接的传输速度会比已经交换过一定量数据的、“已调谐”连接慢一些。

  (3)数据聚集的Nagle算法:TCP有一个数据流接口,应用程序可以通过它将任意尺寸的数据放入TCP栈中——即使一次只放一个字节也可以。所以如果TCP发送了大量包含少数数据的分组,网络的性能就会严重下降。Nagle算法试图在发送一个分组前,将大量TCP数据绑定在一起,以提高网络效率。这个算法会引发几种HTTP性能问题。首先,小的HTTP报文可能无法填满一个分组,可能会因为等待那些永远不会到来的额外数据而产生时延。其次,Nagle算法与延迟确认之间的交互存在问题——Nagle算法会阻止数据的发送,直到有确认的分组抵达为止,但确认分组自身会被延迟确认算法延迟100~200毫秒。HTTP应用程序常常会在自己的栈中设置参数TCP_NODEALY,禁止Nagle算法,提高性能。如果要这么做的话,一定要确保会向TCP写入大块的数据,这样就不会产生一堆小分组。

  (4)用于捎带确认的TCP延迟确认算法:每个TCP段都有一个序列号和数据完整性校验和。每个段的接收者收到完整的段时,都会向发送者回送小的确认分组。如果发送者没有在指定的窗口时间内收到确认信息,发送者就认为分组已被破坏或损毁,并重发数据。由于确认报文很小,所以TCP允许在发往相同方向的输出数据分组中对其进行“捎带”。为了增加确认报文找到同向传输数据分组的可能性,很多TCP栈都实现了一种“延迟确认”算法。延迟确认算法会在一个特定的窗口时间(通常是100~200毫秒)内将输出确认存放在缓冲区中,以录找能够捎带它的输出数据分组。如果在那个时间段内没有输出数据分组,就将确认信息放在单独的分组中传送。但是HTTP具有双峰特征的请求——应答行为降低了捎带信息的可能。当希望有相反方向回传分组的时候,偏偏没有那么多。通常,延迟确认算法会引入相当大的时延。根据所使用操作系统的不同,可以调整或禁止延迟确认算法。

  (5)TIME_WAIT时延和端口耗尽:当某个TCP端点关闭TCP连接时,会在内存中维护一个小的控制块,用来记录最近所关闭连接的IP地址和端口号。这类信息只会维持一小段时间,通常是所估计的最大分端使用期的两倍(称为2MSL,通常为2分钟)左右,以确保在这段时间内不会创建具有相同地址和端口号的新连接。实际上这个算法可以防止在两分钟内创建、关闭并重新创建两个具有相同IP 地址和端口号的连接。由于可用源端口的数量有限(比如60000个),而且在2MSL秒(比如120秒)内连接是无法重用的,连接速率就被限定在了60000/120 = 500 次/秒。超过这个数字,就会因端口耗尽而失败。要修正这个问题,可以把2MSL设置为一个较小的值,或增加客户端负载生成机器的数量,或确保客户端和服务器在循环使用几个虚拟IP 地址以增加更多的连接组合。