HTTPS 与 HTTP 速度比较答案

【问题标题】：HTTPS vs HTTP speed comparisonHTTPS 与 HTTP 速度比较
【发布时间】：2010-11-30 22:01:53
【问题描述】：

2013 年 4 月 25 日更新：

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

速度不应成为决定使用 HTTPS 还是 HTTP 的因素。如果您需要 HTTPS 用于您网站的任何部分（登录、注册、信用卡等），您绝对需要 HTTPS 来处理所有内容强>，一直如此。

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

我正在考虑在 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 更快。

【问题讨论】：

你在压缩这两个请求中的任何一个吗？
没有。没想到你可以 GZip 图像。
您能否在每次请求后重新启动 Firefox 进行测试，以强制执行完整的 https 握手，就像客户端从不同位置连接一样？
当然，我明天试试。但是，由于用户在每次请求之间都没有重新启动浏览器，因此初始握手可能并不那么重要。我会再研究一下。
您甚至可以在图像上设置字符集，例如 UTF-8 和浏览器（至少 ff）尝试从图像中删除 utf-8 编码，因为它不是 utf-8编码图像被破坏。（在更改我的服务器上的配置后，我发现它甚至将 charset-header 添加到图像中）

标签： http ssl https benchmarking download-speed

【解决方案1】：

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

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

【讨论】：

感谢您的信息。这说得通。我会在 1x1 像素 gif 上进行基准测试，并及时回复您。
您还需要考虑到 SSL 握手会在同一个客户端重新连接时缩短（请参阅en.wikipedia.org/wiki/…），以便提供准确的图片，您需要从各种客户端进程中进行测试和机器。

【解决方案2】：

您可能还需要考虑到 HTTPS 文档几乎除了用户浏览器之外，永远不会被缓存在任何地方，所以你可能会发现虽然对单个用户来说差别不大，但 HTTP 文档对于共享缓存的大量人员来说，速度可能会更快。（在某些地方，ISP 将客户置于通过共享代理缓存）

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

【讨论】：

+1 一个非常的好点。如果使用 HTTPS，大部分请求将访问网站的源 Web 服务器，并使网站的可扩展性大大降低。使用 HTTP，中间缓存将占用大量负载，网站的扩展性会更好。
即使 HTTP Header 的 Cache-Control 设置为“public”且具有远期的过期标头？例如缓存控制：public，max-age=2677884 过期：星期六，2009 年 10 月 24 日 20:50:14 GMT
@David：HTTPS 是通过加密的 SSL/TLS 隧道建立的 HTTP 隧道。任何 HTTP 属性（如标头）对于中间体都是不可见的，因为它们无法进入加密的 SSL 隧道。

【解决方案3】：

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

请注意关于您的结果的两件事：

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

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

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

【讨论】：

【解决方案4】：

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

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

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

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

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

【讨论】：

【解决方案5】：

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

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

【讨论】：

【解决方案6】：

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

【讨论】：