带非 TLS 后端的 HTTPS 负载均衡器和带 TLS 后端的 HTTPS 负载均衡器有什么区别

Question

我正在尝试将负载均衡器配置为使用Lets Encrypt提供的证书在 HTTPS 中提供服务，尽管我还无法做到这一点，但阅读本文提供了如何配置的步骤

• 自签名证书
• 带 TLS 后端的网络负载均衡器
• 带非 TLS 后端的 HTTPS 负载均衡器
• 带 TLS 后端的 HTTPS 负载均衡器

由于我只对 HTTPS 感兴趣，我想知道这两者之间有什么区别：

1. 带非 TLS 后端的 HTTPS 负载均衡器
2. 带 TLS 后端的 HTTPS 负载均衡器

但我的意思不是明显的原因，即第一个从负载均衡器到后端没有加密，我的意思是在性能和​​ HTTP2 连接方面，例如我会继续从http2中获得所有好处，如多路复用和流式传输吗？或者是第一个选项

带非 TLS 后端的 HTTPS 负载均衡器

只是一个幻觉，但我不会得到http2？

Answer 1

要使用 HTTP/2，所有 Web 浏览器都需要使用 HTTPS。即使没有 HTTP/2，出于各种原因，使用 HTTPS 仍然是件好事。

因此，您的 Web 浏览器需要与之通信的点（通常称为边缘服务器）需要启用 HTTPS。这通常是一个负载均衡器，但也可能是一个 CDN，或者只是应用程序服务器（例如 Tomcat）前面的单个Web 服务器（例如 Apache）。

那么问题是从该边缘服务器到任何下游服务器的连接是否需要启用 HTTPS？好吧，最终浏览器不会知道，所以不适合它。那么加密此连接有两个原因：

1. 因为流量仍然通过不安全的通道传输（例如，CDN 到源服务器，通过互联网）。

   许多人认为让用户认为他们处于安全状态（带有绿色挂锁），但实际上他们并不支持完整的端到端连接，这是不诚实的。

   如果您的负载均衡器与其连接的服务器位于隔离的网络区域（甚至可能位于同一台计算机上！），这对我来说就不是什么问题。例如，如果负载均衡器和正在连接的 2 个（或更多）Web 服务器都位于 DMZ 隔离网络或其自己的 VPC 中的单独区域。

   最终，流量将在某个时刻被解密，而服务器所有者的问题是在网络堆栈中何时何地发生这种情况以及您对此的适应程度如何。

2. 因为您出于某些其他原因需要 HTTPS（例如始终使用 HTTP/2）。

   在这一点上，我认为没有什么好的理由。HTTP/2 主要帮助高延迟、低带宽连接（即浏览器到边缘节点），对于低延迟、高带宽连接（如负载均衡器到 Web 服务器通常如此）不太重要。我对这个问题的回答更多地讨论了这一点。

在上述两种情况下，如果您在下游服务器上使用 HTTPS，则可以使用自签名证书或长期自签名证书。这意味着您不受 30 天 LetsEncrypt 限制的约束，也不需要您从其他 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 负载平衡器选项可能是最努力的。