Page 210 - Web性能权威指南

HTTP/1.1 200 OK ➌
Content-length: 243
Content-type: text/html
(... HTTP 1.1 response ...)

(or)

HTTP/1.1 101 Switching Protocols ➍
Connection: Upgrade
Upgrade: HTTP/2.0

(... HTTP 2.0 response ...)
➊ 发起带有 HTTP 2.0 Upgrade 首部的 HTTP 1.1 请求
➋ HTTP/2.0 SETTINGS 净荷的 Base64 URL 编码
➌ 服务器拒绝升级，通过 HTTP 1.1 返回响应
➍ 服务器接受 HTTP 2.0 升级，切换到新分帧

使用这种 Upgrade 流，如果服务器不支持 HTTP 2.0，就立即返回 HTTP 1.1 响应。
否则，服务器就会以 HTTP 1.1 格式返回 101 Switching Protocols 响应，然后立即
切换到 HTTP 2.0 并使用新的二进制分帧协议返回响应。无论哪种情况，都不需要
额外往返。

为确定服务器和客户端都有意使用 HTTP 2.0 对话，双方还必须发送“连接
首部”，也就是一串标准的字节。这种信息交换本质上是一种“尽早失败”
（fail-fast）的机制，可以避免客户端、服务器，以及中间设备偶尔接受请
求的升级却不理解新协议。而且，这种信息交换也不会带来额外的往返，
只是在连接开始时要多传一些字节。

最后，如果客户端因为自己保存有或通过其他手段（如 DNS 记录、手工配置等）获
得了关于 HTTP 2.0 的支持信息，它也可以直接发送 HTTP 2.0 分帧，而不必依赖
Upgrade 机制。有了这些信息，客户端可以一上来就通过非加密信道发送 HTTP 2.0
分帧，其他就不管了。最坏的情况，就是无法建立连接，客户端再回退一步，重新
使用 Upgrade 首部，或者切换到带 ALPN 协商的 TLS 信道。

部署 HTTP 2.0 的同时部署 TLS 和 ALPN

服务器之前的 HTTP 2.0 支持信息并不能保证下一次就能可靠地建立连接。以这种
方式通信的前提，就是各端都必须支持 HTTP 2.0。如果任何中间设备不支持，连
接都不会成功。

HTTP 2.0 ｜ 195