这个问题没有一个单一的答案。

加密总是会消耗更多的CPU。在许多情况下，这可以卸载到专用的硬件上，成本将根据所选择的算法而变化。例如，3des比AES更贵。有些算法对加密者来说比解密者更昂贵。有些则有相反的代价。

比批量加密更昂贵的是握手成本。新的连接将消耗更多的CPU。这可以通过会话恢复来减少，代价是保留旧的会话秘密直到它们过期。这意味着来自客户端的小请求是最贵的。

对于跨互联网流量，您可能不会注意到数据速率的成本，因为可用带宽太低了。但您肯定会在繁忙的服务器上的CPU使用情况中注意到这一点。

TLS快吗?是的。

看:https://www.youtube.com/watch?v=0EB7zh_7UE4 阅读:https://istlsfastyet.com/

有许多项目旨在模糊界限，使HTTPS一样快。比如SPDY和mod-spdy。

有一种方法可以衡量这一点。来自apache的jmeter工具将测量吞吐量。如果您在受控环境中使用jmeter对您的服务进行了大量采样，无论是否使用SSL，都应该得到相对成本的准确比较。我对你的结果很感兴趣。

HTTPS确实会影响页面速度…

上面的引用揭示了许多人在网站安全和速度方面的愚蠢。HTTPS / SSL服务器握手会在进行互联网连接时造成初始停顿。在访问者的浏览器屏幕上开始呈现任何内容之前会有一个缓慢的延迟。这个延迟是用Time-to-First-Byte信息来衡量的。

HTTPS握手开销出现在时间到第一字节信息(TTFB)中。常见的TTFB范围从低于100毫秒(最好的情况)到超过1.5秒(最坏的情况)。但是，当然，使用HTTPS时，情况要差500毫秒。

无线3G连接的往返时间可以达到500毫秒甚至更多。额外的行程会使延迟加倍，达到1秒或更长时间。这对手机性能有很大的负面影响。非常坏的消息。

我的建议是，如果你不交换敏感数据，那么你根本不需要SSL，但如果你确实喜欢电子商务网站，那么你可以在某些交换敏感数据的页面上启用HTTPS，比如登录和结账。

来源:Pagepipe

开销不是由于加密造成的。在现代CPU上，SSL所需的加密是微不足道的。

造成这种开销的原因是SSL握手，它很长，并且极大地增加了HTTPS会话与HTTP会话之间所需的往返次数。

当服务器处于模拟的高延迟链接末端时，测量(使用Firebug等工具)页面加载时间。有工具可以模拟一个高延迟的链接——对于Linux，有“netem”。在相同的设置中比较HTTP和HTTPS。

延迟可以通过以下方法在一定程度上减轻:

确保您的服务器正在使用HTTP keepalives—这允许客户端重用SSL会话，从而避免了再次握手的需要 将请求的数量减少到尽可能少——通过在可能的地方组合资源(例如.js包括文件，CSS)和鼓励客户端缓存 减少页面加载的次数，例如，将不需要的数据加载到页面中(可能是隐藏的HTML元素)，然后使用client-script显示它。

这里似乎有一个令人讨厌的边缘情况:Ajax胜过拥塞的wifi。

Ajax通常意味着KeepAlive在20秒后超时。然而，wifi意味着(理想的快速)ajax连接必须进行多次往返。更糟糕的是，wifi经常丢包，并且有TCP重传。在这种情况下，HTTPS执行得非常非常糟糕!