H2O 中的 Cache-Aware Server Push 简介

几个月前,我在《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 等技术点上的实现策略完全取决于具体的服务端和客户端,期待后续有更多让人眼前一亮的方案出来。

本文链接:参与评论 »

--EOF--

提醒:本文最后更新于 412 天前,文中所描述的信息可能已发生改变,请谨慎使用。

专题「HTTP/2 相关」的其他文章 »

Comments