第 11 章：六大实现横评——该选谁？

最佳选择：quinn

原因：
1. 代码最少（~150 文件），全局认知成本低
2. 纯 Rust，类型签名即文档
3. sans-io 核心（quinn-proto）不依赖异步运行时
4. 测试直接驱动状态机，无需真实网络
5. 社区讨论活跃，问题回复快

阅读顺序：
  examples/ → quinn/src/ → quinn-proto/src/ → congestion/

次选：ngtcp2
  如果你更熟悉 C 语言，ngtcp2 代码量也少且结构清晰

最佳选择：quiche 或 msquic

quiche 适合：
  - 需要 HTTP/3 支持
  - 需要与 nginx/curl 集成
  - Linux 为主的服务端
  - 需要 BBR 拥塞控制

msquic 适合：
  - Windows 服务器环境
  - 需要内核态性能
  - .NET 生态集成
  - 需要超大连接数（100K+/核）
  
s2n-quic 适合：
  - AWS 生态
  - 安全合规要求严格
  - 需要 XDP 高性能 I/O

最佳选择：TQUIC

原因：
1. 多路径支持（WiFi + 蜂窝同时用）
2. iOS + Android SDK
3. C FFI 方便移动端集成
4. 腾讯在微信/QQ 上验证过
5. 弱网优化经验丰富

次选：quiche
  - Cloudflare 也有移动端使用经验
  - 但没有多路径支持

最佳选择：quinn-proto 或 ngtcp2

quinn-proto 适合：
  - 目标平台支持 Rust 编译
  - 完全 no-std 可能（需额外工作）
  - sans-io 可以适配任何 I/O 模型

ngtcp2 适合：
  - 目标平台只有 C 编译器
  - 内存极度受限
  - 需要选择最小的 TLS 库（如 wolfSSL）

最佳选择：TQUIC（多路径方向）或 ngtcp2（拥塞控制方向）

TQUIC：
  - MultipathScheduler trait 让你方便实验
  - 多路径调度是当前热点课题
  - 可以快速原型验证算法

ngtcp2：
  - 拥塞控制实现严格遵循论文
  - BBR2 实现可以作为基线
  - 代码简洁，方便修改验证

唯一选择：TQUIC

原因：
  - 竞赛就是围绕 TQUIC 的多路径调度
  - 需要实现 MultipathScheduler trait
  - 需要理解 PathMap、per-path CC
  - 测试环境基于 TQUIC

但需要参考其他实现：
  - quinn：学习 QUIC 基础概念
  - s2n-quic：学习可插拔设计和测试策略
  - ngtcp2：参考 BBR2 拥塞控制实现
  - quiche：参考 Chromium BBR 的生产经验

1. quinn 式 sans-io（轮询输出）
   
   input: conn.handle(data)           → 处理输入
   output: conn.poll_transmit()       → 取出输出
   timer: conn.poll_timeout()         → 获取超时
   
   特点：输出通过轮询获取
   好处：调用者完全控制节奏
   适合：异步运行时集成

2. quiche/TQUIC 式 sans-io（recv/send 对称）
   
   input: conn.recv(buf, info)        → 处理输入
   output: conn.send(buf)             → 获取输出（写入提供的缓冲区）
   timer: conn.timeout()              → 获取超时
   
   特点：输出通过 send() 获取，用调用者提供的缓冲区
   好处：避免内部分配，零拷贝友好
   适合：C FFI（缓冲区由 C 调用者管理）

3. ngtcp2 式 sans-io（回调 + 轮询混合）
   
   input: ngtcp2_conn_read_pkt()      → 处理输入（会触发回调）
   output: ngtcp2_conn_write_pkt()    → 获取输出
   events: 通过回调函数通知           → 流数据、连接状态等
   
   特点：部分通过回调通知、部分通过轮询
   好处：灵活，TLS 操作通过回调委托给适配层
   适合：需要在回调中做 TLS 操作的场景

msquic 的 "全包" 模式：

应用只需要：
  1. 设置回调
  2. 调用 Start
  3. 在回调中处理事件

msquic 内部做：
  - 创建和管理 UDP socket
  - 管理线程池
  - 收发 UDP 包
  - 调度所有定时器
  - 处理 RSS 绑核

好处：
  - 应用代码极简
  - 性能优化集中在库内部
  - 应用开发者不需要理解网络编程细节

坏处：
  - 无法自定义 I/O 模型
  - 无法在无 OS 环境使用
  - 测试需要真实/模拟网络栈

s2n-quic 的 Provider 模式：

