【摘抄】影响HTTP软件的TCP时延

• 握手时延

建立一条新的TCP连接时，甚至是在发送任意数据之前，TCP软件之间都会交换一系列的IP分组，对连接的有关参数进行沟通。如果连接只用来传送少量数据，这些交换过程就会严重降低HTTP的性能。

通常HTTP事务都不会交换太多数据，此时，SYN/SYN+ACK握手会产生一个可测量的时延。TCP连接的ACK分组通常都足够大，可以承载整个HTTP请求报文，而且很多HTTP服务器响应报文都可以放入一个IP分组中去。

最后的结果是，小的HTTP事务可能会在TCP建立上花费50%，或更多的时间。所以，需要重用现有连接。

• 延迟确认

由于确认报文很小，所以TCP允许在发往相同方向的输出数据分组中对其进行“捎带”。可以更有效地利用网络。延迟确认算法会在一个特定的窗口时间（通常是100~200毫秒）内将输出确认存放在缓冲区中，以寻找能够捎带它的输出数据分组。但是HTTP具有双峰特征（？）的请求-应答行为降低了捎带信息的可能。当希望有相反方向回传分组的时候，偏偏没有那么多。通常，延迟确认算法会引入相当大的时延。根据所使用操作系统的不同，可以调整或禁止延迟确认算法。

• TCP慢启动

TCP慢启动限制了一个TCP端点在任意时刻可以传输的分组数。简单来说，没成功接收一个分组，发送端就有了发送另外两个分组的权限。以此类推，这种方式被称为“打开拥塞窗口“，用于防止因特网的突然过载和拥塞。由于已调谐连接要更快一些，所以HTTP中有一些可以重用现存连接的工具。如HTTP”持久连接“。

• Nagle算法与TCP_NODELAY

Nagle算法鼓励发送全尺寸（LAN上最大尺寸的分组大约是1500字节，在因特网上是几百字节）的段。只有当所有其他分组都被确认之后，Nagle算法才允许发送非全尺寸的分组。如果其他分组仍然在传输过程中，就将那部分数据缓存起来。只有当挂起分组被确认，或者缓存中积累了足够发送一个全尺寸分组的数据时，才会将缓存的数据发送出去。

Nagle会引发几种HTTP性能问题。小的HTTP报文可能无法填满一个分组，可能会因为等待那些永远不会到来的额外数据而产生时延。其次，Nagle算法与延迟确认之间的交互存在问题——Nagle算法会阻止数据的发送，直到有确认分组抵达为止，但确认分组自身会被延迟确认算法延迟100~200毫秒。

HTTP应用程序常常会在自己的栈中设置参数TCP_NODELAY，禁用Nagle算法，提高性能。如果这样做，一定要确保会向TCP写入大块的数据，这样才不会产生一堆小分组。

• TIME_WAIT累积与端口耗尽

当某个TCP端点关闭TCP连接时，会在内存中维护一个小的控制块，用来记录最近所关闭连接的IP地址和端口号。这类信息只会维持一小段时间，通常是所估计的最大分段使用期的两倍（称为2MSL，通常为2分钟）左右，以确保在这段时间内不会创建具有相同地址和端口号的新连接。

客户端每次连接到服务器上去时，都会获得一个新的源端口，以实现连接的唯一性。但由于可用源端口的数量有限，并且在2MSL秒内连接是无法重用的，连接率就被限制在了65535/120=546次/秒。这样有可能产生的问题就是端口耗尽问题。