HTTP/2和HTTP/3对CDN速度差多少？如何确认网站真的启用了

在CDN控制台打开HTTP/3以后，网站能快多少？

有人期待速度提升30%，有人实际测试后发现HTTP/2和HTTP/3几乎没有区别，还有人看到响应头里出现alt-svc，就认为网站已经通过HTTP/3传输了。

这些判断都不够完整。

HTTP/3的主要价值，并不是让每一次请求都固定减少几十毫秒，而是在高延迟、丢包、移动网络和网络切换环境中，降低连接建立及队头阻塞带来的影响。网络本来就很稳定、连接又能长期复用时，HTTP/2和HTTP/3的速度差异可能非常小。

先给出一个直接结论：

稳定的低延迟网络中，HTTP/3可能只比HTTP/2快0%～5%，甚至没有提升；在高延迟、存在丢包的移动网络或跨国线路中，部分页面和长尾请求可能改善5%～20%，特殊情况下还会更高，但这不是所有网站都能获得的固定收益。

是否真正启用HTTP/3，也不能只看CDN控制台开关或响应头。最终应确认浏览器实际协商出的协议是不是h3。

HTTP/2和HTTP/3到底差在哪里

HTTP/2和HTTP/3都支持多路复用，也就是在一条连接中并行传输多个请求。两者最根本的区别在于底层传输协议：

• HTTP/2通常运行在TCP和TLS之上；

• HTTP/3运行在QUIC之上；

• QUIC基于UDP承载，并把TLS 1.3整合进连接建立过程；

• HTTP/3将多个请求放在相互独立的QUIC流中传输。

RFC 9114将HTTP/3定义为使用QUIC传输HTTP语义的协议。它保留了与HTTP/2相似的HTTP能力，但根据QUIC的流和连接机制重新设计了传输方式。

HTTP/2的问题不在于不能并发

HTTP/2已经解决了HTTP/1.1需要建立多条连接才能并发请求的问题。一个域名通常可以通过一条TCP连接同时传输HTML、CSS、JavaScript、图片等资源。

问题在于，这些HTTP/2流仍然共享同一条TCP连接。

如果某个TCP数据包丢失，TCP需要先恢复缺失的数据，再向上层交付后续内容。即使后续数据属于另一个没有丢包的HTTP请求，它也可能一起等待。这通常被称为TCP层的队头阻塞。

在丢包很少、往返延迟很低的网络里，这种等待可能不明显；到了移动网络、跨国链路或者晚高峰，它就可能放大页面长尾时间。

HTTP/3为什么更适合不稳定网络

QUIC在一个连接内提供多条独立的传输流。某条流的数据丢失时，主要阻塞这条流，不需要让其他流全部等待缺失数据恢复。

这意味着一张图片丢包时，其他CSS、JavaScript或接口请求仍有机会继续传输。

不过，这并不意味着HTTP/3能够消除丢包影响。QUIC连接仍然需要进行拥塞控制，严重丢包仍会降低总体吞吐量。它改善的是不同请求之间相互阻塞的问题，而不是把质量很差的网络变成无损网络。

RFC 9308指出，QUIC使用UDP承载并整合TLS 1.3，同时也提醒应用开发者考虑网络设备、UDP可达性和实际部署环境等问题。

HTTP/3实际能让CDN快多少

没有一个适用于所有网站的固定百分比。实际差异取决于四个条件：

1. 用户和CDN节点之间的网络延迟；

2. 链路是否存在丢包和抖动；

3. 浏览器是否复用了已有连接；

4. 页面需要并发加载多少资源。

可以把常见结果大致分成以下几类：

表中的数字只能作为测试预期，不能当作HTTP/3的性能承诺。同一个网站在上海电信、东南亚移动网络和美国住宅宽带中，可能得到完全不同的结果。

为什么有些网站启用HTTP/3以后几乎没变化

