有了现代但速度不那么快的 x86 处理器，以及足够好的实现，加密速度不会成为瓶颈。例如，考虑一个相当便宜的 AMD Athlon 2650e 处理器，这是我在家庭文件服务器中使用的一个不那么现代且真正不那么快速的处理器；它的时钟频率为 1.6 GHz，具有单核。它仍然可以每秒执行大约 2200 次 RSA 私钥操作（对于 1024 位 RSA 密钥）。我严重怀疑这台机器运行的 Linux 内核是否可以处理每秒 2200 个新的 TCP 连接......

（请注意，对于与 RSA 相关的任何事情，在 64 位模式下运行 x86 CPU 是一个巨大的胜利——顺便说一句，这就是我使用廉价服务器所做的事情。在 32 位模式下，将数字除以 3 或 4 ; 这仍然是相当可观的表现。）

此外，SSL/TLS有一个称为“缩写握手”的功能，它是关于客户端再次连接并重用先前握手的非对称交换秘密。见标准第 7.3 节。缩写握手仅涉及对称加密，不涉及 RSA。请注意，在实践中，简短握手的最佳之处在于它意味着更少的网络数据包和更低的延迟；较低的 CPU 使用率很漂亮，但在实际测量时并不那么明显。

假设您仍然发现 SSL 的非对称部分对 CPU 预算的影响很大，那么您最好的选择仍然是“普通 RSA”密码套件，尽管可能与 ECDHE 密码套件有联系（但唯一的椭圆曲线是现有客户很好地支持的是 P-256 曲线，这很好，但如果您只针对 80 位安全性，这有点矫枉过正）。

SSL/TLS 也使用对称加密，而且也可以使用一些 CPU。x86 CPU 功能强大，足以加密所有可以通过 100 Mbits/s 链路的数据，但如果您正确选择算法，您可以节省一些费用。实际上，这意味着：使用 AES 或 RC4，而不是3DES。如果您的 CPU 提供AES-NI指令（当然，如果您的 SSL 实现使用它们），AES 将异常快速和便宜。

对于哈希算法，MD5 比 SHA-1 快一些，但 SHA-1在我便宜的 AMD CPU 上已经可以处理 240 Mbytes/s（兆字节，而不是兆位）。

因此，这指向TLS_RSA_WITH_RC4_128_SHA并TLS_RSA_WITH_AES_128_CBC_SHA成为谁希望以最少的 CPU 获得最多的每秒连接数的首选密码套件。或者可能是TLS_ECDHE_RSA_WITH_RC4_128_SHAor TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA，它不会得到广泛的支持，但会给你Perfect Forward Secrecy，这可能是一件好事。

话虽如此，性能在很大程度上取决于架构细节和确切的操作环境，因此您应该测量。尝试一下，看看更改密码套件是否会产生任何实际影响。请记住，性能通常更多地与在协议实现上投入的努力有关，而不是与算法本身的内在优点有关。