QUIC（Quick UDP Internet Connections，快速 UDP 互联网连接）是由 Google 于 2012 年提出、并于 2021 年由 IETF 正式标准化（RFC 9000）的传输层协议。
它是 HTTP/3 的底层传输协议。QUIC 的出现，本质上是为了解决 TCP 协议几十年来的历史包袱 以及 TLS 握手的时延问题，在 UDP 之上重新打造了一个高安全性、低延迟、强抗丢包的下一代传输层协议。
一、 为什么有了 TCP，还需要 QUIC？（TCP 的四大痛点）
TCP 协议诞生于 1981 年，其设计初期的网络环境与如今的移动互联网时代有着天壤之别。TCP 在现代 Web 性能瓶颈中暴露了以下四大痛点：
1. 建立连接延迟高（RTT 冗长）
- TCP + TLS 1.3：需要先进行 TCP 三次握手（1 RTT），再进行 TLS 握手（1 RTT），总共需要 2 个 RTT 才能开始传输真正的应用数据（HTTP Data）。
- 在移动网络（如 4G/5G 弱网、跨国网络）下，1 个 RTT 可能会消耗 100~300ms，建立连接极其耗时。
2. HTTP/2 的 TCP 队头阻塞（Head-of-Line Blocking）
HTTP/2 虽然在一个 TCP 连接上实现了“多路复用”（同时传输多个 HTTP 请求/流），但 TCP 协议本身是不知道“流（Stream）”的概念的。
- TCP 保证的是整条管道数据的绝对按序到达。
- 如果同时传输 Stream A 和 Stream B，一旦 Stream A 的某个 TCP 报文段丢包，TCP 的滑动窗口就会停滞，必须等待 Stream A 重传成功后，后续已到达的 Stream B 数据才能交付给上层应用。
3. 网络切换导致连接中断（四元组绑定）
TCP 连接是由 四元组（源 IP、源端口、目的 IP、目的端口）唯一确定的。
- 当用户从 Wi-Fi 切换到蜂窝网络（5G），或者手机 IP 变化时，四元组被破坏，旧的 TCP 连接强制断开，必须重新建立 TCP + TLS 连接。
4. 内核协议栈升级困难（协议僵化 / Middlebox 篡改）
TCP 运行在操作系统内核中。如果要更新或优化 TCP 拥塞控制算法，需要操作系统层面更新。此外，互联网中间设备（如防火墙、路由器、NAT 网关）会检查甚至篡改 TCP 报头（如删改某些 TCP Option），导致 TCP 难以引入新的特性。
二、 QUIC 的分层架构与设计思想
QUIC 巧妙地选择基于 UDP 协议：
- 为什么选 UDP？ 因为 UDP 头部极轻量（仅 8 字节），且几乎所有操作系统和网络设备都支持 UDP 穿透。
- QUIC 在用户态做到了什么？ QUIC 将 TCP 的“可靠传输、流量控制、拥塞控制”以及 TLS 1.3 的“安全加密”全部移到了应用层（用户态）进行实现。
┌────────────────────────────────────────────────────────┐
│ HTTP/3 应用层 │
├────────────────────────────────────────────────────────┤
│ QUIC 协议层 │
│ ┌───────────────────────┬──────────────────────────┐ │
│ │ 内置 TLS 1.3 安全加密 │ 多路复用 (独立 Stream) │ │
│ ├───────────────────────┼──────────────────────────┤ │
│ │ ACK / 重传 (无RTT歧义)│ 用户态拥塞控制 (BBR等) │ │
│ └───────────────────────┴──────────────────────────┘ │
├────────────────────────────────────────────────────────┤
│ UDP 协议 │
├────────────────────────────────────────────────────────┤
│ IP 协议 │
└────────────────────────────────────────────────────────┘
三、 QUIC 的 6 大核心关键技术解析
1. 极致的建连速度：1-RTT 甚至 0-RTT 握手
QUIC 将传输层握手与加密层握手合并：
- 首次连接（1-RTT）：客户端发送 QUIC
Initial包，将传输参数协商与 TLS 1.3 Client Hello 一起发送。服务端返回 Server Hello 和证书，只需要 1 个 RTT 即可完成握手并开始传输数据。 - 连接复用（0-RTT）：如果之前连接过该服务器，客户端可以利用上次协商的 Session Ticket，在发送第一个握手包的同时直接附带加密的应用数据，实现 0-RTT 极速加载。
2. 彻底解决队头阻塞（真正的多路复用）
QUIC 重新定义了数据传输单位，引入了 Stream（流） 和 Frame（帧）：
- 一个 QUIC 连接内可以并行运行成百上千个独立的 Stream。
- 每个 Stream 都有独立的接收缓冲区和偏移量（Offset）。
- 核心优势：如果 Stream 1 的某个 UDP 包丢失，只有 Stream 1 的接收会被挂起等待重传；Stream 2、Stream 3 等其他流不受任何影响，应用层可以继续正常解析和渲染其他流的数据。
3. 连接迁移（Connection Migration）：网络无感切换
QUIC 弃用了四元组标识连接，改用一个 64 位的连接 ID（Connection ID, CID）：
- 这个 CID 由客户端和服务端协商生成，包含在 QUIC 报文头中。
- 场景应用：当用户走出家门，手机从 Wi-Fi 自动切换到 5G 移动网络时，虽然 IP 地址和端口变了，但 QUIC 报文里的 Connection ID 保持不变。
- 效果：服务端收到包后通过 CID 识别出这依然是之前的连接，直接平滑继续传输，用户完全感知不到网络重连或掉线。
4. 改进的重传与 ACK 机制（解决 RTT 歧义）
在 TCP 中，重传包使用相同的 Sequence Number，导致接收端收到 ACK 时无法判断是对“原始包”还是“重传包”的响应（RTT 歧义）。
QUIC 对此作出了重要革新：
- 单调递增的 Packet Number (PN)：即使是重传包，其 PN 也必须递增（例如原包 PN=10 丢失，重传包分配 PN=11）。
- PN 与 Data Offset 解耦：数据的实际顺序通过 Stream ID 内的
Offset（偏移量）决定，而PN只用于传输层确认包是否到达。 - 精准的 RTT 计算：由于 PN 绝不重复，发送端可以精准计算每一个包的 RTT。此外，QUIC 的 ACK 帧中还包含了接收端处理该包的 ACK Delay（延迟时间），消除了接收端延迟导致的 RTT 误差。
5. 用户态灵活可插拔的拥塞控制
- TCP 的拥塞控制算法（如 Cubic、BBR）绑死在内核。
- QUIC 运行在用户态，应用程序或 Web 服务器（如 Nginx、Caddy）可以根据业务场景随时切换或定制拥塞控制算法。
- 例如，QUIC 默认广泛采用针对高丢包、高时延网络优化的 BBR 算法，并且能够提供比 TCP 更丰富的拥塞控制采样信息（如单包多 ACK 范围确认）。
6. 默认全报文加密与安全增强
- TCP 头部明文：TCP 头的 flags、seq、ack 等都是明文，网络中间设备可以随意篡改或插入 RST 包。
- QUIC 默认加密：除了极少数用于建立连接的公共报头外，QUIC 报文的所有 Payload（包括 ACK 帧、Stream ID 等元数据）全部经过 TLS 1.3 加密。中间设备只能看到这是一个 UDP 包，根本无法伪造或篡改 QUIC 的控制信息，安全性极高。
四、 总结：QUIC 与 TCP + TLS 的全方位对比
| 特性 / 维度 | TCP + TLS 1.3 | QUIC (HTTP/3) |
|---|---|---|
| 网络层依赖 | IP → TCP | IP → UDP → QUIC |
| 首次建连时延 | 2 RTT (1 RTT TCP + 1 RTT TLS) | 1 RTT |
| 连接复用时延 | 1 RTT | 0 RTT |
| 多路复用支持 | 支持 (HTTP/2)，但存在 TCP 队头阻塞 | 支持，且无队头阻塞 |
| 连接标识 | 四元组 (IP+Port) | Connection ID (CID) |
| 网络切换 (Wi-Fi↔5G) | 连接中断，必须重连 | 支持连接迁移，无感切换 |
| 协议运行位置 | 操作系统内核 (Kernel) | 用户态 (User Space) |
| 报文控制头安全 | 头部明文，易被中间设备篡改 | 全面加密 (除少量 Unencrypted Header) |
| 拥塞控制 | 依赖内核，升级困难 | 用户态可插拔，升级极其容易 |
五、 QUIC 的痛点与面临的挑战
虽然 QUIC 优势巨大，但在落地过程中也存在一些工程上的挑战：
- UDP 封禁与 QoS 限速：由于历史原因，部分企业网关、运营商网络对 UDP 流量不太友好，可能会封禁高端口 UDP，或对 UDP 流量施加 QoS 限速。针对此情况，客户端通常需要实现 Happy Eyeballs 算法（同时尝试 QUIC 和 TCP/TLS，哪个快用哪个，QUIC 失败则降级到 TCP）。
- CPU 开销较高：QUIC 运行在用户态，传统的网卡硬件加速（如 TCP Offload Engine, TOE）无法直接作用于 QUIC，导致服务端在处理极高并发的 QUIC 加解密和 UDP 包收发时，CPU 消耗高于传统 TCP。不过随着
eBPF和XDP以及网卡 UDP 硬件 Offload 技术的发展，这一劣势正在被迅速抹平。