我正在尝试更新我们的在线商店以使用具有服务器推送功能的HTTP / 2,但是找不到用于上游HTTP / 2的Web服务器(如Nginx(用于代理和其他东西))的解决方案.目前,我们正在将Node.js与node HTTP模块一起使用,但希望切换到node spdy模块. spdy模块通过服务器推送支持HTTP / 2.我尝试过使用H2O替代Nginx,但它也不支持HTTP / 2上游.

我现在有点迷茫,需要帮助.

解决方法:

Nginx有only just added support for HTTP/2 Push,因此除非您摩擦最新的主线版本,否则将无法执行此操作.同样是因为它太新了there are still some issues with it.Nginx不支持通过后端连接的http2(并具有stated they won’t support this).因此,您不能像您建议的那样直接从下游系统一直推动.

关于这是否是最好的推动方式,存在一些疑问.下游系统可能会推送到上游代理服务器,即使客户端不支持推送(例如,浪费的推送).

因此,更好的方法是从代理服务器进行推送,并让下游系统(通过链接头)告知上游系统进行该推送.这在降低复杂性方面具有多个优势,它允许下游系统推送它可能无法控制的资产(例如,样式表,JavaScript,图像等静态资产),已推送资产的*存储(缓存摘要),并且不进行推送要求一直支持HTTP / 2(链接标头可以像HTTP / 2一样通过HTTP / 1.1发送).

通过链接标头从上游代理推送的主要缺点是,当从响应中读取链接标头时,您必须等待请求的资源准备就绪.如果请求资源需要一些时间来生成,那么在处理过程中开始推送其他资源可能会更有利.可以通过新的103 Early Hints HTTP Status code解决此问题,您可以在先回复,然后再发送主要的200状态代码.此早期消息可以具有链接头,上游代理可以读取该链接头,并使用该链接头来推送资源.我不确定Nginx的实现是否会支持这一点.

顺便说一句,Apache现在已经支持Push了一段时间,并且实现起来更加成熟.它通过直接Apache配置或链接标头(包括通过103响应(默认情况下配置为在出现兼容性问题时不发送))来支持它.由于上述原因,它甚至支持通过HTTP / 2到does not support direct push over back end connections到后端的代理.其他一些不太知名的服务器(例如H2O)也比Nginx更好地支持HTTP / 2.

最后,如果使用CDN,则它们可能支持HTTP / 2推送(通常通过链接头),而无需升级任何后端基础结构.实际上,Cloudflare是基于Nginx的CDN,其中包含had HTTP/2 Push for a while,而我实际上是two Cloudflare engineers which have back ported their implementation to the base Nginx code.