Page 185 - Web性能权威指南

会话。多少个？现实中，大多数现代浏览器，包括桌面和移动浏览器，都支持每个
主机打开 6 个连接。

进一步讨论之前，有必要先想一想同时打开多个 TCP 连接意味着什么。当然，有正
面的也有负面的。下面我们以每个主机打开最多 6 个独立连接为例：

• 客户端可以并行分派最多 6 个请求；
• 服务器可以并行处理最多 6 个请求；
• 第一次往返可以发送的累计分组数量（TCP cwnd）增长为原来的 6 倍。

在没有管道的情况下，最大的请求数与打开的连接数相同。相应地，TCP 拥塞窗口
也要乘以打开的连接数量，从而允许客户端绕开由 TCP 慢启动规定的分组限制。这
好像是一个方便的解决方案。我们再看看这样做的代价：

• 更多的套接字会占用客户端、服务器以及代理的资源，包括内存缓冲区和 CPU
时钟周期；
• 并行 TCP 流之间竞争共享的带宽；
• 由于处理多个套接字，实现复杂性更高；
• 即使并行 TCP 流，应用的并行能力也受限制。

实践中，CPU 和内存占用并非微不足道，由此会导致客户端和服务器端的资源占用
量上升，运维成本提高。类似地，由于客户端实现的复杂性提高，开发成本也会提
高。最后，说到应用的并行性，这种方式提供的好处还是非常有限的。这不是一个
长期的方案。了解这些之后，可以说今天之所以使用它，主要有三个原因：

(1) 作为绕过应用协议（HTTP）限制的一个权宜之计；
(2) 作为绕过 TCP 中低起始拥塞窗口的一个权宜之计；
(3) 作为让客户端绕过不能使用 TCP 窗口缩放的一个权宜之计（参见 2.3 节“带宽
延迟积”）。

后两个针对 TCP 的问题（窗口缩放和 cwnd）最好是通过升级到最新的 OS 内核来
解决，参见 2.5 节“针对 TCP 的优化建议”。cwnd 值最近又提高到了 10 个分组，
而所有最新的平台都能可靠地支持 TCP 窗口缩放。这当然是好消息。但坏消息是，
没有更好办法绕开 HTTP 1.x 的多路复用问题。

只要必须支持 HTTP 1.x 客户端，就不得不想办法应对多 TCP 流的问题。而这又会
带来一个明显的问题：为什么浏览器要规定每个主机 6 个连接呢？恐怕有读者也猜
到了，这个数字是多方平衡的结果：这个数字越大，客户端和服务器的资源占用越
多，但随之也会带来更高的请求并行能力。每个主机 6 个连接只不过是大家都觉得

170 ｜ 第 11 章