Connection: keep-alive——[HTTP权威指南]摘录

HTTP协议的Connection: keep-alive  header是为了解决性能问题而产生的。

HTTP作为一个应用层协议，其性能在很大程度上取决于TCP（传输层协议）通道的性能。而keep-alive就是HTTP对其下的TCP通道性能优化的一种策略。

影响HTTP高并发时性能的若干个因素

建立TCP连接的网络延时

下图描绘了HTTP事务主要的连接、传输以及处理时延。

注意到，在很多情况下，服务器真正“处理”事务的时间并不长。绝大部分时间都被消耗在了建立TCP连接、传输请求和响应报文上。

当客户端请求的资源在一台服务器上，请求被串联执行时，这种时延将会被进一步放大。如下图客户端向服务器请求了3个资源。

TCP慢启动

TCP数据传输的性能还取决于TCP的使用期（age），连接会随着时间进行自我“调谐”。比如一个TCP连接建立后，一个TCP端点在任意时刻可以传输的分组数是有限的。每成功接收一个分组，发送端就有了发送另外两个分组的权限。随着传输的数据越来越多，任意时刻可发送的分组数就会大大增加，这种方式被称为“打开拥塞窗口”。

持久化解决的问题

HTTP/1.0+ keep-alive连接

首先需要了解的一点是，在HTTP/1.0的各种增强版本中，通讯双方默认是不使用持久化连接的。当客户端请求中含有Connection: Keep-Alive首部，服务器响应中也有Connection: Keep-Alive首部时，双方才会成功建立持久连接。

在服务器返回客户端Connection: Keep-Alive首部的同时，它还可以添加一条Keep-Alive首部。

Connection: Keep-Alive

Keep-Alive: max=5, timeout=120

上面个例子说明，服务器最多还会为另外5个事务保持TCP连接的打开状态，或者将打开状态保持到连接空闲了2分钟之后。

在HTTP/1.0+中还存在哑代理与相关解决方案的知识点，此处不再展开。实际上在新的HTTP/1.1规范中已经没有了Keep-Alive的相关说明，它已被标准抛弃。但浏览器和服务器对HTTP/1.0+的支持依旧广泛，因此了解其相关知识并未过时。

HTTP/1.1持久连接

HTTP/1.1在废弃Keep-Alive后，提出了一种持久连接（persistent connection）的改进型设计取代它。它们目的相同，但后者工作机制更优。

持久连接在默认情况下都是支持的。除非特别指明，否则HTTP/1.1假定所有连接都是持久的。如果客户端需要事务处理完之后直接关闭TCP连接，需要显式地添加一个Connection: close首部。同样如果服务器返回的首部中没有Connection: close首部，客户端会认为连接仍维持在打开状态。

管道化连接

HTTP/1.1允许在持久连接上可选地使用请求管道。在响应到达之前，可以将多余请求放入队列。下图显示了持久化连接是怎样消除TCP连接时延，以及管道化请求是如何消除传输时延的。