HTTP权威指南阅读笔记四：链接管理

　　HTTP通讯是由TCP/IP承载的，HTTP紧挨着TCP，位于其上层，因此HTTP事务的性能很大程度上取决于底层TCP通道的性能。

　　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 地址以增长更多的链接组合。