介于 sans-io 和全内管之间：
  - 不像 sans-io 那样把所有 I/O 推给调用者
  - 不像全内管那样锁定 I/O 实现
  - 而是：定义接口（trait），让用户选择实现

Server::builder()
    .with_tls(...)       // 选 TLS 实现
    .with_io(...)        // 选 I/O 实现（tokio/xdp/mock）
    .with_event(...)     // 选事件处理
    .start()?;

好处：
  - 开箱即用（提供默认 Provider）
  - 完全可测试（换成 mock Provider）
  - 灵活（可以换高性能 Provider 如 XDP）
  
是否有"最优解"？
  → 取决于你的优先级：
     极简嵌入 → sans-io（quinn-proto/quiche/TQUIC）
     开箱即用 → 全内管（msquic）或 Provider（s2n-quic）
     多语言 → sans-io + C FFI（quiche/TQUIC/ngtcp2）

                    rustls          BoringSSL        s2n-tls         Schannel
                   (quinn)       (quiche/TQUIC)    (s2n-quic)      (msquic-Win)
┌──────────────────────────────────────────────────────────────────────────────┐
│ 语言         │ Rust            │ C/C++          │ C              │ C (Win API) │
│ 内存安全     │ Rust 保证       │ 靠开发实践     │ 靠审计+fuzzing │ 微软维护    │
│ 编译复杂度   │ 低(cargo build) │ 高(需C++编译)  │ 中             │ N/A(系统库) │
│ 二进制大小   │ 小              │ 大             │ 中             │ N/A         │
│ FIPS 合规    │ 有(aws-lc-rs)   │ 有             │ 有             │ 有          │
│ 硬件加速     │ AES-NI          │ AES-NI + 更多  │ AES-NI         │ 平台相关   │
│ 性能         │ 好              │ 最优           │ 好             │ 好          │
│ 跨平台       │ 优秀            │ 需要配置       │ Linux为主      │ Windows only│
│ 生态成熟度   │ 快速增长        │ 非常成熟       │ AWS验证        │ 非常成熟    │
└──────────────────────────────────────────────────────────────────────────────┘

选择建议：
  纯 Rust 项目且不需要 FIPS → rustls
  需要最高性能或 C FFI → BoringSSL
  AWS 部署且需 FIPS → s2n-tls
  Windows 内核态 → Schannel
  多种 TLS 库灵活切换 → ngtcp2

注意：以下数据来自各项目的基准测试和社区报告
     不同测试环境差异很大，仅供参考

单连接吞吐（理想网络，amd64）：
  msquic:   ~10 Gbps (多核优化)
  quiche:   ~8-10 Gbps (BBR + BoringSSL AES-NI)
  s2n-quic: ~8 Gbps (XDP 模式可更高)
  quinn:    ~6-8 Gbps
  TQUIC:    ~6-8 Gbps (单路径); ~12+ Gbps (双路径聚合)
  ngtcp2:   ~5-7 Gbps

连接建立速率（新连接/秒/核）：
  msquic:   ~100K
  quiche:   ~60K
  s2n-quic: ~50K
  quinn:    ~50K
  ngtcp2:   ~40K
  TQUIC:    ~40K (含多路径初始化开销)

内存占用（每空闲连接）：
  ngtcp2:   ~10-15 KB
  msquic:   ~8-15 KB
  quiche:   ~15-25 KB
  quinn:    ~20-30 KB
  s2n-quic: ~20-30 KB
  TQUIC:    ~25-40 KB (多路径状态占更多内存)

TQUIC 的优势不在单路径性能，而在多路径聚合：
  WiFi: 500 Mbps + 4G: 100 Mbps
  单路径最多: 500 Mbps
  TQUIC 多路径: ~580 Mbps (考虑调度开销)
  提升: 16%
  
  在丢包环境下差距更大：
  WiFi 丢包 10%: 有效吞吐降到 ~200 Mbps
  TQUIC 多路径(WiFi+4G): ~350 Mbps (4G 补上 WiFi 丢的)
  提升: 75%!

维度：Issue 响应时间 / 发布频率 / 文档质量

quinn:
  - Issue 响应：1-3 天
  - 发布频率：约每月
  - 文档：API docs 优秀，教程中等
  - 社区：活跃的 GitHub Discussions
  
quiche:
  - Issue 响应：3-7 天（Cloudflare 内部优先）
  - 发布频率：约每季度
  - 文档：有示例和 API docs
  - 社区：较活跃的 Issue 区

s2n-quic:
  - Issue 响应：1-5 天
  - 发布频率：约每两周
  - 文档：API docs + 设计文档
  - 社区：有 Amazon 工程师参与

