SSL 会产生多少开销？

Question

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

更新

有一个关于 HTTPS 与 HTTP 的问题

，但我有兴趣在堆栈的较低部分进行查找。

（我替换了“数量级”一词以避免混淆；我将其用作非正式术语，而不是正式的 CompSci 意义上的。当然，如果我 had

是正式的意思，那么作为一个真正的极客，我会一直在想二进制而不是十进制！

更新

对于评论中的每个请求，假设我们正在讨论持久连接上的大尺寸消息（范围为 1k-10k）。因此连接设置和数据包开销并不是重要问题。

数量级：零。

Answer 1

“重复”问题

的答案重点关注应用程序性能，以及与 SSL 开销的比较。该问题明确排除了应用程序处理，并且旨在仅将非 SSL 与 SSL 进行比较。虽然在优化时从全局角度看待性能是有意义的，但这并不是这个问题所要问的。

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

这里有一个有趣的轶事。

当 Google 将 Gmail 改用 HTTPS 时，不需要额外的资源；没有网络硬件，没有新主机。仅增加了约 1% 的 CPU 负载。

---

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

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

Answer 2

但是连接设置对于许多应用程序来说确实是一个阻碍。在低带宽、高数据包丢失、高延迟连接（乡村的移动设备）上，TLS 所需的额外往返可能会使某些内容变得缓慢而无法使用。

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

2024 年编辑：使用 HTTP/2+，延迟问题会

低很多

。

假设您不计算连接设置（如您在更新中所示），它很大程度上取决于所选的密码。网络开销（就带宽而言）可以忽略不计。 CPU 开销将由加密技术主导。在我的移动 Core i5 上，我可以在单核上使用 RC4 每秒加密大约 250 MB。 （您应该选择 RC4 以获得最佳性能。）

AES 速度较慢，“仅”提供大约 50 MB/s。因此，如果您选择正确的密码，即使您拥有充分利用的 1 Gbit 线路，您也无法让单个当前核心忙于加密开销。 [

Answer 3

：不应使用 RC4，因为它不再安全。然而，许多 CPU 中现在都支持 AES 硬件，这使得 AES 加密在此类平台上非常快。]

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

在已建立的连接上传输：

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

带宽：可以忽略不计
首次连接建立：

延误：额外往返 带宽：几千字节（证书）

客户端CPU：中等
服务器上的CPU：高
后续连接建立：

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

CPU：几乎没有