QUIC 协议实现 开源项目全景对比
调研时间:2026-06-22 目的:横向对比 TQUIC 与同赛道 QUIC 实现的设计取舍,为犀牛鸟参与做知识储备
6 个项目一览
| # | 项目 | Stars | 主语言 | 核心设计思路 | 典型部署场景 |
|---|---|---|---|---|---|
| 1 | quiche (cloudflare/quiche) | ~11.4K | Rust | sans-io 设计,协议逻辑与 I/O 完全解耦 | Cloudflare 全球边缘网络 |
| 2 | msquic (microsoft/msquic) | ~9.7K | C | 内核级集成,跨平台 C API + 多语言绑定 | Windows 内核、.NET、Xbox |
| 3 | quinn (quinn-rs/quinn) | ~5.2K | Rust | 纯 Rust 异步,原生 Tokio 集成 | Rust 社区 / 异步应用 |
| 4 | s2n-quic (aws/s2n-quic) | ~1.3K | Rust | 安全与正确性优先,形式化验证辅助 | AWS 基础设施 |
| 5 | TQUIC (Tencent/tquic) | ~1.4K | Rust | 多路径 QUIC + 多拥塞控制算法(CUBIC/BBR/COPA) | 腾讯视频 / 腾讯会议 |
| 6 | ngtcp2 (ngtcp2/ngtcp2) | ~1.3K | C | 多 TLS 后端灵活切换,curl 的 QUIC 引擎 | curl / 命令行工具链 |
设计思路对比
架构模式(核心差异)
每个项目对”QUIC 协议栈怎么嵌入应用”这个问题给出了不同答案:
sans-io 模式(quiche):协议逻辑完全不碰网络 I/O——你喂字节进去、它吐字节出来,怎么收发由你决定。类比:quiche 像一个翻译官,只负责”把中文翻成英文、把英文翻成中文”,至于信件怎么寄、用快递还是邮局,翻译官不管。好处是同一套协议代码能跑在用户态、内核、甚至 WebAssembly 里。
内核集成模式(msquic):直接嵌入操作系统内核,所有 Windows 应用”免费”获得 QUIC 能力,上层通过 C API 调用。类比:msquic 像自来水管道,装进楼里之后每家每户打开水龙头就有水,不需要自己去打井。代价是代码必须兼顾用户态和内核态两条路径。
异步原生模式(quinn):完全拥抱 Rust 的 async/await 和 Tokio 运行时,连接、流、数据报都是原生异步类型。类比:quinn 像一个专门为现代厨房设计的嵌入式烤箱——和厨房(Tokio 生态)严丝合缝,但搬到别的厨房就得改装。
安全优先模式(s2n-quic):AWS 出品,用 Duvet(需求追踪工具)把 RFC 条文逐条映射到代码,配合模糊测试和形式化验证。类比:造桥时每颗螺丝都对照图纸编号检查,确保”规范说的每句话都有代码对应”。
多路径+多算法模式(TQUIC):同时在 Wi-Fi 和 4G 两条路上传数据(Multipath QUIC),并且内置 CUBIC、BBR、COPA 等多种拥塞控制算法可切换。类比:快递公司同时走高速和国道两条线路发货,还能根据路况实时切换”稳速模式”或”抢速模式”。这是 TQUIC 最大的差异化特征——在腾讯视频和腾讯会议的弱网场景下打磨出来的实战能力。
多后端灵活模式(ngtcp2):TLS 层可插拔——支持 OpenSSL、GnuTLS、wolfSSL、boringSSL 等多种后端。类比:ngtcp2 像一个万能充电器,不管你的设备用什么接口,换个转接头就能充。curl 选择它正是因为这种灵活性——curl 要跑在一切平台上。
语言与生态对比
| 项目 | 语言 | 构建工具 | 适合接入的场景 |
|---|---|---|---|
| quiche | Rust | Cargo + CMake(C API) | Nginx/Envoy/CDN 边缘、嵌入式 |
| msquic | C | CMake | Windows 应用、.NET/C#/Rust/Go 多语言绑定 |
| quinn | Rust | Cargo | Rust 异步应用(Tokio 生态) |
| s2n-quic | Rust | Cargo | AWS 服务、高安全要求场景 |
| TQUIC | Rust | Cargo + CMake(C/C++ FFI) | 移动端、音视频、弱网场景 |
| ngtcp2 | C | CMake / autotools | curl、命令行工具、需要多 TLS 后端的场景 |
Rust 占 4/6,反映了系统编程领域”内存安全 + 高性能”的趋势。C 的两个项目(msquic、ngtcp2)侧重跨平台兼容性和现有 C 生态集成。
协议特性对比
| 项目 | 0-RTT | 连接迁移 | Multipath QUIC | HTTP/3 | DATAGRAM 扩展 |
|---|---|---|---|---|---|
| quiche | ✓ | ✓ | - | ✓(内建) | ✓ |
| msquic | ✓ | ✓ | - | ✓(通过 MsH3) | ✓ |
| quinn | ✓ | ✓ | - | ✓(quinn-h3) | ✓ |
| s2n-quic | ✓ | ✓ | - | 依赖外部 | ✓ |
| TQUIC | ✓ | ✓ | ✓(核心特性) | ✓(内建) | ✓ |
| ngtcp2 | ✓ | ✓ | - | ✓(通过 nghttp3) | ✓ |
Multipath QUIC 是 TQUIC 独有的已实现特性——允许单个 QUIC 连接同时使用多条网络路径(如 Wi-Fi + 蜂窝),在弱网切换场景下显著降低卡顿。
生产部署规模对比
| 项目 | 部署方 | 规模描述 |
|---|---|---|
| quiche | Cloudflare | 全球 300+ 数据中心边缘节点,处理互联网约 15-20% 的 HTTP 流量 |
| msquic | Microsoft | Windows 11 内核内建、Xbox 网络栈、.NET 运行时、Bing/Teams |
| quinn | 社区 | Iroh(IPFS 替代)、libp2p-quic、多个 Rust 网络项目 |
| s2n-quic | AWS | AWS SDK、Amazon CloudFront、内部服务 |
| TQUIC | Tencent | 腾讯视频(亿级用户)、腾讯会议(音视频实时传输) |
| ngtcp2 | curl 项目 | curl(装机量数十亿的命令行工具)的默认 QUIC/HTTP3 后端 |
代码量级对比
quiche: ~350 files(含 C API 绑定和 HTTP/3)
msquic: ~800 files(含内核驱动、多平台适配、多语言绑定)
quinn: ~150 files(纯 Rust,含 quinn-h3)
s2n-quic: ~600 files(含大量测试和合规追踪代码)
TQUIC: ~300 files(含 Multipath、多拥塞控制、C FFI)
ngtcp2: ~200 files(核心精简,TLS 后端可插拔)
quinn 代码量最小(~150 文件),纯 Rust 单语言,通读成本最低。ngtcp2 核心也非常精简。
学习价值排序
从”理解 QUIC 协议实现设计”的角度:
- quinn — 代码最精简,纯 Rust + Tokio 异步,API 设计清晰,最适合通读理解 QUIC 全流程
- quiche — 赛道标杆(11.4K star),sans-io 设计是理解”协议逻辑与 I/O 解耦”的最佳教材
- TQUIC — Multipath QUIC + 多拥塞控制算法是独有卖点,理解弱网优化和实战工程取舍
- ngtcp2 — 核心精简,C 语言可读性好,理解”多 TLS 后端”的可插拔架构
- s2n-quic — RFC 逐条追踪的做法值得学习,理解”如何验证协议实现的正确性”
- msquic — 内核集成路径有学术价值但代码量大,适合了解”OS 级 QUIC”思路而非通读
推荐阅读路线
- 先通读 quinn 的连接建立 + 流管理(~150 文件,纯 Rust,2-3 天)
- 对比 quiche 的 sans-io 设计(理解”为什么要把 I/O 剥离出协议栈”)
- 精读 TQUIC 的 Multipath 和拥塞控制模块(理解”多路径调度 + BBR/CUBIC/COPA 切换”)
- 如果时间允许,读 ngtcp2 的 TLS 后端抽象层(理解”如何让协议栈适配不同加密库”)
这个阅读顺序会让你从”理解一个完整 QUIC 实现” → “理解架构取舍” → “理解实战优化” → “理解生态兼容”递进。