HTTP vs HTTPS性能


363

http和https之间在性能方面有什么主要区别吗?我似乎还记得阅读过的文章,HTTPS的速度可以是HTTP的五分之一。这对于当前的网络服务器/浏览器有效吗?如果是这样,是否有任何白皮书来支持它?


1
您还应该签出HTTP2,该浏览器当前仅在与HTTPS一起使用时才受支持。en.wikipedia.org/wiki/HTTP/2
卢卡Steeb

1
https总是比http(或慢得多)慢。
i486

如果发生了一些透明的缓存(例如,乌贼),那么这可能很重要。协议本身,我认为它没有太大的开销。
罗尔夫

Answers:


231

对此有一个非常简单的答案:对Web服务器的性能进行分析,以了解特定情况下的性能损失。有几种工具可以比较HTTP与HTTPS服务器的性能(想到了JMeter和Visual Studio),它们非常易于使用。

没有有关网站的性质,硬件,软件和网络配置的某些信息,没有人能给您一个有意义的答案。

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

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

以我的经验,因为内容加密所花的时间(SSL开销)与内容生成时间相比微不足道,所以对动态内容非常重视的服务器受HTTPS的影响较小。

大量服务于可以轻松地缓存在内存中的静态页面集的服务器遭受了高得多的开销(在一种情况下,吞吐量被“内部网”吞噬了)。

编辑:其他几个人提出的一个观点是SSL握手是HTTPS的主要成本。没错,这就是为什么“典型会话长度”和“客户端的缓存行为”很重要的原因。

许多非常短的会话意味着握手时间将压倒任何其他性能因素。较长的会话将意味着握手成本将在会话开始时发生,但后续请求的开销相对较低。

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


James,希望您可以就此aSSL解决方案的相对速度提供简短的评论:assl.sullof.com/assl精打细算 ,在性能方面有什么收获吗?谢谢!
马特·加德纳

PS:据我了解,该解决方案需要一个客户端密钥(可以在webkit / titanium应用程序中实现),目标只是最大限度地提高速度方程的这一部分以及您提到的其他部分。
马特·加德纳

7
这篇文章并没有真正回答这个问题。Jim Geurts似乎在询问HTTP和HTTPS本身的性能本质,而不是特定的实现。毫无疑问,HTTPS速度较慢,因为它可以完成更多工作。所以问题是,速度要慢多少?大家都知道,如果添加更多变量,则会得到不同的结果。
艾略特·卡梅伦

73
这个答案一开始提到很多无关紧要的东西(换句话说是错误的)。他用了5个段落来得出正确的答案,即握手
bobobobo

2
通过HTTPS提供的内容不会被代理缓存。默认情况下,所有现代浏览器均默认缓存HTTPS内容,除非Jeff Atwood
指示不要这样做

222

HTTPS需要初始握手,这可能会很慢。作为握手的一部分,传输的实际数据量并不大(通常小于5 kB),但是对于非常小的请求,这可能会产生相当大的开销。但是,一旦握手完成,就会使用非常快速的对称加密形式,因此开销很小。底线:通过HTTPS发出大量短请求将比HTTP慢很多,但是如果在单个请求中传输大量数据,则差异将不明显。

但是,keepalive是HTTP / 1.1中的默认行为,因此您将进行一次握手,然后在同一连接上进行大量请求。这对HTTPS来说有很大的不同。您可能应该配置您的网站(按照其他人的建议),以确保这一点,但是我怀疑性能差异不会很明显。


19
事实证明,由于大多数浏览器使用同一服务器的多个连接,因此每次会话的握手费用至少约为4-10倍。根据浏览器使用https-keep-alive的时间长短,会话期间可能会反复发生。
James Schek

6
关于HTTP Keepalive功能,我们经历了连接不保持持久的情况。对于每个请求,都将建立并断开请求连接,这意味着MA-SSL握手。客户端或服务器可能已配置为关闭连接。通常发生在Tomcat / Websphere环境中。
zkarthik

8
@JamesSchek多个连接应重用同一个SSL会话,这会大大改变图片。即使HTTP保持活动无效,也是如此。
2013年

