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