直接回答：HTTP/2 的多路复用解决了应用层队头阻塞，但 TCP 层的队头阻塞无解——一个包丢失，所有流等重传。QUIC 把可靠传输、拥塞控制、TLS 1.3 全部在用户态基于 UDP 重新实现：流独立交付（丢包只阻塞所属流）、握手内嵌加密（首次 1-RTT、会话复用 0-RTT）、连接用 Connection ID 标识而非四元组（Wi-Fi 切 5G 连接不断）。基于 UDP 的根本原因是可部署性：TCP 实现在操作系统内核和中间设备里，改不动；用户态 UDP 之上想怎么创新怎么创新。
展开解析：细节价值点：0-RTT 复用对移动端弱网收益巨大，但有重放风险，只用于幂等请求；连接迁移让移动端体验质变，也给负载均衡出难题（要按 CID 一致性路由）。现实代价：用户态协议栈 CPU 开销高于内核 TCP（各家都在优化，sendmmsg/GRO 等手段）；UDP 443 在部分企业网被拦，必须有 TCP 回退（Alt-Svc 机制宣告）；排查工具链不如 TCP 成熟。采用现状：Google/Meta/Cloudflare 量很大，视频与移动端收益最明显；自建服务开 HTTP/3 主要在 CDN 层配置即可，源站维持 HTTP/2 也成立。认知总结：QUIC 是"传输层创新冻结"的破局方案，其设计理念（可插拔拥塞控制、加密默认化）会持续影响协议演进。
追问方向：0-RTT 的重放风险怎么缓解？中间设备对 UDP 的限速策略？MASQUE 用 QUIC 隧道化是什么方向？
（约 470 字）