HTTPS与HTTP速度比较

Question

更新2013-04-25:

这是一个受欢迎的问题,它正在得到更多的关注.为了阻止错误信息的传播,请首先阅读以下段落和随附的文章:

速度不应成为决定是使用HTTPS还是HTTP的因素.如果您的站点的任何部分需要 HTTPS (登录,注册,信用卡等),您绝对需要所有这些的HTTPS.

请阅读SSL是不是加密的特洛伊亨特的原因.

---

我被认为在https下运行我的整个电子商务网站.我决定运行一个粗略的基准来测量156KB图像的下载时间,通过https vs http,因为我已经读过https负担加密过程带来的额外开销.

当从空缓存下载图像时,使用Firefox的Firebug简单地通过将"等待"和"接收"时间(所有其他时间均为0)转录到Excel中的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)会给出不同的结果吗？
有没有人有更好的基准测试下载方法？

---

这是测试图像:

[删除测试图像]

附加信息:

• 该网站通过Godaddy.com在共享主机帐户上.
• 如果您想要运行自己的基准测试,请不要添加"www"子域...无论如何我使用root作为静态内容.
• 在集成管道模式下使用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点左右共享托管,我的特定服务器上通过https服务的内容比http更快.

Answer 1

如果你看一下你的时间,http有更长的等待时间和更短的接收时间.另一方面,https具有较小的等待时间和较长的接收时间.我会解释这一点,因为共享主机服务器上的http端口更忙,因此请求在队列中保持更长时间,直到服务器接受为止.一旦被接受,请求的传输速度将快于https.在https端口上,服务器上的流量较少,因此请求的服务速度更快,但传输时间更长.

对于任何https与http比较,您必须考虑与http相比,握手每个https请求的时间更长.在做很多小的请求时你会看到恶化.

Answer 2

您可能还需要考虑到除了用户浏览器之外几乎不会将HTTPS文档缓存到任何地方,因此您可能会发现虽然对于单个用户没有什么区别,但对于大量共享一个人的人来说,HTTP文档可以明显更快.缓存.(在某些地方,ISP通过共享代理缓存使用其客户仍然很常见)

当然,如果这是你不介意用户分享的东西.

Answer 3

我认为通过HTTPS看到的更快的性能并不是侥幸.

请注意有关结果的两件事:

1. HTTP在第一个"总"结果上总是更快,但在后续总计中更慢.
2. HTTPS结果更加一致.

现代负载平衡器通常启用压缩,而SSL正在使用以帮助提高性能.虽然初始SSL握手确实会产生大量延迟,但用于维护会话的机制("恢复握手"和对称加密而非非对称加密)只会增加可忽略的延迟.因此,除非您的会话很短,否则您从压缩中获得的性能优势远远超过会话维护所带来的损失.

SSL导致大量延迟的传统观念已经过时(除非你的会话很短).一些谷歌工程师撰写了一篇文章,解释了之前关于SSL的一些假设是如何不再适用的.