msquic:
  - Issue 响应：1-3 天
  - 发布频率：约每月
  - 文档：丰富的 wiki 和 API 文档
  - 社区：微软工程师活跃参与

ngtcp2:
  - Issue 响应：1-7 天（一人维护）
  - 发布频率：不定期
  - 文档：API docs 完整
  - 社区：小而精

TQUIC:
  - Issue 响应：3-7 天
  - 发布频率：不定期
  - 文档：中文 + 英文双语
  - 社区：较新，还在成长

互操作矩阵（简化）：

          quinn  quiche  s2n-quic  msquic  ngtcp2  TQUIC
quinn      -      ✓       ✓        ✓       ✓      ✓
quiche     ✓      -       ✓        ✓       ✓      ✓
s2n-quic   ✓      ✓       -        ✓       ✓      ✓
msquic     ✓      ✓       ✓        -       ✓      ✓
ngtcp2     ✓      ✓       ✓        ✓       -      ✓
TQUIC      ✓      ✓       ✓        ✓       ✓      -

所有主要实现之间都能互通！
（这就是标准化的好处——RFC 9000 定义了精确的线上格式）

但多路径互操作是另一回事：
  - 多路径 QUIC 还是 draft，不是正式 RFC
  - 目前只有 TQUIC 和少数实验实现支持
  - 多路径的互操作测试还不完善

quinn:
  成熟度：高
  技术债务：低（代码精简，维护者重视重构）
  风险：社区驱动，可能后继乏人
  
quiche:
  成熟度：很高
  技术债务：中（Chromium CC 移植代码风格不统一）
  风险：Cloudflare 业务调整可能影响投入
  
s2n-quic:
  成熟度：中高（2022 年才开源，但 AWS 内部用更久）
  技术债务：低（设计时就考虑了可维护性）
  风险：AWS 可能内部版本和开源版本分叉
  
msquic:
  成熟度：很高
  技术债务：中（支持内核态 + 用户态增加了复杂度）
  风险：微软可能转向内部闭源版本

ngtcp2:
  成熟度：高
  技术债务：低（一人维护风格统一）
  风险：bus factor = 1（只有一个核心维护者）

TQUIC:
  成熟度：中（2023 年开源，相对年轻）
  技术债务：低（新项目，Rust 写的）
  风险：
  - 多路径 QUIC 标准还是 draft，可能改变
  - 腾讯内部版本可能与开源版本有差异
  - 社区还在早期

Week 1-2: 用 quinn 学习 QUIC 基础
  - 跑通 quinn 的 examples
  - 读 quinn-proto 理解状态机
  - 理解 sans-io 模式

Week 3-4: 用 quiche 或 ngtcp2 看拥塞控制
  - 对比 quinn 只有 CUBIC
  - 看 quiche 的 BBR 实现
  - 看 ngtcp2 的 BBR2 实现

Week 5-6: 学习 s2n-quic 的工程实践
  - Provider 模式
  - 事件系统
  - 测试策略（属性测试）

Week 7-8: 深入 TQUIC 准备竞赛
  - MultipathScheduler trait
  - PathMap 数据结构
  - 三种内置调度器
  - 设计自己的调度器

直接从 TQUIC 开始：
  Day 1-2: 跑通 tquic_client/tquic_server
  Day 3-4: 读 MultipathScheduler trait + 三种实现
  Day 5-6: 读 PathMap 和 per-path CC
  Day 7-10: 设计和实现自定义调度器
  Day 11-14: 性能测试和优化

你的场景是什么？
│
├── 学习 QUIC 协议
│   └── quinn（最简洁可读）
│
├── 生产部署
│   ├── Web/CDN 场景
│   │   ├── 需要 HTTP/3 → quiche
│   │   ├── AWS 部署 → s2n-quic
│   │   └── Windows → msquic
│   │
│   ├── 移动端
│   │   ├── 需要多路径 → TQUIC
│   │   └── 不需要多路径 → quiche 或 msquic
│   │
│   └── 嵌入式/IoT
│       ├── Rust 可用 → quinn-proto
│       └── 只有 C → ngtcp2
│
├── 研究/竞赛
│   ├── 多路径方向 → TQUIC
│   ├── 拥塞控制方向 → ngtcp2 或 quiche
│   └── 安全方向 → s2n-quic
│
└── 多语言集成
    ├── 需要集成到 C/C++ → quiche 或 TQUIC 或 ngtcp2
    ├── 需要集成到 .NET → msquic
    └── 需要适配多种 TLS → ngtcp2