【网络工程】QUIC 生态与工程部署：从实验到生产

# quiche（Cloudflare）
# 优势：Cloudflare 全球网络验证、Rust 安全性、C FFI
# 劣势：API 变动频繁、文档较少
# 适用：与 Cloudflare 生态集成、Nginx 集成

# msquic（Microsoft）
# 优势：Windows 原生支持、跨平台、.NET 集成
# 劣势：Linux 上社区小
# 适用：Windows Server、.NET 应用

# ngtcp2 + nghttp3
# 优势：模块化设计、可替换 TLS 库（OpenSSL/BoringSSL/wolfSSL）
# 劣势：需要手动组装
# 适用：自定义集成、研究

# quic-go
# 优势：Go 生态原生、Caddy 集成、API 友好
# 劣势：性能不如 C/Rust 实现
# 适用：Go 应用、Caddy 反向代理

# quinn
# 优势：Rust async/await 原生支持、类型安全
# 劣势：依赖 Rust 生态
# 适用：Rust 应用

# 性能对比（参考值，实际取决于硬件和配置）：
# 单连接吞吐量（单核）：
# msquic:  ~5 Gbps
# quiche:  ~4 Gbps
# lsquic:  ~4 Gbps
# ngtcp2:  ~3.5 Gbps
# quinn:   ~3 Gbps
# quic-go: ~2 Gbps

# Cloudflare — 默认已启用，无需配置

# AWS CloudFront — 通过分配策略启用
# 在 CloudFront 分配中：
# Viewer Protocol Policy → HTTPS Only
# Supported HTTP versions → HTTP/3

# 验证 HTTP/3 支持
curl -I --http3 https://example.com
# HTTP/3 200
# alt-svc: h3=":443"; ma=86400

# 使用 Chrome 验证
# chrome://flags/#enable-quic → Enabled
# DevTools → Network → Protocol 列显示 h3

# 服务端通过 Alt-Svc 响应头告知客户端 QUIC 可用

# Alt-Svc 格式
Alt-Svc: h3=":443"; ma=86400
# h3     — HTTP/3 协议
# :443   — QUIC 端口（通常与 HTTPS 相同）
# ma     — 最大有效期（秒）

# 多版本支持
Alt-Svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400

# 客户端行为：
# 1. 首次请求通过 TCP + HTTP/2
# 2. 收到 Alt-Svc 头后，后续请求尝试 QUIC
# 3. QUIC 成功则持续使用
# 4. QUIC 失败则回退 TCP（优雅降级）

# IETF QUIC-LB 草案定义了 Connection ID 的路由方案

# 核心思想：服务端在 Connection ID 中编码路由信息
# LB 读取 Connection ID 的路由部分，映射到后端服务器

# 三种模式：
# 1. 明文模式 — Connection ID 直接包含 server ID
#    优势：简单
#    劣势：暴露后端拓扑

# 2. 加密模式 — 用 LB 和后端共享的密钥加密 server ID
#    优势：安全
#    劣势：需要密钥分发

# 3. 流路由模式 — LB 维护 Connection ID 到后端的映射表
#    优势：无需后端配合
#    劣势：状态存储开销

# Nginx 的 QUIC 支持（1.25.0+）
# nginx.conf
http {
    server {
        listen 443 quic reuseport;
        listen 443 ssl;
        
        http2 on;
        http3 on;
        
        ssl_certificate     /path/to/cert.pem;
        ssl_certificate_key /path/to/key.pem;
        
        add_header Alt-Svc 'h3=":443"; ma=86400';
        
        quic_retry on;
    }
}

# 生产环境中 UDP 443 可能被阻断的场景：
# 1. 企业防火墙只允许 TCP 出站
# 2. 运营商对 UDP 有流量限制
# 3. NAT 设备的 UDP 超时时间太短（30s vs TCP 300s）
# 4. 中间设备不转发大 UDP 包

# 检测 UDP 443 可达性
# 使用 curl 的 HTTP/3 支持
curl --http3 -v https://quic.rocks:4433/

# 检查 NAT 超时
# 在客户端发送 QUIC 包，观察多久后连接断开
# 典型 NAT UDP 超时：30s-120s
# QUIC 的 idle timeout 需要小于此值

# 解决方案：
# 1. Keep-alive——QUIC PING 帧维持 NAT 映射
# 2. 回退机制——QUIC 失败后自动切换 TCP
# 3. Happy Eyeballs v2——同时尝试 TCP 和 QUIC

# Linux 内核参数——优化 UDP 性能

# 增大 UDP 收发缓冲区
sysctl -w net.core.rmem_max=26214400
sysctl -w net.core.wmem_max=26214400
sysctl -w net.core.rmem_default=26214400

# 增大 UDP 缓冲区（QUIC 特别需要）
sysctl -w net.core.netdev_max_backlog=8192

