HTTPS与HTTP速度比较

Question

更新2013-04-25：

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

速度不应成为决定是否使用HTTPS或HTTP的因素。如果您需要 HTTPS 您网站的任何部分（登录，注册，信用卡等），您绝对需要所有的HTTPS ，一直都在。

请SSL is not about encryption阅读Troy Hunt了解原因。

---

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

使用Firefox的Firebug进行基准测试，只需在从空缓存下载图像时，从“Net”面板中将“等待”和“接收”时间（所有其他时间均为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）会给出不同的结果吗？ 有没有人有更好的基准测试下载方法？

<小时/>

这是测试图像：

[删除测试图像]

其他信息：

• 该网站位于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文档）没有什么区别 对于大量共享缓存的人来说，可以显着更快。 （在某些地方，互联网服务提供商放置他们的客户仍然很常见 通过共享代理缓存）

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

Answer 3

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

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

1. HTTP在第一个“总计”结果中总是更快，但在后续总计中更慢。
2. HTTPS结果更加一致。

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

SSL导致大量延迟的传统观念已经过时（除非你的会话很短）。一些Google工程师wrote an article解释了以前关于SSL的一些假设不再适用。

Answer 4

https的工作原理如下： 首先进行4次握手（至少如果我没记错的话，它是4路）， 这里客户端和服务器就稍后使用的对称加密算法达成一致并交换证书（包含公钥）。

他们使用publickey crypto交换会话（后来对称enc的密钥）。

现在，他们发送使用会话密钥和一些加密算法（3des，aes，rc4，rc5等）加密的消息。由于对称加密并不是那么昂贵的操作，因此下载时间的差异并不大。

您更少等待时间的事实是因为与http请求相比，您执行https请求时，http端口上的流量可能较少或流量较少。

因此，为了优化性能，您应该使用尽可能少的https连接，因为握手是一个相对昂贵的过程。

Answer 5

您是否通过代理访问您的网站？如果是这样，您可能会看到更好的性能，因为代理被绕过或简化为仅使用处理初始CONNECT请求。

当您使用HTTP时，代理可能正在检查和缓存内容 - 导致性能下降。

Answer 6

速度的全部差异很可能是由于GoDaddy在其服务器上强制执行HTTP压缩以节省带宽，但这种情况并不总是以HTTPS样式发生连接，因为它更新，更好地优化启动。