通常，HTTP /
2的最大直接好处是浏览器连接的多路复用可以提高速度，而浏览器连接通常会受到高延迟（即慢的往返速度）的阻碍。这些还减少了多个连接的需求（和费用），可以尝试在HTTP /
1.1中获得类似的性能优势。

对于内部连接（例如，充当反向代理的Web服务器与后端应用程序服务器之间），延迟通常非常非常低，因此HTTP /
2的速度优势可忽略不计。此外，每个应用程序服务器通常已经是一个单独的连接，因此在这里再也没有收获。

因此，仅在边缘支持HTTP / 2即可获得 大部分 性能收益。这是一个相当普遍的设置-
与HTTPS通常在反向代理/负载平衡器上终止而不是一直执行的方式类似。

但是，始终支持HTTP / 2有潜在的好处。例如，它可以允许服务器从应用程序一直推送。由于HTTP /
2的二进制性质和标头压缩，该最后一跳的数据包大小减小也可能带来好处。尽管像延迟一样，带宽对于内部连接而言通常不是一个大问题，所以这一点的重要性尚有争议。最后有人认为，反向代理将HTTP
/ 2连接到HTTP / 2连接的工作比连接HTTP /
1.1连接要少，因为不需要将一个协议转换为另一个协议，尽管我对此持怀疑态度。引人注意，因为它们是独立的连接（除非它仅充当TCP直通代理的角色）。因此，对我来说，端到端HTTP
/ 2的主要原因是允许端到端服务器推送，但是由于管理跨多个连接的推送的复杂性，即使使用HTTP Link Header和103-Early
Hints可能也可以更好地处理它。

就目前而言，尽管服务器仍在增加支持并且服务器推送使用率很低（并且仍在尝试以定义最佳实践），但我建议仅在终点使用HTTP /
2。在撰写本文时，Nginx还不支持ProxyPass连接的HTTP /
2（尽管Apache支持），并且没有计划添加它，并且它们提出了一个有趣的观点，即单个HTTP
/ 2连接是否可能导致速度缓慢（强调我的）：

是否计划在不久的将来支持HTTP / 2代理？

简短答案：

不，没有计划。

长答案：

几乎没有任何实现的意义，因为HTTP / 2的主要好处是它允许在单个连接中多路复用多个请求，因此[几乎]消除了单请求数量的限制-
与之通信时没有这种限制。您自己的后端。 此外，由于使用单个TCP连接而不是多个TCP连接，因此使用HTTP / 2后端时情况甚至可能变得更糟 。

另一方面，在上游模块的单个连接中实现HTTP / 2协议和请求多路复用将需要对上游模块进行重大更改。

由于上述原因，至少在可预见的将来，尚无计划在上游模块中实现HTTP / 2支持。如果您仍然认为需要通过HTTP / 2与后端通信，请随时提供补丁。

最后，还应注意，尽管浏览器要求HTTPS为HTTP /
2（h2），但大多数服务器不需要，因此可以支持通过HTTP（h2c）进行的最后一跳。因此，如果Node部分中不存在端到端加密（因为通常不存在），则无需端到端加密。但是，根据后端服务器相对于前端服务器的位置，即使流量通过不安全的网络（例如CDN到Internet上的原始服务器）进行传输，甚至对于此连接也应使用HTTPS。