一个历史遗留问题
HTTP/2 解决了 HTTP/1.1 的队头阻塞问题——它在单个 TCP 连接上通过多路复用同时传输多个请求/响应流。
但它没解决另一层队头阻塞：TCP 层的队头阻塞。
TCP 把数据当作有序字节流传输。如果一个数据包在传输中丢失，后续所有数据包即便已经到达，也必须等待丢失的包被重传后才能交给应用层。
在丢包率较高的移动网络或弱网环境下，这个问题尤其明显——一个包的丢失会拖慢所有流。
QUIC 的思路
QUIC 是一个基于 UDP 的新传输协议。它保留了 TCP 的可靠传输、拥塞控制等能力，但做了几个关键改动：
第一，流级别的多路复用。 QUIC 在传输层就引入了"流"的概念。不同流的数据包独立传输，一条流丢包不会阻塞其他流。这彻底消除了传输层的队头阻塞。
第二，把 TLS 集成进握手。 传统上，TCP 三次握手 + TLS 握手需要多个往返。QUIC 把传输和加密握手合并，通常 1-RTT 就能建立安全连接，再次连接时甚至可以 0-RTT。
第三，连接迁移。 TCP 连接由四元组（源 IP、源端口、目的 IP、目的端口）标识。手机从 Wi-Fi 切到 4G，IP 变了，TCP 连接就断了，必须重新建立。
QUIC 用一个连接 ID 来标识连接，而不是四元组。网络切换时，只要连接 ID 不变，连接就能保持。这对移动场景是实实在在的改善。
第四，可插拔的拥塞控制。 拥塞控制算法在应用层实现（而非内核），迭代更快。
代价与挑战
- UDP 穿透问题：部分网络环境对 UDP 有限制或限速，QUIC 可能不通或降级；
- CPU 开销：QUIC 在用户态实现，加密处理比内核态 TCP 更耗 CPU；
- 中间设备兼容：一些老旧防火墙、NAT 设备对 UDP 的处理不够成熟；
- 0-RTT 的安全考量：0-RTT 数据存在重放攻击风险，需要谨慎使用。
当前状态
HTTP/3（即 HTTP over QUIC）已被主流浏览器和大型网站广泛支持。在丢包率高、延迟大、网络频繁切换的场景中，收益最明显；而在高质量有线网络中，差异相对较小。
说明：本文为网络协议的公开知识整理。