我有一个 Web Farm，Web 服务器负责协商安全连接。是否有其他人使用 Web Farm 来减少 TLS 握手开销，方法是确保TLS 恢复握手是否受支持？如果受支持，原因何在？
我们正在从粘性会话切换到更平衡的负载平衡算法。我们担心会失去 TLS 恢复功能的好处。假设来自客户端的每个连接都转到不同的 Web 服务器，我们假设将需要完整的 TLS 握手。我不知道开销，但如果我们考虑 20ms 的往返时间，则似乎完整的握手将花费 3 倍左右的时间才能完成。
答案1
我不知道 OP 的 Web 服务器群有多大，但对于大多数小型/中型安装，我发现在负载均衡器上处理所有 TLS/SSL 是最干净、最简单的。因此，您有：
Internet (HTTPS req) -> L7 HTTPS proxy LB -> plain HTTP on LAN -> webserver
o3 杂志有一个好写下使用 nginx 实现这个相对简单的方法以及您可以期待的性能数据。f5 发布了关于使用商业设备进行 SSL 加速的好处的评论而不是 DIY 解决方案（恕我直言，有点偏见）。
请注意，你需要你的网络服务器来检查X-转发和转发协议标题并正确处理连接。
大多数安装应该可以通过单个 HTTP 和 HTTPS 负载均衡器或一对主动/被动配置的负载均衡器来实现 HA。在此设置中握手简历不是问题，因为只有一个 SSL/TLS 端点（通常会自动支持握手恢复）。
答案2
我的印象是，一旦建立连接，即使有负载平衡器，该会话中所有未来的连接都会发生在同一台服务器上？
也许这只是我使用过的网站和我配置过的服务的运行方式。
答案3
假设你正在使用 Apache，请查看分布式缓存。从手册页来看，“distcache 架构提供了一种协议和一组附带工具，允许应用程序（实际上是机器）通过网络服务在它们之间共享会话状态。”
“distcache 目前的主要用途是 SSL/TLS 会话缓存。这允许 SSL/TLS 服务器（例如提供 HTTPS 支持的安全 Apache Web 服务器）使用集中式会话缓存，即任何服务器都可以恢复网络上任何其他服务器协商的 SSL/TLS 会话。这种方法的优点包括增加了负载平衡机制的自由度。”