如果网站符合下面这些条件，HTTP/3的提升通常不会特别明显：

• 用户距离CDN节点很近；

• 网络丢包率很低；

• 页面资源数量不多；

• 浏览器大量使用缓存；

• 用户主要是重复访问；

• HTTP/2连接能够长期复用；

• 性能瓶颈在源站、数据库或前端渲染。

例如一个接口TTFB需要1.5秒，其中1.3秒都花在源站查询数据库上。即使HTTP/3节省了几十毫秒，用户感知仍然不会有明显变化。

同样，如果LCP过慢是因为首屏图片有3MB，问题重点应该是图片压缩、尺寸和加载优先级，而不是协议版本。

为什么HTTP/3有时反而更慢

HTTP/3不是只要开启就一定更快。以下情况可能让它表现不如HTTP/2：

• 企业网络、防火墙或运营商限制UDP 443端口；

• 用户到CDN节点的UDP路径质量差于TCP；

• CDN在该地区的QUIC实现或调度不理想；

• 客户端首次尝试HTTP/3失败后又回退HTTP/2；

• 测试样本过少，刚好遇到一次网络抖动；

• HTTP/2和HTTP/3请求被调度到不同节点；

• 测试时两边缓存状态不同。

因此，看到单次HTTP/3请求比HTTP/2慢，不足以判断协议无效。至少需要比较相同地区、相同运营商和相同缓存状态下的P50与P95。

开启HTTP/3为什么第一次访问仍可能显示HTTP/2

浏览器必须先知道服务器支持HTTP/3。

常见发现方式包括：

• 服务器通过Alt-Svc响应头声明支持HTTP/3；

• DNS的HTTPS记录提供HTTP/3相关协议信息；

• 浏览器此前访问过该站点，已经缓存了HTTP/3可用信息。

如果浏览器此前完全不知道网站支持HTTP/3，第一次请求可能先通过HTTP/2完成。服务器返回类似下面的响应头：

alt-svc: h3=":443"; ma=86400

浏览器记住这项信息后，后续连接才尝试使用HTTP/3。Cloudflare对HTTP/3发现机制的说明也提到，Alt-Svc是在客户端先通过其他协议访问服务器后返回的，而HTTPS DNS记录可以更早提供协议信息。

因此，第一次刷新显示h2、第二次刷新显示h3，不一定是配置错误。

但需要注意：

响应头出现alt-svc: h3，只能证明服务器向客户端声明支持HTTP/3，不能证明当前这个请求已经通过HTTP/3传输。

要确认实际协议，必须检查请求协商结果。

方法一：使用Chrome开发者工具确认HTTP/3

这是普通站长最直接的检查方法。

操作步骤

1. 使用最新版Chrome打开网站；

2. 按F12打开开发者工具；

3. 进入“Network”面板；

4. 在请求列表的表头处点击右键；

5. 勾选“Protocol”列；

6. 刷新页面；

7. 查看主文档及静态资源的协议。

Chrome开发者工具显示的常见结果包括：

• h2：当前请求使用HTTP/2；

• h3：当前请求使用HTTP/3；

• http/1.1：当前请求使用HTTP/1.1；

• data、blob或其他值：资源并非通过常规网络请求获取。

Chrome官方的Network功能说明明确说明，Protocol列可以显示请求使用的协议，例如HTTP/2对应h2，HTTP/3对应h3。

为什么只检查首页主文档还不够

一个页面的不同资源可能来自不同域名。例如：

• HTML来自www.example.com；

• 图片来自img.example.com；

• JavaScript来自static.example.com；

• 接口来自api.example.com；

• 字体来自第三方服务。

这些域名可能使用不同CDN，也可能只给其中部分域名开启了HTTP/3。

因此，要分别检查主文档、图片、脚本和API请求，不能因为其中一个资源显示h3，就认为整个网站都已经使用HTTP/3。

首次检查没有出现h3怎么办

