HTTP与HTTPS性能

Question

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

Answer 1

对此有一个非常简单的答案： 描述您的网络服务器的性能，以了解您的特定情况下的性能损失。 有几种工具可供选择比较HTTP与HTTPS服务器的性能（想到JMeter和Visual Studio），它们很容易使用。

如果没有关于网站性质，硬件，软件和网络配置的部分信息，任何人都无法给出有意义的答案。

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

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

根据我的经验，对动态内容很重的服务器往往受到HTTPS的影响较小，因为加密时间（SSL开销）与内容生成时间相比无关紧要。

服务于可以轻松缓存在内存中的相当少的静态页面集的服务器遭受更高的开销（在一种情况下，吞吐量在“内部网”上肆虐）。

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

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

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

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

可以通过以下方式缓解延迟：

• 确保您的服务器正在使用HTTP Keepalive - 这允许客户端重用SSL会话，这样就无需再次握手
• 尽可能少地减少请求数量 - 尽可能合并资源（例如.js包含文件，CSS）和鼓励客户端缓存
• 减少页面加载次数，例如通过将不需要的数据加载到页面中（可能在隐藏的HTML元素中），然后使用客户端脚本显示它。

Answer 5

2014年12月更新

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

结果可能让您感到惊讶。

了解有关HTTPS性能的最新信息非常重要，因为 Let’s Encrypt 证书颁发机构将在2015年夏季开始颁发免费，自动和开放的SSL证书感谢Mozilla，Akamai，思科，电子前沿基金会和IdenTrust。

2015年6月更新

Let's加密更新 - 2015年9月到货：

• Let's Encrypt Launch Schedule（2015年6月16日）
• Let's Encrypt Root and Intermediate Certificates（2015年6月4日）
• Draft Let's Encrypt Subscriber Agreement（2015年5月21日）

Twitter上的更多信息：@letsencrypt

有关HTTPS和SSL / TLS性能的详细信息，请参阅：

• Is TLS Fast Yet?
• High Performance Browser Networking, Chapter 4: Transport Layer Security
• Overclocking SSL
• Anatomy and Performance of SSL Processing

有关使用HTTPS的重要性的详细信息，请参阅：

• Why HTTPS for Everything?（仅限HTTPS标准）
• Let’s Encrypt（互联网安全研究组）
• HTTPS Everywhere（电子前沿基金会）

总结一下，让我引用Ilya Grigorik：＆＃34; TLS只有一个性能问题：它的使用不够广泛。其他一切都可以优化。＆＃34;

感谢Chris - HTTP vs HTTPS Test基准的作者 - 感谢下面的评论。

Answer 6

The current top answer并不完全正确。

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

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

请记住，从欧洲到美国的延迟时间约为200毫秒（折扣时间）。

您可以使用HTTPWatch轻松衡量（针对单个用户案例）。

Answer 7

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

Answer 8

在许多情况下，SSL会话可以在两端（桌面和服务器）缓存这一事实，可以减轻SSL握手对性能的影响。例如，在Windows机器上，SSL会话可以缓存最多10个小时。见http://support.microsoft.com/kb/247658/EN-US。某些SSL加速器还具有允许您调整会话缓存时间的参数。

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

Answer 9

对此没有一个答案。

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

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

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

Answer 10

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

Answer 11

我做了一个小实验，从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慢，因为它要求完成更多操作（SSL握手和编码/解码数据）。

Answer 12

这是一篇关于SSL握手延迟的精彩文章（有点旧，但仍然很棒）。帮助我将SSL识别为通过慢速Internet连接使用我的应用程序的客户缓慢的主要原因：

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

Answer 13

这里似乎有一个令人讨厌的边缘案例：Ajax过度拥挤的wifi。

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

Answer 14

  

HTTP VS HTTPS性能比较

与普通的旧HTTP相比，我总是将HTTPS与较慢的页面加载时间相关联。作为一名网络开发人员，网页性能对我来说非常重要，任何会降低网页性能的因素都是禁忌。

为了理解所涉及的性能影响，下面的图表为您提供了在使用HTTPS请求资源时会发生什么情况的基本概念。

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

为了理解性能影响并亲自了解性能影响是否显着，我将此站点用作测试平台。我前往webpagetest.org并使用可视化比较工具来比较使用HTTPS和HTTP加载此站点。

正如您从Here is Test video Result使用HTTPS看到的确对我的页面加载时间有影响，但差异可以忽略不计，我只注意到300毫秒的差异。值得注意的是，这些时间取决于许多因素，例如计算机性能，连接速度，服务器负载以及与服务器的距离。

您的网站可能不同，请务必彻底测试您的网站并检查切换到HTTPS时所涉及的性能影响。

  

我们能否改善表现？   visit here获取详细信息

Answer 15

由于我正在为我的项目调查同样的问题，我找到了这些幻灯片。年长但有趣：

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

Answer 16

  

TLS快了吗？是的。

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

有许多项目旨在模糊线条并使HTTPS速度一样快。与SPDY和mod-spdy一样。

Answer 17

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

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

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

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

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

来源：Pagepipe

Answer 18

有一种方法可以衡量这一点。来自apache的工具称为jmeter，它将测量吞吐量。如果您使用jmeter设置大量的服务采样，在受控环境中（使用和不使用SSL），您应该准确比较相对成本。我会对你的结果感兴趣。

Answer 19

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

你正在运行一个拥有大量并发用户的网站，期望购买大量内存。

Answer 20

HTTPS具有加密/解密开销，因此总是稍微慢一些。 SSL终止非常占用CPU。如果您有卸载SSL的设备，则延迟的差异可能几乎不明显，具体取决于您的服务器所承受的负载。

Answer 21

浏览器可以使用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 over HTTP / 1.1上的HTTP与HTTP / 1.1上的HTTPS进行比较，那么HTTP平均比HTTPS快一点。

以下是我使用Chrome（Ver.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
上的HTTPS快0.37秒

Answer 22

鉴于SSL需要额外的加密步骤（非SLL HTTP不需要），这几乎肯定会成为现实。