QUIC 协议
简介
本文介绍 QUIC（Quick UDP Internet Connections）传输协议的基本概念、其在反审查领域的应用和检测现状，以及 Xray-core 中 QUIC 相关的实现。
本文回答
- QUIC 是什么、与 TCP+TLS 相比有什么优势
- QUIC 在 GFW 中的检测和阻断状态
- REALITY 中 QUIC 的支持情况
- QUIC 作为代理传输层的优势和风险
本文在项目中的位置
本文属于背景知识层。QUIC 既是传输协议也是反审查技术的关注对象。
适合读者
所有想理解新一代传输协议和反审查关系的读者。
前置知识
UDP 基础，TLS 1.3 握手流程，HTTP/2 基础。
文章理解难度
中等。需要理解传输层协议的设计权衡。
重点
- QUIC 如何在用户态实现可靠的加密传输
- 2024 年 GFW 对 QUIC SNI 的阻断机制
- REALITY fork 中的 QUIC 支持
上级文档和相关文档
主要证据
IETF RFC 9000（QUIC 标准）、USENIX Security '25 论文（GFW QUIC 审查）、REALITY quic.go 源码。
QUIC 基本概念
QUIC 是由 Google 设计、现已成为 IETF 标准（RFC 9000）的传输层协议。它基于 UDP 协议，在用户态实现了可靠传输、多路复用、加密和拥塞控制。
QUIC vs TCP+TLS 对比
| 特性 | TCP + TLS 1.3 | QUIC |
|---|---|---|
| 传输层 | 内核 TCP | 用户态 UDP |
| 握手延迟 | 1-RTT（首次），0-RTT（恢复） | 0-RTT（首次，如果知道密钥），0-RTT（恢复） |
| 加密范围 | TLS 记录层（载荷） | 几乎所有包（包括大部分头部） |
| 多路复用 | 通过 HTTP/2（应用层） | 原生 Stream 多路复用，无队头阻塞 |
| 连接迁移 | 不支持 | 支持 Connection ID 迁移（切换网络不中断） |
| 部署位置 | 内核 + 用户态 | 纯用户态，可作为库嵌入应用 |
QUIC 的加密设计
QUIC 将加密深度集成到协议设计中：
- 初始握手：QUIC 使用 TLS 1.3 进行握手，但将其适配到 QUIC 的包格式
- Initial 包：握手的第一批包（Initial）使用从目标 Connection ID 和 salt 派生的初始密钥进行加密
- Handshake 包：后续握手包使用 TLS 1.3 派生的握手密钥加密
- Short Header 包：数据包使用应用数据密钥加密，大部分头部字段也可加密
这意味着 QUIC 对 DPI 系统的透明度远低于 TCP+TLS——QUIC 的几乎所有包内容都是加密的。
HTTP/3
HTTP/3 是 HTTP 协议在 QUIC 上的映射。它在语义上与 HTTP/2 相同（请求/响应、头部压缩 QPACK 等），但在传输层使用了 QUIC 的多路复用 Stream 替代 TCP。
QUIC 在反审查中的角色
作为反审查工具
QUIC 对反审查工具很有吸引力，因为：
- 更少的可检测字段：QUIC 的包头部大部分是加密的，留给 DPI 的检测面更少
- 0-RTT 能力：更快建立连接，减少被检测的机会窗口
- 连接迁移：切换网络时不需要重新握手，减少暴露
GFW 对 QUIC 的审查
根据 USENIX Security '25 论文，GFW 从 2024 年 4 月开始部署 QUIC SNI 过滤：
- 检测方法：GFW 检查 QUIC Initial 包中的 SNI（TLS 1.3 ClientHello 嵌入在 QUIC Crypto 帧中）
- 阻断方式：对包含被封锁 SNI 的 QUIC Initial 包，GFW 丢弃该连接的所有后续数据包（包丢弃而非 TCP RST，这是 GFW 首次对 UDP 协议使用包丢弃方式阻断）
- 阻断范围：基于 3 元组（源 IP、目标 IP、目标端口）进行阻断
- 残留效应：阻断持续约 60 秒，期间从同一源到同一目标的任何 UDP 包都可能被丢弃
- 单包触发：只需检测到一个 QUIC Initial 包即可触发阻断（与 TLS 需要 TCP SYN + PSH/ACK 两个包不同）
研究还发现了一种绕过方法：在 QUIC Initial 包之前发送一个随机 UDP 载荷，这会让 GFW 将该流标记为"非 QUIC"，从而绕过 SNI 检查。
Xray-core 中的 QUIC
KCP 传输
Xray-core 支持 KCP（transport/internet/kcp/），这是一个基于 UDP 的可靠传输协议，功能上类似于简化版的 QUIC：
- 基于 UDP 实现可靠传输
- 使用 ARQ 重传
- 支持多种拥塞控制
- 包含多种伪装头（用于对抗 DPI）
KCP 不是标准 QUIC，但在概念上与 QUIC 类似。
REALITY 中的 QUIC 支持
源码位置：REALITY/quic.go（15,957 字节）
REALITY 的 TLS fork 包含了对 QUIC 的支持，实现了 QUIC 传输参数扩展（extensionQUICTransportParameters = 57）的处理。这意味着 REALITY 可以与 QUIC 传输层协同工作。
QUIC 作为代理传输的风险
- UDP 更容易被整体阻断：如果网络环境对 UDP 流量进行限速或阻断（如某些 ISP 和公共 WiFi），QUIC 会受直接影响
- QUIC 流量占比较小：目前 QUIC 只占互联网总流量的一小部分，审查方可以"宁可错杀"地阻断所有 QUIC 流量而不会造成太大误伤——这与 TCP 不同（阻断所有 TCP 会导致断网）
- 特征更少也更显眼：虽然 QUIC 加密了更多字段，但正因为可检测的字段少，每个字段的统计区分度反而更高
外部参考资料
资料：RFC 9000 - QUIC: A UDP-Based Multiplexed and Secure Transport 类型：IETF 标准 链接：https://www.rfc-editor.org/rfc/rfc9000 可信度：A
资料：Exposing and Circumventing SNI-based QUIC Censorship of the Great Firewall 类型：顶会论文（USENIX Security '25） 链接：https://www.usenix.org/system/files/usenixsecurity25-zohaib.pdf 可信度：A，最新 GFW QUIC 审查研究
资料：REALITY quic.go 类型：源码 链接：
REALITY/quic.go可信度：A
读者自检
读完本文后应能回答：
- QUIC 与 TCP+TLS 的核心区别
- GFW 如何检测和阻断 QUIC 流量
- QUIC 对反审查工具的优缺点
- Xray-core 和 REALITY 中 QUIC 的实现位置