可以按以下方式再次验证：

1. 保持开发者工具打开；

2. 正常刷新两到三次；

3. 不要一开始就勾选“Disable cache”；

4. 换一个无痕窗口测试；

5. 确认浏览器没有关闭QUIC；

6. 确认本地网络允许UDP 443；

7. 检查响应头是否存在alt-svc；

8. 换一个运营商或移动网络测试。

“Disable cache”主要影响HTTP缓存，不一定清除浏览器保存的所有协议发现信息。如果需要验证真正的首次访问，最好使用新的浏览器配置、无痕环境或独立测试终端。

方法二：使用curl检查协商协议

先执行：

curl -V

检查输出中的Features或协议能力是否包含HTTP/3支持。不是所有系统自带的curl都编译了HTTP/3功能，即使curl版本看起来较新，也不能直接认为支持。

curl官方的HTTP/3说明列出了HTTP/3构建方式和相关QUIC依赖。

检查普通请求最终使用的协议

curl -sS -o /dev/null \
  -w 'HTTP version: %{http_version}\n' \
  https://www.example.com/

可能得到：

HTTP version: 2

或者：

HTTP version: 3

普通请求没有使用HTTP/3，不一定表示服务器不支持。curl可能尚未获得Alt-Svc信息，或者当前构建没有启用HTTP/3。

强制使用HTTP/3测试

curl --http3-only -sS -o /dev/null \
  -w 'HTTP version: %{http_version}\n' \
  https://www.example.com/

如果成功并返回：

HTTP version: 3

说明当前终端能够通过HTTP/3访问该域名。

如果提示当前curl不支持--http3-only，需要换用带HTTP/3能力的curl版本；如果命令超时或连接失败，则需要继续检查CDN配置、UDP 443端口、DNS调度和本地网络限制。

同时输出请求耗时

curl --http3-only -sS -o /dev/null \
  -w 'version=%{http_version} starttransfer=%{time_starttransfer} total=%{time_total}\n' \
  https://www.example.com/test.jpg

测试HTTP/2时可以使用：

curl --http2 -sS -o /dev/null \
  -w 'version=%{http_version} starttransfer=%{time_starttransfer} total=%{time_total}\n' \
  https://www.example.com/test.jpg

注意检查输出中的version。--http2允许在无法使用HTTP/2时回退到较早协议，所以不能只看命令是否成功。

另外，不要用一次curl结果比较速度。单次结果很容易受到DNS缓存、连接建立、CDN节点负载和公网抖动影响。

方法三：检查Alt-Svc响应头

可以使用：

curl -I https://www.example.com/

然后查找类似响应头：

alt-svc: h3=":443"; ma=86400

它表示服务器声明可以在443端口使用HTTP/3，并允许客户端在指定时间内记住这个信息。

但是它只能作为HTTP/3可用性的线索，不能作为实际传输协议的最终证据。

以下情况都可能出现“有Alt-Svc但没有用上HTTP/3”：

• 浏览器不支持或关闭了QUIC；

• UDP 443被防火墙拦截；

• 客户端尝试QUIC失败并回退HTTP/2；

• 某些CDN节点尚未正确支持HTTP/3；

• 本地代理、VPN或安全软件不支持QUIC；

• 浏览器认为当前网络条件不适合使用HTTP/3。

所以正确的判断顺序是：

1. 控制台已经开启HTTP/3；

2. 响应头或HTTPS DNS记录声明支持HTTP/3；

3. 浏览器或curl实际协商出h3；

4. CDN日志显示真实用户确实产生HTTP/3流量。

前三项都满足，才能比较有把握地确认功能真正生效。

方法四：通过CDN日志验证真实用户是否使用HTTP/3

如果CDN提供访问日志或日志投递功能，检查是否存在以下字段：

• HTTP协议版本；

• QUIC或HTTP/3标识；

• 客户端到边缘节点的协议；

