SSL 会产生多少开销？
我知道没有单一的硬性答案，但是 SSL 与未加密套接字通信的加密开销是否有一个通用的数量级估计近似值？ 我只讨论通信处理和连线时间，不计算应用程序级处理。
更新
有关于 HTTPS 与 HTTP 的问题，但我'我有兴趣在堆栈中查找较低的部分。
（我替换了“数量级”一词以避免混淆；我将其用作非正式术语，而不是正式的 CompSci 意义上的。当然，如果我是正式的意思，那么作为一个真正的极客，我会考虑二进制而不是十进制！;-)
更新
根据评论中的请求，假设我们正在讨论持久连接上的大尺寸消息（范围为 1k-10k）。 因此，连接设置和数据包开销并不是重要问题。
I know there's no single hard-and-fast answer, but is there a generic order-of-magnitude estimate approximation for the encryption overhead of SSL versus unencrypted socket communication? I'm talking only about the comm processing and wire time, not counting application-level processing.
Update
There is a question about HTTPS versus HTTP, but I'm interested in looking lower in the stack.
(I replaced the phrase "order of magnitude" to avoid confusion; I was using it as informal jargon rather than in the formal CompSci sense. Of course if I had meant it formally, as a true geek I would have been thinking binary rather than decimal! ;-)
Update
Per request in comment, assume we're talking about good-sized messages (range of 1k-10k) over persistent connections. So connection set-up and packet overhead are not significant issues.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
数量级：零。
换句话说，当您添加 TLS 时，您不会看到吞吐量减半或类似情况。 “重复”问题的答案主要关注应用程序性能，以及与 SSL 开销的比较。 该问题明确排除了应用程序处理，并且旨在仅将非 SSL 与 SSL 进行比较。 虽然在优化时从全局角度看待性能是有意义的，但这并不是这个问题所要问的。
SSL 的主要开销是握手。 这就是昂贵的非对称加密发生的地方。 经过协商后，使用相对有效的对称密码。 这就是为什么为建立许多连接的 HTTPS 服务启用 SSL 会话非常有帮助。 对于长期连接，这种“最终效果”并不那么重要，并且会话也不那么有用。
这是一个有趣的轶事。当 Google 将 Gmail 切换为使用 HTTPS 时，不需要额外资源； 没有网络硬件，没有新主机。 它仅增加了大约 1% 的 CPU 负载。
Order of magnitude: zero.
In other words, you won't see your throughput cut in half, or anything like it, when you add TLS. Answers to the "duplicate" question focus heavily on application performance, and how that compares to SSL overhead. This question specifically excludes application processing, and seeks to compare non-SSL to SSL only. While it makes sense to take a global view of performance when optimizing, that is not what this question is asking.
The main overhead of SSL is the handshake. That's where the expensive asymmetric cryptography happens. After negotiation, relatively efficient symmetric ciphers are used. That's why it can be very helpful to enable SSL sessions for your HTTPS service, where many connections are made. For a long-lived connection, this "end-effect" isn't as significant, and sessions aren't as useful.
Here's an interesting anecdote. When Google switched Gmail to use HTTPS, no additional resources were required; no network hardware, no new hosts. It only increased CPU load by about 1%.
我第二@erickson：纯粹的数据传输速度损失可以忽略不计。 现代 CPU 的加密/AES 吞吐量可达数百 MBit/s。 因此，除非您使用的是资源受限的系统（手机），否则 TLS/SSL 的速度足以传输数据。
但请记住，加密会使缓存和负载平衡变得更加困难。 这可能会导致巨大的性能损失。
但对于许多应用程序来说，连接设置确实是一个阻碍。 在低带宽、高数据包丢失、高延迟连接（乡村的移动设备）上，TLS 所需的额外往返可能会使某些内容变得缓慢而无法使用。
例如，我们必须放弃访问某些内部网络应用程序的加密要求 - 如果从中国使用它们，它们几乎无法使用。
I second @erickson: The pure data-transfer speed penalty is negligible. Modern CPUs reach a crypto/AES throughput of several hundred MBit/s. So unless you are on resource constrained system (mobile phone) TLS/SSL is fast enough for slinging data around.
But keep in mind that encryption makes caching and load balancing much harder. This might result in a huge performance penalty.
But connection setup is really a show stopper for many application. On low bandwidth, high packet loss, high latency connections (mobile device in the countryside) the additional roundtrips required by TLS might render something slow into something unusable.
For example we had to drop the encryption requirement for access to some of our internal web apps - they where next to unusable if used from china.
假设您不计算连接设置（如您在更新中所示），它很大程度上取决于所选的密码。 网络开销（就带宽而言）可以忽略不计。 CPU 开销将由加密技术主导。 在我的移动 Core i5 上，我可以在单核上使用 RC4 每秒加密大约 250 MB。
（RC4 是您应该选择的最佳性能。）AES 速度较慢，“仅”提供大约 50 MB/s。 因此，如果您选择正确的密码，即使您拥有充分利用的 1 Gbit 线路，您也无法让单个当前核心忙于加密开销。 [编辑：不应使用 RC4，因为它不再安全。 然而，许多 CPU 中现在都支持 AES 硬件，这使得 AES 加密在此类平台上速度非常快。]然而，连接建立是不同的。 根据实现（例如，对 TLS 错误启动的支持），它将增加往返，这可能会导致明显的延迟。 此外，在第一次连接建立时会发生昂贵的加密（如果您愚蠢地使用 4096 位密钥，上述 CPU 每秒只能接受每个核心 14 个连接，如果您使用 2048 位密钥，则只能接受 100 个连接）。 在后续连接中，以前的会话通常会被重用，从而避免昂贵的加密。
因此，总结一下：
在已建立的连接上进行传输：
首次连接建立：
后续连接建立：
Assuming you don't count connection set-up (as you indicated in your update), it strongly depends on the cipher chosen. Network overhead (in terms of bandwidth) will be negligible. CPU overhead will be dominated by cryptography. On my mobile Core i5, I can encrypt around 250 MB per second with RC4 on a single core.
(RC4 is what you should choose for maximum performance.)AES is slower, providing "only" around 50 MB/s. So, if you choose correct ciphers, you won't manage to keep a single current core busy with the crypto overhead even if you have a fully utilized 1 Gbit line. [Edit: RC4 should not be used because it is no longer secure. However, AES hardware support is now present in many CPUs, which makes AES encryption really fast on such platforms.]Connection establishment, however, is different. Depending on the implementation (e.g. support for TLS false start), it will add round-trips, which can cause noticable delays. Additionally, expensive crypto takes place on the first connection establishment (above-mentioned CPU could only accept 14 connections per core per second if you foolishly used 4096-bit keys and 100 if you use 2048-bit keys). On subsequent connections, previous sessions are often reused, avoiding the expensive crypto.
So, to summarize:
Transfer on established connection:
First connection establishment:
Subsequent connection establishments: