HTTP 与 HTTPS 性能
http 和 https 之间的性能有什么重大差异吗？ 我似乎记得读到过 HTTPS 的速度是 HTTP 的五分之一。 这对于当前一代网络服务器/浏览器有效吗？ 如果是这样，有任何白皮书支持吗？
Are there any major differences in performance between http and https? I seem to recall reading that HTTPS can be a fifth as fast as HTTP. Is this valid with the current generation webservers/browsers? If so, are there any whitepapers to support it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（22）
要真正了解 HTTPS 如何增加延迟，您必须了解 HTTPS 连接是如何建立的。 这是一个漂亮的图表。 关键在于，客户端不是在 2 个“腿”（一次往返，您发送请求，服务器发送响应）后获取数据，而是至少 4 个腿（2 个往返）后客户端才会获取数据。 因此，如果数据包在客户端和服务器之间移动需要 100 毫秒，则您的第一个 HTTPS 请求将至少需要 500 毫秒。
当然，可以通过重新使用 HTTPS 连接（浏览器应该这样做）来缓解这种情况，但它确实解释了加载 HTTPS 网站时初始停顿的部分原因。
To really understand how HTTPS will increase your latency, you have to understand how HTTPS connections are established. Here is a nice diagram. The key is that instead of the client getting the data after 2 "legs" (one round trip, you send a request, the server sends a response), the client won't get data until at least 4 legs (2 round trips). So, if it takes 100 ms for a packet to move between the client and the server, your first HTTPS request will take at least 500 ms.
Of course, this can be mitigated by re-using the HTTPS connection (which browsers should do), but it does explain part of that initial stall when loading up an HTTPS web site.
2014 年 12 月更新
您可以使用HTTP 与 HTTPS 测试AnthumChris 的 Strong> 网站：“此页面通过不安全的 HTTP 和加密的 HTTPS 连接测量其加载时间。 这两个页面都加载 360 个独特的非缓存图像（总共 2.04 MB）。”
结果可能会让你吃惊。
了解有关 HTTPS 性能的最新知识非常重要，因为 Let's Encrypt 证书颁发机构将开始免费颁发、感谢 Mozilla、Akamai、Cisco、Electronic Frontier Foundation 和 IdenTrust，我们于 2015 年夏季实现了自动化和开放 SSL 证书。
2015 年 6 月更新
Let's Encrypt 更新 - 2015 年 9 月发布：
Twitter 上的更多信息：@letsencrypt
有关 HTTPS 和 SSL/TLS 性能的详细信息，请参阅：
有关使用 HTTPS 重要性的更多信息，请参阅：
为了总结这一点，让我引用 Ilya Grigorik< /a>: “TLS 存在一个性能问题：它的使用不够广泛。 其他一切都可以优化。”
感谢 Chris - HTTP 与 HTTPS 测试基准 - 以下是他的评论。
December 2014 Update
You can easily test the difference between HTTP and HTTPS performance in your own browser using the HTTP vs HTTPS Test website by AnthumChris: “This page measures its load time over unsecure HTTP and encrypted HTTPS connections. Both pages load 360 unique, non-cached images (2.04 MB total).”
The results may surprise you.
It's important to have an up to date knowledge about the HTTPS performance because the Let’s Encrypt Certificate Authority will start issuing free, automated, and open SSL certificates in Summer 2015, thanks to Mozilla, Akamai, Cisco, Electronic Frontier Foundation and IdenTrust.
June 2015 Update
Updates on Let’s Encrypt - Arriving September 2015:
More info on Twitter: @letsencrypt
For more info on HTTPS and SSL/TLS performance see:
For more info on the importance of using HTTPS see:
To sum it up, let me quote Ilya Grigorik: "TLS has exactly one performance problem: it is not used widely enough. Everything else can be optimized."
Thanks to Chris - author of the HTTP vs HTTPS Test benchmark - for his comments below.
对此有一个非常简单的答案：分析您的网络服务器的性能，以了解您的特定情况的性能损失。有几种工具可以比较HTTP 与 HTTPS 服务器（想到 JMeter 和 Visual Studio）的性能，并且它们非常易于使用。
如果没有关于您的网站、硬件、软件和网络配置的性质的一些信息，没有人可以给您有意义的答案。
正如其他人所说，由于加密，会产生一定程度的开销，但它高度依赖于：
行为根据我的经验，大量动态内容的服务器往往受 HTTPS 的影响较小，因为与内容生成时间相比，加密时间（SSL 开销）微不足道。
大量提供相当小的静态页面集（可以轻松缓存在内存中）的服务器会遭受更高的开销（在一种情况下，吞吐量在“内部网”上受到影响）。
编辑：其他几个人提出的一点是 SSL 握手是 HTTPS 的主要成本。 这是正确的，这就是为什么“典型会话长度”和“客户端的缓存行为”很重要。
许多非常短的会话意味着握手时间将压倒任何其他性能因素。 较长的会话意味着在会话开始时会产生握手成本，但后续请求的开销相对较低。
客户端缓存可以通过几个步骤完成，从大型代理服务器到单个浏览器缓存。 一般来说，HTTPS 内容不会缓存在共享缓存中（尽管一些代理服务器可以利用中间人类型的行为来实现这一点）。 许多浏览器会缓存当前会话的 HTTPS 内容，并且经常会跨会话缓存 HTTPS 内容。 不缓存或较少缓存的影响意味着客户端将更频繁地检索相同的内容。 这会导致为相同数量的用户提供更多的请求和带宽。
There's a very simple answer to this: Profile the performance of your web server to see what the performance penalty is for your particular situation. There are several tools out there to compare the performance of an HTTP vs HTTPS server (JMeter and Visual Studio come to mind) and they are quite easy to use.
No one can give you a meaningful answer without some information about the nature of your web site, hardware, software, and network configuration.
As others have said, there will be some level of overhead due to encryption, but it is highly dependent on:
In my experience, servers that are heavy on dynamic content tend to be impacted less by HTTPS because the time spent encrypting (SSL-overhead) is insignificant compared to content generation time.
Servers that are heavy on serving a fairly small set of static pages that can easily be cached in memory suffer from a much higher overhead (in one case, throughput was havled on an "intranet").
Edit: One point that has been brought up by several others is that SSL handshaking is the major cost of HTTPS. That is correct, which is why "typical session length" and "caching behavior of clients" are important.
Many, very short sessions means that handshaking time will overwhelm any other performance factors. Longer sessions will mean the handshaking cost will be incurred at the start of the session, but subsequent requests will have relatively low overhead.
Client caching can be done at several steps, anywhere from a large-scale proxy server down to the individual browser cache. Generally HTTPS content will not be cached in a shared cache (though a few proxy servers can exploit a man-in-the-middle type behavior to achieve this). Many browsers cache HTTPS content for the current session and often times across sessions. The impact the not-caching or less caching means clients will retrieve the same content more frequently. This results in more requests and bandwidth to service the same number of users.
HTTPS 需要初始握手，这可能非常慢。 作为握手一部分传输的实际数据量并不大（通常低于 5 kB），但对于非常小的请求，这可能是相当大的开销。 然而，一旦握手完成，就会使用一种非常快速的对称加密形式，因此开销很小。 底线：通过 HTTPS 发出大量短请求将比 HTTP 慢很多，但如果您在单个请求中传输大量数据，则差异将微不足道。
然而，keepalive 是 HTTP/1.1 中的默认行为，因此您将进行一次握手，然后通过同一连接进行大量请求。 这对于 HTTPS 来说有很大的不同。 您可能应该分析您的网站（正如其他人所建议的那样）以确保，但我怀疑性能差异不会很明显。
HTTPS requires an initial handshake which can be very slow. The actual amount of data transferred as part of the handshake isn't huge (under 5 kB typically), but for very small requests, this can be quite a bit of overhead. However, once the handshake is done, a very fast form of symmetric encryption is used, so the overhead there is minimal. Bottom line: making lots of short requests over HTTPS will be quite a bit slower than HTTP, but if you transfer a lot of data in a single request, the difference will be insignificant.
However, keepalive is the default behaviour in HTTP/1.1, so you will do a single handshake and then lots of requests over the same connection. This makes a significant difference for HTTPS. You should probably profile your site (as others have suggested) to make sure, but I suspect that the performance difference will not be noticeable.
开销不是由于加密造成的。 在现代 CPU 上，SSL 所需的加密是微不足道的。
开销是由于 SSL 握手造成的，该握手时间较长，并且大大增加了 HTTPS 会话相对于 HTTP 会话所需的往返次数。
测量（使用 Firebug 等工具）服务器位于模拟高延迟链接末端时的页面加载时间。 存在模拟高延迟链路的工具 - 对于 Linux，有“netem”。 在相同设置下比较 HTTP 和 HTTPS。
通过以下方式可以在一定程度上减轻延迟：
The overhead is NOT due to the encryption. On a modern CPU, the encryption required by SSL is trivial.
The overhead is due to the SSL handshakes, which are lengthy and drastically increase the number of round-trips required for a HTTPS session over a HTTP one.
Measure (using a tool such as Firebug) the page load times while the server is on the end of a simulated high-latency link. Tools exist to simulate a high latency link - for Linux there is "netem". Compare HTTP with HTTPS on the same setup.
The latency can be mitigated to some extent by:
对此没有单一的答案。
加密总是会消耗更多的CPU。 在许多情况下，这可以卸载到专用硬件，并且成本会根据所选算法的不同而有所不同。 例如，3des 比 AES 更昂贵。 有些算法对于加密器来说比解密器更昂贵。 有些则具有相反的成本。
比批量加密更昂贵的是握手成本。 新的连接将消耗更多的CPU。 这可以通过会话恢复来减少，但代价是保留旧的会话秘密直到它们过期。 这意味着来自客户的小请求如果不会回来索取更多，则成本是最高的。
对于跨互联网流量，您可能不会注意到数据速率中的这一成本，因为可用带宽太低。 但您肯定会在繁忙的服务器上的 CPU 使用情况中注意到这一点。
There isn't a single answer for this.
Encryption will always consume more CPU. This can be offloaded to dedicated hardware in many cases, and the cost will vary by algorithm selected. 3des is more expensive than AES, for example. Some algorithms are more expensive for the encrypter than the decryptor. Some have the opposite cost.
More expensive than the bulk crypto is handshake cost. New connections will consume much more CPU. This can be reduced with session resumption, at the cost of keeping old session secrets around until they expire. This means that small requests from a client that doesn't come back for more are the most expensive.
For cross internet traffic you may not notice this cost in your data rate, because the bandwidth available is too low. But you will certainly notice it in CPU usage on a busy server.
除了到目前为止提到的所有内容之外，请记住，出于安全原因，某些（所有？）网络浏览器不会将通过 HTTPS 获取的缓存内容存储在本地硬盘上。 这意味着，从用户的角度来看，具有大量静态内容的页面在浏览器重新启动后加载速度会变慢，而从服务器的角度来看，通过 HTTPS 对静态内容的请求量将高于通过 HTTP 的请求量。
In addition to everything mentioned so far, please keep in mind that some (all?) web browsers do not store cached content obtained over HTTPS on the local hard-drive for security reasons. This means that from the user's perspective pages with plenty of static content will appear to load slower after the browser is restarted, and from your server's perspective the volume of requests for static content over HTTPS will be higher than would have been over HTTP.
当前的最佳答案并不完全正确。
正如其他人在这里指出的那样，https 需要握手，因此会进行更多的 TCP/IP 往返。
在 WAN 环境中，延迟通常会成为限制因素，而不是服务器上增加的 CPU 使用率。
请记住，从欧洲到美国的延迟可能约为 200 毫秒（往返时间）。
您可以使用 HTTPWatch 轻松测量这一点（对于单个用户情况）。
The current top answer is not fully correct.
As others have pointed out here, https requires handshaking and therefore does more TCP/IP roundtrips.
In a WAN environment typically then the latency becomes the limiting factor and not the increased CPU usage on the server.
Just keep in mind that the latency from Europe to the US can be around 200 ms (torundtrip time).
You can easily measure this (for the single user case) with HTTPWatch.
由于我正在调查我的项目的相同问题，因此我找到了这些幻灯片。 较旧但有趣：
http://www.cs.nyu.edu /artg/research/comparison/comparison_slides/sld001.htm
Since I am investigating same problem for my project, I found these slides. Older but interesting:
http://www.cs.nyu.edu/artg/research/comparison/comparison_slides/sld001.htm
这里似乎有一个令人讨厌的边缘情况：Ajax 在拥塞的 wifi 上。
Ajax 通常意味着 KeepAlive 在 20 秒后超时。 然而，wifi 意味着（最好是快速的）ajax 连接必须进行多次往返。 更糟糕的是，wifi经常丢包，还有TCP重传。 在这种情况下，HTTPS 的表现真的非常糟糕！
There seems to be a nasty edge case here: Ajax over congested wifi.
Ajax usually means that the KeepAlive has timed out after say 20 seconds. However, the wifi means that the (ideally fast) ajax connection has to make multiple round trips. Worse, the wifi often loses packets, and there are TCP retransmits. In this case, HTTPS performs really really badly!
我可以告诉您（作为拨号用户），通过 SSL 访问同一页面比通过常规 HTTP 慢几倍......
I can tell you (as a dialup user) that the same page over SSL is several times slower than via regular HTTP...
在许多情况下，SSL 握手的性能影响将因 SSL 会话可以在两端（桌面和服务器）缓存而得到缓解。 例如，在 Windows 计算机上，SSL 会话最多可以缓存 10 小时。 请参阅http://support.microsoft.com/kb/247658/EN-US . 某些 SSL 加速器还具有允许您调整会话缓存时间的参数。
另一个需要考虑的影响是，通过 HTTPS 提供的静态内容不会被代理缓存，这可能会降低多个用户通过同一代理访问站点的性能。 静态内容也将缓存在桌面上，Internet Explorer 版本 6 和 7 缓存可缓存的 HTTPS 静态内容，除非另有指示（工具菜单/Internet 选项/高级/安全/不保存加密页面），这可以缓解这一问题到磁盘）。
In a number of cases the performance impact of SSL handshakes will be mitigated by the fact that the SSL session can be cached on both ends (desktop and server). On Windows machines for example the SSL session can be cached for up to 10 hours. See http://support.microsoft.com/kb/247658/EN-US . Some SSL accelerators will also have parameters allowing you to tune the time the session is cached.
Another impact to consider is that static content served over HTTPS will not be cached by proxies, and this may reduce performance across multiple users accessing the site over the same proxy. This can be mitigated by the fact that static content will be cached at desktops as well, Internet Explorer versions 6 and 7 cache cacheable HTTPS static content unless instructed to do otherwise (Tools Menu/Internet Options/Advanced/Security/Do not save encrypted pages to disk).
我做了一个小实验，从 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 握手和编码/解码数据）。
I made a small experiment and got 16% time difference for the same image from flickr (233 kb):
http://farm8.staticflickr.com/7405/13368635263_d792fc1189_b.jpg
https://farm8.staticflickr.com/7405/13368635263_d792fc1189_b.jpg
Of course these numbers depends on many factors, such as computer performance, connection speed, server load, QoS on path (the particular network path taken from browser to the server) but it shows the general idea: HTTPS is slowser then HTTP, since it requesres more operations to complete (SSL handshaking and encoding/decoding data).
这是一篇关于 SSL 握手延迟的精彩文章（有点旧，但仍然很棒）。 帮助我确定 SSL 是通过缓慢的 Internet 连接使用我的应用程序的客户速度缓慢的主要原因：
http://www.semicomplete.com/blog/geekery/ssl-latency.html
Here's a great article (a little bit old, but still great) on SSL handshake latency. Helped me identifying SSL as the main cause of slowness for clients who were using my app through slow Internet connections:
http://www.semicomplete.com/blog/geekery/ssl-latency.html
与普通的旧 HTTP 相比，我总是将 HTTPS 与较慢的页面加载时间联系起来。 作为一名 Web 开发人员，网页性能对我来说很重要，任何会降低网页性能的行为都是禁忌。
为了了解所涉及的性能影响，下图让您了解当您使用 HTTPS 请求资源时幕后发生的情况。
图所示，与使用纯 HTTP 相比，使用 HTTPS 时需要执行一些额外的步骤。 当您使用 HTTPS 发出请求时，需要进行握手以验证请求的真实性。 与 HTTP 请求相比，此握手是一个额外的步骤，并且不幸的是会产生一些开销。
为了了解性能影响并亲自了解性能影响是否显着，我使用此站点作为测试平台。 我访问了webpagetest.org，并使用视觉比较工具来比较使用HTTPS 和HTTP 的网站加载情况。
正如您可以从 这里看到使用 HTTPS 的测试视频结果确实对我的页面加载时间产生了影响，但差异可以忽略不计，我只注意到 300 毫秒的差异。 值得注意的是，这些时间取决于许多因素，例如计算机性能、连接速度、服务器负载以及与服务器的距离。
您的站点可能有所不同，彻底测试您的站点并检查切换到 HTTPS 所涉及的性能影响非常重要。
I have always associated HTTPS with slower page load times when compared to plain old HTTP. As a web developer, web page performance is important to me and anything that will slow down the performance of my web pages is a no-no.
In order to understand the performance implications involved, the diagram below gives you a basic idea of what happens under the hood when you make a request for a resource using HTTPS.
As you can see from the diagram above, there are a few extra steps that need to take place when using HTTPS compared to using plain HTTP. When you make a request using HTTPS, a handshake needs to occur in order to verify the authenticity of the request. This handshake is an extra step when compared to an HTTP request and does unfortunately incur some overhead.
In order to understand the performance implications and see for myself whether or not the performance impact would be significant, I used this site as a testing platform. I headed over to webpagetest.org and used the visual comparison tool to compare this site loading using HTTPS vs HTTP.
As you can see from Here is Test video Result using HTTPS did have an impact on my page load times, however the difference is negligible and I only noticed a 300 millisecond difference. It's important to note that these times depend on many factors, such as computer performance, connection speed, server load, and distance from server.
Your site may be different, and it is important to test your site thoroughly and check the performance impact involved in switching to HTTPS.
有许多项目旨在模糊界限并使 HTTPS 就像快速地。 例如 SPDY 和 mod-spdy.
There are many projects out there that aim to blur the lines and to make HTTPS just as fast. Like SPDY and mod-spdy.
HTTPS 有加密/解密开销，因此它总是会稍微慢一些。 SSL 终止非常消耗 CPU 资源。 如果您有设备来卸载 SSL，则延迟差异可能几乎不明显，具体取决于服务器所承受的负载。
HTTPS has encryption/decryption overhead so it will always be slightly slower. SSL termination is very CPU intensive. If you have devices to offload SSL, the difference in latencies might be barely noticeable depending on the load your servers are under.
这几乎肯定是正确的，因为 SSL 需要额外的加密步骤，而非 SLL HTTP 根本不需要这一步骤。
This is almost certainly going to be true given that SSL requires an extra step of encryption that simply isn't required by non-SLL HTTP.
有一种方法可以衡量这一点。 apache 中名为 jmeter 的工具将测量吞吐量。 如果您在受控环境中使用 jmeter 设置了服务的大量样本，无论是否使用 SSL，您都应该获得相对成本的准确比较。 我会对你的结果感兴趣。
There is a way to measure this. The tool from apache called jmeter will measure throughput. If you set up a large sampling of your service with jmeter, in a controlled environment, with and without SSL, you should get an accurate comparison of the relative cost. I would be interested in your results.
浏览器可以通过 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（版本 64）进行的一些比较：
HTTPS over HTTP/1.1：
HTTP over HTTP/1.1
HTTPS/2.0 上的 HTTPS
Browsers can accept HTTP/1.1 protocol with either HTTP or HTTPS, yet browsers can only handle HTTP/2.0 protocol with HTTPS. The protocol differences from HTTP/1.1 to HTTP/2.0 make HTTP/2.0, on average, 4-5 times faster than HTTP/1.1. Also, of sites that implement HTTPS, most do so over the HTTP/2.0 protocol. Therefore, HTTPS is almost always going to be faster than HTTP simply due to the different protocol it generally uses. However, if HTTP over HTTP/1.1 is compared with HTTPS over HTTP/1.1, then HTTP is slightly faster, on average, than HTTPS.
Here are some comparisons I ran using Chrome (Ver. 64):
HTTPS over HTTP/1.1:
HTTP over HTTP/1.1
HTTPS over HTTP/2.0
更重要的性能差异是，HTTPS 会话在用户连接时保持打开状态。 HTTP“会话”仅持续单个项目请求。
如果您运行的站点有大量并发用户，则需要购买大量内存。
A more important performance difference is that an HTTPS session is ketp open while the user is connected. An HTTP 'session' lasts only for a single item request.
It you are running a site with a large number of concurrent users, expect to buy a lot of memory.
HTTPS 确实会影响页面速度...
上面的引用揭示了许多人对网站安全和速度的愚蠢行为。 HTTPS / SSL 服务器握手会在建立 Internet 连接时造成初始停顿。 在访问者的浏览器屏幕上开始呈现任何内容之前，会有一个缓慢的延迟。 该延迟是通过“首字节时间”信息来测量的。
HTTPS 握手开销出现在首字节时间信息 (TTFB) 中。 常见的 TTFB 范围从低于 100 毫秒（最好情况）到超过 1.5 秒（最坏情况）。 但是，当然，对于 HTTPS，情况会差 500 毫秒。
往返无线 3G 连接时间可能为 500 毫秒或更长。 额外的行程导致双倍延迟，达到 1 秒或更长。 这对移动性能有很大的负面影响。 非常坏的消息。
我的建议是，如果您不交换敏感数据，那么您根本不需要 SSL，但如果您确实喜欢电子商务网站，那么您可以在某些交换敏感数据的页面（例如登录和结帐）上启用 HTTPS。
来源：Pagepipe
The HTTPS indeed affects page speed...
The quotes above reveal the foolishness of many people about site security and speed. HTTPS / SSL server handshaking creates an initial stall in making Internet connections. There’s a slow delay before anything starts to render on your visitor’s browser screen. This delay is measured in Time-to-First-Byte information.
HTTPS handshake overhead appears in Time-to-First-Byte information (TTFB). Common TTFB ranges from under 100 milliseconds (best-case) to over 1.5 seconds (worst case). But, of course, with HTTPS it’s 500 milliseconds worse.
Roundtrip, wireless 3G connections can be 500 milliseconds or more. The extra trips double delays to 1 second or more. This is a big, negative impact on mobile performance. Very bad news.
My advice, if you're not exchanging sensitive data then you don't need SSL at all, but if you do like an ecommerce website then you can just enable HTTPS on certain pages where sensitive data is exchanged like Login and checkout.
Source: Pagepipe