阅读理解：HTTP/2 push is tougher than I thought

先贴原文地址：HTTP/2 push is tougher than I thought
本文是一篇关于 HTTP/2 push 文章的阅读理解，并不是译文因为懒得做全文翻译，大概概括了中心思想。由于文章原文写于2017年5月份，据本篇博客已经过去了一年半时间，时效性已经不强，在这里仅仅做一个记录，以免它在我笔记本里头腐烂。

HTTP/2 push 比我想象中的更麻烦

万事先上图：//这个长条的图。。。看起来真不方便

以上是包含了 Service Worker 和一系列 cache 策略的整体请求流程。

传统的 Web 请求与解析的过程一般是这样的：

1. 请求并接收 index.html
2. parse html 文件，发现有一大票的依赖，包含 stylesheet、js file、image 等等
3. 对依赖文件发送请求，并苦苦等待
4. 获取所有依赖，完成 parse 过程

（理想中的） HTTP push 可以很好的解决这一问题：

1. 请求 index.html 并从服务器接收 index.html 并附带上了一大堆不知道干什么用的文件
2. parse html 文件并惊喜的发现需要的依赖都已经包含在那一堆杂物里头了
3. 完成 parse 过程
4. 喝杯茶并嘲讽还在用 http 1.x 的垃圾

但是理想终归是理想，现实中 HTTP/2 push 是否真如此美好呢？

多浏览器测试

实际在多浏览器的测试中（chrome、safari、firefox、edge），针对于不同的请求，包括：

• fetch()
• XMLHttpRequest
• <link rel="stylesheet" href="…">
• <script src="…">
• <iframe src="…">

edge 表现的非常惨淡，safari 表现的非常怪异，并且仅有 chrome 提供了开发工具。
对此，作者给出的建议是：在使用 http push 的时候，使用用户嗅探的方法避开这两位祖宗吧（记住这两位祖宗，因为后头还会无数次的提到这两位 ）。

push cache 仅在 http 连接关闭前有效

当 http 连接关闭时，push cache 也就莫得了。
push cache 是在 http cache 之上的，只有当浏览器请求 push cache 中的对应资源时，其才会从 push cache 中被取出，经过 http cache、service worker 等，最终到达 page。
可能出现的情况是，当 server 成功 push 了一堆资源，美滋滋的准备休息的时候，浏览器却在请求对应依赖前关闭了该 http 连接，从而导致需要重新建立 http 连接。
对此，作者给出的建议是：仅使用 http push 一些立即使用的资源，不要寄希望于 push cache 能够存留足够的时间。

备注：HTTP1.1规定了默认保持长连接（HTTP persistent connection ，也有翻译为持久连接），数据传输完成了保持TCP连接不断开（不发RST包、不四次握手），等待在同域名下继续用这个通道传输数据。详见《HTTP权威指南》。

多个页面可以使用同个 http push

每一个 http 连接都有其自己的 push cache，但是多页面可以使用同一个 http 连接，也意味着其可以使用同一个 push cache。
在这一项的测试中，不出意外的又是 edge 和 safari 两兄弟出问题了。edge 会对每个 tab 都建立新的连接，而 safari 会对同个域下的页面创建多个连接。
对此，作者给出的建议是：注意你在 http push 中推送的 json 等数据，其可能会被错误的 page 获取。

non credentials 请求会建立独立的连接

当使用 cookie、HTTP basic auth 等方法时，你建立的连接实际上是一个 credentialed 的连接。为了保证隐私性，浏览器会对 non-credentialed 的连接建立独立的连接。
这也意味着，credentialed 和 non-credentialed 的连接无法使用同一份 push cache。例如，当使用 credentialed 的连接获取了 page 后， non-credentialed 的连接无法从对应的 push cache 中获取资源。
对此，作者给出的建议是：对于所有的请求使用相同的 credential mode，大多数情况下，这也意味着对于所有的请求加上 credential。
但是对于一些请求，如跨域请求 fonts 无法对其增添 credential、image 总是附带 credential，这些是否包含 credential 的调和最终还需要使用 sw 对每个 fetch 进行控制来实现统一。

push cache 中的资源仅被使用一次

当浏览器从 push cache 中获取了资源时，其将从 push cache 中进行删除。本来这一点并不会造成很大的困扰，但是这时 safari 大爷又跳出来对众多开发者说：你们高兴的太早了。
Safari 存在着相同资源相互竞速的问题，如果某个被 push 的资源需要被多次 fetch，其会多次从 push cache 中获取。但是当 push 结束后，在对某个资源进行两次 fetch，safari 能够正确进行处理：第一个资源将从 push cache 中取出；第二个资源则不是。

push cache 中的资源应当基于 http 语义进行匹配

当使用 vaty: cookie 的 http 头字段时，浏览器应当根据其内容进行 push cache 的匹配。但是实际上只有 safari 实现了这一点（surprise！）。
这也就意味着，你给用户A push 了一些 json，当用户A退出登录，用户B登录后，其仍然能够获取到 push 给用户A的 json。

你可以对其他域进行资源的push

我的理解是，某个域服务端可以对其他域下的跨域请求 push 资源，只要保证其对于该域是 authoritative 的。例如下图中的 .google.com 域对于 youtube.com 等域均是 authoritative 的。

不过，必须注意：不同的域下的请求首先会引起 DNS 查询，由于其获得了不同的 IP，浏览器会建立新的 http 连接，导致 push cache 无效。
这一问题可以使用 ORIGIN frame 的技术解决，不过当前仅有 Firefox 对其支持。

总结

上述内容基本上概括了文章所想表述的主要内容，省略了部分较不重要的章节：例如 Push vs preload（由于 preload 的浏览器支持情况很差）。
总体而言，大概就是前景很美好，但是当下的实现中仍存在很多问题，在了解了这些 bug 并进行完整的测试的情况下，http push 可以发挥其作用；否则的话，还是等着 bug 都修复了再说吧，正所谓路漫漫其修远兮。。。