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

我正在尝试配置负载均衡器 https://cloud.google.com/load-balancing/使用 HTTPS 提供的证书提供服务让我们加密 https://letsencrypt.org/，尽管我还做不到，读这篇文章article https://medium.com/google-cloud/kubernetes-w-lets-encrypt-cloud-dns-c888b2ff8c0e给出了如何配置的步骤

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

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

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

但我的意思不是明显的原因，即第一个没有从负载均衡器到后端加密，我的意思是在性能和​​ HTTP2 连接方面，例如，我将继续获得以下所有好处http2 https://developers.google.com/web/fundamentals/performance/http2/#streams_messages_and_frames比如多路复用和流媒体？或者是第一个选项

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

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

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

因此，您的网络浏览器需要与之对话的点（通常称为边缘服务器），需要启用 HTTPS。这往往是一个负载均衡器，但也可以是 CDN，或者只是一个网络服务器（例如 Apache）在应用服务器（例如雄猫）。

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

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

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

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

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

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

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

在上述两种情况下，如果您在下游服务器上使用 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 负载平衡器选项可能是最努力的。