Page 204 - Web性能权威指南

上述每一点都可能对 HTTP 2.0 连接的吞吐量和延迟性能造成不利影响。然而，
除了这些局限性之外，实验表明一个 TCP 连接仍然是 HTTP 2.0 基础上的最佳
部署策略：
目前为止的测试表明，压缩和优先级排定带来的性能提升，已经超过了
队首阻塞（特别是丢包情况下）造成的负面效果。
——HTTP/2.0
Draft 2
与所有性能优化过程一样，去掉一个性能瓶颈，又会带来新的瓶颈。对 HTTP
2.0 而言，TCP 很可能就是下一个性能瓶颈。这也是为什么服务器端 TCP 配置对
HTTP 2.0 至关重要的一个原因。
目前，针对 TCP 性能优化的研究还在进行中：TCP 快速打开、比例降速、增大的
初始拥塞窗口，等等不一而足。总之，一定要知道 HTTP 2.0 与之前的版本一样，
并不强制使用 TCP。UDP 等其他传输协议也并非不可以。

12.3.6 流量控制

在同一个 TCP 连接上传输多个数据流，就意味着要共享带宽。标定数据流的优先级
有助于按序交付，但只有优先级还不足以确定多个数据流或多个连接间的资源分配。
为解决这个问题，HTTP 2.0 为数据流和连接的流量控制提供了一个简单的机制：

• 流量控制基于每一跳进行，而非端到端的控制；
• 流量控制基于窗口更新帧进行，即接收方广播自己准备接收某个数据流的多少字
节，以及对整个连接要接收多少字节；
• 流量控制窗口大小通过 WINDOW_UPDATE 帧更新，这个字段指定了流 ID 和窗口大小
递增值；
• 流量控制有方向性，即接收方可能根据自己的情况为每个流乃至整个连接设置任
意窗口大小；
• 流量控制可以由接收方禁用，包括针对个别的流和针对整个连接。

HTTP 2.0 连接建立之后，客户端与服务器交换 SETTINGS 帧，目的是设置
双向的流量控制窗口大小。除此之外，任何一端都可以选择禁用个别流或
整个连接的流量控制。

上面这个列表是不是让你想起了 TCP 流量控制？应该是，这两个机制实际上是一样
的，参见 2.2.1 节“流量控制”。然而，由于 TCP 流量控制不能对同一条 HTTP 2.0
连接内的多个流实施差异化策略，因此光有它自己是不够的。这正是 HTTP 2.0 流

HTTP 2.0 ｜ 189