Page 209 - Web性能权威指南

然而，2012 年夏天，出现了针对 TLS 和 SPDY 压缩算法的“CRIME”安全攻击，
它可以利用首部压缩拦截会话。于是，zlib 压缩算法被撤销，取而代之的是前面
介绍的新索引表算法。索引表算法没有类似的安全问题，但可以实现相差无几的
性能提升。
要全面了解 HTTP 2.0 压缩算法，请看这里：http://tools.ietf.org/html/draft-ietf-httpbis-
header-compression。

12.3.9 有效的HTTP 2.0升级与发现

向 HTTP 2.0 的迁移不可能一蹴而就。数百万台服务器必须升级才能使用新的二进
制分帧，还有数十亿客户端必须更新浏览器和网络库。

好消息是，大多数现代浏览器都内置有高效的后台升级机制，因而对相当大一部分
既有用户来说，这些浏览器能很快支持 HTTP 2.0，又不会带来太多干扰。尽管如
此，还是有一部分用户只能使用旧版本的浏览器，而服务器和中间设备也必须升级
支持 HTTP 2.0，这需要一个比较长的时期，而且是一个费力、费钱的过程。

HTTP 1.x 至少还会存在十年以上，大多数服务器和客户端在此期间必须同时支持
1.x 和 2.0 标准。于是，支持 HTTP 2.0 的客户端在发起新请求之前，必须能发现服
务器及所有中间设备是否支持 HTTP 2.0 协议。有三种可能的情况：

• 通过 TLS 和 ALPN 发起新的 HTTPS 连接；
• 根据之前的信息发起新的 HTTP 连接；
• 没有之前的信息而发起新的 HTTP 连接。

HTTPS 协商过程中有一个环节会使用 ALPN（Application Layer Protocol Negotiation）
发现和协商 HTTP 2.0 的支持情况 [ 参见 4.2.1 节“应用层协议协商（ALPN）”]。减
少网络延迟是 HTTP 2.0 的关键条件，因此在建立 HTTPS 连接时一定会用到 ALPN
协商。

通过常规非加密信道建立 HTTP 2.0 连接需要多做一点工作。因为 HTTP 1.0 和
HTTP 2.0 都使用同一个端口（80），又没有服务器是否支持 HTTP 2.0 的其他任何信
息，此时客户端只能使用 HTTP Upgrade 机制通过协调确定适当的协议：

GET /page HTTP/1.1
Host: server.example.com
Connection: Upgrade, HTTP2-Settings
Upgrade: HTTP/2.0 ➊
HTTP2-Settings: (SETTINGS payload) ➋

194 ｜ 第 12 章