Page 227 - Web性能权威指南

大多数支持 HTTP 2.0 的 Web 服务器默认都提供 2.0 到 1.x 的转换机制：
2.0 会话终止于服务器（Apache 或 Nginx），如果服务器被配置为反向代
理，那么分派给具体应用服务器的就是 1.x 请求。

然而，2.0 到 1.x 的这种简单策略并非长久之计。从很多方面来说，这种工作流实
际是一种倒退。真正正确的做法，不是把优化的、可复用的会话转换成一系列 1.x
请求，因基础设施而废优化，而是相反：把接收到的 1.x 客户端请求转换成 2.0 流，
并把我们的基础设施标准化，使其在任何时候都处理 2.0 会话。

为获得最佳性能，同时实现低延迟和实时的 Web 应用，应该要求我们的内部基础设
施达到如下标准：

• 负载均衡器和代理与应用的连接应该持久化；
• 请求和响应流及多路复用应该是默认配置；
• 与应用服务器的通信应该基于消息；
• 客户端与应用服务器的通信应该是双向的。

端到端的 HTTP 2.0 会话符合上述所有条件，能实现对客户端以及数据中心内部的
低延迟交付：无需定制的 RPC 层及相应机制，就能实现内部服务之间的通信，并
获得理想的性能。简言之，不要把 2.0 降级到 1.x，这不是长久之计。长久之计是把
1.x 升级到 2.0，这样才能求得最佳性能。

13.3.4 评估服务器质量与性能

HTTP 2.0 服务器实现的质量对客户端性能影响很大。HTTP 服务器的配置当然是一
个重要因素，但服务器实现逻辑的质量同样与优先级、服务器推送、多路复用等性
能机制的发挥紧密相关。

• HTTP 2.0 服务器必须理解流优先级；
• HTTP 2.0 服务器必须根据优先级处理响应和交付资源；
• HTTP 2.0 服务器必须支持服务器推送；
• HTTP 2.0 服务器应该提供不同推送策略的实现。

HTTP 2.0 服务器的初级实现也能支持某些功能，但不能明确支持请求的优先级和服
务器推送，可能导致次优性能。比如，发送大型、静态图片导致带宽饱和，而客户
端又因为其他重要资源（如 CSS 或 JavaScript）被阻塞。

为尽可能获得最佳性能，HTTP 2.0 客户端必须是个“乐观主义者”：尽可
能早地发送所有请求，然后完全听凭服务器的优化。事实上，HTTP 2.0 客
户端对服务器的依赖程度较之以前更甚。

优化应用的交付 ｜ 213