H2O 中的 Cache-Aware Server Push 简介

几个月前，我在《 HTTP/2 中的 Server Push 讨论》这篇文章中写到：

Server Push 会在客户端请求页面 HTML 时，新建一个流将最重要的资源一并返回。同时，如果服务端要推送的资源浏览器已经缓存过，客户端会发送 RST_STREAM 帧来终止流，服务端收到这个信号之前所传输的数据就造成了带宽浪费。

简而言之，HTTP/2 中的 Server Push 技术使得服务端收到页面请求后，能够将页面所需资源（CSS、JS）通过 PUSH_PROMISE 帧推送给浏览器，从而减少延迟。这样带来一个问题： PUSH_PROMISE 帧离开服务端的时间非常早，如果要推送的资源浏览器本地已经有了缓存，会导致流量的浪费。

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 产生的结果进行压缩，使得占用更少的存储空间。关于这个算法的详细信息，可以关注这个仓库，对应的 JS 实现和 Demo，请点击这个页面查看。

H2O 将要推送的资源路径 + ETag 存入一个集合，采用 Golomb-compressed sets 算法生成指纹，并转为 Base64 字符串存储 Cookie 中，之后就可以通过 Cookie 中的指纹检查出某个资源路径 + ETag 是否存在于集合之中。H2O 默认使用了 13 位二进制来存放指纹，假设一个网站有 100 个不同的文件需要推送，误判率将会控制在 1% 左右。

通过 Chrome 的 HTTP/2 调试工具对比首次和第二次访问 H2O 官网的帧信息，可以清楚地看出 Cache-Aware Server Push 机制产生的效果，大家可以自己动手试一下。

本文先写到这里，想要了解如何在 H2O 中启用这个功能，请直接查看官方文档。最后想说的是，HTTP/2 在优先级、Server Push 等技术点上的实现策略完全取决于具体的服务端和客户端，期待后续有更多让人眼前一亮的方案出来。

本文链接： https://imququ.com/post/cache-aware-server-push-in-h2o.html

-- EOF --

于 2015-10-21 01:54:51 发表于「WEB 后端」分类下。

本站部署于「阿里云 ECS 」。如果你也要购买阿里云服务，可以使用我的九折推荐码 NY1Z0E ，感谢你对本站的支持！