SSL 会产生多少开销？答案

【问题标题】：How much overhead does SSL impose?SSL 会产生多少开销？
【发布时间】：2010-10-07 13:49:16
【问题描述】：

我知道没有单一的硬性答案，但是对于 SSL 与未加密套接字通信的加密开销，是否存在通用的 ~~数量级估计~~ 近似值？我说的只是通信处理和连线时间，不包括应用程序级处理。

更新

有a question about HTTPS versus HTTP，但我有兴趣在堆栈中寻找更低的位置。

（我替换了短语“数量级”以避免混淆；我将其用作非正式术语，而不是正式的 CompSci 意义。当然，如果我有是正式的意思，作为真正的极客，我会考虑二进制而不是十进制！;-)

更新

根据评论中的请求，假设我们正在讨论持久连接上的大尺寸消息（范围为 1k-10k）。所以连接建立和数据包开销并不是什么大问题。

【问题讨论】：

你可以看看这个类似的question。
您能否再描述一下您的应用程序？例如，它是否建立了很多短暂的连接？连接后，单个消息的大小往往有多大？（例如，您可能正在通过 SSL 隧道使用 Telnet 刷新每次按键操作，或者您正在复制 1 Tb 日志文件。）

标签： performance sockets ssl overhead

【解决方案1】：

数量级：零。

换句话说，当您添加 TLS 时，您不会看到吞吐量减半或类似情况。 "duplicate" question 的答案主要关注应用程序性能，以及它与 SSL 开销的比较。这个问题专门排除了应用程序处理，并试图将非 SSL 与 SSL 进行比较。虽然在优化时从全局角度看待性能是有意义的，但这不是这个问题要问的。

SSL 的主要开销是握手。这就是昂贵的非对称加密发生的地方。经过协商，使用相对有效的对称密码。这就是为什么为您的 HTTPS 服务启用 SSL 会话非常有帮助的原因，在该服务中建立了许多连接。对于长期存在的连接，这种“最终效果”没有那么重要，会话也没有那么有用。

这里是an interesting anecdote. 当 Google 将 Gmail 切换为使用 HTTPS 时，不需要额外的资源；没有网络硬件，没有新主机。它只增加了大约 1% 的 CPU 负载。

【讨论】：

您如何“为您的 HTTPS 服务启用 SSL 会话”？有什么好的资源可以了解这个？
@Bart van Heukelom -- Keep-alive 将有助于保持套接字（和 SSL 连接）打开更长时间，这会有所帮助。但是 SSL 会话会导致协商的加密参数从一个套接字“记住”到另一个套接字。所以 HTTP keep-alive 对于加载单个网页及其引用的内容很有用，但几秒钟后，该连接将关闭。三分钟后，比如说，当另一个页面被获取时，SSL 会话允许重新建立 SSL 连接，而无需重复完整的握手。特别是，可以跳过与公钥加密的慢密钥交换。
@Tony 您是否有任何现实世界的示例，其中 TLS 增加了超过百分之几的开销？我的回答和问题一样笼统。如果你有不同的看法，请分享。
@Tony 我已经看到，当一次写入一个字节时，普通套接字的空间性能比 SSL 套接字高 42 倍，这是最坏的情况。没见过250x。我在 Internet 上对 1700 个数据点进行了广泛的实验，一般结果是明文套接字的速度不比 SSL 快三倍，使用的编程并不比缓冲和刷新更复杂。 JSSE，考虑到实验日期，可能是 Java 5。
@Powerlord 引用的文章讨论了过时的算法，但我的回答没有，我坚持它的结论。加密一切。

【解决方案2】：

我第二个@erickson：纯粹的数据传输速度损失可以忽略不计。现代 CPU 达到数百 MBit/s 的加密/AES 吞吐量。因此，除非您使用的是资源受限的系统（手机），否则 TLS/SSL 的速度足够快，可以传输数据。

但请记住，加密使缓存和负载平衡变得更加困难。这可能会导致巨大的性能损失。

但连接设置确实是许多应用程序的障碍。在低带宽、高丢包率、高延迟连接（农村的移动设备）上，TLS 所需的额外往返可能会使某些东西变慢而无法使用。

例如，我们不得不放弃访问我们一些内部网络应用程序的加密要求 - 如果在中国使用，它们几乎无法使用。

【讨论】：

经过 4 年的事后看来：中国也可能故意搞砸了所有 SSL/TLS 流量。
中国审查互联网并试图嗅探每个人的流量并不是新闻。不过，经过 4 年的事后看来，您会认为是 NSA MITMing 在前往您的站点的路上。
连接不稳定的关键是，设置一次加密，除非真的必要，否则避免重新协商，并允许双方随时更改IP地址而无需眨眼。（OpenVPN 支持这一点。）IT 有助于使碎片化成为可能，因为 MTU 可能非常不可靠且完全不诚实。

【解决方案3】：

假设您不计算连接设置（如您在更新中指出的那样），这在很大程度上取决于选择的密码。网络开销（就带宽而言）将可以忽略不计。 CPU 开销将由密码学主导。在我的移动 Core i5 上，我可以在单核上使用 RC4 每秒加密大约 250 MB。 ~~（RC4 是您应该选择的最佳性能。）~~ AES 速度较慢，“仅”提供大约 50 MB/s。因此，如果您选择正确的密码，即使您拥有完全利用的 1 Gbit 线路，您也不会设法让单个当前核心忙于加密开销。 [编辑：不应使用 RC4，因为它不再安全。但是，现在许多 CPU 都支持 AES 硬件，这使得 AES 加密在此类平台上非常快速。]

但是，连接建立是不同的。根据实现（例如，对 TLS 错误启动的支持），它将添加往返，这可能会导致明显的延迟。此外，在第一次建立连接时会发生昂贵的加密（如果您愚蠢地使用 4096 位密钥，上述 CPU 每秒只能接受每核 14 个连接，如果您使用 2048 位密钥，则每秒只能接受 100 个连接）。在随后的连接中，以前的会话通常会被重用，从而避免了昂贵的加密。

所以，总结一下：

在建立连接时传输：

延迟：几乎没有
CPU：可以忽略不计
带宽：可以忽略不计

首次连接建立：

延迟：额外往返
带宽：几千字节（证书）
客户端 CPU：中等
服务器上的 CPU：高

后续连接建立：

延迟：额外的往返（不确定是一个还是多个，可能取决于实现）
带宽：可以忽略不计
CPU：几乎没有

【讨论】：

重要提示：没有人应该再使用 RC4。该协议必须被视为已损坏，并且必须将使用它的 RC4 传输视为至少等同于未加密传输，以确保间谍组织的安全。如今，由于独立于此类组织，强烈建议将 chacha20-poly1305 之类的东西用于批量加密。