☰

HTTPS 负载平衡是否存在任何阻碍因素？

tag-icon • tag-icon load-balancing https
HTTPS 负载平衡是否存在任何阻碍因素？

HTTPS 负载平衡与 HTTP 负载平衡相比是否存在任何不利因素？

这可能是 HTTPS 无法在各个网站上普及的原因吗？（市场上有便宜的 CA）

答案1

我不确定詹姆斯是否正确。我的理解是 SSL 握手以请求/响应对开始和结束。即使 HTTPS 支持通过会话密钥恢复 TLS，这些恢复密钥也会与客户端一起位于前端负载均衡器上，而客户端将始终访问同一个负载均衡器。

话虽如此，完全有可能对 HTTPS 服务器进行负载平衡，我认为大多数人不这样做的原因是：

  • 解密 SSL 会产生大量开销。许多负载平衡器产品在硬件中执行此操作，并节省 Web 服务器（或 2 层配置中的应用服务器）上的计算时间
  • 在同一设备上解密和重新加密的开销会更多（可能是双倍）。
  • 理想情况下，它要求您在内部设置有效证书。这不需要花费任何金钱，但它需要金钱或可靠、安全的内部 CA。简而言之，这会增加管理开销。

答案2

您的问题似乎有点混乱。

如果你的意思是 HTTPS 相对于 HTTP 有什么缺点，那么：

1)速度慢了很多 - 虽然带宽开销不是很大，但问题依然是延迟 - SSL 每个请求至少需要 2 次额外的往返。

2）代理无法缓存数据——这使得速度更慢

3）对任何可能需要处理的东西都会产生重大影响 - 例如内容防火墙和负载平衡器

处理开销并不是那么大 - 性能问题都是关于网络延迟的 - 并且终止 Web 服务器上的 SSL 没有帮助。

答案3

这并不是证书的成本（尽管这有争议，并且往往取决于所使用的 CA 以及该 CA 的许可要求），而是服务器的成本。从实施的角度来看，HTTPS 流量与 HTTP 流量的负载平衡也没有太大区别。这都是成本驱动的。从 CPU 的角度来看，SSL 可能是一项昂贵的操作，无论是密钥交换还是数据的加密/解密。使用 HTTPS 时，您可以从服务器获得的并发用户总数将低于使用 HTTP 时获得的并发用户总数，这意味着您需要更多的服务器来执行相同的操作。

尽管它们确实运行良好，但卸载这些 SSL 操作的设备也可能相当昂贵。

“传统”网站（与 Web 应用程序相反）往往具有流量很大的网站组件，这些组件严格来说是营销内容，大部分是无状态和匿名流量。新闻稿、营销传播、产品规格表、可下载或在线演示等虽然对企业很重要，但都旨在将这些匿名用户转化为买家，但为什么要加密这些匿名流量呢？我认为网站管理员倾向于将此视为对计算资源的非最佳和不必要的使用。

然而，Web 2.0、社交网络和 Web 应用程序有所不同，它们应该采用 SSL 加密，主要是因为从本质上讲，用户和网站之间没有匿名性。毕竟，人们在 Twitter 或 Facebook 上做的第一件事往往就是登录。

答案4

嗯，HTTPS 不是无状态/无连接的；客户端必须对于后续连接，将返回同一服务器，因为会话密钥保存在该服务器的缓存中。使用 HTTP，只要内容在服务器之间复制，客户端访问哪个服务器并不重要，并且可以在后续请求中将它们发送到不同的服务器。

此外，人们在负载均衡器上终止 SSL 的主要原因之一是节省证书成本；在 LB 上放置一个证书，解密流量，以纯 HTTP 形式传递到您的服务器，然后通过负载均衡器重新加密返回流量。

我建议进一步阅读 SSL/TLS 握手过程： http://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake_in_detail

相关内容