Page 228 - Web性能权威指南

类似地，不同的服务器可能提供利用服务器推送的不同机制和策略（参见 12.3.7 节
中的“实现 HTTP 2.0 服务器推送”）。如果说你的应用性能与 HTTP 2.0 服务器的质
量紧密相关，是一点也不夸张的。

鉴于 HTTP 2.0 和 SPDY 的迅速发展，不同服务器（Apache、Nginx、Jetty
等）对 HTTP 2.0 的实现还处于不同的阶段。要了解它们当前支持的功能
和最新消息，请查阅相应的文档和发版说明。

13.3.5 2.0与TLS

实践中，由于存在很多不兼容的中间代理，早期的 HTTP 2.0 部署必然依赖加密信
道。这样一来，我们就面临两种可能出现 ALPN 协商和 TLS 终止的情况：

• TLS 连接可能会在 HTTP 2.0 服务器上终止；
• TLS 连接可能会在上游（如负载均衡器）上终止。

第一种情况要求 HTTP 2.0 服务器能够处理 TLS，除此之外就没有什么了。第二种
情况复杂一些：TLS+ALPN 握手可能会在上游代理处终止（图 13-3），然后再从那
里建立一条加密信道，或者直接将非加密的 HTTP 2.0 流发送到服务器。

HTTP 2.xޜခഗ

TLSዕኹLj
پ૙+޶ሜ਩࢚ഗ HTTP 1.xޜခഗ

图 13-3：支持 TLS+ALPN 的负载均衡器

代理和应用服务器之间使用安全信道还是非加密信道，取决于应用：只要能控制
中间设备，就可以保证未加密的帧不会被修改或丢弃。那么，虽然大多数 HTTP
2.0 服务器都应该支持 TLS+ALPN 协商，但它们同时也应该在不加密的情况下实现
HTTP 2.0 通信。

另外，智能负载均衡器也可以使用 TLS+ALPN 协商机制，根据协商后的协议，选择
性地将不同的客户端路由到不同的服务器。

214 ｜ 第 13 章