• 边缘节点或PoP；

• 请求状态码；

• 缓存命中状态；

• 请求耗时；

• 客户端网络或地区。

日志比单台电脑的检查更有代表性，因为它能够回答：

• 实际有多少用户使用HTTP/3；

• 哪些地区的HTTP/3占比较高；

• HTTP/3是否集中在移动端；

• HTTP/3和HTTP/2的P50、P95有何差异；

• QUIC失败或回退是否集中在特定运营商。

这里需要区分两个方向：

用户浏览器 → CDN边缘节点 → 源站

网站对外开启HTTP/3，通常指“用户浏览器到CDN边缘节点”支持HTTP/3。CDN边缘节点回源时，仍可能使用HTTP/1.1或HTTP/2。

因此，在源站Nginx日志里看到HTTP/1.1，并不能证明用户没有使用HTTP/3。源站看到的是CDN回源协议，不是浏览器访问CDN的协议。

要确认用户侧HTTP/3，应该查看CDN的边缘访问日志，而不是只看源站日志中的$server_protocol。

如何公平测试HTTP/2和HTTP/3速度

真正有意义的协议对比，至少需要控制以下变量：

• 使用相同域名；

• 命中相同CDN节点；

• 请求相同文件；

• 保持文件大小一致；

• 保持压缩方式一致；

• 分开测试HIT和MISS；

• 分开测试首次连接和连接复用；

• 使用相同地区和运营商；

• 在相近时间段交替测试；

• 分别记录P50、P95和失败率。

测试对象建议至少包括：

1. 一个较小的HTML或API响应；

2. 一个100KB左右的静态文件；

3. 一个1MB～5MB的图片或测试文件；

4. 一个包含较多并发资源的完整页面。

小文件更容易体现连接和TTFB差异，大文件更容易体现吞吐量，资源较多的页面则更容易体现多路复用和丢包恢复的影响。

具体测试设计可以参考CDN测速方法论：主动探测、P50/P95与可复现性能排名。

不要只在办公室网络测试

HTTP/3的优势往往出现在不稳定网络中。如果只在低延迟、千兆办公网络测试，很可能得到“HTTP/2和HTTP/3完全一样”的结论。

建议至少覆盖：

• 本地固定宽带；

• 4G或5G移动网络；

• 一个高延迟跨国网络；

• 核心用户所在地区；

• 晚高峰时段；

• 人为加入轻度延迟和丢包的测试环境。

如果网站真实用户主要来自中国大陆，还应按电信、联通、移动及区域分别观察，而不是只看一个云服务器测试点。

HTTP/3测试最容易出现的五个误判

误判一：控制台打开了，所以网站已经使用HTTP/3

控制台开关只代表配置意图。配置可能尚未下发到全部节点，客户端也可能因为UDP不可达而回退。

最终仍要看浏览器Protocol列、强制HTTP/3测试或CDN日志。

误判二：看到Alt-Svc就证明当前请求是HTTP/3

Alt-Svc只是服务器对后续请求的协议提示。当前返回这个响应头的请求本身完全可能使用HTTP/2。

误判三：HTTP/3的TTFB低一次，就说明它更快

一次请求没有统计意义。DNS缓存、连接复用、缓存命中和节点负载都可能让单次结果偏离正常水平。

如果网站存在“有时快、有时慢”的问题，应按照网站有时快有时慢，CDN测速应该怎么测？中的方法观察多轮结果和长尾。

误判四：源站日志显示HTTP/1.1，所以CDN没启用HTTP/3

源站日志通常记录CDN节点到源站的回源协议，不能直接代表用户到CDN的协议。

误判五：HTTP/3占比不高，就是配置失败

并非所有浏览器、网络、代理和企业防火墙都能稳定使用QUIC。部分用户回退HTTP/2属于正常兼容行为。

应观察HTTP/3可用用户的实际占比、失败率和地区分布，而不是要求所有请求都必须显示h3。

