设想：
- 硬件负载均衡器背后的小型网络场
- 无需服务器关联。如果一台服务器宕机，另一台服务器可以接管。
- 部分系统需要 HTTPS。该协议终止于服务器。每台服务器均安装有 SSL 证书。
- 服务器具有足够的容量，因此不必担心将请求路由到哪个服务器（即使一台服务器无法轮换）。
考虑到这一点，负载平衡策略最明显的选择似乎是简单的循环方法。基于源 IP 的平衡似乎很难测试，而基于 cookie 的平衡似乎不适用于 SSL。
不过，我担心每次页面由不同的 Web 服务器提供时，浏览器可能会重新协商其 HTTPS 连接，从而导致网站速度比应有的速度慢很多。
我的问题是：
- 这确实会是个问题吗？或者负载均衡器是否足够聪明，即使内容来自多台服务器，也能以某种方式仅进行 1 次 SSL 握手？
- 是否有任何工具（Windows）可以用来在浏览网站时轻松监控 SSL 握手、HTTP 保持连接等？
- 如果我们在这里确实遇到问题，我们该如何解决？（我猜最明显的解决方案是在我们的负载均衡器上卸载 SSL，但我们当前的硬件不支持这一点，因此在这个阶段任何其他解决方案都是更好的选择。）
答案1
使用 keepalive 的连续调用是同一 TCP 流的一部分，因此只涉及一次 SSL 协商，并且它们都应该发送到同一台服务器。
没有保持活动的请求将是独立的流程，每个请求都需要单独的 SSL 协商。
是的，循环赛应该没问题。