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

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

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

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

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

TLS快吗?是的。

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

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

在许多情况下，SSL握手对性能的影响将由于SSL会话可以缓存在两端(桌面和服务器)而得到缓解。例如，在Windows机器上，SSL会话可以缓存长达10个小时。见http://support.microsoft.com/kb/247658/EN-US。一些SSL加速器还具有允许您优化会话缓存时间的参数。

另一个需要考虑的影响是，通过HTTPS提供的静态内容不会被代理缓存，这可能会降低通过同一个代理访问站点的多个用户的性能。这可以通过静态内容也会缓存到桌面的事实来缓解，Internet Explorer版本6和7缓存可缓存的HTTPS静态内容，除非另有指示(工具菜单/Internet选项/高级/安全/不将加密页面保存到磁盘)。

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

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

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

我可以告诉你(作为一个拨号用户)，通过SSL访问同一个页面要比通过常规HTTP慢几倍…