HTTP / 2推送已失败

2020-12-05 21:47:20

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

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

为了推动这一想法的发展,我编写了一份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响应以编程方式在浏览器中。