caching - 是否有必要在 HTTP/2 中缓存 bust？

Question

在 HTTP/1 中，为了避免决定资源是否应保持缓存的额外网络请求，我们将设置一个高值 max-age或 Expires静态 Assets 的值(value)，并为每个修订版赋予它们唯一的 URL。但是在 HTTP/2 中，请求是廉价的，所以我们可以不使用缓存破坏，只依赖 ETags，last-modified 等吗？

我可以看到继续破坏缓存的唯一优势(除了同时为 HTTP/1 和 HTTP/2 客户端提供服务)是节省带宽检查资源是否过期。即使这对于 HPACK 来说也可能无关紧要。那么我是否遗漏了什么，或者我现在可以停止缓存破坏吗？

Answer 1

“必要”部分取决于您对性能的感受有多极端。简而言之，如果您可以忍受三到四次往返，则不需要缓存破坏。否则缓存破坏仍然是删除它们的唯一方法。

以下是一些与 HTTP/2 与 HTTP/1.1、延迟问题以及 HTTP/2 推送的使用相关的争论。

HTTP/2 请求不是即时的

HTTP/2 请求比 HTTP/1.1 便宜，但不会太多。在 HTTP/1.1 中，一旦浏览器打开到服务器的 6 到 8 个 TCP 连接，它就有 6 到 8 个 channel 来进行重新验证。在一些 TCP 丢包率高、延迟高的场景下，尤其是在 TCP 慢启动为王的连接开始时，HTTP/1.1 的多个 TCP 套接字比单个 HTTP/2 TCP 连接工作得更好。 HTTP/2 很好，但不是 Elixir 。

HTTP/2 连接仍然存在网络延迟。我们一直在为我们网站 (It can be measured using HTTP/2 Ping) 的访问者平均往返时间 (RTT)，并且由于并非每个人都与我们的服务器位于同一块中，因此我们的平均 RTT 介于 200 到 280 毫秒之间。 304 重新验证将花费 1 RTT。在不使用 Assets 串联的站点中， Assets 树的每个新级别都将花费更多的 RTT。

HTTP/2 Push 可以为您节省尽可能多的 RTT，同时与缓存正常工作。但是有一些问题，请继续阅读!

HTTP/2 推送最适合缓存破坏

理想的情况是服务器不推送新资源，而是推送自客户端上次访问以来发生变化的所有内容。

如果浏览器认为资源是新鲜的(例如，因为 max-age)，它会拒绝或不对该资源使用任何推送。这使得无法通过 HTTP/2 推送刷新浏览器认为新鲜的 Assets 。

由于浏览器中广泛存在的错误，推送 304 重新验证不起作用。这些将需要一个小的 max-age .

因此，保持 RTTs 最小的唯一方法，不推送浏览器已经拥有的任何东西并且仍然能够推送新版本的 Assets 是使用缓存破坏，即新版本的新名称或查询参数 Assets 。

也可以看看

Url query parameters are still needed to update assets at clients

Interactions with the browser's cache