《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和哑代理

1. Connection首部和盲中继 
   问题出在代理上一一尤其是那些不理解c。nnection 首部，而且不知道在沿着转发链路将其发迭出去之前，应该将该首部删除的代理。很多老的或简单的代理都是盲中继（ blind relay），它们只是将字节从一个连接转发到另一个连接中去，不对Connection 首部进行特殊的处理。 
   

2. 代理和逐跳首部 
   为避免此类代理通信问题的发生，现代的代理都绝不能转发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 正常关闭连接

1. 完全关闭与半关闭

2. TCP关闭及重置错误 
   

3. 正常关闭