HTTP与HTTPS性能

http和https在性能上有什么主要的区别吗?我似乎记得读到过HTTPS的速度是HTTP的五分之一。这对当前的web服务器/浏览器有效吗?如果有，是否有相关白皮书支持?

240892 次浏览
小开

考虑到SSL需要一个非sll HTTP不需要的额外加密步骤，这几乎肯定是正确的。

小开

HTTPS有加密/解密的开销，所以它总是会稍微慢一点。SSL终止是非常消耗CPU的。如果您有卸载SSL的设备，则延迟的差异可能几乎不明显，这取决于服务器所处的负载。

小开

一个更重要的性能差异是HTTPS会话在用户连接时保持打开。一个HTTP“会话”只持续一个项目请求。

如果你正在运行一个有大量并发用户的网站，预计会购买大量内存。

小开

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

小开
最佳答案

有几个工具可以比较HTTP和HTTPS服务器的性能(想到了JMeter和Visual Studio)，它们很容易使用。

没有关于你的网站、硬件、软件和网络配置的一些信息，没有人能给你一个有意义的答案。

正如其他人所说，由于加密，会有一定程度的开销，但它高度依赖于:

  • 硬件
  • 服务器软件
  • 动态与静态内容的比例
  • 客户端到服务器的距离
  • 典型会话长度
  • 等等(我个人的最爱)
  • 客户端的缓存行为

根据我的经验，动态内容较多的服务器受HTTPS的影响较小，因为与内容生成时间相比，加密所花费的时间(ssl开销)微不足道。

大量服务于相当小的静态页面集(这些页面可以很容易地缓存在内存中)的服务器会遭受更高的开销(在一个案例中，吞吐量在“内部网”上受到了影响)。

编辑:有一点已经被其他几个人提出，SSL握手是HTTPS的主要成本。这是正确的，这就是为什么“典型会话长度”和“客户端的缓存行为”很重要。

很多非常短的会议意味着握手时间将压倒其他任何表现因素。较长的会话将意味着在会话开始时产生握手成本，但后续请求的开销将相对较低。

客户端缓存可以分几个步骤完成，从大型代理服务器到单个浏览器缓存都可以。通常HTTPS内容不会缓存在共享缓存中(尽管一些代理服务器可以利用中间人类型的行为来实现这一点)。许多浏览器为当前会话缓存HTTPS内容，而且通常是跨会话缓存。不缓存或较少缓存的影响意味着客户端将更频繁地检索相同的内容。这将导致为相同数量的用户提供更多的请求和带宽。

小开

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

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

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

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

小开

HTTPS需要第一次握手，这可能非常慢。作为握手的一部分，实际传输的数据量并不大(通常不超过5 kB)，但对于非常小的请求，这可能是相当大的开销。但是，一旦握手完成，就会使用一种非常快速的对称加密形式，因此开销很小。底线:通过HTTPS进行大量的短请求将比HTTP慢一些，但如果您在一个请求中传输大量数据，差异将是微不足道的。

然而，keepalive是HTTP/1.1中的默认行为，因此您将在同一个连接上进行单握手，然后进行大量请求。这对HTTPS产生了重大影响。您可能应该对站点进行概要分析(正如其他人建议的那样)以确保这一点，但我怀疑性能差异不会很明显。

小开

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

小开

除了到目前为止提到的所有内容，请记住，出于安全原因，一些(所有?)web浏览器不会将通过HTTPS获得的缓存内容存储在本地硬盘上。这意味着，从用户的角度看，在浏览器重启后，含有大量静态内容的页面加载速度会变慢，而从服务器的角度看，通过HTTPS请求静态内容的量将比通过HTTP请求的量要高。

小开

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

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

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

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

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

要真正理解HTTPS如何增加延迟，您必须了解HTTPS连接是如何建立的。这是一个漂亮的图。关键在于，客户端不是在2个“腿”(一个往返，你发送一个请求，服务器发送一个响应)后才获得数据，而是至少要到4个“腿”(2个往返)后才能获得数据。因此，如果一个数据包在客户端和服务器之间移动需要100毫秒，那么您的第一个HTTPS请求至少需要500毫秒。

当然，这可以通过重新使用HTTPS连接来缓解(浏览器应该这样做)，但它确实解释了加载HTTPS网站时的部分初始停滞。

小开

当前最上面的答案不完全正确。

正如其他人在这里指出的，https需要握手，因此需要更多的TCP/IP往返。

在WAN环境中，延迟通常成为限制因素，而不是服务器上增加的CPU使用量。

请记住，从欧洲到美国的延迟大约是200毫秒(往返时间)。

你可以很容易地用HTTPWatch来测量(对于单用户情况)。

小开

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

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

小开

因为我正在为我的项目调查同样的问题，我发现了这些幻灯片。年长但有趣:

