HTTP性能（时延）问题的关注点

TCP 连接建立握手

也就是三次握手的时延，最后的结果是，小的HTTP 事务可能会在TCP 建立上花费50%，或更多的时间。

TCP 慢启动拥塞控制

TCP 数据传输的性能还取决于TCP 连接的使用期（age）。TCP 连接会随着时间进行自我“调谐”，起初会限制连接的最大速度，如果数据成功传输，会随着时间的推移提高传输的速度。这种调谐被称为TCP 慢启动（slow start），用于防止因特网的突然过载和拥塞。

也就是TCP数据传输开始是受限的，然后慢慢增加，这当然是会增加时延。

数据聚集的 Nagle 算法（以及用于捎带确认的 TCP 延迟确认算法）

TCP 有一个数据流接口，应用程序可以通过它将任意尺寸的数据放入TCP 栈中——即使一次只放一个字节也可以！但是，每个TCP 段中都至少装载了40 个字节的标记和首部，所以如果TCP 发送了大量包含少量数据的分组，网络的性能就会严重下降。
Nagle 算法（根据其发明者John Nagle 命名）试图在发送一个分组之前，将大量TCP 数据绑定在一起，以提高网络效率。

这个算法就是为了减少发送过少数据引起网络性能下降的问题。

算法可能的问题：

Nagle 算法会引发几种HTTP 性能问题。首先，小的HTTP 报文可能无法填满一个分组，可能会因为等待那些永远不会到来的额外数据而产生时延。其次，Nagle 算法与延迟确认之间的交互存在问题——Nagle 算法会阻止数据的发送，直到有确认分组抵达为止，但确认分组自身会被延迟确认算法延迟100 ～ 200 毫秒。
HTTP 应用程序常常会在自己的栈中设置参数TCP_NODELAY，禁用Nagle 算法，提高性能。如果要这么做的话，一定要确保会向TCP 写入大块的数据，这样就不会产生一堆小分组了。

TIME_WAIT 时延和端口耗尽

TIME_WAIT 端口耗尽是很严重的性能问题，会影响到性能基准，但在现实中相对较少出现。大多数遇到性能基准问题的人最终都会碰到这个问题，而且性能都会变得出乎意料地差，所以这个问题值得特别关注。
当某个TCP 端点关闭TCP 连接时，会在内存中维护一个小的控制块，用来记录最近所关闭连接的IP 地址和端口号。这类信息只会维持一小段时间，通常是所估计的最大分段使用期的两倍（称为2MSL，通常为2 分钟）左右，以确保在这段时间内不会创建具有相同地址和端口号的新连接。实际上，这个算法可以防止在两分钟内创建、关闭并重新创建两个具有相同IP 地址和端口号的连接。用TIME_WAIT 防止端口号重用时，这些情况也限制了可用的连接值组合。

也就是相当于在客户端断开tcp连接之后，然后会进入TIME_WAIT状态，这段时间就是2MSL（通常2分钟），这样就可能出现下面的问题：

连接IP和端口的组合情况具体内容：

在只有一个客户端和一台Web 服务器的异常情况下，构建一条TCP 连接的4 个值：
<source-IP-address, source-port, destination-IP-address, destination-port>
其中的3 个都是固定的——只有源端口号可以随意改变：
<client-IP, source-port, server-IP, 80>

客户端每次连接到服务器上去时，都会获得一个新的源端口，以实现连接的唯一性。但由于可用源端口的数量有限（比如，60 000 个），而且在2MSL 秒（比如，120秒）内连接是无法重用的，连接率就被限制在了60 000/120=500 次/ 秒。如果再不断进行优化，并且服务器的连接率不高于500 次/ 秒，就可确保不会遇到TIME_WAIT 端口耗尽问题。要修正这个问题，可以增加客户端负载生成机器的数量，或者确保客户端和服务器在循环使用几个虚拟IP 地址以增加更多的连接组合。
即使没有遇到端口耗尽问题，也要特别小心有大量连接处于打开状态的情况，或为处于等待状态的连接分配了大量控制块的情况。在有大量打开连接或控制块的情况下，有些操作系统的速度会严重减缓。
参开文献：
1、HTTP权威指南（HTTP: The Definitive Guide）
[美]　David Gourley Brian Totty Marjorie Sayer
Sailu Reddy Anshu Aggarwal 著
陈涓 赵振平 译