# 启用 GRO（Generic Receive Offload）
ethtool -K eth0 gro on

# 启用 GSO（Generic Segmentation Offload）
ethtool -K eth0 gso on

# SO_REUSEPORT——多进程共享 UDP 端口
# QUIC 服务端应使用 SO_REUSEPORT 实现多核并行
# quiche/msquic 默认支持

# 0-RTT 可以消除握手延迟，但有重放攻击风险

# 0-RTT 安全考虑：
# 1. 0-RTT 数据可能被重放——不要在 0-RTT 中发送非幂等请求
# 2. 服务端需要维护 anti-replay 机制
# 3. 限制 0-RTT 的有效期

# 0-RTT 适用场景：
# ✓ GET 请求（幂等）
# ✓ DNS 查询
# ✓ 静态资源请求
# ✗ POST 请求（非幂等）
# ✗ 转账/支付操作
# ✗ 带副作用的 API 调用

# 服务端配置示例（Nginx）
# quic_gso on;
# ssl_early_data on;  # 启用 0-RTT

# QUIC 的拥塞控制在用户态实现，可以灵活选择

# 常见选择：
# 1. Cubic（默认）——与 TCP 共存公平
# 2. BBR v1——高带宽高延迟网络表现好
# 3. BBR v2——解决 v1 的公平性问题
# 4. Reno——简单但性能一般

# quiche 配置示例（Rust）
# let mut config = quiche::Config::new(quiche::PROTOCOL_VERSION)?;
# config.set_cc_algorithm(quiche::CongestionControlAlgorithm::BBR);

# msquic 配置
# QUIC_SETTINGS Settings = {0};
# Settings.CongestionControlAlgorithm = QUIC_CONGESTION_CONTROL_ALGORITHM_BBR;

# 性能对比（100ms RTT + 1% 丢包场景）：
# BBR:   ~80 Mbps
# Cubic: ~30 Mbps
# Reno:  ~10 Mbps

# qlog 是 QUIC 的标准化日志格式（IETF 草案）
# 可以用 qvis 工具可视化

# quiche 启用 qlog
# let mut config = quiche::Config::new(quiche::PROTOCOL_VERSION)?;
# config.log_keys();
# 设置环境变量 QLOGDIR=/tmp/qlogs

# qvis 分析工具
# https://qvis.quictools.info/
# 上传 qlog 文件后可以看到：
# - 连接状态时间线
# - 拥塞窗口变化
# - 流的发送/接收时序
# - RTT 测量值变化
# - 丢包和重传事件

# Wireshark 4.0+ 原生支持 QUIC 协议解析

# 但 QUIC 有效载荷是加密的——需要密钥才能解密

# 方法 1：使用 SSLKEYLOGFILE
# 设置环境变量
export SSLKEYLOGFILE=/tmp/quic-keys.log
# 然后运行 QUIC 客户端

# 在 Wireshark 中配置：
# Edit → Preferences → Protocols → TLS
# (Pre)-Master-Secret log filename → /tmp/quic-keys.log

# 方法 2：使用 qlog 代替 Wireshark
# qlog 不需要密钥，直接记录应用层事件

# 过滤 QUIC 流量
# Wireshark 过滤器：quic
# 只看 Initial 包：quic.long.packet_type == 0
# 只看 Handshake 包：quic.long.packet_type == 2
# 看特定 Connection ID：quic.dcid == <CID>

# curl 8.x 支持 HTTP/3（需要编译时启用）

# 基本 HTTP/3 请求
curl --http3 https://example.com

# 详细输出
curl --http3 -v https://example.com 2>&1 | head -30
# * using HTTP/3
# * [QUIC] connected to example.com:443
# * [QUIC] ALPN: h3

# 强制只用 HTTP/3（不回退）
curl --http3-only https://example.com

# 连接时间分析
curl --http3 -o /dev/null -w "\
    DNS: %{time_namelookup}s\n\
    Connect: %{time_connect}s\n\
    AppConnect: %{time_appconnect}s\n\
    TTFB: %{time_starttransfer}s\n\
    Total: %{time_total}s\n" \
    https://example.com

# HTTP/2 vs HTTP/3 对比
echo "=== HTTP/2 ==="
curl -o /dev/null -w "TTFB: %{time_starttransfer}s\n" https://example.com
echo "=== HTTP/3 ==="
curl --http3 -o /dev/null -w "TTFB: %{time_starttransfer}s\n" https://example.com

# 企业环境对 QUIC 的特殊考虑

# 问题 1：可见性
# TCP 流量可以被 IDS/IPS/DLP 检查
# QUIC 加密所有载荷，中间设备无法检查
# 方案：在边界解密 QUIC（QUIC 代理）

