❗ 本文最后更新于 3305 天前,文中所描述的信息可能已发生改变,请谨慎使用。
几个月前,我在《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 等技术点上的实现策略完全取决于具体的服务端和客户端,期待后续有更多让人眼前一亮的方案出来。
本文链接:https://imququ.com/post/cache-aware-server-push-in-h2o.html,参与评论 »
--EOF--
发表于 2015-10-21 01:54:51,并被添加「HTTP2、H2O」标签。查看本文 Markdown 版本 »
专题「HTTP/2 相关」的其他文章 »
- 谈谈 Nginx 的 HTTP/2 POST Bug (Aug 20, 2016)
- 为什么我们应该尽快支持 ALPN? (May 18, 2016)
- 谈谈 HTTP/2 的协议协商机制 (Apr 14, 2016)
- 使用 nghttp2 调试 HTTP/2 流量 (Mar 07, 2016)
- 从启用 HTTP/2 导致网站无法访问说起 (Jan 17, 2016)
- 基于 HTTP/2 的 WEB 内网穿透实现 (Nov 23, 2015)
- HTTP/2:新的机遇与挑战 (Nov 22, 2015)
- HTTP/2 头部压缩技术介绍 (Oct 25, 2015)
- 使用 Wireshark 调试 HTTP/2 流量 (Oct 24, 2015)
- HTTP/2 资料汇总 (Aug 31, 2015)
Comments
Waline 评论加载中...