在HTTP / 1中，为了避免额外的网络请求来确定资源是否应该保持缓存，我们会在静态资产上设置高max-age或Expires值，并为它们提供唯一的URL每次修订。但是在HTTP / 2中，请求很便宜，所以我们可以在没有缓存破坏的情况下完成，只需依赖ETag，最后修改，等等？
我可以看到继续破解缓存（除了双重服务HTTP / 1和HTTP / 2客户端）之外的唯一优势是在资源过期时节省带宽检查。甚至那可能与HPACK无关。我错过了什么，或者我现在可以阻止缓存破坏吗？
答案 0 :(得分：7)
“必要”部分取决于您对表现的看法。简而言之，如果您可以住三到四次往返，则不需要缓存清除。否则缓存清除仍然是删除它们的唯一方法。
以下是与HTTP / 2与HTTP / 1.1相关的一些参数，延迟问题以及HTTP / 2推送的使用。
HTTP / 2请求比HTTP / 1.1便宜，但不是太多。在HTTP / 1.1中，一旦浏览器打开到服务器的六到八个TCP连接，它就有六到八个通道来进行重新验证。在高TCP丢包，高延迟的情况下，特别是在TCP慢启动的连接开始时，HTTP / 1.1的许多TCP套接字比单个HTTP / 2 TCP连接更好。 HTTP / 2很好，但不是银弹。
HTTP / 2连接仍然存在网络延迟。我们一直在为我们网站的访问者（It can be measured using HTTP/2 Ping）平均往返时间（RTT），因为不是每个人都在我们服务器的同一个区块中，我们的平均RTT在200到280毫秒之间。 304重新验证将花费1 RTT。在不使用资产连接的站点中，资产树的每个新级别将花费进一步的RTT。
HTTP / 2 Push可以在您正常使用缓存时为您节省尽可能多的RTT。但是有一些问题，请继续阅读！
理想情况是服务器不会推送新资源，但它会推送自客户端上次访问以来所有已更改的内容。
如果浏览器认为资源是新鲜的（例如因为max-age），则拒绝或不使用该资源的任何推送。这使得无法刷新浏览器认为具有HTTP / 2推送的新资产。
由于浏览器中存在广泛的错误，推送304重新验证不起作用。这些将需要一个小的max-age。
因此，将RTT保持在最低限度的唯一方法是，不要推送浏览器已有的任何东西，并且仍然可以推送新版本的资产，就是使用缓存清除，即新的名称或查询参数新版资产。
Url query parameters are still needed to update assets at clients