为了了解 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）
服务器
Caddy用于提供所有资产和 HTML。
- 提供所有响应Cache-Control: "no-store"以确保浏览器每次都会重新下载。
- TLS 1.2 用于 HTTP/1.1 和 HTTP/2
- TLS 1.3用于 HTTP/3。
- 为所有 HTTP/3 连接启用了0-RTT
客户端
让浏览器自动连续请求同一页面 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 支持O-RTT QUIC 连接，这降低了与服务器建立安全 TLS 连接所需的往返次数。