为了HTTP/3更换CDN值不值得

不建议只因为一家CDN支持HTTP/3，就直接判断它比另一家CDN更快。

相比协议名称，下面这些因素通常更重要：

• 节点是否靠近目标用户；

• 运营商线路是否稳定；

• DNS调度是否准确；

• 缓存命中率是否足够高；

• 边缘节点负载是否稳定；

• 回源链路是否合理；

• TLS握手和TTFB是否正常；

• 高峰期P95是否失控；

• HTTP/3是否在核心地区真正可用。

一家节点覆盖和调度都不理想的CDN，不会因为打开HTTP/3就自动变快。相反，一家使用HTTP/2但节点更近、缓存命中率更高、运营商互联更好的CDN，完全可能提供更好的真实体验。

选型时可以先用主动探测对比HTTP/2与HTTP/3在不同地区的基础表现，再通过RUM验证真实用户收益。两类数据各自的作用，可以参考主动探测和真实用户监控RUM有什么区别？选CDN该信哪一个。

最后应该看什么结果

确认HTTP/3是否启用，最直接的证据是：

Chrome开发者工具的Protocol列显示h3，或者支持HTTP/3的curl通过--http3-only成功连接并返回版本3。

确认HTTP/3有没有带来实际价值，则需要继续比较：

• HTTP/2和HTTP/3的成功率；

• 首次连接耗时；

• TTFB；

• 完整页面加载时间；

• P50、P95和P99；

• 移动网络与固定宽带差异；

• 不同地区及运营商表现；

• LCP等真实用户体验指标。

HTTP/3不是一个打开后必然提速的按钮。它更像是在高延迟、丢包和网络切换条件下，为CDN增加了一条更有韧性的传输路径。

如果稳定网络下只提升2%，但移动用户的P95下降了15%，这项优化依然可能非常有价值；如果协议显示为h3，真实用户的TTFB和页面体验却没有改善，那么继续优化节点、缓存、回源和页面资源，往往比追求协议名称更重要。

常见问题

1. HTTP/3一定比HTTP/2快吗？

不一定。在低延迟、低丢包并且连接能够复用的环境中，两者差异可能非常小。HTTP/3的优势通常在高延迟、丢包和移动网络中更明显。

2. 响应头有Alt-Svc，为什么Chrome仍然显示h2？

当前请求可能先通过HTTP/2获得Alt-Svc信息，后续请求才尝试HTTP/3；也可能是UDP 443受限、浏览器关闭QUIC或HTTP/3连接失败后发生了回退。

3. Chrome里找不到Protocol列怎么办？

进入开发者工具的Network面板，在请求列表表头处点击右键，然后勾选Protocol。部分界面宽度较小时，该列可能默认隐藏。

4. curl提示不支持--http3-only怎么办？

说明当前curl构建没有包含HTTP/3相关功能。需要安装带QUIC和HTTP/3支持的curl，不能只依靠curl版本号判断。

5. 为什么首页是h3，部分图片却是h2？

这些资源可能来自不同域名、不同CDN或不同配置。每个资源域名都需要单独支持并成功协商HTTP/3。

6. HTTP/3使用UDP，会不会比TCP不安全？

不会因为使用UDP就降低传输安全性。QUIC整合TLS 1.3，HTTP/3业务内容仍然经过加密和身份验证。UDP只是承载方式不同。

7. 开启HTTP/3需要修改源站吗？

使用CDN时，很多情况下只需在CDN侧启用客户端到边缘节点的HTTP/3，源站不必直接支持。但具体还要看CDN产品、域名证书和节点配置。

8. HTTP/3适合哪些网站优先测试？

移动端用户较多、跨国访问明显、页面并发资源多、用户网络波动较大的网站更值得优先测试。下载站、图片站、跨境电商和全球化SaaS也可以重点观察长尾改善。