HTTP持续连接和管道化连接

持续连接

重用已对目标服务器打开的空闲连接，就可以避开缓慢的连接建立阶段。而且，已经打开的连接还可以避免慢启动的拥塞适应阶段，以便更快速地进行数据的传输。

建立持续连接keep-alive

HTTP/1.0 keep-alive连接的客户端可以通过包含Connection: Keep-Alive首部请求将一条连接保持在打开状态。
HTTP/1.1客户端默认Keep-Alive是打开的

keep-alive参数

1. 参数timeout是在Keep-Alive响应首部发送的。它估计了服务器希望将连接保持在活跃状态的时间。这并不是一个承诺值。
2. 参数max是在Keep-Alive响应首部发送的。它估计了服务器还希望为多少个事务保持此连接的活跃状态。这并不是一个承诺值。

Keep-Alive连接的限制和规则

1. 发送了Connection: close请求首部之后，客户端就无法在那条连接上发送更多的请求了。
2. 只有响应报文的主体长度（Content-Length）确定或者可以确定响应报文什么时候能发送完（Transfer-Encoding），这样才能建立持续连接，否则不能
3. 每个持久连接都只适用于一跳传输。
4. 除非请求有副作用，否则如果请求在完成之前连接关闭了，浏览器会自动重新发送该请求
5. 一个用户客户端对任何服务器或代理最多只能维护两条持久连接，以防服务器过载

管道化连接

HTTP/1.1允许在持久连接上可选地使用请求管道。这是相对于keep-alive连接的又一性能优化。在响应到达之前，可以将多条请求放入队列。当第一条请求通过网络流向地球另一端的服务器时，第二条和第三条请求也可以开始发送了。在高时延网络条件下，这样做可以降低网络的环回时间，提高性能。

管道化的限制

1. 如果HTTP客户端无法确认连接是持久的，就不应该使用管道。
2. 必须按照与请求相同的顺序回送HTTP响应
3. HTTP客户端必须做好连接会在任意时刻关闭的准备，还要准备好重发所有未完成的管道化请求。如果客户端打开了一条持久连接，并立即发出了10条请求，服务器可能在只处理了，比方说，5条请求之后关闭连接。剩下的5条请求会失败，客户端必须能够应对这些过早关闭连接的情况，重新发出这些请求。
4. HTTP客户端不应该用管道化的方式发送会产生副作用的请求（比如POST）。出错的时候，管道化方式会阻碍客户端了解服务器执行的是一系列管道化请求中的哪一些。由于无法安全地重试POST这样的非幂等请求，所以出错时，就存在某些方法永远不会被执行的风险。

注意点和一些名词解释

http持续连接关闭时的一些问题

HTTP应用程序要做好正确处理非预期关闭的准备。如果在客户端执行事务的过程中，传输连接关闭了，那么，除非事务处理会带来一些副作用，否则客户端就应该重新打开连接，并重试一次。对管道化连接来说，这种情况更加严重一些。客户端可以将大量请求放入队列中排队，但源端服务器可以关闭连接，这样就会留下大量未处理的请求，需要重新调度。

事务副作用

副作用是很重要的问题。如果在发送出一些请求数据之后，收到返回结果之前，连接关闭了，客户端就无法百分之百地确定服务器端实际激活了多少事务。有些事务，比如GET一个静态的HTML页面，可以反复执行多次，也不会有什么变化。而其他一些事务，比如向一个在线书店POST一张订单，就不能重复执行，不然会有下多张订单的危险。

事务幂等性

如果一个事务，不管是执行一次还是很多次，得到的结果都相同，这个事务就是幂等的。实现者们可以认为GET、HEAD、PUT、DELETE、TRACE和OPTIONS方法都共享这一特性。客户端不应该以管道化方式传送非幂等请求（比如POST）。否则，传输连接的过早终止就会造成一些不确定的后果。