QUIC 传输协议原理深度解析：从 RFC 9000 到 HTTP/3 的传输层革命

协议详解 · 2026-07-08

概述

QUIC（Quick UDP Internet Connections）是由 IETF 标准化的传输层协议，定义于 RFC 9000（2021 年 5 月）。它最初由 Google 设计，后提交 IETF 进行标准化，现已成为 HTTP/3（RFC 9114）的传输层基础。

与 TCP 不同，QUIC 基于 UDP 构建，并在用户空间实现可靠性保证、拥塞控制和加密。QUIC 的核心设计目标包括：

降低连接建立延迟：将传输层握手与 TLS 握手合并为单一步骤，支持 1-RTT 和 0-RTT 连接
消除队头阻塞：通过独立的多流复用，使单条流的丢包不影响其他流
支持连接迁移：使用连接 ID（Connection ID）而非四元组标识连接，使网络切换时连接不中断
内置安全性：强制集成 TLS 1.3，所有数据包均经过认证加密

协议架构

整体结构

CODE

┌────────────────────────────────────────────────┐
│                 应用层协议                        │
│           (HTTP/3, DNS, SMB, ...)                │
├────────────────────────────────────────────────┤
│              QUIC 传输层                         │
│  ┌──────────┐ ┌──────────┐ ┌────────────────┐  │
│  │ 流管理    │ │ 包保护    │ │ 连接管理        │  │
│  │ (Streams) │ │ (Packet  │ │ (Connection    │  │
│  │          │ │ Protection)│ │ ID, Migration) │  │
│  └──────────┘ └──────────┘ └────────────────┘  │
│  ┌──────────┐ ┌──────────┐ ┌────────────────┐  │
│  │ 可靠传输  │ │ 流量控制  │ │ 丢包检测与恢复   │  │
│  │          │ │          │ │ (RFC 9002)     │  │
│  └──────────┘ └──────────┘ └────────────────┘  │
├────────────────────────────────────────────────┤
│          TLS 1.3 握手 (RFC 9001)                 │
├────────────────────────────────────────────────┤
│              UDP 数据报                           │
└────────────────────────────────────────────────┘

QUIC 将加密握手（TLS 1.3）与传输参数协商合并，这是其区别于 TCP+TLS 堆栈的关键设计。根据 RFC 9001，QUIC 使用自定义帧保护 TLS 握手消息，并直接将其作为 QUIC 数据包的有效载荷传输。

文档体系

QUIC 的规范分散在多个 RFC 中：

RFC	题目	内容
8999	QUIC 版本无关属性	跨版本通用属性的不变量定义
9000	QUIC 传输协议	核心规范：流、包、连接管理
9001	Using TLS to Secure QUIC	TLS 1.3 与 QUIC 的集成方式
9002	QUIC 丢包检测与拥塞控制	恢复算法和拥塞控制器
9114	HTTP/3	基于 QUIC 的 HTTP 语义映射

流与多路复用

流类型与标识符

QUIC 连接上的数据通过流（Stream）传输。每条流是一个有序的字节序列，分为四种类型：

流 ID 位	类型	发起方	方向
0x00	客户端创建的双向流	客户端	双向
0x01	服务端创建的双向流	服务端	双向
0x02	客户端创建的单向流	客户端	客户端→服务端
0x03	服务端创建的单向流	服务端	服务端→客户端

流 ID 是一个 62 位整数，最小有效位标识发起方（0=客户端，1=服务端），次小有效位标识方向（0=双向，1=单向）。每个流 ID 在连接中唯一，不可重复使用。

多路复用与队头阻塞消除

HTTP/2 在单一 TCP 连接上实现了多路复用，但存在队头阻塞（Head-of-Line Blocking）问题：一条流的丢包会阻塞该连接上所有流的数据传递。QUIC 通过以下机制解决此问题：

CODE

