SSL 开销有多大？

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

更新

有 一个关于 HTTPS 和 HTTP 的问题，但我感兴趣的是在堆栈中寻找更低的。

(为了避免混淆，我把“数量级”这个词换成了非正式的术语，而不是正式的 CompSci 意义上的术语。当然，如果我 曾经的意思是正式的，作为一个真正的极客，我会认为二进制而不是十进制！;-)

更新

对于注释中的每个请求，假设我们讨论的是持久连接上的大小合适的消息(范围为1k-10k)。因此，连接设置和数据包开销并不是重要问题。

108891 次浏览
小开
最佳答案

数量级: 0。

换句话说，当您添加 TLS 时，您不会看到吞吐量减少一半，或者任何类似的情况。“重复”问题的答案主要集中在应用程序性能，以及与 SSL 开销的比较。这个问题明确地排除了应用程序处理，并试图仅比较非 SSL 和 SSL。虽然在优化时采用全局性能观点是有意义的，但这并不是这个问题要问的。

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

这是 一个有趣的轶事。当 Google 将 Gmail 转换为使用 HTTPS 时，不需要额外的资源; 不需要网络硬件，不需要新的主机。它只增加了大约1% 的 CPU 负载。

小开

我附议@erickson: 纯数据传输速度的损失可以忽略不计。现代 CPU 的加密/AES 吞吐量达到几百 MBit/s。因此，除非您使用的是资源受限的系统(移动电话) ，否则 TLS/SSL 对于传输数据来说已经足够快了。

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

但是对于许多应用程序来说，连接设置实际上是一个阻碍。在低带宽、高数据包丢失、高延迟连接(乡村移动设备)的情况下，TLS 所需的额外往返可能会使某些缓慢的东西变成不可用的东西。

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

小开

假设您不计算连接设置(正如您在更新中指出的那样) ，那么它很大程度上取决于所选择的密码。网络开销(就带宽而言)可以忽略不计。CPU 开销将由密码学控制。在我的移动 Corei5上，我可以用 RC4在一个核上每秒加密大约250MB。(为了获得最佳性能，您应该选择 RC4。) AES 比较慢，“只”提供大约50MB/s。因此，如果您选择正确的密码，即使您有一个充分利用的1 Gbit 线路，您也不会设法使单个当前核心忙于加密开销。[ 剪辑: RC4不应该被使用，因为它不再安全。然而，AES 硬件支持现在存在于许多 CPU 中，这使得 AES 加密在这样的平台上真的很快。]

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

总结一下:

根据已建立的连接进行转移:

  • 延迟: 几乎没有
  • 微不足道
  • 带宽可以忽略不计

第一连接建立:

  • 延误: 增加往返
  • 带宽: 几千字节(证书)
  • 客户端 CPU: 中等
  • 服务器 CPU: 高

随后的连接机构:

  • 延迟: 额外的往返(不确定是一个还是多个，可能与实现有关)
  • 带宽可以忽略不计
  • 几乎没有

提交答案