上周我正在为我的启用 TLS 的端点(共享相同的证书)使用负载均衡器，并且惊讶地发现可以在 SSL 端点之前安装 TPC 负载均衡器。配置完成后，就可以与 TCP 负载均衡器进行通信，就像它配置为支持 TLS/SSL 一样。所以，我想确保这样的网络配置是完全有效的解决方案:
- TLS/SSL session 和握手工作流程是无状态的，这意味着可以从主服务器开始握手并以镜像结束。是真的吗？
- 是否有任何我必须注意的隐患？
- 如果前面的陈述是正确的，那么在负载均衡器本身上执行所有 TLS/SSL 工作的原因是什么？
附言我不在负载均衡器上执行 TLS/SSL 工作的原因是我需要平衡多个仅支持 SSL/TLS 的专有端点。
最佳答案
TLS/SSL session and handshake workflow are stateless, meaning it is possible to start handshake with a primary server and end it with a mirror. Is it true?
没有。我怀疑您的负载均衡器正在使用 TCP keep-alive，以便握手每次都在同一台服务器上完成。
Are there any hidden dangers I must be aware of?
您可能会招致严重的性能损失。 HTTPS 具有“ session key ”，这些 key 可能在默认情况下对服务器是唯一的。如果您无法使用负载均衡器执行诸如粘性 session 之类的操作，那么每次客户端从一台服务器移动到另一台服务器时，您都将进行一次完整的握手。
您还将拥有在服务器之间无法使用的 session 票证，因此 session 恢复可能也无法正常工作，并退回到完全握手。一些服务器支持配置通用 session 票证 key ，例如 nginx。
If previous statements are true, what the reason to to do all TLS/SSL work on a load balancer itself?
嗯，它们并不完全正确。不过还有其他好处。主要是负载均衡器可以更加智能，因为它可以看到 session 的明文。一个示例可能是检查请求的 cookie 以确定将请求发送到哪个服务器。这是蓝/绿部署的常见需求。
关于ssl - TLS/SSL 端点前的 TCP 负载平衡器，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/45785301/