HTTP与HTTPS性能

Question

HTTP与HTTPS性能

Jim*_*rts 360 performance https http

http和https之间的性能有任何重大差异吗？我似乎记得读到HTTPS的速度可以达到HTTP的五分之一.这对当前的网络服务器/浏览器有效吗？如果是这样,有没有支持它的白皮书？

Answer 1

Jam*_*hek 230

对此有一个非常简单的答案:描述您的Web服务器的性能,以了解对您的特定情况的性能损失.有几种工具可以比较HTTP与HTTPS服务器(JMeter和Visual Studio)的性能,并且它们非常易于使用.

如果没有关于网站性质,硬件,软件和网络配置的一些信息,没有人能给你一个有意义的答案.

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

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

根据我的经验,对动态内容很重的服务器往往受到HTTPS的影响较小,因为与内容生成时间相比,加密所花费的时间(SSL开销)是微不足道的.

服务于可以容易地在内存中缓存的相当小的静态页面集的服务器遭受更高的开销(在一种情况下,吞吐量在"内联网"上肆虐).

编辑:其他几个人提出的一点是SSL握手是HTTPS的主要成本.这是正确的,这就是"典型的会话长度"和"客户端的缓存行为"很重要的原因.

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

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

__这个答案在开头提到了很多不相关的(换句话说是错误的)东西.他花了5个段落来找到正确答案,这是__HANDSHAKING__. (67认同)
这篇文章并没有真正回答这个问题.Jim Geurts似乎在询问HTTP和HTTPS本身的性能特性,而不是特定的实现.HTTPS无疑会更慢,因为它可以提供更多功能.所以问题是,慢多少？每个人都知道,如果你添加更多变量,你会得到不同的结果. (7认同)
通过 HTTPS 提供的内容不会*由代理*缓存。默认情况下，所有现代浏览器都会缓存 HTTPS 内容，除非按照 [Jeff Atwood](http://stackoverflow.com/questions/174348/will-web-browsers-cache-content-over-https/174510# 174510) (2认同)

Answer 2

Gra*_*row 218

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

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

事实证明,由于大多数浏览器使用多个连接到同一服务器,这个握手成本至少每次会话支付4-10倍.根据https-keep-alive对浏览器的持续时间,可能会在会话期间重复发生. (18认同)
@EJP那是真的.在2013年,大多数浏览器/服务器和SSL/TLS实现都使用会话重用.在2008年,它并不总是一个安全的假设. (14认同)
@JamesSchek多个连接应该重用相同的*SSL*会话,这会更改图片.即使HTTP keep-alive不起作用,同样适用. (8认同)
关于HTTP keepalive功能,我们遇到了连接不保持持久性的情况.对于每个请求,正在构建和拆除请求连接 - 意味着MA-SSL握手.存在客户端或服务器可能已经配置为关闭连接的可能性.通常发生在Tomcat/Websphere环境中. (6认同)
Google在"http vs https性能"中显示了这个问题.尽管上述答案在2008年是正确的,但在2015年已不再适用,不应将其作为避免使用https的决策依据. (2认同)

Answer 3

twk*_*twk 101

要真正了解HTTPS如何增加延迟,您必须了解如何建立HTTPS连接.这是一个很好的图表.关键是,不是客户端获取2"腿"之后的数据(一次往返,你发送请求,服务器发送响应),客户端将至少在4条腿(2次往返)之前不会获取数据.因此,如果数据包在客户端和服务器之间移动需要100毫秒,那么您的第一个HTTPS请求将至少花费500毫秒.

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

@FRoZen 找到了替代链接 (2认同)

Answer 4

Mar*_*rkR 76

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

开销是由于SSL握手造成的,这种握手很长并且大大增加了HTTP会话所需的往返次数.

在服务器处于模拟高延迟链接的末尾时,测量(使用Firebug等工具)页面加载时间.存在用于模拟高延迟链接的工具 - 对于Linux存在"netem".在同一设置上将HTTP与HTTPS进行比较.

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

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

我非常同意@MarkR.我最近的主页配置文件HTTP与HTTPS相比,平均加载时间分别为1.5秒和4.5秒.在查看连接细节时,由于SSL握手,最大的减速因素是额外的往返行程.3G上的移动浏览器更糟糕.数字分别为5s和9s. (8认同)

Answer 5

rsp*_*rsp 25

2014年12月更新

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

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

有一个高达约在HTTPS的性能,因为最新的知识是很重要的让我们的加密证书颁发机构将开始在夏季2015年发布免费的,自动化的,开放的SSL证书,这要归功于Mozilla的阿卡迈,思科,电子前沿基金会和的IdenTrust.

2015年6月更新

关于Let's加密的更新 - 到2015年9月:

有关Twitter的更多信息:@letsencrypt

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

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

为什么HTTPS为万物？(仅限HTTPS的标准)
让我们加密(互联网安全研究组)
HTTPS无处不在(电子前沿基金会)

总而言之,让我引用Ilya Grigorik的话:"TLS只有一个性能问题:它没有被广泛使用.其他所有东西都可以优化."

感谢Chris - HTTP与HTTPS测试基准的作者 - 以下是他的评论.

"HTTP与HTTPS测试"是故意欺骗,请不要链接到它.该页面实际上做的是比较**HTTP和SPDY**.这是真的,如果你不相信我,可以在IE中试一试,看看它的内容.没有HTTP请求比等效HTTPS请求更快的情况. (4认同)
该测试具有误导性和欺骗性。根据 https://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 测试。然后讨论。 (4认同)
该网站提供了与实际数字的定量比较,旨在鼓励更多人使用HTTPS保护其用户.意见只带我们到目前为止,我们总是可以通过HTTP构建缓慢,不安全的IE应用程序.我将一直投票支持使用HTTPS为Chrome/Firefox构建快速,前沿且安全的Web应用程序. (3认同)
谷歌强迫SPDY仅出于政治原因使用安全连接,而不是技术原因.HTTP/2(使用SPDY的相同速度改进技术)可以使用不安全的连接,并且它会稍微快一些.不安全的连接仍然总是比使用相同协议的安全连接快一点."HTTP与HTTPS测试"是故意欺骗性和误导性的. (2认同)
https://www.httpvshttps.com 上的算术看起来是错误的：1.7 秒与 34 秒相比并不是“快 95%”。它快了 20 倍，或快了 1900%。它应该比较速度而不是持续时间。 (2认同)

Answer 6

koh*_*erm 23

目前的最佳答案并不完全正确.

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

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

请记住,从欧洲到美国的延迟时间约为200毫秒(折扣时间).

您可以使用HTTPWatch轻松测量(针对单个用户案例).

Answer 7

Ale*_*der 12

除了目前为止提到的所有内容之外,请注意,出于安全原因,某些(所有？)Web浏览器不会将通过HTTPS获取的缓存内容存储在本地硬盘驱动器上.这意味着从用户的角度来看,具有大量静态内容的页面在重新启动浏览器后似乎加载速度较慢,从服务器的角度来看,通过HTTPS的静态内容请求量将高于通过HTTP的量.

发送标题"Cach-Control:max-age = X,public"将导致现代浏览器(仅测试FF4,Chrome12,IE8,IE9)缓存内容.但是,我注意到这些浏览器发送了一个条件GET,这可能会导致额外往返的额外延迟,尤其是在没有缓存SSL连接的情况下(Keep Alive). (6认同)

Answer 8

Dar*_*ron 6

对此没有一个答案.

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

比批量加密更昂贵的是握手成本.新连接将消耗更多CPU.这可以通过会话恢复来减少,代价是保持旧的会话秘密,直到它们到期为止.这意味着来自客户端的小额请求不会再回来的费用最高.

对于跨互联网流量,您可能不会在数据速率中注意到此成本,因为可用带宽太低.但是你肯定会注意到它在繁忙的服务器上的CPU使用率.

Answer 9

Bri*_*uch 6

我可以告诉你(作为拨号用户)SSL上的同一页面比普通HTTP慢几倍......

好点子.我还发现通过移动电话网络(3G)的加载时间也慢了2到3倍. (6认同)

Answer 10

小智 6

在许多情况下,SSL会话的性能影响将通过SSL会话可以在两端(桌面和服务器)缓存这一事实得到缓解.例如,在Windows机器上,SSL会话可以缓存最多10个小时.请参阅 http://support.microsoft.com/kb/247658/EN-US.某些SSL加速器还具有允许您调整会话缓存时间的参数.

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

归档时间：	16 年，11 月前
查看次数：	218153 次
最近记录：	6 年，9 月前