第一部分 HTTP：Web的基础——第4章 连接管理

本章的知识点：

• HTTP是如何使用TCP连接的；
• TCP连接的时延、瓶颈以及存在的障碍；
• HTTP的优化，包括并行连接、keep-alive（持久连接）和管道化连接；
• 管理连接时应该以及不应该做的事情。

4.1 TCP连接

世界上几乎所有的HTTP通信都是 由TCP/IP承载的，TCP/IP是全球计算机及网络设备都在使用的一种常用的分组交换分层协议集。

4.1.1 TCP的可靠数据管道

HTTP连接实际上就是TCP连接及其使用规则。TCP连接是因特网上的可靠连接。

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

TCP的数据是通过IP分组（或IP数据报）的小数据块来发送的。HTTP就是“HTTP over TCP over IP”这个“协议栈”中的最顶层了。其安全版本HTTPS就是在HTTP和TCP之间插入了一个（TLS或SSL的）密码加密层。

HTTP要传送一条报文，会以流的形式将报文数据的内容通过一条打开的TCP连接按序传输。TCP收到数据流之后，会将数据流砍成被称作段的小数据块，并将段封装在IP分组中，通过因特网进行传输。所有这些工作都是由TCP/IP软件来处理的，HTTP程序员什么都看不到。
每个TCP段都是由IP分组承载，从一个IP地址发送到另一个IP地址的。每个IP分组中都包括：

• 一个IP分组首部（通常为20字节）
• 一个TCP段首部（通常为20字节）
• 一个TCP数据块（0个或多个字节）

4.1.3 保持TCP连接持续不断地运行

TCP是通过端口号来保持所有这些连接不断地运行。
<源IP地址、源端口号、目的IP地址、目的端口号>

4.2 对TCP性能的考虑

4.2.1 HTTP事务的时延

与建立TCP连接，以及传输请求和响应的报文的时间相比，事务处理时间可能是很短的。除非客户端或服务器超载，或正在处理复杂的动态资源，否则HTTP时延就是由TCP网络时延构成的。

HTTP事务的时延的主要原因：

1. 客户端首先需要根据URI确定Web服务器的IP地址和端口号。如果最近没有对URI中的主机名进行访问，通过DNS解析系统将URI中的主机转换成一个IP地址可能需要花费数十秒的时间。
2. 接下来，客户端会向服务器发送一条TCP连接请求，并等待服务器回送一个请求接受应答。每条新的TCP连接都会有连接建立时延。这个值通常最多只有一两秒钟，但如果有数百个HTTP事务的话，这个值会快速地叠加上去。
3. 一旦连接建立起来了，客户端就会通过新建立的TCP管道来发送HTTP请求。数据一旦到达时，Web服务器会从TCP连接中读取请求报文，并对请求进行处理。因特网传输请求报文，以及服务器处理请求报文都需要时间。
4. 然后，Web服务器会回送HTTP响应，这也需要花费时间。

TCP网络时延的大小取决于硬件速度、网络和服务器的负载，请求和响应报文的尺寸，以及客户端和服务器之间的距离。TCP协议的技术复杂性也会对时延产生巨大的影响。

4.2.1 HTTP事务的时延

常见的TCP相关时延：

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

4.2.3 TCP连接的握手时延

TCP连接握手需要经过以下几个步骤。

1. 请求新的TCP连接时，客户端要向服务器发送一个小的TCP分组（通常是40-60个字节）。这个分组中设置了一个特殊的SYN标记，说明这是一个连接请求。（参见图4-8a）
2. 如果服务器接受了连接，就会对一些连接参数进行计算，并向客户端回送一个TCP分组，这个分组中的SYN和ACK标记都被置位，说明连接请求已被接受。（参见图4-8b）
3. 客户端向服务器回送一条确认消息，通知它连接已成功建立（参见图4-8c）。现代的TCP栈都允许客户端在这个确认分组中发送数据。

4.2.5 TCP慢启动

TCP数据传输的性能还取决于TCP连接的使用期（age）。TCP连接会随着时间进行自我“调谐”，起初会限制连接的最大速度，如果数据成功传输，会随着时间的推移提高传输的速度。这种调协被称为TCP慢启动（slow start），用于防止因特网的突然过载和拥塞。

4.2.6 Nagle算法与TCP_NODELAY

