数量级：零。
换句话说，当您添加TLS时，您不会看到吞吐量减半或其他任何影响。对于“重复”问题的答案主要关注应用程序性能及其与SSL开销的比较。而这个问题特别排除了应用程序处理，并且仅寻求非SSL和SSL之间的比较。在优化时考虑总体性能是有意义的，但这不是这个问题所问的。
SSL的主要开销在于握手。那是昂贵的非对称加密发生的地方。在协商之后，使用相对高效的对称密码。那就是为什么在HTTPS服务中启用SSL会非常有帮助，因为许多连接被建立。对于长期存在的连接，“结束效应”并不那么显着，而且会话没有那么有用。
这里有有趣的轶事。当Google将Gmail切换为使用HTTPS时，不需要额外的资源，也不需要网络硬件或新主机。它只增加了大约1％的CPU负载。
我同意@erickson的观点：单纯的数据传输速度惩罚可以忽略不计。现代CPU的加密/AES吞吐量达到几百兆比特/秒。因此，除非您在资源受限的系统上（移动电话），否则TLS/SSL足够快地处理数据。
但要记住，加密使缓存和负载平衡变得更加困难。这可能导致巨大的性能惩罚。
但是连接设置确实是许多应用程序的绊脚石。在带宽低、丢包率高、延迟高的连接（乡村地区的移动设备）上，TLS需要的附加往返可能会使某些东西变慢而无法使用。
例如，我们不得不放弃对一些内部Web应用程序的访问要求加密——如果从中国使用，它们几乎无法使用。
假设你不计算连接建立(正如你在更新中所指示的一样)，其主要取决于所选择的密码。网络开销(以带宽为单位)将是可忽略的。CPU开销将被加密支配。在我的移动Core i5上，我可以使用单个核心在每秒加密大约250 MB的RC4。[(RC4是你应该选择的最佳性能.)]AES更慢，仅提供大约50 MB/s。因此，如果选择正确的密码，即使您拥有完全利用的1 Gbit线路，也无法使单个当前核心繁忙处理加密开销。
然而，连接建立是不同的。根据实现方式（例如支持TLS错误启动），它将添加往返，这可能会导致明显的延迟。此外，第一次连接建立时进行昂贵的加密操作(如果您愚蠢地使用了4096位密钥，则上述CPU每个核心每秒只能接受14个连接，如果您使用2048位密钥，则为100个)。在随后的连接中，通常会重用以前的会话，避免昂贵的加密。
所以，总结一下：
已建立连接的传输：
第一次连接建立：
随后的连接建立：
