HTTP与HTTPS性能比较

Question

HTTP与HTTPS性能比较

performancehttphttps

388

HTTP和HTTPS在性能方面有什么主要差异吗？我记得曾经读过HTTPS可能只有HTTP的五分之一快。这个说法对于当前的网络服务器/浏览器是否仍然有效？如果是，是否有任何支持它的白皮书？

- Jim Geurts

1

你还应该了解一下HTTP2，目前浏览器只支持在HTTPS下使用。https://zh.wikipedia.org/wiki/HTTP/2 - Luca Steeb

3

“https” 比 “http” 慢（或慢很多）。 - i486

如果有一些透明缓存发生（例如Squid），那么它可能是重要的。协议本身，我不认为它具有很大的开销。 - Rolf

22个回答

235

HTTPS需要进行初始握手，这可能会非常缓慢。握手时实际传输的数据量不大（通常少于5 kB），但对于非常小的请求来说，这可能是相当大的开销。然而，一旦完成握手，就会使用一种非常快速的对称加密形式，因此在那里的开销是最小的。底线是：通过HTTPS进行大量短请求将比HTTP慢得多，但如果您在单个请求中传输大量数据，则差异将不重要。

但是，在HTTP/1.1中，保持连接是默认行为，因此您将进行一次握手，然后在同一连接上进行许多请求。这对HTTPS有很大影响。您应该根据其他人建议，对您的站点进行分析以确保，但我怀疑性能差异不会显着。

- Graeme Perrow

20

原来每次握手的成本将会在每个会话中支付4-10倍，至少如此，因为大多数浏览器使用多个连接到同一服务器。根据浏览器的https-keep-alive持续时间，它可能会在会话期间重复发生。 - James Schek

6

关于HTTP keepalive功能，我们曾经遇到过连接不稳定的情况。每个请求都会建立和断开连接，意味着进行了MA-SSL握手。客户端或服务器可能已经配置为关闭连接，这种情况通常发生在Tomcat/Websphere环境中。 - zkarthik

8

多个连接应该重用相同的SSL会话，这将对情况造成相当大的变化。即使HTTP keep-alive不起作用，也适用相同的规则。 - user207421

14

没错。在2013年，大多数浏览器/服务器和SSL/TLS实现都利用会话复用。但在2008年，这并不总是一个安全的假设。 - James Schek

4

这个问题在谷歌搜索“http vs https performance”时排名很高。虽然以上回答在2008年是正确的，但在2015年已经不再正确，不应该将其作为避免使用https的决策基础。 - Paul Schreiber

1

有人可以更新一下这个到2019年吗？我看了答案，没有一个提到HTTPS是当今事实上的标准和推荐的安全实践。 - Mayank Sharma

102

为了真正理解HTTPS如何增加延迟，您需要了解HTTPS连接是如何建立的。这里有一个漂亮的图表。关键在于，客户端不会在2个“步骤”（一次往返，您发送请求，服务器发送响应）之后获取数据，而是至少要等到4个步骤（2次往返）才能获取数据。因此，如果数据包在客户端和服务器之间移动需要100毫秒，那么您的第一个HTTPS请求将至少需要500毫秒。

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

- twk

1

就Java客户端而言，如何使HTTPS连接可重复使用？我的意思是说，我可以创建一个HttpsConnection的静态对象并重新使用它吗？（在Web应用程序上下文中） - Niks

1

五年后，漂亮的+1图表的链接失效了，有人能找到它并将其放在答案中吗？ - Jim Wolff

2

@FRoZen 找到了替代链接。 - Stefan L

我认为这个页面是一个非常好的HTTP图解，可以更好地理解整个过程：http://blog.catchpoint.com/2010/09/17/anatomyhttp/ - Elliptical view

1

@Nikhil Java会自动重用底层连接并在请求之间共享它，除非用户通过disconnect强制断开连接。请查看文档。 - Mohnish

80

这种开销并非由加密引起，对于现代CPU来说，SSL所需的加密处理是微不足道的。

这种开销源于SSL握手过程，该过程很漫长并且会显著增加HTTPS会话相比HTTP所需的往返次数。

通过使用工具（例如Firebug）测量页面加载时间, 在模拟高延迟链路的情况下进行测试。有一些模拟高延迟链路的工具—例如Linux上的 "netem"。将HTTP与在相同环境下的HTTPS进行比较。

可以通过以下方式在某种程度上缓解延迟问题：

确保您的服务器正在使用HTTP keepalive - 这使客户端可以重用SSL会话，避免了需要进行另一个握手的情况
尽可能减少请求数量 - 通过合并资源（例如.js包含文件、CSS）和鼓励客户端缓存来实现
减少页面加载次数，例如通过将不需要的数据加载到页面中（可能在隐藏的HTML元素中），然后使用客户端脚本显示它。

- MarkR

9

我完全同意@MarkR的观点。我最近查看了我的主页的HTTP和HTTPS版本，并发现平均加载时间分别为1.5秒和4.5秒。在查看连接详细信息时，SSL握手所需的额外往返是导致加载速度变慢的主要因素。对于3G移动浏览器而言，情况更糟。加载时间分别为5秒和9秒。 - Clint Pachl

26

2014年12月更新

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

结果可能会让你惊讶。

