performance - HTTP 与 HTTPS 性能

Question

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

score 237 · Accepted Answer

对此有一个非常简单的答案：分析您的 Web 服务器的性能，以查看针对您的特定情况的性能损失。有几种工具可以比较 HTTP 与 HTTPS 服务器的性能（想到 JMeter 和 Visual Studio），它们非常易于使用。

如果没有关于您的网站性质、硬件、软件和网络配置的一些信息，没有人可以给您一个有意义的答案。

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

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

以我的经验，大量处理动态内容的服务器往往受 HTTPS 的影响较小，因为与内容生成时间相比，加密所花费的时间（SSL 开销）微不足道。

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

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

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

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

score 229 · Accepted Answer

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

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

score 102 · Accepted Answer

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

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

score 79 · Accepted Answer

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

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

在服务器位于模拟的高延迟链接末端时测量（使用 Firebug 等工具）页面加载时间。存在模拟高延迟链接的工具 - 对于 Linux，有“netem”。在相同的设置上比较 HTTP 和 HTTPS。

延迟可以通过以下方式在一定程度上得到缓解：

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

score 25 · Accepted Answer

2014 年 12 月更新

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

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

由于 Mozilla、Akamai、Cisco、Electronic Frontier Foundation 和 IdenTrust 的支持，让我们加密证书颁发机构将于 2015 年夏季开始发布免费、自动化和开放的 SSL 证书，因此了解 HTTPS 性能的最新知识非常重要。

2015 年 6 月更新

Let's Encrypt 的更新 - 2015 年 9 月到货：

Let's Encrypt 发布时间表（2015 年 6 月 16 日）
让我们加密根证书和中间证书（2015 年 6 月 4 日）
Let's Encrypt 订户协议草案（2015 年 5 月 21 日）

Twitter 上的更多信息：@letsencrypt

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

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

为什么要使用 HTTPS？（仅 HTTPS 标准）
Let's Encrypt（互联网安全研究组）
HTTPS 无处不在（电子前沿基金会）

总结一下，让我引用Ilya Grigorik 的话：“TLS 恰好有一个性能问题：它使用得不够广泛。其他一切都可以优化。”

感谢Chris （ HTTP 与 HTTPS 测试基准测试的作者）在下面发表的评论。

score 24 · Accepted Answer

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

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

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

请记住，从欧洲到美国的延迟可能在 200 毫秒左右（往返时间）。

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

score 12 · Accepted Answer

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

score 6 · Accepted Answer

对此没有一个单一的答案。

加密总是会消耗更多的 CPU。在许多情况下，这可以卸载到专用硬件，并且成本会因所选算法而异。例如，3des 比 AES 贵。有些算法对于加密器来说比解密器更昂贵。有些有相反的成本。

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

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

score 6 · Accepted Answer

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

score 6 · Accepted Answer

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

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

score 3 · Accepted Answer

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

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

score 3 · Accepted Answer

我做了一个小实验，从 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 握手和编码/解码数据）。

score 2 · Accepted Answer

因为我正在为我的项目调查同样的问题，所以我找到了这些幻灯片。较旧但有趣：

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

score 2 · Accepted Answer

TLS 快了吗？是的。

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

有许多项目旨在模糊界限并使 HTTPS 一样快。像SPDY和mod-spdy。

score 2 · Accepted Answer

这里似乎有一个令人讨厌的边缘案例：Ajax over congested wifi。

Ajax 通常意味着 KeepAlive 在 20 秒后超时。但是，wifi 意味着（理想情况下是快速的）ajax 连接必须进行多次往返。更糟糕的是，wifi经常丢包，还有TCP重传。在这种情况下，HTTPS 的表现真的很糟糕！

score 2 · Accepted Answer

HTTP 与 HTTPS 性能比较

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

为了理解所涉及的性能影响，下图让您基本了解当您使用 HTTPS 请求资源时会发生什么。

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

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

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

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

score 0 · Accepted Answer

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

score 0 · Accepted Answer

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

score 0 · Accepted Answer

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

score 0 · Accepted Answer

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

上面的引述揭示了许多人对网站安全和速度的愚蠢。HTTPS / SSL 服务器握手会在建立 Internet 连接时造成初始停滞。在访问者的浏览器屏幕上开始呈现任何内容之前会有一个缓慢的延迟。这种延迟是在 Time-to-First-Byte 信息中测量的。

HTTPS 握手开销出现在 Time-to-First-Byte 信息 (TTFB) 中。常见的 TTFB 范围从低于 100 毫秒（最佳情况）到超过 1.5 秒（最坏情况）。但是，当然，使用 HTTPS 会差 500 毫秒。

往返、无线 3G 连接可能需要 500 毫秒或更长时间。额外的行程将延迟加倍至 1 秒或更多。这对移动性能有很大的负面影响。非常坏的消息。

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

资料来源：Pagepipe

score -1 · Accepted Answer

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

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

score -1 · Accepted Answer

浏览器可以接受带有 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/1.1 上的 HTTP 与 HTTP/1.1 上的 HTTPS 进行比较，则平均而言，HTTP 比 HTTPS 稍快。

以下是我使用 Chrome (Ver. 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 秒

performance - HTTP 与 HTTPS 性能

22 回答 22

2014 年 12 月更新

2015 年 6 月更新

Related

Reference