互联网传输协议这几年变化很大。HTTP/2 刚普及没多久，HTTP/3 就来了。这次升级不像以前修修补补，而是直接把底层的 TCP 协议换成了基于 UDP 的 QUIC。这么大的动静，主要是为了解决 HTTP/2 在弱网环境下表现不佳的问题。
一、HTTP/2 有什么问题？
HTTP/2 虽然有多路复用（一个连接传多个文件），看似解决了并发问题，但底层的 TCP 协议没变。TCP 是按顺序传输的，只要有一个数据包丢了，操作系统就会暂停后续所有数据的交付，等待这个包重传回来。这就是所谓的“队头阻塞”（Head-of-Line Blocking）。
在网络状况好的时候（比如办公室 WiFi），HTTP/2 很快；但一旦到了信号不好的地方（比如地铁、电梯里），丢包率一上来，HTTP/2 甚至还不如 HTTP/1.1 稳定。HTTP/3 就是为了解决这个问题来的，它即使在丢包严重的网络下，也能保持流畅。
二、QUIC 协议强在哪？
1. 0-RTT 建连（握手非常快）
以前用 TCP+TLS，建立连接得一来一回好几次（2-3 个 RTT）。QUIC 也就是 HTTP/3 的底层协议，如果是第二次连接，直接 0-RTT，也就是发出的第一个包里就带着加密数据，没有握手等待时间。
2. 没有队头阻塞
QUIC 也是多路复用，但它基于 UDP，每个流（Stream）之间是真正独立的。A 文件丢包了，只影响 A，B/C/D 照样传输，互不干扰。
3. 切换网络不断线
用 TCP 的时候，你从 WiFi 切到 4G，IP 变了，连接就断了，必须重新建立。QUIC 用一个叫 Connection ID 的东西标识连接，不管你 IP 怎么变，只要 ID 还是那个，连接就一直保持。打游戏、看直播的时候切换网络，几乎感觉不到卡顿。
4. 拥塞控制更灵活
TCP 的拥塞控制写在系统内核里，想升级很难。QUIC 是在应用层实现的，升级算法（比如 BBR）就像升级 APP 一样简单，可以针对即时通讯、视频点播等不同场景用不同的策略。
三、HTTP/2 vs HTTP/3 实测对比
| 场景 | HTTP/2 (TCP) | HTTP/3 (QUIC) |
|---|---|---|
| 弱网环境（高丢包） | 卡顿明显，速度慢 | 依然流畅，提升 20% - 50% |
| 握手延迟 | 200-300ms | 0-100ms |
| 网络切换 | 连接中断，需重连 | 连接平滑迁移，无感知 |
四、怎么部署 HTTP/3？
1. 服务器端
- Nginx：1.25+ 版本已经正式支持了，但配置起来稍显复杂，需要配合 OpenSSL QUIC 分支。
- Caddy：默认就开启了 HTTP/3，比较省心。
- CDN：由于配置复杂，最简单的办法是直接用支持 HTTP/3 的 CDN（比如飞盾云），源站不用动，边缘节点帮你搞定协议转换。
2. 浏览器兼容性
现在的 Chrome、Firefox、Edge、Safari 都默认支持了。浏览器会通过响应头里的 `Alt-Svc` 字段发现服务器支持 HTTP/3，下次请求就会自动切过去。
3. 怎么看生效没？
打开 Chrome 开发者工具 -> Network，右键表头勾选 Protocol，如果看到 `h3`，那就是成功了。
飞盾云 HTTP/3 加速方案
飞盾云 CDN 已经全线支持 HTTP/3：
- 无感接入：源站哪怕只支持 HTTP/1.1 也没关系，我们在边缘节点处理 HTTP/3 连接。
- 智能回退：如果用户网络环境（比如某些公司内网）封了 UDP，会自动退回到 HTTP/2，保证能访问。
- 针对性优化：针对视频和动态 API 场景做了专门的拥塞控制调优。
总结
HTTP/3 对移动端用户多的应用提升尤其明显。如果你的用户经常在弱网环境（比如移动数据网络）下使用，或者对延迟很敏感，值得尽早接入。