Nagle算法试图在发送一个分组之前，将大量TCP数据绑定在一起，以提高网络效率。

Nagle算法引发的几种HTTP性能问题：

1. 小的报文可能无法填满一个分组，可能会因为等待那些永远不会到来的额外数据而产生时延续。
2. Nagle算法与延迟确认之间的交互存在问题——Nagle算法会阻止数据的发送，直到有确认分组抵达为止，但确认分组自身会被延迟确认算法延迟100～200毫秒。

4.2.7 TIME_WAIT累积与端口耗尽

当某个TCP端点关闭TCP连接时，会在内存中维护一个小的控制块，用来记录最近所关闭连接的IP地址和端口号。这类信息只会维持一小段时间，通常是所估计的最大分段使用期的两倍（通常为2分钟）左右，以确保在这段时间内不会创建具有相同地址和端口号的新连接。
算法可以防止在两分钟内创建、关闭并重新创建两个具有相同IP地址和端口的连接。

4.3 HTTP连接的处理

Connection首部可以承载3种不同类型的标签：

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

逐跳首部概念：此类别的首部只对单次转发有效，经过缓存或代理时，将会失效。

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

提高HTTP连接性能的几种方法：

1. 并行连接——通过多条TCP连接发起并发的HTTP请求
2. 持久连接——重用TCP连接，以消除连接及关闭时延
3. 管道化连接——通过共享的TCP连接发起并发的HTTP请求
4. 复用的连接——交替传送请求和响应报文

4.4 并行连接

4.4.1 并行连接不一定更快

客户端的网络带宽不足时，大部分的时间可能都是用来传数据的。在这种情况下，一个连接到速度较快服务器上的HTTP事务就会很容易地耗尽所有可用的Modem带宽。如果并行加载多个对象，每个对象都会去竞争这有限的带宽，每个对象都会以较慢的速度按比例加载，这样带来的性能提升就很小，甚至没什么提升。

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

4.5 持久连接

在事务处理结束之后仍然保持打开状态的TCP连接称为持久连接。非持久连接会在每个事务结束之后关闭。持久连接会在不同事务之间保持打开状态，直到客户端或服务器决定将其关闭为止。

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

4.5.1 并行连接的缺点

• 每个事务都会打开/关闭一条新的连接，会耗费时间和带宽
• 由于TCP慢启动特性的存在，每条新连接的性能都会有所降低
• 可打开的并行连接数量实际上是有限的

4.5.2 持久连接的优势

持久连接降低了时延和连接建立的开销，将连接保持在已调谐状态，而且减少了打开连接的潜在数量。

4.5.3 持久连接的类型

1. 比较老的HTTP/1.0+“keep-alive”连接
2. 现代的HTTP/1.1“persistent”连接

Keep-Alive首部只是请求将连接保持在活跃状态。发出keep-alive请求之后，客户端和服务器并不一定会同意进行keep-alive会话。它们可以在任意时刻关闭空闲的keep-alive连接，并随意限制keep-alive连接所处理事务的数量。

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

上面的例子说明服务器最多还会为另外5个事务保持连接的打开状态，或者将打开状态保持到连接空闲了2分钟之后。

逐跳首部：
按是否缓存代理的行为划分：端到端首部（End to end Header）、逐跳首部（Hop by hop Header）

端到端首部：此类别的首部将转发给请求或响应的最终目标，经过代理时，也必须保存在由缓存生成的响应中，必须被转发。
逐跳首部：此类别的首部只对单次转发有效，经过缓存或代理时，将会失效。
参考博文

4.5.4 HTTP/1.1持久连接

HTTP/1.1客户端假定在收到响应后，除非响应中包含了Connection：close首部，不然HTTP/1.1连接就仍维持在打开状态。但是，客户端和服务器仍然可以随时关闭空闲的连接。不发送Connection：close并不意味着服务器承诺永远将连接保持在打开状态。

4.6 管道化连接

管道化连接的限制条件：

1. 如果HTTP客户端无法确认连接是持久的，就不应该使用管道
2. 必须按照与请求相同的顺序回送HTTP响应
3. HTTP客户端必须做好连接会在任意时刻关闭的准备，还要准备好重发所有未完成的管道化请求。
4. HTTP客户端不应该用管道化的方式发送会产生副作用的请求如post。

4.7 关闭连接