14
@EJP是的。并且在2013年,大多数浏览器/服务器和SSL / TLS实施都利用了会话重用。在2008年,这并不总是一个安全的假设。
James Schek

3
这个问题在Google中对于“ http vs https performance”表现得很高。尽管上述答案在2008年是正确的,但在2015年就不再适用,因此不应将其用作避免使用https的决策依据。
Paul Schreiber 2015年

101

要真正了解HTTPS如何增加延迟,您必须了解HTTPS连接是如何建立的。这是一个不错的图。关键是客户端不是在2个“行程”之后获得数据(一次往返,您发送一个请求,服务器发送一个响应),而是直到至少4个行程(两次往返),客户端才获取数据。 。因此,如果数据包在客户端和服务器之间移动需要100毫秒,则您的第一个HTTPS请求将至少花费500毫秒。

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


1
就Java客户端而言,如何使HTTPS连接可重用?我的意思是,我可以使HttpsConnection成为静态对象并重新使用它吗?(在网络应用程序上下文中)
Niks

1
5年后,指向+1图表的链接无效,有人能找到它并将其放在答案中而不是链接吗?
吉姆·沃尔夫

2
@FRoZen找到了替代链接
Stefan L

我也认为此页面是一个非常好的http图表,可以更好地理解整个图片: blog.catchpoint.com/2010/09/17/anatomyhttp
椭圆视图

1
@Nikhil Java会自动重用基础连接,并在请求之间共享它,除非用户通过强制disconnect。检查文档
Mohnish

76

开销不是由于加密引起的。在现代CPU上,SSL所需的加密非常简单。

开销归因于SSL握手,这很长,并且极大地增加了HTTPS会话通过HTTP会话所需的往返次数。

当服务器位于模拟的高延迟链接的末端时,测量(使用Firebug等工具)页面加载时间。存在用于模拟高延迟链接的工具-对于Linux,存在“ netem”。在相同设置下将HTTP与HTTPS进行比较。

可以通过以下方式在某种程度上减轻延迟:

  • 确保您的服务器正在使用HTTP Keepalive-这允许客户端重用SSL会话,从而避免了再次握手的需要
  • 将请求数量减少到最少-通过在可能的情况下合并资源(例如.js包括文件,CSS)并鼓励客户端缓存
  • 减少页面加载的次数,例如,通过将不需要的数据加载到页面中(也许在隐藏的HTML元素中),然后使用客户端脚本进行显示。

8
我非常赞同@MarkR。我最近的主页配置文件HTTP vs HTTPS,平均加载时间分别为1.5秒和4.5秒。当查看连接详细信息时,最大的减速因素是由于SSL握手而产生的额外往返行程。超过3G的移动浏览器甚至更糟。数字分别为5s和9s。
克林特·帕奇

26

2014年12月更新

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

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

重要的是要拥有最新的HTTPS性能知识,因为感谢Mozilla,Akamai,Cisco,Electronic Frontier Foundation和IdenTrust,“ 让我们的加密证书颁发机构”将于2015年夏季开始发行免费,自动化和开放的SSL证书。

2015年6月更新

让我们加密的更新-将于2015年9月发布:

Twitter上的更多信息:@letsencrypt

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

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

综上所述,让我引用Ilya Grigorik的话“ TLS 确实存在一个性能问题:它的使用范围不够广泛。其他所有内容都可以优化。”

感谢ChrisHTTP与HTTPS测试基准测试的作者)在下面的评论。


6
“ HTTP vs HTTPS测试”是故意欺骗的,请不要链接到它。该页面的实际作用是将HTTP与SPDY进行比较。的确如此,如果您不相信我,请在IE中尝试一下,然后看看它怎么说。在任何情况下,HTTP请求都不会比等效的HTTPS请求快。
2015年

3
Google强迫SPDY仅出于政治原因而不是技术原因使用安全连接。HTTP / 2(使用SPDY相同的速度改进技术)可以使用不安全的连接,连接时速度稍快。不安全的连接仍然总是比使用相同协议的安全连接至少快一点。“ HTTP vs HTTPS测试”是故意的欺骗和误导。
2015年

