我知道没有单一的硬性答案，但是对于 SSL 的加密开销与未加密的套接字通信是否有一个通用的数量级估计近似值？我说的只是通信处理和连线时间，不包括应用程序级处理。
更新
有一个关于 HTTPS 与 HTTP 的问题，但我有兴趣在堆栈中寻找更低的位置。
（我替换了短语“数量级”以避免混淆；我将其用作非正式的术语，而不是正式的 CompSci 意义上的。当然，如果我是正式的意思，作为一个真正的极客，我会考虑二进制而不是十进制！;-)
更新
根据评论中的请求，假设我们正在讨论持久连接上的大消息（范围为 1k-10k）。所以连接建立和数据包开销不是重要的问题。
数量级：零。
换句话说，当您添加 TLS 时，您不会看到吞吐量减半或类似情况。“重复”问题的答案主要集中在应用程序性能，以及与 SSL 开销相比如何。这个问题专门排除了应用程序处理，并试图将非 SSL 与 SSL 进行比较。虽然在优化时从全局角度看待性能是有意义的，但这不是这个问题要问的。
SSL 的主要开销是握手。这就是昂贵的非对称加密发生的地方。经过协商，使用相对有效的对称密码。这就是为您的 HTTPS 服务启用 SSL 会话非常有帮助的原因，在该服务中建立了许多连接。对于长期存在的连接，这种“最终效果”没有那么重要，会话也没有那么有用。
这是一个有趣的轶事。当 Google 将 Gmail 切换为使用 HTTPS 时，不需要额外的资源；没有网络硬件，没有新主机。它只增加了大约 1% 的 CPU 负载。
我第二个@erickson：纯粹的数据传输速度损失可以忽略不计。现代 CPU 达到数百 MBit/s 的加密/AES 吞吐量。因此，除非您使用的是资源受限的系统（手机），否则 TLS/SSL 的速度足够快，可以随意传输数据。
但请记住，加密使缓存和负载平衡变得更加困难。这可能会导致巨大的性能损失。
但是连接设置对于许多应用程序来说确实是一个障碍。在低带宽、高丢包率、高延迟连接（农村的移动设备）上，TLS 所需的额外往返可能会使某些东西变慢而无法使用。
例如，我们不得不放弃访问我们一些内部网络应用程序的加密要求——如果在中国使用，它们几乎无法使用。
假设您不计算连接设置（如您在更新中指出的那样），它在很大程度上取决于选择的密码。网络开销（就带宽而言）将可以忽略不计。CPU 开销将由密码学主导。在我的移动 Core i5 上，我可以在单核上使用 RC4 每秒加密大约 250 MB。（RC4 是您应该选择的最佳性能。） AES 速度较慢，“仅”提供大约 50 MB/s。因此，如果您选择正确的密码，即使您有一条充分利用的 1 Gbit 线路，您也不会设法让单个当前核心忙于加密开销。[编辑：不应该使用RC4，因为它不再安全。但是，现在许多 CPU 都支持 AES 硬件，这使得 AES 加密在此类平台上非常快。]
然而，连接建立是不同的。根据实现（例如，对 TLS 错误启动的支持），它将添加往返，这可能会导致明显的延迟。此外，在第一次建立连接时会发生昂贵的加密（如果您愚蠢地使用 4096 位密钥，上述 CPU 每秒只能接受每核 14 个连接，如果您使用 2048 位密钥，则每秒只能接受 100 个连接）。在随后的连接中，以前的会话经常被重用，避免了昂贵的加密。
所以，总结一下：
在已建立的连接上传输：
第一次连接建立：
后续连接建立：