Page 207 - Web性能权威指南

• 应用可以在自身的代码中明确发起服务器推送。这种情况要求与 HTTP 2.0 紧密
耦合，但开发人员有控制权。
• 应用可以通过额外的 HTTP 首部向服务器发送信号，列出它希望推送的资源。这
样可以将应用与 HTTP 服务器 API 分离。比如 Apache 的 mod_spdy 能够识别
X-Associated-Content 首部，这个首部中列出了希望服务器推送的资源。
• 服务器可以不依赖应用而自动学习相关资源。服务器可以解析文档，推断出要
推送的资源，或者可以分析流量，然后作出适当的决定。比如服务器可以根据
Referer 首部收集依赖数据，然后自动向客户端推送关键资源。

当然，以上只是各种可能策略中的几个，但由此也可以知道可能性是很多的：可能
是手工调用低级 API，也可能是一种全自动的实现。类似地，服务器应不应该重复
推送相同的资源，还是应该实现一个更智能的策略？服务器可以根据自身的模型、
客户端 cookie 或其他机制，智能推断出客户端缓存中有什么资源，然后再作出推送
决定。简言之，服务器推送领域将爆出各种创新。

最后还有一点，就是推送的资源将直接进入客户端缓存，就像客户端请求了似的。
不存在客户端 API 或 JavaScript 回调方法等通知机制，可以用于确定资源何时到达。
整个过程对运行在浏览器中的 Web 应用来说好像根本不存在。

12.3.8 首部压缩

HTTP 的每一次通信都会携带一组首部，用于描述传输的资源及其属性。在 HTTP
1.x 中，这些元数据都是以纯文本形式发送的，通常会给每个请求增加 500~800 字
节的负荷。如果算上 HTTP cookie，增加的负荷通常会达到上千字节（参见 11.5 节
“度量和控制协议开销”）。为减少这些开销并提升性能，HTTP 2.0 会压缩首部元数
据：

• HTTP 2.0 在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键－值对，
对于相同的数据，不再通过每次请求和响应发送；
• 首部表在 HTTP 2.0 的连接存续期内始终存在，由客户端和服务器共同渐进地更新 ;
• 每个新的首部键－值对要么被追加到当前表的末尾，要么替换表中之前的值。

于是，HTTP 2.0 连接的两端都知道已经发送了哪些首部，这些首部的值是什么，从
而可以针对之前的数据只编码发送差异数据（图 12-5）。

192 ｜ 第 12 章