为什么又要一个新的 HTTP？
HTTP/2 用多路复用解决了"一个连接同时只能跑一个请求"的问题，但它仍然跑在 TCP 上—— 而 TCP 有一个绕不开的顽疾：队头阻塞（Head-of-Line Blocking）。 TCP 保证字节流严格有序，只要有一个包丢了，后面所有已经到达的数据都必须等它重传， 哪怕它们属于完全不相干的请求。
在丢包率接近 0 的机房内网，这无所谓；但在跨境链路、移动弱网这类丢包率 1%～5% 的环境里，一次丢包就能卡住整条连接上的所有资源，页面表现为"莫名其妙地卡一下"。
QUIC：把传输层搬到 UDP 上重写
HTTP/3 底层的 QUIC 协议基于 UDP 重新实现了可靠传输，核心改进有三个：
1. 流级别的独立传输
QUIC 里每个请求是独立的流（Stream），丢包只影响所属的那条流，其他流照常推进—— 队头阻塞从"连接级"缩小到"流级"，弱网下的整体表现显著更稳。
2. 更快的握手：1-RTT 与 0-RTT
传统 HTTPS 建连需要 TCP 三次握手 + TLS 握手，跨境场景下往返延迟高，建连动辄几百毫秒。 QUIC 把传输握手与 TLS 1.3 加密握手合并，首次连接 1-RTT 完成；重连时更可以用0-RTT 直接携带请求数据——对跨境访问来说，省下的每一个 RTT 都是真金白银。
3. 连接迁移
TCP 连接由四元组（源 IP、源端口、目的 IP、目的端口）标识，手机从 Wi-Fi 切到蜂窝网络， IP 一变连接就断。QUIC 用连接 ID 标识连接，换网络不断连， 移动端场景（地铁、电梯、跨楼层）体验提升明显。
收益有多大？
| 场景 | HTTP/2 (TCP) | HTTP/3 (QUIC) |
|---|---|---|
| 机房内网、低丢包 | 表现良好 | 基本持平 |
| 跨境链路、1%+ 丢包 | 频繁整连接卡顿 | 仅单流受影响，整体流畅 |
| 移动弱网 / 切换网络 | 断连重建，重新握手 | 连接迁移，无感继续 |
| 重复访问建连 | TCP + TLS 多次往返 | 0-RTT 直接发请求 |
一句话：链路质量越差，HTTP/3 的优势越大。这正是它对跨境业务特别有价值的原因—— 大陆到海外源站的公网链路，恰恰是高延迟 + 有丢包的典型环境。
在 CDN 上开启：一键的事
自建 HTTP/3 需要升级服务端（nginx 1.25+ / Caddy 等）、放行 UDP 443、调优拥塞控制， 还要处理客户端兼容探测。而在 CDN 上，这些都发生在边缘节点与用户之间：
- QEdgeCDN 套餐支持 HTTP/3 的档位，站点开启后边缘节点自动对外提供 H3 服务；
- 浏览器通过
Alt-Svc响应头发现 H3 支持，自动升级，不支持的客户端无感回落到 H2； - 源站完全不用改——边缘到源站的回源链路仍走原有协议，用户侧却已享受 QUIC 的全部收益。
验证方式：浏览器开发者工具 Network 面板打开 Protocol 列，看到 h3 即已生效。
协议升级解决"传输快不快"，缓存命中解决"要不要传"——两者叠加才是完整的加速方案， 推荐继续阅读《CDN 缓存如何提升网站访问性能》。