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

在 HTTP/1 中，为了避免额外的网络请求来确定资源是否应该保留缓存，我们将设置一个高值max-age or Expires静态资产的值，并为每个修订版提供唯一的 URL。但在 HTTP/2 中，请求很便宜，所以我们可以在不清除缓存的情况下仅依赖 ETag、last-modified 等吗？

我认为继续破坏缓存（除了双重服务 HTTP/1 和 HTTP/2 客户端之外）的唯一好处是在资源过期时节省带宽检查。即使这对于 HPACK 来说也可能微不足道。那么我是否遗漏了一些东西，或者我现在可以停止缓存破坏吗？

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

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

HTTP/2 请求不是即时的

• HTTP/2 请求比 HTTP/1.1 便宜，但也不是太多。在 HTTP/1.1 中，一旦浏览器打开到服务器的六到八个 TCP 连接，它就有六到八个通道来进行重新验证。在一些 TCP 丢包率高、延迟高的场景中，尤其是在 TCP 慢启动占主导地位的连接开始时，HTTP/1.1 的多个 TCP 套接字比单个 HTTP/2 TCP 连接工作得更好。 HTTP/2 很好，但不是灵丹妙药。

• HTTP/2 连接仍然存在网络延迟。我们一直在计算我们网站访问者的平均往返时间 (RTT) (可以使用 HTTP/2 Ping 进行测量 https://www.shimmercat.com/en/info/articles/forwarded-header/#client-latency-latency-）并且因为并非每个人都与我们的服务器位于同一块中，所以我们的平均 RTT 在 200 到 280 毫秒之间。 304 重新验证将花费 1 RTT。在不使用资产串联的站点中，资产树的每个新级别都将花费更多的 RTT。

HTTP/2 Push 可以在与缓存良好配合的同时为您节省尽可能多的 RTT。但还有一些问题，请继续阅读！

HTTP/2 推送最适合缓存清除

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

• 如果浏览器认为资源是新鲜的（例如，因为max-age），它拒绝或不对该资源使用任何推送。这使得不可能通过 HTTP/2 Push 刷新浏览器认为是新鲜的资产。

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

因此，将 RTT 保持在最低限度、不推送浏览器已有的任何内容并仍然能够推送资产的新版本的唯一方法是使用缓存清除，即为新版本的资产使用新名称或查询参数。资产。

See also

仍然需要 URL 查询参数来更新客户端的资产 https://www.shimmercat.com/en/info/articles/caching/#url-query-parameters-are-still-needed-to-update-assets-at-clients-

与浏览器缓存的交互 https://www.shimmercat.com/en/blog/articles/whats-push/#interaction-with-the-browser-s-cache