TCP + HTTP/2:
  Connection: TCP
  ┌─────────────────────────────────────┐
  │ Stream 1: [Pkt1][Pkt2][Pkt3]...    │
  │ Stream 3: [Pkt4][Pkt5][Pkt6]...    │  ← Pkt5 丢失会阻塞 Stream 1/5
  │ Stream 5: [Pkt7][Pkt8][Pkt9]...    │
  └─────────────────────────────────────┘
  共享丢包重传队列，单一流丢包影响全局

QUIC + HTTP/3:
  Connection: QUIC (UDP)
  ┌─────────────────────────────────────┐
  │ Stream 1: [Frame1][Frame2]...      │  ← 独立传输，不受其他流丢包影响
  │ Stream 3: [Frame3][Frame4]...      │
  │ Stream 5: [Frame5][Frame6]...      │  ← Frame5 丢失只影响 Stream 5
  └─────────────────────────────────────┘
  各流独立传输，丢包仅影响该流

QUIC 使用流帧（STREAM Frame）封装应用数据，帧内的偏移字段（Offset）允许接收方将乱序到达的数据重组为有序字节流。不同流的流帧相互独立，一条流的丢包和重传不会影响其他流的数据传递。

流的状态机

QUIC 为发送方和接收方分别定义了状态机，以下是发送方的核心状态：

CODE

写首个流帧
        ┌────────────────────────────┐
        │                            ▼
   ┌────────┐  所有数据发送+FIN   ┌─────────────┐  所有数据确认  ┌──────────┐
   │ 就绪    │ ─────────────────▶ │ 发送         │ ─────────────▶ │ 发送完成   │
   │ (Ready) │                    │ (Send)       │               │ (Data    │
   └────────┘                     └─────────────┘               │  Sent)   │
        │                             │                         └──────────┘
        │                             │                               │
        │                             ▼                               │
        │    应用层重置/收到 STOP_SENDING                              │
        │        ┌────────────────────┘                               │
        ▼        ▼                                                    │
   ┌──────────┐         确认 RESET_STREAM 帧                         │
   │ 重置发送   │ ────────────────────────────────────────────────────┘
   │ (Reset   │
   │  Sent)   │
   └──────────┘
         │
         │ 重置帧确认
         ▼
   ┌──────────┐
   │ 重置接收   │
   │ (Reset   │  ← 终态
   │  Read)   │
   └──────────┘

接收方状态相对简单：

接收（Receive）：接收缓存乱序数据，组装后传递给应用层
数据量确认（Size Known）：收到 FIN 帧，确定最终数据量
读取完成（Read Complete）：所有数据已传递给应用层

双向流的状态是发送和接收状态的组合。最简单的模型中，当发送和接收部分均处于非终态时流为"打开"状态，均处于终态时为"关闭"状态。

流量控制

双层控制模型

QUIC 采用基于额度（Credit-Based）的流量控制模型，存在两层限制：

流级流量控制：限制单条流可发送的数据量，防止单一流耗尽接收缓冲区
连接级流量控制：限制所有流合计可发送的数据量，保护接收端整体缓冲区

CODE

接收方
  │
  ├── 连接级上限 (initial_max_data)
  │    └── 所有流累计已发送字节数不得超过此值
  │
  ├── 流 1 上限 (initial_max_stream_data_bidi_local)
  │    └── 流 1 已发送字节数不得超过此值
  │
  ├── 流 3 上限
  │    └── ...
  │
  └── 流 N 上限
       └── ...

流量控制帧

接收方通过以下两种帧来调整流量控制上限：

MAX_STREAM_DATA 帧（第 19.10 节）：提高指定流的字节偏移上限
MAX_DATA 帧（第 19.9 节）：提高连接级字节偏移上限

发送方若达到上限不得发送新数据，应发送 STREAM_DATA_BLOCKED 或 DATA_BLOCKED 帧通知接收方其被阻塞状态。

并发流限制

除数据量限制外，QUIC 还限制对端可同时开启的流数量：

