HTTP推送已死

HTTP/2附带的热门特性之一是推送帧。其主要思想是，如果服务器可以预测客户端可能想要发出的请求，那么服务器就可以抢先地向客户端发送请求/响应对，并对其进行预热缓存。

这是我很长一段时间以来一直非常感兴趣的功能。我觉得API可以让温缓存失效，消除复合请求(我觉得这是一种黑客行为，尽管有时是必要的)，这是非常有用的。

为了帮助推进这个想法，我设计了一个互联网草案，让API客户端告诉服务器他们想要推送什么资源，我构建了一个Node.js框架，它具有一流的、深度集成的推送支持，并增加了对首选推送的支持，而不是Keting。

不幸的是，HTTP/2推送给人的感觉总是像是一种还不太存在的功能。由于HTTP/2的缓存摘要被扼杀，而且没有浏览器API可以与推送事件挂钩，它的有用性受到了阻碍。

Chrome团队至少从2018年就开始考虑移除推送支持。主要原因是他们没有真正看到推动静态资产带来的业绩好处。当时，我试图为API用例捍卫这一特性。

昨天，Chrome团队宣布从他们的HTTP/2和HTTP/3协议实现中移除该功能。

我有点难过，因为它从来没有发挥出它的全部潜力，但有了这一步，我不再认为在这个功能上投资是值得的。因此，我将停止我在PERFER-PUSH方面的工作，并将从下一个主要的Keting版本中移除对它的支持。

从积极的方面来说，我花了很多时间思考和研究这一点，但有时能够结束一章，而不是等待并让它发出嘶嘶声是很好的。这不是一个理想的结论，但却是一个无结论的结论。

由于缺少服务器驱动程序推送，我们又回到了许多小的HTTP请求或复合请求。这意味着要么存在N+1问题，要么(在复合请求的情况下)与HTTP缓存的集成不佳。有关这方面的更多信息，请点击此处。

如果你采用“复合请求”路线，有一个类似的报头草案，类似于PERVER-PUSH；PERFER：Transclude，Keting也支持它。

我希望服务器推送的一个特性在未来能很好地工作，那就是服务器启动的缓存失效。我们一直没有完全理解这一点。为了解决这个问题，我们使用WebSockets，并将在可预见的未来继续这样做。

为了减少获取很多东西的一般延迟，103早期的Hintscan提供了帮助，尽管Chrome还不支持这一点，而且这也只对加快图像、CSS和Javascript等资产的传输非常有用，因为没有办法在浏览器中以编程方式连接到1XX响应中。