假设我有一个 TCP 级负载均衡器，它在两个后端 HTTPS 服务器之一和客户端之间传递 TCP 数据包。为了确保加密没有问题，负载均衡器必须维护一个表，以确保 X 客户端 IP 始终落在 HTTPS 服务器 A 上，而 Y 客户端 IP 落在 HTTPS 服务器 B 上，依此类推。
假设客户端是移动的，当从 3G 切换到 1X 互联网连接协议时会发生什么？在这种情况下，这（几乎肯定会）导致 IP 地址发生变化。用户体验会怎样？
- 重新建立 SSL/TLS 连接？（假设用户的下一次点击是在 IP 地址更改完成后，不会出现中断）
- 安全连接完全中断？（用户会看到错误，然后必须重试）
- 回退到较低版本的 SSL/TLS？（同样，没有中断，但如果 IP 再次发生变化，它会恢复正常还是会失败？）
答案1
如果您拥有一个能够很好地理解 HTTP 的负载均衡器（大多数），您通常可以根据 Cookie 将“粘性”配置到给定的真实服务器。负载均衡器会将 Cookie 注入到服务器的响应中，每个可能的真实服务器都有一个唯一的值。在对同一域的后续请求中，行为良好的浏览器将发回相同的 Cookie，负载均衡器将读取该 Cookie 并将其重定向回与之前相同的服务器。
这将取决于特定负载均衡器的实现，即它是否尊重不同源 IP 地址的 cookie 值，或者是否仅将其放回循环（或加权）池中，但我使用过的大多数人只会在存在“粘性”配置时使用 cookie。
更大的问题将取决于你如何使用 SSL 证书。你将有让负载平衡器执行 SSL 加密/解密，以便此操作正常工作。如果 SSL 证书应用于服务器，负载均衡器将无法检查加密隧道中的底层 HTTP 数据，因此只能进行 TCP 负载平衡（即加权或循环）。如果此设置必需的（例如，作为某些端到端加密合同条款的一部分），您必须设置规则，以便一台服务器优先于另一台服务器，除非它不可用（例如，将其设置为故障转移备份，而不是负载平衡服务）——在这种情况下，您只需在重新连接客户端时承受短暂的打击。您可以通过将应用程序/会话状态存储在弹性/冗余（数据库）存储中并在每个请求中发布会话标识符（通过 cookie、隐藏表单字段或查询字符串参数）来缓解应用程序中的这种情况——如果您这样做，请务必小心会话安全。
其他规定将适用于您在同一 IP 上应用多个启用 SSL 的网站。大多数（如果不是全部）负载平衡器/服务器设备不会将多个 SSL 证书绑定到同一 IP/端口组合。最多可以将通配符证书应用于一个 IP/*.yourdomain.example.org端口（例如覆盖 www.yourdomain.example.org、other.yourdomain.example.org），或者可以使用具有多个 SAN（主题备用名称）的证书（尽管大多数证书供应商不会为多个根域颁发具有 SAN 的基于 SAN 的证书）。