几个月前，我在《HTTP/2 中的 Server Push 讨论》这篇文章中写到：
Server Push 会在客户端请求页面 HTML 时，新建一个流将最重要的资源一并返回。同时，如果服务端要推送的资源浏览器已经缓存过，客户端会发送 RST_STREAM 帧来终止流，服务端收到这个信号之前所传输的数据就造成了带宽浪费。
简而言之，HTTP/2 中的 Server Push 技术使得服务端收到页面请求后，能够将页面所需资源（CSS、JS）通过
PUSH_PROMISE 帧推送给浏览器，从而减少延迟。但这带来一个问题：PUSH_PROMISE 帧和对应的 DATA
帧离开服务端的时机非常早，如果要推送的资源浏览器本地已经有了缓存，会导致流量的浪费。
HTTP/2 协议本身只有关于 Server Push 技术细节的描述，对于 Web 开发人员与 Web Server 之间使用何种方式约定要 Push 的资源；以及浪费流量的问题是否需要解决，如何解决，协议本身并未做出任何说明，这些都留给了 Web Server 开发者去考虑。我之前说过「这个问题可以通过在服务端记录给每个客户端发送过何种资源，何时过期来优化」，本文介绍 H2O 的解决方案。
H2O（官网、GitHub）是一个用 C 语言实现的轻量级 Web Server，它最近发布的 1.5.0 版，新增了一个名为 Cache-Aware Server-Push 的技术，直译过来意思是「可感知缓存的 Server Push」。原理是在首次 Server Push
完成后，在客户端存一个指纹，服务端后续检查到指纹存在时，先在指纹中查询要 Push 的资源，没查到才推送。
原理不复杂，跟如今大家广泛使用的「内联资源 localStorage 存储」方案类似，H2O 的指纹也是存在 Cookie 中，名为
h2o_casper，过期时间在 2030 年。
我们考虑一个问题，对于携带了 h2o_casper 指纹的请求，H2O 如何能知道哪些资源需要被推送，哪些不需要？Cookie
每个字节都很宝贵，不可能把每个资源的文件名及对应版本都装进去。如果 Cookie 中只存放用户标识，那又依赖于后端的 KV 查询服务，不符合 H2O
轻量、单一的理念。
实际上，这是一个经典的问题：在存储空间有限的情况下，如何判断一个元素是否存在于一个集合之内，且允许一定的误差（Server Push
属于锦上添花功能，没被推送的资源浏览器还会走常规流程获取）。这个问题正好可以用 Bloom Filter（布隆过滤器）算法解决，它能以很小的误差作为代价换取了存储空间的极大节省。有关 Bloom Filter
的详细原理请看这篇《Bloom Filter 概念和原理》。
H2O 使用了一种名为 Golomb-compressed sets 的算法，它与 Bloom Filter
非常类似，根据官方说明，它的压缩率比 Bloom Filter 高 20-30%。关于这个算法的详细介绍，请看我写的《Golomb-coded
sets 原理介绍》；对应的 JS 实现和 Demo，请点击这个页面查看。
H2O 将要推送的资源路径 + ETag 存入一个集合，采用 Golomb-compressed sets 算法生成指纹，并编码为 Base64
字符串存入 Cookie，之后就可以检查某个资源路径 + ETag 是否存在于 Cookie 指纹对应的集合之中。H2O 默认使用 13
位二进制来存放单个资源的指纹，单资源误判率为 1/8192。最终输出的 h2o_casper Cookie 大小等于单个指纹大小乘以 Push
的资源个数，由于需要转为 Base64，最后还要变大 4/3 倍。
通过 Chrome 的 HTTP/2 调试工具对比首次和第二次访问 H2O 官网的帧信息，可以清楚地看出 Cache-Aware Server Push 机制产生的效果，大家可以自己动手试一下。
本文先写到这里，想要了解如何在 H2O 中启用这个功能，请直接查看官方文档。最后想说的是，HTTP/2 在优先级、Server Push 等技术点上的实现策略完全取决于具体的服务端和客户端，期待后续有更多让人眼前一亮的方案出来。
Copyright© 2013-2020
All Rights Reserved 京ICP备2023019179号-8