# 问题 2：合规
# 某些行业要求审计所有网络流量
# QUIC 的端到端加密使合规检查困难
# 方案：使用企业 CA + mTLS + QUIC 代理

# 问题 3：防火墙策略
# 传统防火墙基于 TCP 端口做策略
# QUIC 使用 UDP，策略需要调整
# 方案：升级到 NGFW（Next-Gen Firewall）

# 问题 4：带宽管理
# QoS 策略通常基于 TCP 端口/流
# QUIC 的连接迁移可能绕过 QoS 策略
# 方案：基于 Connection ID 或 DSCP 做 QoS

# 企业 QUIC 策略建议：
# 内网服务间通信 → 推荐 QUIC（性能提升明显）
# 面向公网用户 → 推荐 QUIC + TCP 回退
# 合规敏感场景 → 评估后决定（可能需要 QUIC 代理）

# QUIC 特有的监控指标

# 连接级别
quic_connections_active          # 活跃连接数
quic_connections_established     # 成功建立的连接数
quic_handshake_duration_seconds  # 握手耗时
quic_0rtt_accepted_total         # 0-RTT 接受次数
quic_0rtt_rejected_total         # 0-RTT 拒绝次数

# 传输级别
quic_bytes_sent_total            # 发送字节数
quic_bytes_received_total        # 接收字节数
quic_packets_lost_total          # 丢包数
quic_packets_retransmitted_total # 重传数
quic_rtt_seconds                 # RTT（直方图）
quic_cwnd_bytes                  # 拥塞窗口大小

# 连接迁移
quic_path_validated_total        # 路径验证成功次数
quic_connection_migrated_total   # 连接迁移次数

# UDP 回退
quic_fallback_to_tcp_total       # 回退 TCP 次数
quic_udp_blocked_total           # UDP 被阻断次数

# Happy Eyeballs v2（RFC 8305）的 QUIC 扩展

# 算法：
# 1. 同时发起 TCP 和 QUIC 连接
# 2. QUIC 有 250ms 的优先窗口
# 3. 250ms 内 QUIC 成功 → 使用 QUIC
# 4. 250ms 内 QUIC 未成功 → 启动 TCP 作为备选
# 5. 谁先完成握手就用谁
# 6. 记住结果，下次调整策略

# 客户端缓存策略：
# 域名 → (协议, 过期时间)
# example.com → (QUIC, 2025-08-04 12:00:00)
# api.legacy.com → (TCP, 2025-08-04 15:00:00)
# QUIC 标记失败后 5 分钟重试

# Chrome 的实现：
# - 首次访问：TCP（因为没有 Alt-Svc 信息）
# - 收到 Alt-Svc 后：下次尝试 QUIC
# - QUIC 成功：标记该域名支持 QUIC
# - QUIC 失败：标记该域名 QUIC 不可用

# 服务端配合：
# 1. 始终提供 TCP + TLS 回退
# 2. Alt-Svc 头部设置合理的 ma（最大有效期）
# 3. 监控 QUIC vs TCP 的连接比例

# QUIC 性能测试需要注意的特殊因素：
# 1. 用户态实现——CPU 使用率比 TCP 高
# 2. UDP 缓冲区——需要预先调优
# 3. 加密开销——始终存在
# 4. GSO/GRO——对吞吐量影响巨大

# 使用 quiche 的 quiche-client/quiche-server 基准测试
# 服务端
quiche-server --listen 0.0.0.0:4433 \
    --cert /path/to/cert.pem \
    --key /path/to/key.pem \
    --root /var/www

# 客户端
quiche-client --no-verify \
    https://server:4433/large-file

# 使用 h2load 测试 HTTP/3 并发性能
h2load -n 10000 -c 100 -t 4 \
    --npn-list h3 \
    https://server:4433/

# 结果对比示例（单服务器，16 核）：
# 指标          TCP+HTTP/2   QUIC+HTTP/3
# 握手延迟      ~60ms        ~30ms
# 0-RTT 延迟    N/A          ~0ms
# 吞吐量        9.5 Gbps     7.2 Gbps
# CPU 使用率    45%          72%
# 并发连接      100K         80K

# 使用 netem 模拟不同网络条件测试
# 基准测试——无延迟
curl --http3 -o /dev/null -w "TTFB: %{time_starttransfer}\n" https://server/test

# 添加 50ms 延迟
tc qdisc add dev eth0 root netem delay 50ms
curl --http3 -o /dev/null -w "TTFB: %{time_starttransfer}\n" https://server/test

# 添加 1% 丢包
tc qdisc change dev eth0 root netem delay 50ms loss 1%
curl --http3 -o /dev/null -w "TTFB: %{time_starttransfer}\n" https://server/test

# 清除
tc qdisc del dev eth0 root

# 第一步：Nginx 配置 QUIC
# 升级到 Nginx 1.25+

