基准测试：HTTP/3 有多快？ - requestmetrics

为了了解 HTTP/3 产生什么样的性能差异，需要一个基准测试设置。

为了更接近实际使用情况，测试设置由三个场景组成 - 一个小站点、一个内容丰富的站点（大量图像和一些 JS）和一个单页面应用程序（在 JS 上很重）。我查看了几个真实世界的站点，并对每个站点的图像和 JS 文件的数量求平均值，然后编写了一些与这些资源数量（和大小）匹配的演示站点。

HTML

小型站点 10 个2kb 到 100kb 的 JS 文件 从 1kb 到 50kb 的10张图像 总有效载荷大小600kb，总共 20 个阻塞资源 内容站点 50 个2kb 到 1mb 的 JS 文件 55张大小从 1kb 到 1mb 的图像。 总有效负载大小10MB，总共 105 个资源（有时在开发工具中查看 cnn.com，您会明白为什么它如此之大） 单页应用程序 从 2kb 到 1mb 的85 个JS 文件 30张大小从 1kb 到 50kb 的图像。 总有效负载大小15MB，总共 115 个资源（有时在开发工具中查看 JIRA）

服务器

用于提供所有资产和 HTML。

提供所有响应Cache-Control: "no-store"以确保浏览器每次都会重新下载。 TLS 1.2 用于 HTTP/1.1 和 HTTP/2 用于 HTTP/3。 为所有 HTTP/3 连接启用了

客户端

让浏览器自动连续请求同一页面 20 次，在页面加载后等待 3 秒开始下一个请求。互联网连接的额定速度为 200mbps。数据捕获时，计算机上没有运行其他应用程序。

测试地点

测试是从我在明尼苏达州的计算机到由 Digital Ocean 托管的三个独立数据中心进行的：

美国纽约，相比Http2： 小型站点快200 毫秒 内容站点快325 毫秒 单页应用程序快300 毫秒 伦敦，英国，相比http2: 小型站点快600 毫秒（与纽约相比，速度提高了3 倍） 1200ms（以上为内容网站更快的3.5倍与纽约相比的加速） 单页应用程序快1000 毫秒（与纽约相比，速度提高了3 倍以上） 印度班加罗尔：当涉及更大的地域和更多的网络跃点时，HTTP/3 继续领先。也许更引人注目的是 HTTP/3 的响应时间分组的紧密程度。当数据包传输数千英里时，QUIC 会产生很大的影响。

结论

在任何情况下，HTTP/3 都比HTTP/2更快！

为什么 HTTP/3 这么快？

真正的多路复用

HTTP/3 真正的多路复用特性意味着堆栈中的任何地方都不会发生行头阻塞。当从更远的地方请求资源时，在地理上，数据包丢失的可能性要高得多，并且 TCP 需要重新传输这些数据包。

0-RTT 是游戏规则的改变者

此外，HTTP/3 支持 QUIC 连接，这降低了与服务器建立安全 TLS 连接所需的往返次数。