38

2013 年 4 月 25 日更新：

这是一个受欢迎的问题，它得到的关注超出了它可能应该得到的关注。为了阻止错误信息的传播，请先阅读以下段落和随附的文章：

速度不应成为决定使用 HTTPS 还是 HTTP 的因素。如果您网站的任何部分（登录、注册、信用卡等）都需要 HTTPS，那么您绝对需要始终使用 HTTPS。

请阅读SSL 不是关于Troy Hunt的加密的原因。

我被考虑在 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）会给出不同的结果吗？
有没有人有更好的基准下载方法？



这是测试图像：

[删除测试图像]

附加信息：

  • 该网站位于通过 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还是更快；虽然在这种情况下微不足道。

如果有人发现我的基准测试中有缺陷，请告诉我，以便我发布更好的结果。

因此，在下午 6:00 左右的 Godaddy 共享主机上，我通过 https 提供的特定服务器内容比通过 http 更快。

4

6 回答 6

19

如果您查看您的时间，http 的等待时间更长，接收时间更短。另一方面，https 的等待时间更短，接收时间更长。我将此解释为共享托管服务器上的 http 端口更忙，因此请求在队列中停留的时间更长，直到被服务器接受。一旦被接受，请求的传输速度将比 https 更快。在 https 端口上，服务器上的流量较少，因此请求的服务速度更快，但传输时间更长。

对于任何 https 与 http 的比较，您都必须考虑到与 http 相比，握手每个 https 请求的时间更长。在执行许多小请求时，您应该会看到情况恶化。

于 2009-09-23T21:50:20.753 回答
11

您可能还需要考虑到 HTTPS 文档几乎不会被缓存到除了用户浏览器之外的任何地方，因此您可能会发现，虽然对于单个用户来说几乎没有区别，但对于大量共享缓存。（在某些地方，ISP 将客户通过共享代理缓存仍然很常见）

当然，如果您不介意用户共享它。

于 2009-09-24T01:37:53.280 回答
5

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

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

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

现代负载平衡器通常在使用 SSL 以提高性能时启用压缩。虽然初始 SSL 握手确实会产生大量延迟，但用于维护会话的机制（“恢复握手”和对称加密而不是非对称加密）只会增加微不足道的延迟。因此，除非您的会话很短，否则您从压缩中获得的性能收益要比从会话维护中损失的性能收益多。

SSL 导致大量延迟的传统观点已经过时（除非您的会话非常短）。一些 Google 工程师写了一篇文章，解释了以前关于 SSL 的一些假设如何不再正确。

于 2010-11-16T21:24:15.660 回答
2

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

他们使用公钥加密交换会话（稍后对称编码的密钥）。

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

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

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

于 2009-09-23T21:59:45.180 回答
1

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

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

于 2009-09-24T17:12:28.997 回答
-1

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

于 2016-03-02T22:42:04.780 回答