HTTP/1.1、HTTP/2、HTTP/3 到底差多少？实测：单次请求总耗时几乎一样

HTTP/1.1、HTTP/2、HTTP/3 在单次请求、良好网络下，总耗时几乎一样；HTTP/3 的优势在弱网和并发，不在单请求延迟。用 curl 对支持 HTTP/3 的 www.cloudflare.com 各测 5 次，总耗时中位数是 287ms（1.1）/ 279ms（2）/ 299ms（3），差异在 20ms 以内。

顺便说一句：宝塔 HTTP 检测（t.bt.cn/http/）的全国节点结果里，响应头统一是 HTTP/1.1——它不主动升级 HTTP/2、HTTP/3。下面分开讲清。

宝塔 HTTP 检测为什么都是 HTTP/1.1

用宝塔网站测速对 www.cloudflare.com 做了一次全国拨测：384 个成功节点，响应头全部是 HTTP/1.1 200 OK，没有一个协商到 HTTP/2 或 HTTP/3。

原因是检测节点用 HEAD 请求探测，默认按 HTTP/1.1 发起、不主动做协议升级。所以拨测回答的是「全国各节点能不能连上、耗时多少、状态码是什么」，它不会告诉你换成 HTTP/2、HTTP/3 会快多少。

本次拨测口径：384/389 节点成功、覆盖 59 个省份，总耗时中位数 851.2ms、首字节中位数 835.6ms。这是全国跨网访问的耗时，和下面本机单点对比是两套数字，别混为一谈。

用 curl 指定协议版本实测

要看协议差异，用 curl 的 --http1.1 / --http2 / --http3 分别测。目标选支持 HTTP/3 的 www.cloudflare.com，本机单点各跑 5 次取中位数（2026-10-28）：

协议	TTFB（首字节）中位数	总耗时中位数
HTTP/1.1	273ms	287ms
HTTP/2	30ms	279ms
HTTP/3	28ms	299ms

结论很直接：总耗时基本持平（287 / 279 / 299ms，最大差 20ms）。TTFB 一栏 HTTP/2、HTTP/3 只有约 30ms，看着像快 10 倍，其实是假象——下面解释。

TTFB 快 10 倍是 103 Early Hints 的假象

curl 的 time_starttransfer（首字节）测的是「收到第一个响应字节」。Cloudflare 对 HTTP/2、HTTP/3 会先返回一条 103 Early Hints（预加载提示），再返回真正的 200。curl 把这条 103 记为「首字节到达」，所以 TTFB 只有约 30ms。

HTTP/1.1 不返回 103，首字节就是 200 响应的第一字节，所以显示 273ms。

真正的内容响应到达时间要看总耗时：三个协议都是 280–300ms，没有 10 倍差异。

HTTP/3 的优势在哪：弱网和并发，不在单请求

单次请求测不出 HTTP/3 的优势，因为它的改进都在传输层：

• 多路复用：HTTP/2 已支持；HTTP/3 进一步用 QUIC（基于 UDP）消除 TCP 层的队头阻塞。
• 弱网丢包：QUIC 丢一个包只重传对应流，不像 TCP 要等整条连接恢复。
• 连接迁移：手机在 Wi-Fi 和蜂窝网络间切换时，QUIC 用连接 ID 保持连接，不用重新握手。

这些在「单点、良好网络、单请求」里都不体现，所以上面实测三个协议总耗时几乎一样。

怎么自己复现

1. 打开宝塔网站测速，输入目标看全国节点的总耗时和状态码，响应头里能看到协商出的 HTTP 版本。
2. 单点测协议差异，用 curl：

curl -o /dev/null --http1.1 -w 'HTTP/1.1 TTFB=%{time_starttransfer} 总耗时=%{time_total}\n' https://www.cloudflare.com/
curl -o /dev/null --http2    -w 'HTTP/2   TTFB=%{time_starttransfer} 总耗时=%{time_total}\n' https://www.cloudflare.com/
curl -o /dev/null --http3    -w 'HTTP/3   TTFB=%{time_starttransfer} 总耗时=%{time_total}\n' https://www.cloudflare.com/

注意：目标必须支持对应协议，HTTP/3 要服务器开启 QUIC。不同站点的协议支持情况不同，测前先确认目标是否开启 QUIC。