HTTP/3 为什么这么快？( 二 ) _HTTP

如果你不关心测试是怎么进行的，那就跳到下方的结果吧！
HTTP/3 的基准测试要想了解 HTTP/3 在性能方面带来了什么改变，我们需要先搭建一个基准测试环境。
html为了能更贴合实际使用情况，这次的测试考虑了三种场景 —— 一个小型站点、一个内容站点（大量图片和些许 JavaScript 资源）和一个单页面应用（大量 JavaScript 资源）。我查看了几个现实生活中的站点，并计算了每个站点的图片和 JavaScript 文件的平均数量，然后编写了一些与这些资源数量（和大小）差不多的的演示站点。

小型站点
- 10 个 2 kB 到 100 kB 的 JavaScript 文件；
- 10 张 1kB 到 50 kB 的图片；
- 总载荷大小 600 kB ，共计 20 个阻塞资源。
内容站点
- 50 个 2 kB 到 1 MB 的 JavaScript 文件；
- 55 张 1 kB 到 1 MB 的图片；
- 总载荷大小 10MB ，共计 105 个阻塞资源（在开发者工具中看看 cnn.com 你就会明白这个量为什么会这么大了）。
单页面应用
- 85 个 2 kB 到 1 MB 的 JavaScript 文件；
- 30 张 1 kB 到 50 kB 的图片；
- 总载荷大小 15MB ，共计 115 个阻塞资源（在开发者工具中看看 JIRA （缺陷跟踪管理系统）吧）。

服务端Caddy 作为这次测试的服务器，向外提供资源及 HTML 。

所有响应都使用 Cache-Control: "no-store" 以确保浏览器每次都会重新下载资源；
HTTP/1.1 和 HTTP/2 使用 TLS 1.2；
HTTP/3 使用 TLS 1.3；
所有的 HTTP/3 连接都开启 0-RTT 。

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

美国纽约
英国伦敦
印度班加罗尔

客户端浏览器将连续请求同一个页面 20 次，每次请求间隔 3 秒，过程完全自动化。网络的额定速度为 200 Mbps 。数据采集时，计算机上没有运行其他应用程序。
HTTP/3 有多快？美国纽约以下是从纽约数据中心请求三个不同站点时 HTTP/2 与 HTTP/3 的响应时间：

文章插图

HTTP/3 在：

小型站点快了 200 毫秒
内容站点快了 325 毫秒
单页面应用快了 300 毫秒

明尼苏达州距离纽约 1000 英里（约等于 160 公里）；这长度对于网络连接来说不算什么。然而重要的是，即使在相对较短的距离内， HTTP/3 也能够将性能提高这么多。
英国伦敦在这次的测试中，我也包含了 HTTP/1.1 的基准测试。为了展示 HTTP/2 和 HTTP/3 快了多少，我将下方图表的轴刻度都保持一致了。你可以看到，对于内容站点， HTTP/1.1 的速度是多么的慢；慢得连图表都不能完全显示！

文章插图

正如你所见，当网络的距离更远时，速度的提高更明显了。

小型站点快了 600 毫秒（速度是纽约的 3 倍）
内容站点快了 1200 毫秒（速度是纽约的 3.5 倍）
单页面应用快了 1000 毫秒（速度是纽约的 3 倍）

印度班加罗尔HTTP/3 性能的进步在从印度加载页面时最为明显。我并不打算测试 HTTP/1.1 ，因为它太慢了。以下是 HTTP/2 与 HTTP/3 的结果对比：

文章插图

当请求涉及更大的地理区域和更多的网络跃点时， HTTP/3 仍然继续领先。更值得注意的是 HTTP/3 的响应时间数据分布是多么的集中（译者注：这说明在保证快的前提下， HTTP/3也很稳定）。当数据包传输数千英里时， QUIC 将发挥重要的作用。
在每种情况下 HTTP/3 都比历代 HTTP 更快！
为什么 HTTP/3 这么快？真正的多路复用HTTP/3 真正的多路复用特性意味着堆栈上的任何地方都不会发生队头阻塞。当你从更远的地理位置请求资源时，丢包的可能性会高出很多， TCP 重新传输的需求也会提高。