为了使用HTTP/2，所有的网页浏览器都需要使用HTTPS。即使没有HTTP/2，有多种原因也使得使用HTTPS仍然是一个好主意。
所以你的网页浏览器需要与（通常称为“边缘服务器”）通信的点需要启用HTTPS。这通常是一个负载均衡器，但也可能是CDN或仅仅是一个单独的Web服务器（例如Apache），在应用服务器（例如Tomcat）之前。
那么问题来了，从该“边缘服务器”到下游服务器的连接是否需要启用HTTPS？嗯，最终浏览器不会知道，所以不需要。那么你只需要加密此连接的两个原因：
1.因为流量仍然通过不安全的通道传输（例如CDN到源服务器，穿过互联网）。
许多人认为，让用户认为他们处于安全状态（带有绿色的挂锁），而实际上却没有进行完整的端对端连接，这是虚伪的。
对我来说，如果你的负载均衡器处于隔离的网络区域（甚至可能是同一台机器上！）与它连接的服务器在一起，这就不是一个问题。例如，如果负载均衡器和它连接的2（或更多）Web服务器都在DMZ隔离网络或它们自己的VPC中的单独区域中。
最终流量将在某个时候被解密，服务器所有者的问题是在您的网络堆栈中发生这种情况的位置/时间以及您对此的舒适程度。
2.因为你想出于其他原因使用HTTPS（例如HTTP/2全程）。
在这一点上，我认为很难提出一个好的理由。HTTP/2主要有助于高延迟、低带宽的连接（即浏览器到边缘节点），对于低延迟、高带宽的连接（如负载均衡器到Web服务器）来说则不那么重要。我的回答
这个问题讨论了更多。
在上述两种情况下，如果你在下游服务器上使用HTTPS，你可以使用自签名证书或长期有效的自签名证书。这意味着你不受30天LetsEncrypt限制的约束，也不需要从另一个CA购买更长的证书。由于浏览器从未看到这些证书，因此你只需要让负载均衡器信任它们，对于自签名证书来说，这在你的控制范围内。如果下游Web服务器无法与LetsEncrypt通信以从那里获取证书，这也很有用。
第三种选择，如果有必要全程使用HTTPS和/或HTTP/2，则可以使用TCP负载均衡器（这是您问题中的第二个选项，对于混淆编号我表示歉意！）。它只是将TCP数据包转发到下游服务器。数据包可能仍然是HTTPS加密的，但负载均衡器并不关心——它只是将它们转发，并且如果它们是HTTPS加密的，则下游服务器被委托解密它们。因此，在这种情况下，您仍然可以拥有HTTPS和HTTP/2，只需在下游Web服务器上拥有最终用户证书（即LetsEncrypt证书）。这可能很难管理（是否应在两者上使用相同的证书？还是应该有不同的证书？我们需要粘性会话，以便HTTPS流量始终命中相同的下游服务器）。这也意味着负载均衡器无法查看或理解任何HTTP流量——在它看来，它们都只是TCP数据包。因此，不能对HTTP标头进行过滤或添加新的HTTP标头（例如带有原始IP地址的X-FORWARDED_FOR）。
老实说，如果在两者之间使用安全网络，则在负载均衡器上使用HTTPS并在下游服务器上使用HTTP流量是完全可以的，甚至非常常见。这通常是最容易设置的方法（一个地方管理HTTPS证书和更新），并且最容易支持（例如，某些下游服务器可能不容易支持HTTPS或HTTP/2）。在此连接上使用自签名证书或CA颁发的证书同样可以，但需要更多的努力，而TCP负载均衡器选项可能需要最大的努力。