了解HTTPS性能的最新知识很重要，因为由于Mozilla、Akamai、Cisco、Electronic Frontier Foundation和IdenTrust的努力，Let’s Encrypt证书颁发机构将从2015年夏季开始发布免费、自动化和开放SSL证书。

2015年6月更新

Let’s Encrypt的最新消息-将于2015年9月到达：

Let's Encrypt发布计划（2015年6月16日）
Let's Encrypt根和中间证书（2015年6月4日）
草案Let's Encrypt用户协议（2015年5月21日）

更多信息请关注Twitter：@letsencrypt

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

超频SSL

SSL处理的解剖和性能

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

为什么全部使用HTTPS？（HTTPS-Only标准）
Let’s Encrypt（互联网安全研究小组）
HTTPS Everywhere（电子前沿基金会）

总之，让我引用Ilya Grigorik的话来概括：“TLS只有一个性能问题：它没有被广泛使用。其他一切都可以优化。”

感谢Chris——HTTP vs HTTPS Test基准测试的作者——对以下评论提供的意见。

- rsp

10

“HTTP vs HTTPS测试”故意误导，请不要链接到它。该页面实际上比较的是HTTP和SPDY。如果您不相信，请在IE中尝试并查看其显示内容。不存在HTTP请求比等效的HTTPS请求更快的情况。 - orrd

7

为了政治原因而非技术原因，谷歌强制SPDY只使用安全连接。HTTP/2（使用SPDY相同的速度提升技术）可以使用不安全连接，并且在这种情况下速度略快。一个未加密的连接始终比使用相同协议的安全连接稍快一些。 "HTTP vs HTTPS测试" 故意具有欺骗性和误导性。 - orrd

3

该网站提供了具有实际数字的定量比较，旨在鼓励更多人使用HTTPS来保护其用户。仅凭意见无法解决问题，我们始终可以选择为IE构建缓慢不安全的应用程序。我将始终投票支持使用HTTPS为Chrome/Firefox构建快速、前沿和安全的Web应用程序。 - anthumchris

2

https://www.httpvshttps.com 上的算术似乎有误：1.7秒与34秒相比不是“95%更快”。它实际上是20倍更快，或者说快了1900%。应该比较速度而不是持续时间。 - Colonel Panic

5

这个测试是误导和欺骗性的。根据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测试。然后讨论。 - Shinrai

显示剩余9条评论

25

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

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

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

只需记住，从欧洲到美国的延迟可能约为200毫秒（往返时间）。

您可以使用HTTPWatch轻松测量（针对单个用户情况）。

- kohlerm

12

除了之前提到的所有内容，还需要记住一些(全部?) Web浏览器由于安全原因不会将通过HTTPS获取的缓存内容存储在本地硬盘上。这意味着从用户的角度来看，在浏览器重新启动后，具有大量静态内容的页面将显示为加载较慢，并且从服务器的角度来看，通过HTTPS请求静态内容的请求量将高于HTTP。

- Alexander

7

发送头部信息 "Cach-Control: max-age=X, public"，会导致现代浏览器（已测试FF4，Chrome12，IE8，IE9）缓存内容。但是我发现这些浏览器发送了一个有条件的GET请求，这可能会因为额外来回的延迟而带来附加的延迟，特别是如果SSL连接没有被缓存（保持活动状态）。 - Clint Pachl

6

这个问题没有一个确定的答案。

加密总是会消耗更多的CPU。在许多情况下，这可以转移到专用硬件中，并且所选算法的成本也会有所不同。例如，3DES比AES更昂贵。一些算法对加密器和解密器的成本更高。另一些则成本相反。

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

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

- Darron

6

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

- Brian Knoblauch

7

好的，我会尽力进行翻译。该内容的翻译如下：
很好的观点。我也发现在移动网络（3G）上的加载时间慢2倍到3倍。 - Clint Pachl

是的！在那个回答之后的一年半里，我搬到了新房子，终于能够以比拥有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选项/高级/安全/不保存加密页面到磁盘)。

- ZX81

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- James Schek · Accepted Answer

这个问题有一个非常简单的答案：对您特定情况下的网站性能进行分析，以查看使用HTTPS协议与HTTP相比的性能影响。 有很多工具可用于比较HTTP和HTTPS服务器的性能（如JMeter和Visual Studio），而且它们很容易使用。

没有人能在没有一些关于您的网站、硬件、软件和网络配置的信息的情况下给您有意义的答案。

就像其他人说的那样，加密会带来一定程度的开销，但它高度依赖于：

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

根据我的经验，重度使用动态内容的服务器受HTTPS的影响较小，因为加密时间（SSL开销）与生成内容的时间相比微不足道。

服务大量提供可以轻松缓存在内存中的静态页面的服务器遭受更高的开销（在一个案例中，“内部网络”的吞吐量减半）。

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

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

客户端缓存可以在几个步骤中完成，从大规模代理服务器到单个浏览器缓存。通常情况下，HTTPS内容不会被缓存在共享缓存中（虽然一些代理服务器可以利用中间人类型的行为实现）。许多浏览器会在当前会话和经常性的情况下缓存HTTPS内容。未缓存或缓存较少的影响是客户端将更频繁地检索相同的内容。这会导致服务相同数量的用户需要更多的请求和带宽。