$${允许的最大流 ID} = max\_streams \times 4 + first\_stream\_id\_of\_type$$

其中 max_streams 由初始传输参数设定，后续可通过 MAX_STREAMS 帧更新。单向流和双向流的限制相互独立。

连接建立

握手流程

QUIC 握手将传输参数协商与 TLS 1.3 密钥交换合并为单一步骤：

CODE

客户端选择
                                                    不可预测的
                                                   目标连接ID

客户端                                            服务端
  │                                                  │
  │  Initial Packet (目标连接ID, TLS ClientHello)    │
  │─────────────────────────────────────────────────▶│
  │                                                  │
  │  Initial Packet (TLS ServerHello, {Handshake     │
  │  Encrypted Extensions}, {Certificate,            │
  │  CertificateVerify, Finished})                   │
  │◀─────────────────────────────────────────────────│
  │                                                  │
  │  Handshake Packet (TLS {Certificate,             │
  │  CertificateVerify, Finished})                   │
  │  客户端握手完成，可使用 1-RTT 密钥发送应用数据     │
  │─────────────────────────────────────────────────▶│
  │                                                  │
  │  1-RTT 数据包 (应用数据)                          │
  │◀────────────────────────────────▶│

1-RTT 握手：客户端在第一个数据包中发送 TLS ClientHello，服务端回复 ServerHello 后双方即完成密钥派生，后续可发送应用数据。相比 TCP+TLS 1.3 的 2-RTT，QUIC 减少了一个 RTT
0-RTT 握手：客户端通过 PSK（pre_shared_key）机制重连先前访问过的服务端，可在首个数据包中即发送应用数据，但 0-RTT 数据不具备抗重放攻击保护

密钥层次

QUIC 的密钥派生依赖于 TLS 1.3 握手过程中派生的密钥材料，使用 HKDF 生成不同用途的密钥：

密钥类型	用途	派生时机
初始密钥（Initial）	保护 Initial 数据包	连接 ID + QUIC 版本指定盐
握手密钥（Handshake）	保护 Handshake 数据包	TLS 密钥交换
1-RTT 密钥	保护应用数据（前向安全）	TLS 导出密钥
0-RTT 密钥	保护 0-RTT 应用数据（无前向安全）	PSK

QUIC 不使用 TLS 记录层保护数据，而是使用自定义帧（自定义包保护方式）直接对数据包进行认证加密（AEAD），详见 RFC 9001 第 5 章。

连接迁移

连接 ID 机制

QUIC 的核心创新之一是使用连接 ID（Connection ID, CID）替代 TCP 四元组来标识连接。CID 是由终端独立选择的不透明值，对端无法从中推断连接信息。

CODE

TCP 连接标识：
  {源 IP, 源端口, 目标 IP, 目标端口}
  → 地址变化后连接断开

QUIC 连接标识：
  Connection ID (64-bit 或更长)
  → 地址变化后连接保持，只需更换连接 ID

每个连接可拥有多个 CID，通过 NEW_CONNECTION_ID 帧发布，通过 RETIRE_CONNECTION_ID 帧撤销。CID 的主要用途包括：

防止地址变化导致连接断开（连接迁移）
防止网络观察者关联同一连接的不同数据包（隐私保护）
支持负载均衡器将数据包路由到正确的后端服务器

连接迁移流程

当客户端切换网络（如从 Wi-Fi 切换到蜂窝网络）时，QUIC 连接会自动迁移：

CODE

客户端 (Wi-Fi)                                  服务端
  │  CID: 0xDEADBEEF, 1-RTT Pkt #100              │
  │───────────────────────────────────────────────▶│
  │                                                │
  │  ── 切换网络 ──                                 │
  │                                                │
  │  CID: 0xDEADBEEF, 新 IP, 1-RTT Pkt #101        │
  │  路径验证 (PATH_CHALLENGE/PATH_RESPONSE)        │
  │───────────────────────────────────────────────▶│
  │                                                │
  │  路径验证通过，1-RTT Pkt #102...                │
  │───────────────────────────────────────────────▶│

