SSL强加多less开销？
我知道没有一个硬性的答案，但是对于SSLencryption开销与未encryption的套接字通信，是否有一个通用的数量级估计近似值？ 我只谈通信处理和连线时间，不包括应用程序级别的处理。
更新
有一个关于HTTPS与HTTP的问题 ，但我有兴趣在堆栈中寻找更低的。
（为了避免混淆，我用“数量级”这个词来代替;我把它当作非正式的术语，而不是正式的CompSci意义上的，当然，如果我正式的意思，作为一个真正的极客，十进制！;-)
更新
根据每个请求的评论，假设我们正在讨论长连接上的大尺寸邮件（范围从1k到10k）。 所以连接build立和数据包开销并不重要。
数量级：零。
换句话说，当你添加TLS时，你不会看到你的吞吐量减半，或者类似的东西。 “重复”问题的答案主要集中在应用程序性能，以及如何与SSL开销进行比较。 此问题明确排除了应用程序处理，并试图将非SSL与SSL进行比较。 虽然在优化时对全局的性能视angular是有意义的，但这不是这个问题所要求的。
SSL的主要开销是握手。 这就是昂贵的不对称encryption发生的地方。 在谈判之后，使用相对高效的对称密码。 这就是为什么启用HTTPS服务的SSL会话非常有帮助的地方。 对于一个长期的连接，这个“最终效果”并不重要，会话也没有那么有用。
这是一个有趣的故事。 当Google将Gmail切换为使用HTTPS时，不需要额外的资源。 没有networking硬件，没有新的主机。 它只增加了大约1％的CPU负载。
我第二@erickson：纯粹的数据传输速度罚款可以忽略不计。 现代CPU达到几百MBit / s的encryption/ AES吞吐量。 所以除非你在资源受限的系统（移动电话）上，TLS / SSL足够快速地传输数据。
但请记住，encryption使得caching和负载平衡更加困难。 这可能会导致巨大的性能损失。
但连接设置对许多应用程序来说真的是一个阻碍。 在低带宽，高数据包丢失，高延迟连接（农村中的移动设备）的情况下，TLS所需的额外往返可能会使某些东西变慢，变得无法使用。
例如，我们不得不放弃访问我们的一些内部networking应用程序的encryption要求 – 如果在中国使用，那么这些应用程序就不可用。
假设您不计数连接设置（如您在更新中指示的那样），它强烈依赖于select的密码。 networking开销（就带宽而言）将可以忽略不计。 CPU开销将由密码学占主导地位。 在我的移动Core i5上，我可以在一个核心上用RC4encryption每秒250 MB左右。 （为了获得最佳性能，RC4是您应该select的。） AES速度较慢，提供“仅”约50 MB / s。 所以，如果你select正确的密码，即使你有一个充分利用的1 Gbit线路，你也不会设法保持一个当前核心忙于encryption开销。 [ 编辑 ：不应该使用RC4，因为它不再安全。 但是，AES硬件支持现在出现在许多CPU中，这使得AESencryption在这样的平台上真的很快。
然而，连接build立是不同的。 根据实施情况（例如支持TLS错误启动），将会增加往返时间，这可能导致明显的延迟。 另外，在第一次build立连接时会发生昂贵的encryption（如果你愚蠢地使用4096位密钥，那么上面提到的CPU只能接受每个核心每秒14个连接，如果你使用2048位密钥，则只能接受100个连接）。 在随后的连接中，以前的会话通常会被重复使用，避免了昂贵的encryption。
所以，总结一下：
在已build立的连接上转移
- 延迟：几乎没有
- CPU：可以忽略不计
- 带宽：可以忽略不计
首先build立连接：
- 延迟：额外往返
- 带宽：几千字节（证书）
- 客户端上的CPU：中等
- 服务器上的CPU：高
随后的连接机构：
- 延迟：额外往返（不确定如果一个或多个，可能是实现相关的）
- 带宽：可以忽略不计
- CPU：几乎没有
