我正在尝试将负载均衡器配置为使用Lets Encrypt提供的证书在HTTPS中服务，尽管我还不能做到这一点，但阅读本文会给出如何配置的步骤
- 自签名证书
- 网络负载平衡器w/TLS后端
- HTTPS负载平衡器w/非TLS后端
- HTTPS负载平衡器w/TLS后端
由于我只对HTTPS感兴趣，我想知道这两者之间有什么区别：
- HTTPS负载均衡器w/非TLS后端
- HTTPS负载平衡器w/TLS后端
但我的意思不是第一个没有从负载均衡器到后端加密的明显原因，我的意思是在性能和HTTP2连接方面，例如，我会继续从HTTP2获得所有好处吗，比如多路复用和流媒体？或者是的第一个选项
HTTPS负载均衡器w/非TLS后端
只是一个幻觉，但我不会得到http2？
要使用HTTP/2，所有web浏览器都需要使用HTTPS。即使没有HTTP/2，由于各种原因，使用HTTPS仍然很好。
因此，您的web浏览器需要与之通信的点(通常称为边缘服务器)需要启用HTTPS。这通常是负载均衡器，但也可以是CDN，或者只是应用程序服务器(例如Tomcat)前面的单个 web服务器那么问题是，从边缘服务器到任何下游服务器的连接是否需要启用HTTPS？好吧，最终浏览器不会知道，所以不知道。然后你有两个原因来加密这个连接： 因为流量仍然通过不安全的通道(例如，CDN到原始服务器，通过互联网)传输。 许多人认为，让用户认为他们处于安全状态(使用绿色挂锁)是虚伪的，而事实上，他们并不支持完全的端到端连接。 对我来说，如果你的负载平衡器与它连接的服务器位于隔离的网络区域(甚至可能在同一台机器上！)，这就不是什么问题了。例如，如果负载平衡器和2台(或更多)web服务器都位于DMZ隔离网络或它们自己的VPC中的单独区域。 最终，流量将在某个时候被解密，服务器所有者的问题是在你的网络堆栈中何时何地发生这种情况，以及你对此有多舒服 因为您出于其他原因想要HTTPS(例如HTTP/2)。 在这个问题上，我认为没有什么好的理由。HTTP/2主要有助于高延迟、低带宽的连接(即浏览器到边缘节点)，而对于低延迟、高带宽的连接则不那么重要(就像web服务器的负载均衡器一样)。我对这个问题的回答更多地讨论了这个问题。 在上述两种情况下，如果在下游服务器上使用HTTPS，则可以使用自签名证书或长期自签名证书。这意味着你不受30天LetsCrypt限制的约束，也不需要你从另一个CA购买更长的证书。由于浏览器永远看不到这些证书，你只需要你的负载平衡器信任它们，这在你的控制范围内，可以用于自签名证书。如果下游web服务器无法与LetsEncrypt通信以从那里获得证书，这也很有用。 第三种选择，如果HTTPS和/或HTTP/2始终有效确实很重要，那就是使用TCP负载均衡器(这是您问题中的选项2，很抱歉混淆了这里的编号！)。这只是将TCP数据包转发到下游服务器。数据包可能仍然是HTTPS加密的，但负载均衡器并不在乎——它只是转发它们，如果它们是HTTPS加密，则下游服务器负责解密它们。因此，在这种情况下，您仍然可以使用HTTPS和HTTP/2，您只需要在下游web服务器上拥有最终用户证书(即LetsEncrypt证书)。这可能很难管理(两个证书应该使用相同的证书吗？或者它们应该有不同的证书？我们是否需要有粘性会话，以便HTTPS流量总是到达sae下游服务器)。这也意味着负载均衡器无法看到或理解任何HTTP流量——就其而言，它们都只是TCP数据包。因此，没有对HTTP标头进行过滤，也没有添加新的HTTP标头(例如，具有原始IP地址的X-FORWARDED_FOR) 老实说，在负载均衡器上使用HTTPS，在下游服务器上使用HTTP流量，如果在两者之间的安全网络中，这是非常好的，甚至是非常常见的。它通常是最容易设置的(一个管理HTTPS证书和续订的地方)和最容易支持的(例如，一些下游服务器可能不容易支持HTTPS或HTTP/2)。通过使用自签名证书或CA颁发的证书在该连接上使用HTTPS同样可以，但需要付出更多的努力，而TCP负载均衡器选项可能是最努力的。