Answers:
对此有一个非常简单的答案:对Web服务器的性能进行分析,以了解特定情况下的性能损失。有几种工具可以比较HTTP与HTTPS服务器的性能(想到了JMeter和Visual Studio),它们非常易于使用。
没有有关网站的性质,硬件,软件和网络配置的某些信息,没有人能给您一个有意义的答案。
正如其他人所说,由于加密,会产生一定程度的开销,但是它高度依赖于:
以我的经验,因为内容加密所花的时间(SSL开销)与内容生成时间相比微不足道,所以对动态内容非常重视的服务器受HTTPS的影响较小。
大量服务于可以轻松地缓存在内存中的静态页面集的服务器遭受了高得多的开销(在一种情况下,吞吐量被“内部网”吞噬了)。
编辑:其他几个人提出的一个观点是SSL握手是HTTPS的主要成本。没错,这就是为什么“典型会话长度”和“客户端的缓存行为”很重要的原因。
许多非常短的会话意味着握手时间将压倒任何其他性能因素。较长的会话将意味着握手成本将在会话开始时发生,但后续请求的开销相对较低。
客户端缓存可以分几步完成,从大型代理服务器到单个浏览器缓存,可以随时随地进行。通常,HTTPS内容不会缓存在共享缓存中(尽管一些代理服务器可以利用中间人行为来实现这一目的)。许多浏览器为当前会话缓存HTTPS内容,并且经常跨会话缓存HTTPS内容。不缓存或缓存较少的影响意味着客户端将更频繁地检索相同的内容。这导致更多的请求和带宽可以服务于相同数量的用户。
HTTPS需要初始握手,这可能会很慢。作为握手的一部分,传输的实际数据量并不大(通常小于5 kB),但是对于非常小的请求,这可能会产生相当大的开销。但是,一旦握手完成,就会使用非常快速的对称加密形式,因此开销很小。底线:通过HTTPS发出大量短请求将比HTTP慢很多,但是如果在单个请求中传输大量数据,则差异将不明显。
但是,keepalive是HTTP / 1.1中的默认行为,因此您将进行一次握手,然后在同一连接上进行大量请求。这对HTTPS来说有很大的不同。您可能应该配置您的网站(按照其他人的建议),以确保这一点,但是我怀疑性能差异不会很明显。
要真正了解HTTPS如何增加延迟,您必须了解HTTPS连接是如何建立的。这是一个不错的图。关键是客户端不是在2个“行程”之后获得数据(一次往返,您发送一个请求,服务器发送一个响应),而是直到至少4个行程(两次往返),客户端才获取数据。 。因此,如果数据包在客户端和服务器之间移动需要100毫秒,则您的第一个HTTPS请求将至少花费500毫秒。
当然,可以通过重新使用HTTPS连接(浏览器应该这样做)来缓解这种情况,但是它确实解释了在加载HTTPS网站时初始停顿的一部分。
开销不是由于加密引起的。在现代CPU上,SSL所需的加密非常简单。
开销归因于SSL握手,这很长,并且极大地增加了HTTPS会话通过HTTP会话所需的往返次数。
当服务器位于模拟的高延迟链接的末端时,测量(使用Firebug等工具)页面加载时间。存在用于模拟高延迟链接的工具-对于Linux,存在“ netem”。在相同设置下将HTTP与HTTPS进行比较。
可以通过以下方式在某种程度上减轻延迟:
您可以使用AnthumChris的HTTP vs HTTPS Test网站在自己的浏览器中轻松测试HTTP和HTTPS性能之间的差异:“此页面通过不安全的HTTP和加密的HTTPS连接来衡量其加载时间。两个页面均加载360个唯一的非缓存图像(总计2.04 MB)。”
结果可能会让你大吃一惊。
重要的是要拥有最新的HTTPS性能知识,因为感谢Mozilla,Akamai,Cisco,Electronic Frontier Foundation和IdenTrust,“ 让我们的加密证书颁发机构”将于2015年夏季开始发行免费,自动化和开放的SSL证书。
让我们加密的更新-将于2015年9月发布:
Twitter上的更多信息:@letsencrypt
有关HTTPS和SSL / TLS性能的更多信息,请参见:
有关使用HTTPS重要性的更多信息,请参见:
综上所述,让我引用Ilya Grigorik的话:“ TLS 确实存在一个性能问题:它的使用范围不够广泛。其他所有内容都可以优化。”
感谢Chris(HTTP与HTTPS测试基准测试的作者)在下面的评论。
除了到目前为止提到的所有内容外,请记住,出于安全原因,某些(全部?)网络浏览器未将通过HTTPS获得的缓存内容存储在本地硬盘驱动器上。这意味着从用户的角度来看,具有大量静态内容的页面在重新启动浏览器后似乎加载速度较慢,并且从服务器的角度来看,通过HTTPS请求静态内容的数量将大于通过HTTP请求的静态内容。
我可以告诉您(作为拨号用户)基于SSL的同一页面比通过常规HTTP慢几倍...
在许多情况下,SSL会话可以在两端(台式机和服务器)上缓存,因此可以减轻SSL握手对性能的影响。例如,在Windows计算机上,SSL会话最多可以缓存10个小时。请参阅 http://support.microsoft.com/kb/247658/EN-US。某些SSL加速器还将具有参数,使您可以调整会话的缓存时间。
要考虑的另一个影响是,通过HTTPS提供的静态内容不会被代理缓存,这可能会降低跨同一代理访问该站点的多个用户的性能。可以通过以下方式缓解这种情况:静态内容也将被缓存在台式机上,除非另有说明,否则Internet Explorer 6和7版会缓存可缓存的HTTPS静态内容(工具菜单/ Internet选项/高级/安全性/不保存加密页面)到磁盘)。
我做了一个小实验,从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握手和编码/解码数据)。
这是一篇有关SSL握手延迟的很棒的文章(有些陈旧,但仍然很棒)。帮助我将SSL识别为通过慢速Internet连接使用我的应用程序的客户端速度缓慢的主要原因:
由于我正在为我的项目调查相同的问题,因此我找到了这些幻灯片。较旧但有趣:
http://www.cs.nyu.edu/artg/research/comparison/comparison_slides/sld001.htm
TLS快吗?是。
那里有许多项目旨在模糊界限并使HTTPS变得同样快。就像SPDY和mod-spdy一样。
HTTP VS HTTPS性能比较
与普通的旧HTTP相比,我总是将HTTPS与较慢的页面加载时间相关联。作为一名Web开发人员,网页性能对我很重要,任何会降低我的网页性能的事情都是不可以的。
为了理解所涉及的性能含义,下图为您提供了使用HTTPS请求资源时幕后情况的基本想法。
从上图可以看到,与使用普通HTTP相比,使用HTTPS时需要执行一些额外的步骤。使用HTTPS发出请求时,需要进行握手以验证请求的真实性。与HTTP请求相比,握手是一个额外的步骤,不幸的是确实会产生一些开销。
为了理解性能影响并亲自查看性能影响是否重大,我将本站点用作测试平台。我转到webpagetest.org,并使用可视化比较工具来比较使用HTTPS和HTTP加载此网站的情况。
正如您从“ 测试视频结果”中看到的使用HTTPS的确实对我的页面加载时间有影响,但是这种差异可以忽略不计,我只注意到300毫秒的差异。重要的是要注意,这些时间取决于许多因素,例如计算机性能,连接速度,服务器负载以及与服务器的距离。
您的站点可能有所不同,因此彻底测试您的站点并检查切换到HTTPS所涉及的性能影响非常重要。
鉴于SSL需要额外的加密步骤,而非SLL HTTP根本不需要,因此几乎可以肯定这是正确的。
HTTPS确实会影响页面速度...
上面的引用揭示了许多人对站点安全性和速度的愚蠢。HTTPS / SSL服务器握手会在建立Internet连接时造成最初的停顿。在访问者的浏览器屏幕上开始呈现任何内容之前,会有一个缓慢的延迟。此延迟以“到第一个字节的时间”信息来衡量。
HTTPS握手开销出现在“第一个字节的时间”信息(TTFB)中。常见的TTFB范围从不到100毫秒(最佳情况)到超过1.5秒(最坏情况)。但是,当然,使用HTTPS的情况要差500毫秒。
往返无线3G连接可能长达500毫秒或更长。额外的行程将延迟加倍至1秒或更长。这对移动性能产生了很大的负面影响。非常不好的消息。
我的建议是,如果您不交换敏感数据,则根本不需要SSL,但是如果您确实喜欢电子商务网站,则可以仅在交换敏感数据的某些页面(例如登录和签出)上启用HTTPS。
资料来源:Pagepipe
浏览器可以使用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:
通过HTTP / 1.1的HTTP
通过HTTP / 2.0的HTTPS