# nginx.conf
server {
    listen 443 ssl;
    listen 443 quic reuseport;
    
    http2 on;
    http3 on;
    
    ssl_certificate     /etc/nginx/cert.pem;
    ssl_certificate_key /etc/nginx/key.pem;
    ssl_protocols       TLSv1.3;
    
    # 告知浏览器支持 HTTP/3
    add_header Alt-Svc 'h3=":443"; ma=86400' always;
    
    # QUIC 特定优化
    quic_retry on;         # 防 DDoS
    quic_gso on;           # Generic Segmentation Offload
    
    ssl_early_data on;     # 0-RTT
    proxy_set_header Early-Data $ssl_early_data;
}

# 第二步：内核参数调优
sysctl -w net.core.rmem_max=26214400
sysctl -w net.core.wmem_max=26214400

# 第三步：防火墙放行 UDP 443
iptables -A INPUT -p udp --dport 443 -j ACCEPT

# 第四步：验证
curl --http3 -I https://shop.example.com
# HTTP/3 200

# 第五步：监控 QUIC 采纳率
# Nginx 日志中添加 $server_protocol 字段
# 分析 HTTP/2 vs HTTP/3 的比例变化

# 问题分析：
# WiFi → 4G 切换时：
# - TCP：IP 地址变化 → 连接中断 → 重新建立连接（>1s）
# - QUIC：Connection ID 不变 → 路径验证 → 无感迁移（<100ms）

# 实现方案：
# 1. 服务端部署支持连接迁移的 QUIC 服务
# 2. 移动端 SDK 使用 quiche/msquic
# 3. 配置连接迁移参数

# 效果对比：
# 指标              TCP      QUIC
# 切换成功率        60%      99%
# 切换延迟          1500ms   80ms
# 切换时请求失败    40%      <1%

# 注意事项：
# 1. 负载均衡器需要支持 Connection ID 路由
# 2. 服务端需要配置足够的 idle_timeout
# 3. 客户端需要正确处理路径验证

# QUIC v2（RFC 9369）是 QUIC 的第二个标准化版本
# 主要变化：版本号 → 0x6b3343cf

# 核心改进：
# 1. 密钥更新——更新初始密钥的 salt 值
# 2. 版本协商——更安全的版本协商机制
# 3. 防僵化——减少中间设备对特定版本的依赖

# Compatible Version Negotiation
# 客户端和服务端可以在握手中协商版本
# 无需额外的 RTT

# 当前支持情况：
# quiche:   支持（Cloudflare 已部署）
# msquic:   支持
# ngtcp2:   支持
# quic-go:  支持
# quinn:    支持
# Chrome:   支持（Chrome 111+）
# Firefox:  支持（Firefox 114+）

# Multipath QUIC 允许一个连接同时使用多条网络路径
# 类似 MPTCP，但在 QUIC 层实现

# 使用场景：
# 1. 移动设备——同时使用 WiFi 和 4G
# 2. 数据中心——多路径负载均衡
# 3. 高可用——路径故障自动切换

# 与 MPTCP 的区别：
# MPTCP：内核实现，部署困难，需要中间设备支持
# MP-QUIC：用户态实现，UDP 不受中间设备影响

# 当前状态：IETF 草案阶段
# draft-ietf-quic-multipath
# 部分库已有实验性支持（picoquic）

# ===== 部署前检查 =====
# [ ] UDP 443 在所有网络路径上可达
# [ ] 防火墙/安全组已放行 UDP 443
# [ ] QUIC 库已选定并完成集成测试
# [ ] 内核 UDP 缓冲区已调优
# [ ] TLS 1.3 证书已准备

# ===== 服务端配置 =====
# [ ] Alt-Svc 头部正确设置
# [ ] 0-RTT 已根据安全需求配置
# [ ] 拥塞控制算法已选择
# [ ] GSO/GRO 已启用
# [ ] SO_REUSEPORT 已启用

# ===== 负载均衡 =====
# [ ] LB 支持 UDP 转发
# [ ] 会话保持策略已配置
# [ ] QUIC-LB Connection ID 路由（如适用）
# [ ] 健康检查包含 QUIC 端口

# ===== 回退机制 =====
# [ ] TCP + HTTP/2 回退正常工作
# [ ] Happy Eyeballs v2 逻辑正确
# [ ] 回退事件有监控和告警

# ===== 监控 =====
# [ ] QUIC 连接成功率监控
# [ ] QUIC vs TCP 连接比例
# [ ] 0-RTT 接受/拒绝率
# [ ] 握手延迟分布
# [ ] UDP 阻断检测
# [ ] 连接迁移成功率

# ===== 灰度策略 =====
# [ ] 1% → 5% → 20% → 50% → 100%
# [ ] 每阶段至少观察 24 小时
# [ ] 回滚方案就绪（移除 Alt-Svc 头部）