HTTP连接管理

整理自《HTTP权威指南》及网络

TCP 连接

大多数HTTP报文是基于TCP连接的。

假设我们有Web服务器www.windeal.com， 该服务器端口号为80， 有资源index.html。 我们可以通过URLwww.windeal.com:80/index.html 访问该资源。

此时，Web浏览器和Web服务器进行一下动作：

1. 从URL中解析出 主机名

www.windeal.com

， 端口号

80

， 资源URL

index.html

2. 通过DNS域名解析，将

www.windeal.com

解析为IP地址。

3. 根据服务器IP地址和端口号与服务器建立TCP连接

4. 浏览器想Web服务器发送GET请求。

5. Web服务器根据请求的URL，回复响应报文

6. 关闭TCP连接。

关于TCP连接的细节，此处不做讨论， 我们主要关系HTTP协议栈。

HTTPS协议是进行了加密了HTTP协议，在HTTP层和TCP层之间增加了安全层 TSL/SSL

对TCP性能的考虑

一个Web浏览器的忧虑不仅在于其功能的强大与否， 也在于其性能。

由于HTTP事务的大部分工作都在TCP连接中实现，因此HTTP事务的性能主要取决于其所依赖的TCP连接的性能。

前面我们已经了解了一次HTTP通信的主要步骤： DNS解析、TCP连接、HTTP请求、请求处理、HTTP响应、关闭连接。 这里，我们不考虑关闭连接导致的时延（因为既然要关闭了，考虑时延意义不大）；其他几个步骤都会导致HTTP事务的时延。

+ DNS解析： 在没有缓存的情况下，将一个URI中共的主机名转换为IP地址可能需要几十秒的时间。

+ TCP连接： TCP连接的三次握手会花费一定的时间。

+ HTTP请求： Web客户端（浏览器）发送HTTP请求到Web服务器收到并读取请求报文都需要话费一定时间。

+ 请求处理： Web服务器处理接收到的HTTP请求报文需要话费一定时间

+ HTTP响应： Web服务器发送HTTP响应报文也需要时间。

以上网络时间取决于多种因素： 硬件设施、网络和服务器负载、报文尺寸等等。

缩小HTTP事务时延

缩小TCP连接的握手时延：

建立一条TCP连接、TCP连接在发送任何数据，都需要交换一些IP分组进行参数的沟通。 进行IP分组交换是需要话费时间的，因此我们应该尽量减少IP分组的交换。也就是说，TCP连接不应该值传送少量的数据，而应该一次传送更多的数据，以减少IP分组交换的次数，进而缩小握手时延。

下面是两个充分利用TCP连接一次传送更多数据的例子：

1. 将HTTP请求报文包含在TCP三次握手的ACK报文中。

2. 将HTTP响应报文尽可能放在一个IP分组中去。

TCP的慢启动

TCP连接在启动初期会自动调节数据的传输速度。从一个比较慢的速度开始传输数据，如果成功则慢慢提升传输速度，直到调整到一个合适的速度。

TCP的慢启动可以防止网络过载和阻塞。

Nagle算法与TCP_NODELAY

每个TCP段至少装载40bytes的首部，如果TCP负载的大小相对于TCP整个报文的大小占比越小说明这个TCP段的利用率越低。为提升HTTP事务的性能，应提升TCP段的利用率。

Nagle算法鼓励发送全尺寸（LAN上大约是1500bytes， 因特网上只是为512Bytes）的段。Nagle需要在其他（全尺寸的分组都被确认之后才允许发送最后剩下的非全尺寸的分组）

Nagle算法会引发一些问题： 一些小的HTTP报文可能无法填满一个分组，需要等待一定时延。

TCP_NODELAY： 用于禁用Nagle算法，此时我们需要自己确保向TCP写入大块的数据。

TIME_WAIT和端口耗尽

TIME_WAIT用于防止端口重用，每个客户端连接到Web服务器时，都会获得一个源端口。 但禁止端口重用又会导致端口耗尽的问题。

HTTP连接的处理

Connection 首部

一个从客户端到服务器的HTTP连接可能会经过一些中间设备， 相邻的中间设备的HTTP程序之间可能需要沟通一些选项，这些选项不需要传递到其他的设备上去。此时我们可以通过Connection首部字段中的标签列表来制定不传播到其他HTTP连接中去的选项。

connection首部字段可以接收三种不同的标签：

+ 首部字段名：列出只与本连接有关的首部字段。

+ 任意标签值： 用于描述此连接的非标准选项

+ close： 操作完成后，关闭此连接。

串行事务处理时延

串行处理HTTP事务可能会增加时延。

如客户端请求一个带有多个嵌入式图片的页面，如果串行依次建立连接来获取这些对象则大大增加了网络时延。

以下几种方法可以用于规避串行事务处理时延。

+ 并行连接：通过多条TCP连接发起HTTP请求。

+ 持久连接：重用TCP连接，以消除连接及关闭时延

+ 管道化连接：通过共享的TCP连接发起并发的HTTP请求。

并行连接

HTTP允许客户打开多条连接，并行地执行多个HTTP事务。

并行连接能够克服单挑连接的空载时间 和 带宽限制，从而提高网络加载速度。

并行连接并不总是更快： 当（Modem）的网络带宽较小（单条连接已经满负荷运行）时、建立多条连接可能会增加连接之间的资源竞争，增加内存消耗，这样反而会增加HTTP事务时延。

并行连接一般能让人感觉更快一下

持久连接

并行连接有以下缺点：

+ 每个事务都打开、关闭一条新的连接， 这回消耗时间和带宽。

+ 由于TCP慢启动的特性，每条新连接的性能都会有所降低

+ 可以打开i的并行连接数量是有限的。

为解决这些问题，持久连接出现了。

HTTP/1.0 开始尝试支持持久连接keep-alive，持久连接在HTTP/1.1初始版本中修正了一些问题。

keep-alive在最新HTTP/1.1规范中已经被删除了，不应在使用。 但因为它已经被广泛应用与各种浏览器和服务器，因此在设计HTTP程序时，还是应该尽可能对其兼容。

实现HTTP/1.0 keep-alive连接的客户端可以通过包含

Connection: Keep-alive

首部请求将一条连接保持在打开状态。然而HTTP连接的另一端不一定会同意进行keep-alive会话，它们可能在任意时刻关闭空闲的keep-alive。 可以用

keep-alive

首部中*指定的、有逗号分隔的选项）来调节keep-alive的行为，因而我们可以看到如下首部：

Connection: Keep-Alive
Keep-Alive: max=5, timeout=120;

max表示希望为多少个事务保持连接的活跃状态，timeout表示希望将此连接保持活跃状态的时间。

管道化连接

HTTP/1.1允许在持久连接上可选第使用请求管道，对keep-alive连接进一步优化。在响应到达之前，可以煎更多条请求放入队列，当第一条请求通过网络流向服务器时，第二条和第三条请求也开始发送。