HTTPS 与 HTTP 速度比较
2013-04-25 更新：
这是一个很受欢迎的问题，但得到的关注却超出了应有的程度。为了阻止错误信息的传播，请先阅读以下段落和随附文章：
速度不应成为决定使用 HTTPS 还是 HTTP 的因素。如果您网站的任何部分（登录、注册、信用卡等）需要 HTTPS，那么您绝对需要 HTTPS 来实现所有这些强>，一直。
我考虑在 https 下运行我的整个电子商务网站。我决定运行一个粗略的基准测试来测量通过 https 与 http 的 156KB 图像的下载时间，因为我了解到 https 承受着加密过程的额外开销。
基准测试是使用 Firefox 的 Firebug 执行的，只需在从空缓存下载图像时，将“等待”和“接收”时间（所有其他时间均为 0）从网络面板转录到 Excel 中即可。
我的结果出乎意料：
http: 11.233 seconds
Waiting Receiving Total
1.56 0.88 2.44
1.55 0.101 1.651
1.53 0.9 2.43
1.71 0.172 1.882
1.9 0.93 2.83
https: 9.936 seconds
Waiting Receiving Total
0.867 1.59 2.457
0.4 1.67 2.07
0.277 1.5 1.777
0.536 1.29 1.826
0.256 1.55 1.806
[明显]基准测试的观察结果：
- https 的服务器响应速度更快，但下载时间比 http 慢。
- https 总体上速度显着加快 (~10%)。
<强> 谁能解释一下为什么会发生这种情况？
您认为文档（html、css、javascript）会给出不同的结果吗？
有没有人有更好的下载基准测试方法？
Here is the test image:
[测试图像已删除]
附加信息：
- 该网站位于 Godaddy.com 的共享托管帐户上。
- 如果您打算运行自己的基准测试，请不要添加“www”子域...无论如何，我都使用根目录来存储静态内容。
- 在集成管道模式下使用 IIS7。
编辑：下面 1px GIF（35 字节）的基准：
http: 2.666 seconds
Waiting Receiving Total
0.122 0.31 0.432
0.184 0.34 0.524
0.122 0.36 0.482
0.122 0.34 0.462
0.126 0.64 0.766
https: 2.604 seconds
Waiting Receiving Total
0.25 0.34 0.59
0.118 0.34 0.458
0.12 0.34 0.46
0.182 0.31 0.492
0.134 0.47 0.604
结果： https 还是更快；尽管在这种情况下微不足道。
如果有人发现我的基准测试存在缺陷，请告诉我，以便我可以发布更好的结果。
因此，在 Godaddy 共享托管上，下午 6:00 左右，在我的特定服务器上，通过 https 提供的内容比通过 http 提供的速度更快。
Update 2013-04-25:
This is a popular question that is getting more attention than it probably should. In order to stop the spread of misinformation please read the following paragraphs and the accompanying article first:
Speed should not be a factor in deciding whether to use HTTPS or HTTP. If you need HTTPS for any part of your site (log-ins, registration, credit cards, etc), you absolutely need HTTPS for all of it, all the time.
Please read SSL is not about encryption by Troy Hunt for the reasons why.
I'm considered running my entire e-commerce website under https. I decided to run a crude benchmark to measure the download time of a 156KB image through https vs http because I had read that https is burdened with additional overhead from the encryption process.
Benchmark was performed using Firefox's Firebug simply by transcribing the "Waiting" and "Receiving" times (all other times are 0) to Excel from the Net panel when downloading the image from an empty cache.
My results were unexpected:
http: 11.233 seconds
Waiting Receiving Total
1.56 0.88 2.44
1.55 0.101 1.651
1.53 0.9 2.43
1.71 0.172 1.882
1.9 0.93 2.83
https: 9.936 seconds
Waiting Receiving Total
0.867 1.59 2.457
0.4 1.67 2.07
0.277 1.5 1.777
0.536 1.29 1.826
0.256 1.55 1.806
[Obvious] Observations from benchmark:
- The server response is faster but the download time is slower for https than http.
- https is faster overall by a significant amount (~10%).
Can anyone explain why this would happen?
Do you think a document (html,css,javascript) will give different results?
Does anyone have a better method of benchmarking downloads?
Here is the test image:
[test image removed]
Additional Information:
- The website is on a shared hosting account through Godaddy.com.
- If you are going to be so kind as to run your own benchmark don't add the "www" subdomain...I use the root for static content anyway.
- Uses IIS7 in Integrated Pipeline Mode.
Edit: benchmark for 1px GIF (35 bytes) below:
http: 2.666 seconds
Waiting Receiving Total
0.122 0.31 0.432
0.184 0.34 0.524
0.122 0.36 0.482
0.122 0.34 0.462
0.126 0.64 0.766
https: 2.604 seconds
Waiting Receiving Total
0.25 0.34 0.59
0.118 0.34 0.458
0.12 0.34 0.46
0.182 0.31 0.492
0.134 0.47 0.604
Results:
https is still faster; though trivially in this case.
If anyone sees a flaw in my benchmark let me know so I can post better results.
So, on Godaddy shared hosting at around 6:00pm on my specific server content served over https is faster than over http.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
如果你看看你的时间http有更长的等待时间和更小的接收时间。另一方面，https 的等待时间更短，接收时间更长。我将其解释为共享托管服务器上的 http 端口更加繁忙，因此请求在队列中停留的时间更长，直到被服务器接受。一旦被接受，请求的传输速度比 https 更快。在 https 端口上，服务器上的流量较少，因此请求的处理速度更快，但传输时间更长。
对于任何 https 与 http 的比较，您必须考虑到与 http 相比，每个 https 请求的握手时间更长。当执行许多小请求时，您应该会看到情况变得更糟。
If you look at your times http has bigger waiting time and smaller receiving time. https on the other hand has smaller waiting time and bigger receiving time. I would interpret this as the http port on the shared hosting server is more busy, thus a request stays longer in the queue until is accepted by the server. Once accepted, the requests is transferred faster than https. On the https port there is less traffic on the server so the request is serviced faster but takes longer to transfer.
For any https vs. http comparison you'll have to take into account the bigger time to handshake each request for https compared with http. You should see worsening when doing many small requests.
您可能还需要考虑到 HTTPS 文档几乎将
除了用户浏览器之外，永远不会缓存在任何地方，因此您可能会发现
虽然对于个人用户来说差别不大，但是 HTTP 文档
对于大量共享缓存的人来说，速度会明显加快。
（在某些地方，ISP 将其客户置于
通过共享代理缓存）
当然，如果您不介意用户共享它。
You may also want to take into account that HTTPS documents will almost
never be cached anywhere except the users browser, so you might find that
while there's little difference to an individual user, an HTTP document
can be significantly quicker for large numbers of people sharing a cache.
(It's still quite common in some places for ISPs to put their customers
through a shared proxy cache)
If it's something that you don't mind users sharing, of course.
我认为通过 HTTPS 获得的更快性能并非侥幸。
请注意有关结果的两件事：
现代负载均衡器通常会启用压缩，同时使用 SSL 来提高性能。虽然初始 SSL 握手确实会产生大量延迟，但用于维持会话的机制（“恢复握手”和对称加密而不是非对称加密）仅增加了可以忽略不计的延迟。因此，除非您的会话很短，否则您从压缩中获得的性能优势将多于会话维护中损失的性能优势。
SSL 会产生大量延迟的传统观点已经过时（除非您的会话非常短）。一些 Google 工程师撰写了一篇文章解释了之前关于 SSL 的一些假设不再真实。
I think the faster performance you're seeing over HTTPS isn't a fluke.
Notice two things about your results:
Modern load balancers typically enable compression while SSL is in use to aid performance. While it's true that the initial SSL handshake incurs substantial latency, the mechanisms used to maintain the session (the "resumed handshake" and symmetric encryption instead of asymmetric encryption) add only negligible latency. As a result, unless your sessions are short, you get more performance benefit from the compression than you lose from the session maintenance.
The conventional wisdom that SSL incurs substantial latency is out of date (unless your sessions are quite short). Some Google engineers wrote an article explaining how some previous assumptions about SSL are no longer true.
https 的工作原理如下：
首先执行四次握手（至少如果我没记错的话是四次握手），
这里客户端和服务器就稍后使用的对称加密算法达成一致并交换证书（包含公钥）。
他们使用公钥加密交换会话（稍后对称 enc 的密钥）。
现在，他们发送使用会话密钥和某种加密算法（3des、aes、rc4、rc5 等）加密的消息。由于对称加密并不是那么昂贵的操作，因此下载时间的差异并不大。
事实上，您的等待时间更少是因为与 http 请求相比，您在 http 端口上的流量可能较少，或者在您执行 https 请求时的流量也较少。
因此，为了优化性能，您应该使用尽可能少的 https 连接，因为握手是一个相对昂贵的过程。
https works as follows:
First a 4-way handshake is performed (at least if i remember correctly it was 4way),
here client and server agree on the symmetric encryption algorithm used later on and exchange certificates (containing public keys).
They exchange a session (key for the symmetric enc later) using publickey crypto.
Now they send messages encrypted with the session key and some encryption algorithm (3des, aes, rc4, rc5, etc). Since symmetric encryptions are not that expensive operations the differences in download time are not that big.
The fact that you have less waiting time is because you probably have less traffic on http port or less traffic at the time you did the https request compared to the http requests.
So to optimize performance you should use as few https connections as possible since the handshake is a relative expensive procedure.
您是否通过代理访问您的网站？如果是这样，您可能会看到更好的性能，因为代理被绕过或简化为仅使用处理初始 CONNECT 请求。
当您使用 HTTP 时，代理可能会检查和缓存内容 - 导致性能下降。
Are you accessing your site through a proxy? If so, you may be seeing better performance because the proxy is being bypassed or reduced to just using handling the initial CONNECT requests.
A proxy could be checking and caching content when you use HTTP - leading to reduced performance.
速度上的全部差异很可能是由于 GoDaddy 在其服务器上强制执行 HTTP 压缩以节省带宽，但这在 HTTPS 样式连接中不会总是发生，因为它是较新的并更好地优化启动。
The whole difference in speed is most likely due to GoDaddy enforcing HTTP Compression on their servers in an effort to conserve bandwidth, but this is something that doesn't always occur with the HTTPS style connection as it is newer and better optimized to start.