基于 UDP 的新一代传输协议，内置 TLS、多路复用无队头阻塞、0-RTT 与连接迁移，是 DoQ 与 HTTP/3 的底层基石。
QUIC 由 IETF RFC 9000（2022）定义，是一种基于 UDP 的多路复用、安全传输协议；RFC 9114（2022）定义的 HTTP/3 则是跑在 QUIC 之上的 HTTP 语义。它把原本 TCP+TLS 才有的可靠传输、加密、拥塞控制搬到用户态基于 UDP 重新实现，一举解决了 TCP 队头阻塞、握手慢、不能随应用快速迭代三大老问题：多路复用下一个流丢包不影响其他流、首次握手 1-RTT 且恢复时 0-RTT、内置 TLS 1.3、还支持连接迁移（Wi-Fi 切 4G 不断线）。Chrome/Edge/Firefox/Safari 与主流 CDN 已默认支持。
它到底解决了 TCP 时代的什么痛点
HTTP/2 虽在应用层多路复用，但跑在 TCP 上，一个包丢失会卡住整条 TCP 连接上所有流。QUIC 在 UDP 之上用独立 stream，某个流丢包只拖慢它自己，其他流照常收发。
首次连接 1-RTT 完成握手；已会话过的客户端可凭票据 0-RTT 直接发数据。传统 HTTPS 需要 TCP 握手 + TLS 握手两轮往返，QUIC 把它们合并，省掉延迟。
QUIC 把 TLS 1.3 集成进传输层本身，所有报文默认加密与认证，不需要像 TCP 那样「先建连接再叠加 TLS」。
TCP 连接由四元组标识，手机切网就断。QUIC 用连接 ID 标识连接，只要两端互相认识，源地址从 Wi-Fi 切到 4G，连接继续，体验更平滑。
传统 Web 协议栈与 QUIC 栈逐项对照
| 维度 | TCP + TLS 1.3 + HTTP/2 | QUIC + HTTP/3 |
|---|---|---|
| 底层传输 | TCP（操作系统内核实现） | UDP（用户态实现） |
| 多路复用 | 应用层复用，但受 TCP 队头阻塞拖累 | stream 级隔离，无传输层队头阻塞 |
| 握手延迟 | TCP 握手 + TLS 握手，多轮往返 | 1-RTT 首次，0-RTT 恢复 |
| 加密 | TLS 叠加在 TCP 之上 | TLS 1.3 内建，默认加密 |
| 连接标识 | 四元组（地址变即断） | 连接 ID（地址变可迁移） |
| 协议演进 | TCP 改动需动内核，慢 | 在用户态，随客户端 App 快速迭代 |
| 对应标准 | RFC 9114 之前的传统栈 | RFC 9000（QUIC）+ RFC 9114（HTTP/3） |
QUIC/HTTP/3 早已不是实验特性
QUIC 最初由 Google 在实验协议中推动，后交给 IETF 标准化为 RFC 9000，HTTP/3 对应 RFC 9114。经过数年落地，它已经从「实验特性」变成「默认开启」：
Chrome、Edge、Firefox、Safari 均已在近期版本默认支持 HTTP/3。浏览器访问支持的网站时，服务器通过 Alt-Svc 响应头告知「我也支持 HTTP/3」，浏览器会在后续连接中自动尝试升级到 QUIC，用户几乎无感。
Cloudflare、Google 等主流 CDN 和大型网站已默认对开启者提供 HTTP/3 支持。这也是为什么 DoQ（DNS over QUIC）能落地——底层 QUIC 通道在浏览器和网络基础设施里已经铺好。
本系列讲的 DoQ（RFC 9250）正是把 DNS 报文放进 QUIC stream，相当于在 QUIC 这条新传输上跑一种特殊的「应用」。理解了 QUIC 的多路复用、0-RTT、连接迁移，也就理解了 DoQ 为什么比 DoT 更快。