我知道没有单一的硬性答案，但是对于SSL的加密开销与未加密的套接字通信，是否存在通用的数量级估计值近似值？我只谈论通信处理和线路时间，而不是计算应用级处理。
更新
有a question about HTTPS versus HTTP，但我有兴趣在堆栈中看得更低。
（我替换了“数量级”这个短语以避免混淆;我使用它作为非正式行话，而不是正式的CompSci意义。当然，如果我有正式表示它，作为一个真正的极客我会一直在思考二进制而不是十进制！; - ）
更新
评论中的每个请求，假设我们正在谈论持久连接上的大小良好的消息（范围为1k-10k）。因此，连接建立和数据包开销不是重要问题。
答案 0 :(得分：174)
数量级：零。
换句话说，当您添加TLS时，您不会看到您的吞吐量减少一半或类似的东西。 "duplicate" question的答案主要关注应用程序性能，以及与SSL开销的比较。此问题明确排除了应用程序处理，并试图仅将非SSL与SSL进行比较。虽然在优化时采用全局性能视图是有意义的，但这不是这个问题所要求的。
SSL的主要开销是握手。这就是昂贵的非对称加密技术发生的地方。在协商之后，使用相对有效的对称密码。这就是为什么为您的HTTPS服务启用SSL会话非常有用，因为HTTPS服务建立了许多连接。对于长期连接，这种“终端效应”并不那么重要，会话也没那么有用。
以下是an interesting anecdote.当Google将Gmail切换为使用HTTPS时，无需其他资源;没有网络硬件，没有新主机。它只增加了1％的CPU负载。
答案 1 :(得分：39)
我是第二个@erickson：纯粹的数据传输速度惩罚可以忽略不计。现代CPU达到几百MBit / s的加密/ AES吞吐量。因此，除非您使用资源受限系统（移动电话），否则TLS / SSL的速度足够快，可以用于存储数据。
但请记住，加密使缓存和负载平衡更加困难。这可能会导致巨大的性能损失。
但是连接设置实际上是许多应用程序的显示阻止。在低带宽，高数据包丢失，高延迟连接（乡村移动设备）上，TLS所需的额外往返可能会使某些东西变得无法使用。
例如，我们不得不放弃访问我们的一些内部网络应用程序的加密要求 - 如果在中国使用，它们旁边就无法使用。
答案 2 :(得分：11)
假设您没有计算连接设置（如您在更新中所示），它很大程度上取决于所选的密码。网络开销（带宽方面）可以忽略不计。 CPU开销将由密码学主导。在我的移动Core i5上，我可以在一个内核上使用RC4每秒加密大约250 MB。 （RC4是您应该选择的最佳性能。） AES速度较慢，仅“50”/秒左右。因此，如果您选择了正确的密码，即使您拥有充分利用的1 Gbit线路，也无法保持单个当前核心忙于加密开销。 [修改：不应使用RC4，因为它不再安全。但是，AES硬件支持现在存在于许多CPU中，这使得AES加密在这些平台上非常快。]
然而，连接建立是不同的。根据实施情况（例如支持TLS错误启动），它会增加往返次数，这可能会导致明显的延迟。另外，在第一个连接建立时发生了昂贵的加密（如果您愚蠢地使用4096位密钥，上述CPU每秒只能接受每个核心14个连接，如果使用2048位密钥，则只能接受100个连接）。在后续连接中，以前的会话经常被重用，避免了昂贵的加密。
所以，总结一下：
转移已建立的连接：
首次建立连接：
后续连接机构：