当资源在缓存中时，浏览器是否取消服务器推送？答案

【问题标题】：Does the browser cancel server push when a resource is in cache?当资源在缓存中时，浏览器是否取消服务器推送？
【发布时间】：2015-06-03 19:50:46
【问题描述】：

HTTP/2 规范表明，在 PUSH_PROMISE 帧中标识的任何资源都不会在客户端取消时被推送。

当浏览器检测到资源已经在缓存中时，它应该取消对该资源的推送。但是，我看不到浏览器如何检测到它。框架是否提供额外的信息，例如 etag 或上次修改，以允许浏览器检测是否必须驱逐任何缓存条目或是否可以取消推送？

如果可能的话，可以节省一些带宽。但是，似乎服务器推送会损害任何客户端缓存优化。

【问题讨论】：

【解决方案1】：

简单而简短的回答：是的，如果浏览器缓存中有此 URL，浏览器将取消服务器推送。

【讨论】：

这有什么来源吗？本文不同意css-tricks.com/cache-aware-server-push
来自那篇文章：Browsers do have the capability to reject pushes。但是，当它被拒绝时，由于延迟，大部分或全部文件可能已经被传输。本文进一步探讨了当客户端可能已缓存资源时如何减少浪费的带宽。
那么为什么 Nginx 在这里 nginx.com/blog/nginx-1-13-9-http2-server-push 解释如何使用 cookie 不发送浏览器已有的内容？

【解决方案2】：

在 HTTP/2 中，服务器通过 PUSH_PROMISE 帧向客户端推送资源的请求。

从服务器到客户端时，这不是响应，而是请求，即客户端为获取该资源而发出的请求。

当客户端收到 PUSH_PROMISE 时，它可以查看 URI，并找出该资源的缓存状态。浏览器通常对正常接收的资源和推送的资源使用不同的缓存。如果缓存仍然有效，客户端可以通过向服务器发送一个 RST_STREAM 帧来取消推送的流。

同时，服务器启动推送资源所需的一切。这将生成一个 HEADERS 响应帧，其中将包含典型的响应标头，例如 etag。当客户端收到 HEADERS 响应帧时，它还有一次取消流的机会，尽管 - 当然 - DATA 帧可能正在传输中，可能是所有的。

节省带宽可能很有趣，但浪费一点带宽通常不是问题；从用户体验的角度来看，更重要的是延迟，而推送机制可将其大大减少。

我认为推送机制不会损害任何客户端缓存优化；如果是这种情况，浏览器供应商会反对此功能，而他们中的大多数（如果不是全部）实施它，在用户体验和减少延迟方面取得了非常好的结果。

当然可以改进机制，例如让客户端和服务器就某个标头达成一致，该标头将提供有关被推送资源的更多信息，但到目前为止效果还不错。

[免责声明：我是 Jetty 提交者] 作为第一个为 Java 生态系统 (almost 3 years ago) 实现 SPDY 和 HTTP/2 推送的人，Jetty Project 肯定对围绕 HTTP/2 推送的more discussions and ideas 感兴趣。

【讨论】：

我很好奇你是否知道客户端使用什么机制来知道它是否可以取消推送。是 etag 或最后修改的还是随推送承诺一起发送的？这个关于 SPDY 的 Chromum 页面似乎表明 PUSH 将是多余的（忽略缓存），并且 HINT 会在检查其缓存后要求浏览器获取该项目：chromium.org/spdy/link-headers-and-server-hint 这种机制在 SPDY 和 HTTP2 之间是否发生了变化？
除了我上面的评论，这里有一个 Chrome 讨论线程groups.google.com/a/chromium.org/forum/#!msg/net-dev/…（更具体到 SPDY）表明不支持服务器推送缓存。服务器从 HTTP2 服务器推送的文件不会显示在 chrome://cache 中（最初请求的文件确实出现在缓存中，但另外推送的文件不会出现）。我认为 HTTP2 规范可以让浏览器在 PUSH_PROMISE 中接收 etag 并取消推送，但看起来 Chrome 至少没有以这种方式实现。