我有一个 node .运行在nginx代理后面的js服务器. node .js正在端口3000上运行HTTP 1.1(无SSL)服务器.两者都在同一台服务器上运行.
我最近设置了nginx，将HTTP2与SSL(h2)一起使用.看来HTTP2确实已经启用并正在运行.
However, I want to know whether the fact that the proxy connection (nginx <--> node.js) is using HTTP 1.1 affects performance. That is, am I missing the HTTP2 benefits in terms of speed because my internal connection is HTTP 1.1?
一般来说，HTTP/2的最大直接好处是浏览器连接的速度提高了multiplexing倍，而浏览器连接往往会受到高延迟(即缓慢的往返速度)的阻碍.这些还减少了对多个连接的需求(和费用)，这是在HTTP/1.1中实现类似性能优势的一种变通方法.
对于内部连接(例如，充当反向代理的Web服务器和后端应用服务器之间)，延迟通常非常非常低，因此HTTP/2的速度优势可以忽略不计.此外，每个应用服务器通常已经是一个单独的连接，因此这里也没有yield .
因此，只要在边缘支持HTTP/2，您就可以获得most%的性能优势.这是一种相当常见的设置——类似于HTTPS通常在反向代理/负载平衡器上终止的方式，而不是一直终止.
然而，始终支持HTTP/2有potential个好处.例如，它可以允许服务器从应用程序一路推送.此外，由于HTTP/2和报头压缩的二进制特性，最后一跳的数据包大小减小也会带来潜在的好处.不过，和延迟一样，带宽对于内部连接来说通常不是什么问题，所以这一点的重要性是有争议的.最后，一些人认为，反向代理将HTTP/2连接到HTTP/2连接比将其连接到HTTP/1.1连接所做的工作要少，因为不需要将一个协议转换为另一个协议，尽管我怀疑这是否值得注意，因为它们是独立的连接(除非它只是充当TCP传递代理).所以，对我来说，端到端HTTP/2的主要原因是允许端到端服务器推送，但我不知道有哪个HTTP代理服务器会支持这种方式(很少有后端支持HTTP/2，更不用说像这样链接HTTP/2连接了)，所以你需要一个第四层负载平衡器来转发TCP打包程序，而不是链接HTTP请求——这会带来其他复杂问题.
目前，虽然服务器仍在增加支持，而且服务器推送使用率很低(仍在进行实验以定义最佳实践)，但我建议只在端点使用HTTP/2.在 compose 本文时，Nginx也不支持ProxyPass连接的HTTP/2(尽管Apache支持)，并且有no plans to add this个，他们提出了一个有趣的观点，即一个HTTP/2连接是否会带来缓慢性(我的重点是):
是否计划在不久的将来支持HTTP/2代理？
简短回答:
没有，没有计划.
详细回答:
作为HTTP/2的主要优势，实现它几乎毫无意义
另一方面，实现HTTP/2协议和请求
由于上述原因，目前还没有在中国实施HTTP/2支持的计划
最后，还应该注意的是，虽然浏览器需要HTTP/2(h2)的HTTPS，但大多数服务器不需要，因此可以支持HTTP上的最后一跳(h2c).因此，如果 node 部分不存在端到端加密(通常不存在)，就不需要进行端到端加密.不过，如果流量将在不安全的网络上传输(例如，通过互联网从CDN到源服务器)，则根据后端服务器相对于前端服务器的位置，即使在这种连接中使用HTTPS也可能是应该考虑的.
EDIT AUGUST 2021
HTTP/1.1是基于文本的，而不是基于binary的，这使得它容易受到各种请求走私攻击.在DefCon 2021 PosiSigigGER demonstrated a number of real-life attacks中，主要涉及当将前端HTTP / 2请求降级到后端HTTP/1.1请求时的问题.通过一直讲HTTP/2可能可以避免这些问题，但考虑到目前支持前端服务器和CDN将HTTP/2讲给后端，以及后端支持HTTP/2，这似乎需要很长时间才能普及，而确保这些攻击不被利用的前端HTTP/2服务器似乎是更现实的解决方案.