3
该网站提供了与真实数字的定量比较,这是为了鼓励更多的人使用HTTPS保护他们的用户。意见仅使我们走了这么远,我们始终可以自由地通过HTTP为IE构建缓慢,不安全的应用程序。我将始终投票支持通过HTTPS为Chrome / Firefox构建快速,尖端且安全的Web应用程序。
AnthumChris 2015年

2
httpvshttps.com上的算法看起来不正确:1.7秒(相比34秒)并不“快95%”。它快20倍,或快1900%。它应该比较速度而不是持续时间。
恐慌上校

2
该测试具有误导性和欺骗性。根据tools.ietf.org/html/rfc7540#section-3.2,没有理由不能在非安全连接上使用HTTP / 2。大公司正在推动通用HTTPS的使用。原因各不相同。但是事实仍然存在。除非页面上没有个人数据,否则没有理由运行SSL。虽然可以,但对于当今的计算机,SSL握手是微不足道的。如果我们开始这样说的话,那琐碎的事情就会简单地陷入困境。对HTTP / 1.1与HTTP / 1.1 SSL和HTTP / 2与HTTP / 2 SSL进行1:1测试。然后讨论。

23

当前的最佳答案并不完全正确。

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

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

请记住,从欧洲到美国的延迟时间可能约为200毫秒(原路段时间)。

您可以使用HTTPWatch轻松衡量(针对单个用户)


12

除了到目前为止提到的所有内容外,请记住,出于安全原因,某些(全部?)网络浏览器未将通过HTTPS获得的缓存内容存储在本地硬盘驱动器上。这意味着从用户的角度来看,具有大量静态内容的页面在重新启动浏览器后似乎加载速度较慢,并且从服务器的角度来看,通过HTTPS请求静态内容的数量将大于通过HTTP请求的静态内容。


6
发送标头“ Cach-Control:max-age = X,公共”会导致现代浏览器(刚刚经过测试的FF4,Chrome12,IE8,IE9)缓存内容。但是,我注意到这些浏览器发送了一个有条件的GET,这可能为额外的往返行程带来额外的延迟,尤其是在未缓存SSL连接的情况下(Keep Alive)。
克林特·帕奇

6

对此没有一个答案。

加密将始终消耗更多的CPU。在许多情况下,可以将其卸载到专用硬件,并且成本将因所选算法而异。例如,3des比AES贵。对于加密器而言,某些算法比解密器更昂贵。有些成本相反。

握手成本比批量加密更昂贵。新的连接将消耗更多的CPU。可以通过恢复会话来减少这种情况,其代价是保留旧的会话机密直到过期。这意味着来自客户端的小额请求如果再也回不来,那是最昂贵的。

对于跨Internet流量,您可能不会在数据速率中注意到这笔费用,因为可用带宽太低。但是您肯定会在繁忙服务器上的CPU使用率中注意到它。


6

我可以告诉您(作为拨号用户)基于SSL的同一页面比通过常规HTTP慢几倍...


6
好点子。我还发现,通过移动电话网络(3G)的加载时间也慢了2到3倍。
克林特·帕奇

是的 回答了仅一年半之后,我搬到了一所新房子,终于能够以比拥有POTS线路更少的钱切换到DSL!
Brian Knoblauch

6

在许多情况下,SSL会话可以在两端(台式机和服务器)上缓存,因此可以减轻SSL握手对性能的影响。例如,在Windows计算机上,SSL会话最多可以缓存10个小时。请参阅 http://support.microsoft.com/kb/247658/EN-US。某些SSL加速器还将具有参数,使您可以调整会话的缓存时间。

要考虑的另一个影响是,通过HTTPS提供的静态内容不会被代理缓存,这可能会降低跨同一代理访问该站点的多个用户的性能。可以通过以下方式缓解这种情况:静态内容也将被缓存在台式机上,除非另有说明,否则Internet Explorer 6和7版会缓存可缓存的HTTPS静态内容(工具菜单/ Internet选项/高级/安全性/不保存加密页面)到磁盘)。