RFC 9000 第 9 章详细规定了连接迁移的完整流程：

终端在发送数据包前需通过 PATH_CHALLENGE 帧验证新路径对端的可达性
接收方回复 PATH_RESPONSE 帧携带挑战数据
验证完成后可使用新路径发送数据
旧路径上的地址验证可能失败，但连接不中断

当前版本的 QUIC 仅支持客户端发起连接迁移，服务端不在初始连接上发起迁移。

包格式

长包头 vs 短包头

QUIC 数据包分为两种格式，长包头用于建立连接和协商参数，短包头用于高效传输数据：

CODE

长包头 (Long Header):
 1bit  4bit    1-4B      0-20B        0-20B       变长
 ┌────┬────┬─────────┬───────────┬───────────┬──────────┐
 │ 1  │Type│  Length │ DCID Len  │ Dest CID  │ Source   │
 │    │    │         │           │ (0-20B)   │ CID      │
 │    │    │         │           │           │          │
 │    │    │         │           │           └──────────┤
 │hdr │    │         │           │           Source CID  │
 │    │    │         │           │           (0-20B)     │
 │    │    │         └───────────┘                      │
 │    │    │         DCID Len (0-20B)                   │
 └────┴────┴─────────┴──────────────────────────────────┘
  │                                                    │
  └─ Long Header Form                                  └─ 版本、帧类型等
     Bit = 1

短包头 (Short Header):
 1bit  2bit   0-20B      变长
 ┌────┬────┬───────────┬───────────┐
 │ 0  │Phase│ Dest CID  │ Packet    │
 │    │     │ (0-20B)   │ Number +  │
 │    │     │           │ Protected │
 │    │     │           │ Payload   │
 └────┴────┴───────────┴───────────┘
  │
  └─ Long Header Form
     Bit = 0

长包头有两种主要类型：

Initial 包：ClientHello 载体，用于握手初始
Handshake 包：TLS 握手后续消息载体
Retry 包：服务端地址验证机制
0-RTT 包：携带早期应用数据

短包头用于握手完成后，目标连接 ID 字段的长度对端已知，省略了长度字段和版本号。

安全性分析

数据包保护

QUIC 对除版本协商和 Retry 包外的所有数据包进行认证加密保护（AEAD）：

Initial 包：使用由 QUIC 版本指定的确定性密钥材料（版本相关盐 + 目标连接 ID 派生）
Handshake 包和 1-RTT 包：使用从 TLS 1.3 握手派生的密钥

包保护分为两部分：

头部保护：使用 AES-ECB 或 ChaCha20 混淆头部中的数据包号和部分标志位，防止网络中间设备读取
有效载荷保护：使用 AEAD 算法（AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305）认证加密Payload

安全属性

QUIC 的安全模型（RFC 9000 第 21 章）将攻击者分为三类：

攻击者类型	能力	QUIC 防御
不在路径上的	观察、复制和注入伪造数据包	数据包加密使伪造数据包无法通过认证
路径上的	观察、注入、修改、丢弃、延迟、重排序数据包	认证加密防止数据包内容被修改
受限路径上的	路径上能力的子集，需在竞速中获胜	地址验证防止连接被劫持

QUIC 还提供以下安全机制：

Address Validation：通过 Retry 包或 TLS 令牌验证客户端地址所有权，防止放大攻击
Anti-Amplification：服务端在地址验证前限制发送数据量为接收量的 3 倍
Connection ID Rotation：防止观察者追踪连接

已知攻击与对策

攻击类型	描述	QUIC 对策
放大攻击	伪造源地址使服务端向受害者发送大量数据	Retry 包 + 3 倍发送限制
请求伪造	操控对端向受害者发送数据	地址验证 + 服务端不主动迁移
慢速连接攻击	开启大量连接尽可能长时间维持	最大连接数限制 + 空闲超时
流占用攻击	开启大量流耗尽接收方状态	MAX_STREAMS 限制
版本降级	迫使双方降级到不安全的早期版本	版本协商包设计（当前版本暂无完备防御）

