终止大量 SSL 连接具有成本效益

Posted 2023-02-25

【中文标题】终止大量 SSL 连接具有成本效益

【英文标题】：Terminating a high volume of SSL connections cost effectively

【发布时间】：2012-02-22 10:56:08

【问题描述】：

我最近设置了一个基于 Node.js 的 Web 套接字服务器，该服务器经过测试可以在一个小型 EC2 实例 (m1.small) 上每秒处理大约 2,000 个新连接请求。考虑到 m1.small 实例的成本，以及将多个实例置于支持 WebSocket 的代理服务器（如 HAProxy）之后的能力，我们对结果非常满意。

但是，我们意识到我们尚未使用 SSL 进行任何测试，因此研究了一些 SSL 选项。很明显，在代理服务器上终止 SSL 连接是理想的，因为这样代理服务器可以检查流量并插入 X-Forward-For 等标头，以便服务器知道请求来自哪个 IP。

所以我研究了许多解决方案，例如 Pound、stunnel 和 stud，所有这些都允许终止 443 上的传入连接，然后传递到端口 80 上的 HAProxy，然后将连接传递到 Web 服务器.然而不幸的是，我发现向 c1.medium（高 CPU）实例上的 SSL 终止代理服务器发送流量非常快地消耗了所有 CPU 资源，并且每秒只有 50 个左右的请求。我尝试使用上面列出的所有三个解决方案，它们的性能与我假设的大致相同，它们都依赖于 OpenSSL。我尝试使用 64 位非常大的 High CPU 实例 (c1.xlarge)，发现性能仅与成本呈线性关系。因此，根据 EC2 定价，我需要为每秒 200 个 SSL 请求支付大约 600 美元/米，而每秒 2,000 个非 SSL 请求需要 60 美元/米。当我们开始计划每秒接受 1,000 或 10,000 个请求时，前一个价格在经济上很快变得不可行。

我还尝试使用 Node.js 的 https 服务器终止 SSL，其性能与 Pound、stunnel 和 stud 非常相似，因此该方法没有明显优势。

因此，我希望有人能提供帮助，建议我如何规避我们为提供 SSL 连接而必须承担的荒谬成本。我听说 SSL 硬件加速器提供了更好的性能，因为硬件是为 SSL 加密和解密而设计的，但是由于我们目前对所有服务器都使用 Amazon EC2，除非我们有单独的数据，否则不能使用 SSL 硬件加速器以物理服务器为中心。当成本如此之高时，我只是想看看亚马逊、谷歌、Facebook 等公司如何通过 SSL 提供所有流量。肯定有更好的解决方案。

任何建议或想法将不胜感激。

谢谢 马特

【问题讨论】：

“终止”一词至少在您的上下文中令人困惑。我花了一分钟左右的时间试图理解为什么要终止 SSL 连接以及为什么不直接关闭套接字。

太糟糕了 elb 不做网络套接字！您是否尝试过将可用于计算成本低的密码集限制为？

您是否尝试过使用带有 SSL 的 Amazon elb 来处理它？我将它用于我运行的几个 SaaS。工作正常。没有 2000 conn/sec 的要求，所以不知道是否可以

您能否提供用于测试/基准测试服务器的命令？您的测试客户在哪里，也在亚马逊云中？您是否尝试过同时从多个客户端进行测试？

我不能在一条评论中回答所有问题，所以每个问题都写一条评论...我使用了“终止”，因为这是大多数负载均衡器在谈论 SSL 时使用的术语，请参阅以下链接，aws.amazon.com/elasticloadbalancing，rackspace.com/cloud/cloud_hosting_products/loadbalancers/…，www.snapt-ui.com/haproxy/snapt-haproxy-ssl-termination-released/。很抱歉，如果它令人困惑。

【参考方案1】：

我刚刚意识到 Amazon 的弹性负载均衡器对于 SSL 终止非常慢...我在 www.blitz.io 上做了一个简单的测试（没有关系，只是一个客户），1 分钟内有 1 到 250 个并发连接。它严重失败了......但是如果我在 ELB 的前端执行 TCP 443 并在没有证书的后端执行 TCP 443，它会在该实例上运行 IIS 和 SSL 证书时清除一个小型实例的 CPU。我只需要握手，这是一个简单的 Web 服务，为来自各地的客户提供服务。每次都有新的连接设置和拆除。

如何设计高流量 SSL Web 服务，最好使用 SSL 一直到后端以严格遵守安全性？

【参考方案2】：

我对不同 EC2 实例上可用的 CPU 能力了解不多，但我认为您的问题不在于您选择的 TLS 终止代理软件，而在于它们的配置。 如果没有任何配置，我假设它们都将提供他们支持的所有密码套件，包括（非常）慢的。他们可能也会让客户选择最喜欢的那个。

并非所有 TLS 密码套件生来都是平等的，有些套件的 CPU 成本高于其他套件，无论是来自密钥交换还是密码本身。 根据所使用的软件，应该有一种方法可以指定服务器接受的一串密码（还有一种方法可以让服务器坚持这一点）。对于 OpenSSL，这些工作方式如下：http://www.openssl.org/docs/apps/ciphers.html#CIPHER_STRINGS

如果您追求速度，至少要确保您没有使用采用 Diffie-Hellmann（非椭圆曲线类型）密钥交换的密码。 要使用 DH 密钥交换禁用密码套件，请确保字符串在某些时候包含 !DH。 您可以测试哪些字符串导致哪些密码可用，例如openssl ciphers -v 'HIGH:!aNULL:!DH:!ECDH'。

此字符串禁用正常的 Diffie-Hellman 以及椭圆曲线 Diffie-Hellmann 密钥交换。这可能只剩下 RSA 密钥交换，具体取决于您的 OpenSSL 版本。

关于密码，您可能应该在预期的 EC2 硬件上进行测试。如果没有硬件加速，您可能应该更喜欢 RC4 而不是 AES128 而不是 AES256，at least according to this benchmark。

我还建议阅读this wonderful post，尤其是第一个显示 DH 对 TLS 握手性能影响的启发性图表。

最后，确保您使用的是 TLS 会话缓存。这也节省了一些 CPU。

【参考方案3】：

我也想知道如何有效地做到这一点。 AWS ssl 终止速度非常慢，但也许有一些方法可以提高其性能。 Stud 看起来很有希望，但就像你提到的那样，CPU 成本也很高。

【参考方案4】：

Node.js 的 https 服务器的性能与 Pound、stunnel 和 stud 非常相似，这种方法没有明显的优势。

【讨论】：

那么可以说是有。假设 Node 的 HTTPS 性能相似，那么您会争论为什么要在 Node.js 前面使用 Pound / Stunnel / Stud，因为它只是在系统中增加了另一个瓶颈和组件。