4

我做了一个小实验,从flickr(233 kb)获得同一图像的时差为16%:

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

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

在此处输入图片说明

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


4
无法基于2个请求(每个请求一个)创建统计分析指标。
Tom Roggero



2

这里似乎有一个讨厌的边缘案例:Ajax拥塞的wifi。

Ajax通常意味着KeepAlive在20秒后超时。但是,wifi意味着(理想的快速)ajax连接必须进行多次往返。更糟糕的是,WiFi经常丢失数据包,并且存在TCP重传。在这种情况下,HTTPS的性能确实非常差!



2

HTTP VS HTTPS性能比较

与普通的旧HTTP相比,我总是将HTTPS与较慢的页面加载时间相关联。作为一名Web开发人员,网页性能对我很重要,任何会降低我的网页性能的事情都是不可以的。

为了理解所涉及的性能含义,下图为您提供了使用HTTPS请求资源时幕后情况的基本想法。

在此处输入图片说明

从上图可以看到,与使用普通HTTP相比,使用HTTPS时需要执行一些额外的步骤。使用HTTPS发出请求时,需要进行握手以验证请求的真实性。与HTTP请求相比,握手是一个额外的步骤,不幸的是确实会产生一些开销。

为了理解性能影响并亲自查看性能影响是否重大,我将本站点用作测试平台。我转到webpagetest.org,并使用可视化比较工具来比较使用HTTPS和HTTP加载此网站的情况。

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

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


1
总的来说,这个例子很好,但它比所描述的要复杂得多,尤其是在使用“完美向前保密”时。另外,实际上有四个对称密钥正在使用中。
zaph

0

有一种方法可以衡量这一点。来自Apache的名为jmeter的工具将测量吞吐量。如果您在受控的环境中(使用SSL和不使用SSL)使用jmeter对服务进行大量采样,则应该准确比较相对成本。我会对您的结果感兴趣。


-1

HTTPS具有加密/解密开销,因此它总是会稍微慢一些。SSL终止占用大量CPU。如果您有要卸载SSL的设备,则延迟的差异可能几乎不会引起注意,具体取决于服务器所承受的负载。


-1

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

如果您正在运行具有大量并发用户的站点,则期望购买大量内存。


2
在HTTP 1.1中不适用。连接长时间处于打开状态。
Sklivvz

-1

鉴于SSL需要额外的加密步骤,而非SLL HTTP根本不需要,因此几乎可以肯定这是正确的。


2
两种情况下的性能有所不同。
David The Man

2
但是问题是“ http和https之间的性能是否存在重大差异?”
Sklivvz

-1

HTTPS确实会影响页面速度...

上面的引用揭示了许多人对站点安全性和速度的愚蠢。HTTPS / SSL服务器握手会在建立Internet连接时造成最初的停顿。在访问者的浏览器屏幕上开始呈现任何内容之前,会有一个缓慢的延迟。此延迟以“到第一个字节的时间”信息来衡量。

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

往返无线3G连接可能长达500毫秒或更长。额外的行程将延迟加倍至1秒或更长。这对移动性能产生了很大的负面影响。非常不好的消息。

我的建议是,如果您不交换敏感数据,则根本不需要SSL,但是如果您确实喜欢电子商务网站,则可以仅在交换敏感数据的某些页面(例如登录和签出)上启用HTTPS。

资料来源:Pagepipe


-2

浏览器可以使用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通常使用不同的协议,HTTPS几乎总是比HTTP更快。但是,如果将HTTP / 1.1上的HTTP与HTTP / 1.1上的HTTPS进行比较,则HTTP的平均速度要比HTTPS稍快。

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

通过HTTP / 1.1的HTTPS:

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

通过HTTP / 1.1的HTTP

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

通过HTTP / 2.0的HTTPS

  • 平均载入时间0.10秒
  • 通过HTTP / 1.1比HTTP快0.32秒
  • 在HTTPS / 1.1上比HTTPS快0.37秒
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.