QUIC 与传统协议对比

维度	TCP + TLS 1.3	QUIC + TLS 1.3
握手延迟	2-3 RTT	1 RTT（0-RTT 可能）
队头阻塞	存在（传输层）	消除（仅影响丢包的流）
拥塞控制	内核实现	用户空间实现（更易更新）
连接迁移	不支持	支持（通过 Connection ID）
包过滤友好性	高（端口可见）	低（UDP + 加密头部）
握手可见性	握手明文可见	握手消息加密
多路复用	需 HTTP/2 等上层协议	原生支持
前向安全	依赖 TLS	1-RTT 密钥具有前向安全
NAT 穿透	较难	较易（UDP + Connection ID）
中间设备友好性	高	低（UDP 常被限制或降级）

实现与部署现状

服务端支持

截至 2026 年，主流服务端对 QUIC 的支持已相当成熟：

Nginx：自 1.25.0 起提供实验性 HTTP/3 支持
Apache Traffic Server：自 9.0 起支持 QUIC
Cloudflare：大规模部署 QUIC 并贡献性能优化
LiteSpeed：原生支持 HTTP/3/QUIC

客户端支持

浏览器：Chrome、Firefox、Safari、Edge 均已默认启用 HTTP/3
curl：自 7.66 起支持 HTTP/3，支持多种 QUIC 后端（ngtcp2, quiche, msquic）
编程语言库：Python（aioquic, quic-go）、Rust（quiche, quinn）、Go（quic-go）

标准化状态

QUIC 协议族（RFC 9000, 9001, 9002, 8999, 9114）均为 IETF 标准（Internet Standard）。2025 年起，IETF 持续推进 QUIC 扩展标准化，包括：

QUIC 多路径（Multipath QUIC）
QUIC 上的组播（Multicast QUIC）
不可靠数据报扩展（Datagram Extension, RFC 9221）

总结

QUIC 代表了传输层协议的一次重大演进。通过将 TLS 1.3 集成到传输层内核，QUIC 从根本上解决了 TCP 的握手延迟高、队头阻塞严重、连接不可迁移等问题。其核心设计——基于连接标识的多流复用——使其成为现代互联网应用（尤其是 HTTP/3）的理想传输协议。

QUIC 的存在意义不仅在于替代 TCP，更在于提供了一个灵活的传输层框架。随着多路径 QUIC、QUIC over Satellite 等扩展的推进，QUIC 有望成为未来互联网传输层的主导协议。

参考来源

RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport — QUIC 核心规范
RFC 9001: Using TLS to Secure QUIC — TLS 与 QUIC 集成
RFC 9002: QUIC Loss Detection and Congestion Control — 丢包检测与拥塞控制
RFC 9114: HTTP/3 — 基于 QUIC 的 HTTP 语义
RFC 8999: Version-Independent Properties of QUIC — QUIC 不变量
RFC 9221: An Unreliable Datagram Extension to QUIC — 不可靠数据报扩展
IETF QUIC Working Group — 标准化工作组主页
QUIC 工作组 draft 列表 — 扩展协议标准化进展

← 返回知识库

QUIC 传输协议原理深度解析：从 RFC 9000 到 HTTP/3 的传输层革命

概述

协议架构

整体结构

文档体系

流与多路复用

流类型与标识符

多路复用与队头阻塞消除

流的状态机

流量控制

双层控制模型

流量控制帧

并发流限制

连接建立

握手流程

密钥层次

连接迁移

连接 ID 机制

连接迁移流程

包格式

长包头 vs 短包头

安全性分析

数据包保护

安全属性

已知攻击与对策

QUIC 与传统协议对比

实现与部署现状

服务端支持

客户端支持

标准化状态

总结

相关实践

参考来源