http://www.cs.nyu.edu/artg/research/comparison/comparison_slides/sld001.htm

小开

TLS快吗?是的。

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

小开

这里有一篇关于SSL握手延迟的很棒的文章(有点老，但仍然很棒)。帮助我确定SSL是客户端通过较慢的互联网连接使用我的应用程序的缓慢的主要原因:

http://www.semicomplete.com/blog/geekery/ssl-latency.html

小开

我做了一个小实验，从flickr (233 kb)上获得了16%的时差:

http://farm8.staticflickr.com/7405/13368635263_d792fc1189_b.jpg

https://farm8.staticflickr.com/7405/13368635263_d792fc1189_b.jpg

enter image description here

当然，这些数字取决于许多因素，如计算机性能、连接速度、服务器负载、路径上的QoS(从浏览器到服务器的特定网络路径)，但它显示了一个大致的想法:HTTPS比HTTP慢，因为它需要更多的操作来完成(SSL握手和编码/解码数据)。

小开

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

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

小开

2014年12月更新

您可以通过AnthumChris在自己的浏览器中使用HTTP vs HTTPS Test网站轻松测试HTTP和HTTPS性能之间的差异:“此页面测量其在不安全的HTTP和加密HTTPS连接上的加载时间。这两个页面都加载了360张独特的非缓存图像(总计2.04 MB)。”

结果可能会让你大吃一惊。

由于Mozilla、Akamai、Cisco、电子前沿基金会和IdenTrust的支持，Let 's Encrypt证书颁发机构将在2015年夏天开始颁发免费、自动化和开放的SSL证书，因此了解HTTPS性能的最新知识非常重要。

2015年6月更新

Let 's Encrypt更新-到2015年9月:

更多Twitter信息:@letsencrypt

有关HTTPS和SSL/TLS性能的更多信息，请参阅:

有关使用HTTPS的重要性的更多信息，请参阅:

总结一下，让我引用Ilya Grigorik: “TLS只有一个性能问题:它的应用不够广泛。其他一切都可以优化。”

感谢克里斯 (HTTP与HTTPS测试基准测试的作者)在下面的评论。

小开

HTTP和HTTPS性能比较

与传统的HTTP相比，我总是将HTTPS与较慢的页面加载时间联系起来。作为一个网页开发人员，网页性能对我来说很重要，任何会降低我网页性能的东西都是禁忌。

为了理解所涉及的性能影响，下面的图向您提供了使用HTTPS对资源发出请求时的基本概念。

enter image description here

从上图中可以看出，与使用普通HTTP相比，使用HTTPS需要执行一些额外的步骤。当您使用HTTPS发出请求时，需要进行握手以验证请求的真实性。与HTTP请求相比，这个握手是一个额外的步骤，不幸的是会引起一些开销。

为了理解性能影响并亲自查看性能影响是否显著，我使用这个站点作为测试平台。我访问了webpagetest.org，并使用可视化比较工具来比较使用HTTPS和HTTP加载的站点。

正如你可以从这里是测试视频结果中看到的，使用HTTPS确实对我的页面加载时间有影响，但这种差异可以忽略不计，我只注意到300毫秒的差异。需要注意的是，这些时间取决于许多因素，如计算机性能、连接速度、服务器负载以及与服务器的距离。

您的站点可能有所不同，因此彻底测试您的站点并检查切换到HTTPS所涉及的性能影响非常重要。

小开

浏览器可以使用HTTP或HTTPS接受HTTP/1.1协议，但浏览器只能使用HTTPS处理HTTP/2.0协议。从HTTP/1.1到HTTP/2.0的协议差异使得HTTP/2.0比HTTP/1.1平均快4-5倍。此外，在实现HTTPS的网站中，大多数都是通过HTTP/2.0协议实现的。因此，HTTPS几乎总是比HTTP快，这仅仅是因为它通常使用不同的协议。然而，如果将基于HTTP/1.1的HTTP与基于HTTP/1.1的HTTPS进行比较，那么平均而言，HTTP比HTTPS略快。

以下是我使用Chrome(版本64)运行的一些比较:

HTTPS over HTTP/1.1:

  • 0.47秒的平均页面加载时间
  • 在HTTP/1.1上比HTTP慢0.05秒
  • 比HTTP/2.0上的HTTPS慢0.37秒

HTTP over HTTP/1.1

  • 0.42秒的平均页面加载时间
  • 比HTTP/1.1上的HTTPS快0.05秒
  • 比HTTP/2.0上的HTTPS慢0.32秒

HTTPS over HTTP/2.0

  • 平均加载时间0.10秒
  • 在HTTP/1.1上比HTTP快0.32秒
  • 比HTTPS/1.1快0.37秒
小开

HTTPS确实会影响页面速度…

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

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

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

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

来源:Pagepipe


提交答案