《HTTP权威指南》-第4章连接管理

4.1 TCP连接

4.1.1 TCP的可靠数据管道

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

4.1.3 保持TCP连接的正确运行

承载TCP 段的IP 分组，它承戴了TCP 数据流中的小块数据：

4.1.4 用TCP套接字编程

TCP 客户端和服务器是如何通过TCP 套接字接口进行通信的

4.2 对TCP性能的考虑

4.2.1 HTTP事务的时延

4.2.2 性能聚焦区域

TCP 连接建立握手；
TCP 慢启动拥塞控制；
数据聚集的Nagle 算法；
用于捎带确认的TCP 延迟确认算法，TIME_WAIT 时延和端口耗尽。

4.2.3 TCP连接的握手时延

4.2.4 延迟确认

延迟确认算越会在一个特定的窗口时间（通常是1 00 ～ 200 毫秒）内将输出确认存放在缓冲区中，以寻找能够捎带它的输出数据分组。如果在那
个时间段内没有输出数据分组，就将确认信息放在单独的分组中传送。

4.2.5 TCP慢启动

4.2.6 Nagle算法与TCP_NODELAY

HTTP 应用程序常常会在自己的枝中设置参数TCP_NODELA Y ，禁用Nagle 算法，
提高性能。如果要这么傲的话，一定要确保会向TCP 写入大块的数据，这样就不会产生一堆小分组了。

4.2.7 TIME_WAIT累积与端口耗尽

4.3 HTTP连接的处理

4.3.1 常被误解的connection首部

connection 首部可以承载3 种不同类型的标签，因此有时会很令人费解：

HTTP 首部字段名，列出了只与此连接有关的首。
任意标签值，用于描述此连接的非标准选项。
值close ，说明操作完成之后需关闭这条持久连接。

HTTP 应用程序收到一条带有Connection 首部的报文肘，接收端会解析发送端请求的所有选项，并将其应用。然后会在将此报文转发给下一跳地址之前，删除connection 首部以及 Connection 中列出的所有首部。而且，可能还会有少量没有作为connection 首都值列出，但一定不能被代理转发的逐跳首部。其中包括Prxoy- Authenticate 、Proxy- Connection、Transfer-Encoding 和Upgrade.

4.3 .2 串行事务处理时延

4个事务串行：

并行连接
通过多条TCP 连接发起并发的HTTP 请求。
持久连接
重用TCP 连接，以消除连接及关闭时延。
管道化连接
通过共享的TCP 连接发起并发的HTTP 请求。

4.4 并行连接

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

4.4.2 并行连接不一定更快

浏览器确实使用了并行连接，但它们会将并行连接的总数限制为一个较小的值（通常是4 个）。服务器可以随意关闭来自特定客户端的超量连接。

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

4.5 持久连接

4.5.1 持久以及并行连接

4.5.2 HTTP/1.0+ keep-alive连接

4.5.3 Keep - Alive操作

实现HTTP/1 .0 keep-alive 连接的客户端可以通过包含connecti。n: Keep-Alive 首部请求将一条连接保持在打开状态。
如果晌应中没有c。nnection: Keep-Alive 首部，客户端就认为服务器不支持keep-alive ，会在发回响应报文之后关闭连接。

4.5.5 Keep - Alive选项

参数timeout 是在Keep - Alive 响应首部发迭的。它估计了服务器希望将连接保持在活跃状态的时间。这并不是一个承诺值。
参数max 是在Keep - Alive 响应首部发迭的。它估计了服务器还希望为多少个事务保持此连接的活跃状态。这并不是一个承诺值。
Keep-Alive 首部还可支持任意未经处理的属性，这些属性主要用于诊断和调试。语法为name [=value ］。

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

4 .5.6 Keep-Alive和哑代理

Connection首部和盲中继
问题出在代理上一一尤其是那些不理解c。nnection 首部，而且不知道在沿着转发链路将其发迭出去之前，应该将该首部删除的代理。很多老的或简单的代理都是盲中继（ blind relay），它们只是将字节从一个连接转发到另一个连接中去，不对Connection 首部进行特殊的处理。
代理和逐跳首部
为避免此类代理通信问题的发生，现代的代理都绝不能转发Connection 首部
和所有名字出现在connection 值中的首部。因此，如果一个代理收到了一个
connection: Keep-Alive 首部，是不应该转发Connection 首部，或所有名为
Keep-Alive 的首部的。
另外，还有几个不能作为Connection 首部值列出，也不能被代理转发或作为缓存响应使用的首部。其中包括Proxy - Authenticate 、Proxy - Connection 、Transfer - Encoding 和Upgrade。

4.5.7 插入Proxy-Connection

在网景的变通做法是，浏览器会向代理发送非标准的Proxy-connection 扩展首部，而不是官方支持的著名的connection 首部。如果代理是盲中继，它会将无意义的Proxy-Connection 首部转发给Web 服务器，服务器会忽略此首部，不会带来任何问题。但如果代理是个聪明的代理（能够理解持久连接的握手动作），就用一个connect ion 首部取代无意义的Proxy-Connection 首部，然后将其发送给服务器，以收到预期的效果。

4.5.8 HTTP/1.1 持久连接

HTTP/1.1 逐渐停止了对keep-alive 连接的支持，用一种名为持久连接（ persistent connection ）的改进型设计取代了它。
与HTTP/1.0＋的keep-alive 连接不同， HTTP/1.1 持久连接在默认情况下是激活
的。除非特别指明，否则HTTP/1.1 假定所有连接都是持久的。要在事务处理结束之后将连接关闭， HTTP/1.1 应用程序必须向报文中显式地添加一个Connection: close 首部。

4.5.9 持久连接的限制和规则

4.6 管道化连接

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

4.7 关闭连接的奥秘

4.7.1 “任意” 解除连接

4.7.2 content - Length及截尾操作

每条HTTP 响应都应该有精确的Content - Length 首部，用以描述响应主体的尺寸。一些老的HTTP 服务据会省略content-Length 首部，或者包含错误的长度指示，这样就要依赖服务器发出的连接关闭来说明数据的真实末尾。

客户端或代理收到一条随连接关闭而结束的HTTP响应，且实际传输的实体长度与content-Length 并不匹配（或没有content-Length）时，接收端就应该质疑长度的正确性。

如果接收端是个缓存代理，接收端就不应该缓存这条响应（以降低今后将潜在的错误报文混合起来的可能）。代理应该将有问题的报文原封不动地转发出去，而不应该试图去“校正” content - Length ，以维护语义的透明性。

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

如果一个事务，不管是执行一次还是很多次，得到的结果都相同，这个事务就是幂等的。

客户端不应该以管道化方式传送非幂等请求（比如POST)。否则，传输连接的过早终止就会造成一些不确定的后果。要发送一条非事等请求，就需要等待来自前一条请求的响应状态。

4.7.4 正常关闭连接

完全关闭与半关闭
TCP关闭及重置错误
正常关闭