《HTTP权威指南》学习笔记（4）第4章连接管理（关键词：计算机网络/HTTP/连接管理）

第4章 连接管理

4.1 TCP连接

4.1.1 TCP的可靠数据管道

4.1.2 TCP流是分段的、由IP分组传送

4.1.3 保持TCP连接的正确运行

4.2 对TCP性能的考虑

4.2.1 HTTP事务的时延

4.2.2 性能聚焦区域

4.2.3 TCP 连接的握手时延

4.2.4 延迟确认

4.2.5 TCP慢启动

4.2.6 Nagle算法与TCP_NODELAY

4.2.7 TIME_WAIT累积与端口耗尽

4.3 HTTP连接的处理

4.3.1 常被误解的Connection首部

4.3.2 串行事务处理时延

4.4 并行连接

4.4.1 并行连接可能会提高页面的加载速度

4.4.2 并行连接不一定更快

4.4.3 并行连接可能让人“感觉”更快一些

4.5 持久链接

4.5.1 持久以及并行连接

4.5.2 HTTP/1.0+keep-alive连接

4.5.3 Keep-alive操作

4.5.4 Keep-alive选项

4.5.5 Keep-alive连接的限制和规则

4.5.6 Keep-alive和哑代理

1.Connection首部和盲中继

2.代理和逐跳首部

4.5.7 插入Proxy-Connection

4.5.8 HTTP/1.1持久连接

4.5.9 持久连接的限制和规则

4.6 管道化连接

4.7 关闭连接的奥秘

4.7.1 “任意”解除连接

4.7.2 Content-Length及截尾操作

4.7.3 连接关闭容限、重试以及幂等性

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

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

如果一个事务， 不管是执行一次还是很多次， 得到的结果都相同， 这个事务就是幂等的。 实现者们可以认为 GET、HEAD、 PUT、 DELETE、 TRACE 和 OPTIONS 方法都共享这一特性。 客户端不应该以管道化方式传送非幂等请求（比如 POST）。否则， 传输连接的过早终止就会造成一些不确定的后果。 要发送一条非幂等请求，就需要等待来自前一条请求的响应状态。尽管用户 Agent 代理可能会让操作员来选择是否对请求进行重试， 但一定不能自动重试非幂等方法或序列。 比如， 大多数浏览器都会在重载一个缓存的 POST 响应时提供一个对话框， 询问用户是否希望再次发起事务处理。

4.7.4 正常关闭连接

1.完全关闭与半关闭

2.TCP关闭及重置错误

3.正常关闭

4.8 更多信息

4.8.1 HTTP连接

4.8.2 HTTP性能问题

4.8.3 TCP/IP

参考文献：
1.《HTTP权威指南》。