HTTP / 2推送已失败

HTTP / 2附带的热门功能之一是PUSH帧。主要思想是，如果服务器可以预测客户端可能要发出的请求，则服务器可以抢先向客户端发送请求/响应对并预热缓存。

这是我很久以来一直很感兴趣的功能。我认为对于API使＆amp;温暖的缓存，消除对复合请求的需求（我认为这是一种技巧，尽管有时是必要的）。

为了推动这一想法的发展，我编写了一份Internet草案，以使API客户端可以告诉服务器他们希望推送哪些资源，我构建了一个Node.js框架，该框架具有一流的，深度集成的Push支持，并增加了对Prefer-推送至Ketting。

不幸的是，HTTP / 2推送总是让人感觉还不太成熟。由于HTTP / 2的Cache-Digest被淘汰，而且没有浏览器API可以挂入推送事件，因此它的实用性被削弱了。

Chrome团队至少从2018年开始考虑取消对Push的支持。主要原因是他们并没有真正看到推动静态资产带来的性能优势。当时，我试图捍卫API用例的功能。

昨天，Chrome小组宣布从其HTTP / 2和HTTP / 3协议实现中删除该功能。

我感到有点遗憾，因为它没有发挥出最大的潜力，但是通过这一步骤，我认为不再值得投资此功能。因此，我正在停止Prefer-Push的工作，还将从下一个majorKetting版本中删除对它的支持。

积极的一面，我花了很多时间思考和解决这个问题，但是有时候能够关闭一章而不是等待并让它腾出水来，这有时是很好的选择。这不是一个理想的结论，但仍然是一个结论。

缺少服务器驱动程序推送，我们回到了许多小的HTTP请求或复合请求。这意味着您或者遇到了N + 1问题，或者（对于复合请求）与HTTP缓存的集成不良。在这里更多。

如果您要使用“复合请求”路线，则有一个与“首选”按钮相似的标题草稿；首选：超越，Ketting也支持。

我希望该功能将来与Server Push一起使用时可以使服务器启动的缓存失效。我们从来没有得到过。为了解决此问题，我们使用Websockets，并将在可预见的将来继续这样做。

为了减少获取很多东西的一般延迟，尽管在Chrome中尚不支持103早期Hintscan帮助，但它对于加快图像，css和Javascript等资产的交付速度也非常有用，因为无法挂接到1xx响应以编程方式在浏览器中。