高效管理http链接

1.Http链接基础

  Http协议承载了互联网上的主要流量，然而说到传输，还要回归到最基本的网络分层模型TCP/IP。TCP/IP是全球计算机及网络设备都在使用的一种经常使用的分组交互网络分层协议集。客户端能够打开一条TCP/IP链接，与世界上的任何服务器进行数据交换，而且交换的数据永远不会丢失，受损或失序。

  下面是常见的TCP/IP分层协议，分为安全与非安全版本。

  由图可知，HTTP的整个传输过程能够描述为“HTTP over TCP over IP”。TCP是可靠地传输协议，就好像一条管道，从TCP链接一段填入的字节会从另一端以原有的顺序，正确的传送出来。

  TCP层与IP层都有本身的协议，他们对数据的关注点不一样。总的来讲，TCP段包含了目的端口与源端口，用来创建程序之间的链接。IP段包含了目的IP与源IP，用来进行网络寻址，最终创建机器之间的链接。而一条TCP链接正是根据这四点惟一对应的：

<源IP地址，源端口号，目的IP地址，目的端口号>

  不一样的链接不能够拥有彻底相同的四个属性。对于通常功能而言，本身发起的链接中源端口号是随机生成的。

2.http链接性能

  因为http数据是经过TCP传输的，http链接的性能很大程度上取决于TCP通道的性能。咱们先分析一个正常的http事务。

1. 客户端若是拿到的是域名，则须要先从DNS服务器中解析得到服务器IP地址，这个过程称为“DNS查询”，须要花费必定的时间。
2. 客户端与服务器进行三次握手创建链接。
3. 创建链接后，客户端会发送有真正含义的请求报文。
4. 服务器接收到请求后开始处理。
5. 服务器处理完毕后，发送响应给客户端。
6. 客户端收到响应后，与服务器进行四次挥手，断开链接。

  从上面的流程能够看出来，真正的有业务意义的阶段是“请求-处理-响应”，其余阶段时间消耗都是与业务无关的。所以能够从这上面思考如何优化TCP性能。

3.TCP链接性能聚焦

TCP链接的性能一般从下面5个方面考虑：

1. TCP创建握手
2. 捎带确认的TCP延迟确认算法
3. TCP慢启动的拥塞控制
4. 数据汇集的Nagle算法
5. TIME_WAIT时延与端口耗尽

3.1 TCP创建握手

  从上面的图中能够看出，一次正常的交互须要通过DNS查询、握手、挥手等与数据传输无关的操做。若是每次传输的数据都不多，那么这种操做所占用的比例就会增长，这将大大下降HTTP的性能。因为HTTP是创建在TCP链接的基础上的，因此握手的过程是对HTTP不可见的，HTTP只能看到创建链接发生了时延。三次握手的过程这里不作赘述，感兴趣的请查阅相关资料。

  三次握手简单来讲是创建链接前的三次交互来确认链接能够创建，有SYN,ACK+SYN,ACK三次报文通讯。对于一些小的HTTP事务，好比握手后告知页面304了，这种事务中在TCP创建上可能会法费一半甚至更多的时间。

  解决方案：咱们能够经过重用TCP链接来减小这种性能上的损失，好比持久链接。

3.2 延迟确认

  因特网是没法保证数据可靠传输的，由于在网络路由超负荷的状况下，容许丢弃任意网络分组。因此，TCP实现了一套本身的确认机制来保障数据可靠传输。

  每一个TCP段都有一个序号和数据校验和，接受者在接受完整以后会向发送者送回确认分组，这样保证了这个分组的可靠传输。若是发送者在必定时间窗口内没有接收到响应的确认分组，则认为这个分组已经丢失，对该分组进行重发。

  因为确认报文很小，因此TCP容许在发往相同方向的数据分组中对其进行“捎带”，就是这种捎带出了问题。TCP将返回确认信息与输出信息集合在一块儿，能够有效的利用网络链接。所以为了找到相同方向的数据分组来进行捎带，不少TCP栈实现了一种“延时确认”的算法。这种算法将确认信息放入缓冲区，在必定的时间窗口内（通常是100-200毫秒）找不到输出分组，则对确认数据进行单独发送。

  若是请求响应并无较多的数据传输过程，则知足捎带确认的可能性就很低。一般，延迟确认算法会引入至关大的时延。

  解决方案：根据操做系统的不容，能够调整或禁止延迟确认算法。

3.3 慢启动与拥塞控制

  TCP传输过程有慢启动与拥塞控制的概念。

  TCP在创建链接开始的时候，会进行慢启动，数据窗口会逐渐指数变大，在达到阈值后会线性增加。当发生某次超时以后，会迅速减少窗口到最小，从新开始慢启动，通知减少以前的阈值。

  在这种机制的保障下，一个TCP链接是会进行自我调整的，所以一个新的链接的传输效率是不如老链接的。

  解决方案：咱们经过重用链接，可使得传输效率提高，好比持久链接。

3.4 Nagle算法与TCP_NODELAY

  Nagle算法与延时确认算法有些相似。不过Nagle算法关注的是发送方，为了保证不大量发送小的数据报文形成3.1的问题。该算法鼓励每次发送大的数据组，若是数据分组不够大，则放在缓存区等待与其余数据分组结合起来达到上限后一块儿发送，或者其余分组被确认后发送。

  而对于一些小的数据分组而言，可能不少个也没法攒够一次发送的数量。当这时接收端也采用延时确认算法以后，事情就变得恐怖了。对于发送端而言，不少小的数据分组没有成功发送，由于第一个分组发送以后，服务端进行了延时确认200ms，在这段时间过去以后发送端的第二个分组才会被发送，这样的排队阻塞简直是噩梦。

  解决方案：能够在协议栈中设置TCP_NODELAY来禁用Nagle算法。

3.5 TIME_WAIT时延与端口耗尽

  当一个TCP链接完成四次挥手关闭以后，会进入TIME_WAIT状态，在等待2MSL以后会释放该TCP链接。由于TCP的分组可能不是按照顺序到达的，咱们假设一个分组在网络中最多存货1MSL，则2MSL以后基本上就能够认为确实结束了。若是在2MSL之间服务端没有接收到LAST_ACK发送的FIN对应的响应，则TIME_WAIT会再次发送ACK。

  以前有说过，一个TCP能够经过下面四个属性来确认。

<源IP地址，源端口号，目的IP地址，目的端口号>

　而对于一个服务来讲，以后源端口是不肯定的，由于每次源端口都是随机生成的。可是源端口是有数量限制的，好比60000个端口，MSL是60秒。则链接速率就被限制在60000/120=500次/秒。若是不进行相关的优化，操做系统就没法发起更多的链接。

  解决方案：能够增长请求端机器，经过负载均衡的方法下降端口耗尽的可能性，或者在服务端使用几个虚拟IP增长链接的组合。　

4 总结

  HTTP创建在TCP的基础上，若是咱们在工做中发现HTTP创建链接的效率很低，能够考虑从上面的五个角度分析是否达到了相关的瓶颈，并经过推荐方案解决问题。