答案：HTTP3与QUIC

为什么 QUIC 选择基于 UDP 而不是直接修改 TCP？

QUIC 选择基于 UDP 而非直接修改 TCP，核心原因在于TCP 协议栈深植于操作系统内核，修改 TCP 需要更新全球数十亿台设备的操作系统，这在现实中几乎不可能实现。相比之下，UDP 作为用户态协议，QUIC 可以直接在应用层（如浏览器、APP）中实现和迭代，无需等待操作系统升级。

从飞翔公司的技术演进来看，翼王在评估协议选型时曾算过一笔账：如果修改 TCP，Windows、Linux、macOS、Android、iOS 等主流系统都需要推送内核更新，用户侧覆盖率可能需要 5-10 年才能达到可用水平。而基于 UDP 的 QUIC 只需要更新浏览器（如 Chrome、Edge）或 APP 版本，3-6 个月就能覆盖大部分活跃用户。

此外，UDP 给了 QUIC 更大的设计自由度：

连接迁移：TCP 依赖四元组（源 IP、源端口、目的 IP、目的端口）标识连接，手机从 WiFi 切换到 4G 时连接会中断。QUIC 使用 64 位 Connection ID，IP 变化不影响连接连续性。航仔在地铁上刷飞翔 APP 时，网络切换不再导致视频卡顿，正是受益于此。
队头阻塞消除：HTTP/2 在单条 TCP 连接上多路复用，一旦某个流丢包，整个连接的所有流都要等待重传。QUIC 基于 UDP，在应用层实现了独立的流控和丢包恢复，单个流的丢包不会影响其他流。
更快的握手：QUIC 将 TLS 1.3 的加密握手与传输层握手合并，通常只需 1-RTT，甚至支持 0-RTT 恢复。

当然，UDP 本身不可靠，QUIC 需要在用户空间重新实现拥塞控制、重传、流量控制等机制。但这笔"重复造轮子"的代价，换来了部署灵活性和协议演进速度，对互联网巨头和飞翔这样的创新公司而言是完全值得的。

# 用 nc 测试 UDP 连通性，理解 UDP 无连接特性
$ nc -u -v api.feixiang.com 443
Connection to api.feixiang.com 443 port [udp/https] succeeded!
# 输入任意内容后不会收到确认，这就是 UDP 的"发完不管"

飞翔公司的 APP 从 HTTP/2 升级到 HTTP/3，运维凌叔需要关注哪些部署问题？

凌叔作为飞翔公司的运维负责人，在将 APP 从 HTTP/2 升级到 HTTP/3 时，需要系统性地关注以下几个层面的部署问题：

1. 服务端基础设施升级

HTTP/3 需要服务端支持 QUIC 和 TLS 1.3。凌叔需要确保 Nginx、Envoy 或自研网关升级到支持 HTTP/3 的版本。以 Nginx 为例，需要编译时开启 --with-http_v3_module：

# 检查 Nginx 是否支持 HTTP/3
$ nginx -V 2>&1 | grep -o 'http_v3'
http_v3

# Nginx 配置示例
server {
    listen 443 quic reuseport;
    listen 443 ssl;
    ssl_certificate     /etc/ssl/feixiang.crt;
    ssl_certificate_key /etc/ssl/feixiang.key;
    add_header Alt-Svc 'h3=":443"; ma=86400';
}

Alt-Svc 响应头是关键：它告诉客户端"我同时也支持 HTTP/3"，客户端后续会尝试 QUIC 连接，实现平滑过渡而非强制切换。

2. 防火墙与网络策略

很多企业防火墙默认只允许 TCP 80/443，UDP 流量可能被拦截。凌叔需要协调网络团队开放 UDP 443 端口。同时，一些 NAT 设备对 UDP 会话的超时时间较短（如 30 秒），可能导致 QUIC 连接频繁断开，需要调整 NAT 超时配置或启用 QUIC 的 keep-alive 机制。

3. 负载均衡与连接迁移

传统四层负载均衡基于四元组做哈希，QUIC 的连接迁移特性可能导致同一个 Connection ID 的流量被分发到不同后端。凌叔需要确保负载均衡器支持基于 Connection ID 的调度，或者使用七层代理统一终止 QUIC 连接。

4. 监控与排障体系

HTTP/3 运行在 UDP 之上，现有的 TCP 抓包工具（如 tcpdump）无法直接分析 QUIC 流量。凌叔需要部署支持 QUIC 的抓包分析方案，并在 APP 端埋点统计协议版本分布、握手时延、0-RTT 成功率等指标。

5. 回退策略

并非所有网络环境都支持 QUIC（某些企业代理会阻断 UDP）。凌叔必须确保 APP 在 QUIC 失败时能无缝回退到 HTTP/2 或 HTTP/1.1，避免用户无法访问服务。

# 用 curl 测试 HTTP/3 支持（需编译支持 QUIC 的 curl）
$ curl --http3 -I https://api.feixiang.com/health
HTTP/3 200
alt-svc: h3=":443"; ma=86400

0-RTT 恢复有什么安全隐患？如何防范重放攻击？

0-RTT（Zero Round Trip Time）恢复是 QUIC 的一大性能亮点：当客户端之前与服务器建立过连接并保存了会话票据（Session Ticket）时，再次连接可以直接发送加密数据，无需等待握手完成。这对飞翔 APP 的启动速度提升显著——航仔打开 APP 时，首屏请求可以立即发出，无需等待 TLS 握手。

然而，0-RTT 存在一个本质性的安全隐患：重放攻击（Replay Attack）。

安全隐患分析

在 0-RTT 阶段，客户端使用之前协商的密钥直接加密并发送数据。问题在于，这些数据在服务器正式完成握手验证之前就已经被处理。攻击者可以截获这段加密数据，在稍后甚至数小时后重新发送给服务器，而服务器会将其视为合法的 0-RTT 数据并执行相应操作。

假设飞翔 APP 的 0-RTT 请求是 POST /api/transfer?to=attacker&amount=10000，攻击者雁姐截获后反复重放，可能导致用户账户被多次扣款。虽然 QUIC 有防重放机制，但在 0-RTT 窗口期内（通常数秒到数分钟），风险依然存在。

防范措施

1. 限制 0-RTT 请求的副作用

TLS 1.3 和 QUIC 的规范都建议：服务器不应让 0-RTT 请求触发具有副作用的操作。凌叔在配置飞翔 API 网关时，应明确禁止 0-RTT 数据用于以下操作：

资金交易（转账、支付）
状态变更（修改密码、注销账户）
数据删除操作

只允许 0-RTT 用于幂等的读操作，如 GET /api/user/profile。

2. 使用 Early Data 指示

服务器在应用层标记请求是否来自 0-RTT，后端业务代码据此决定是否接受：

# 飞翔 API 网关的伪代码示例
def handle_request(request):
    if request.is_early_data:  # 0-RTT 请求标记
        if request.method != "GET":
            return 425, "Too Early"  # RFC 8470 标准响应码
    # 正常处理

HTTP 状态码 425 Too Early 专门用于拒绝过早发送的请求，要求客户端完成完整握手后重试。

3. 票据绑定与单次使用

TLS 1.3 支持将 Session Ticket 与特定客户端参数（如 SNI、ALPN）绑定，降低跨站重放风险。凌叔还可以配置票据的单次使用策略，服务器接受 0-RTT 后立即使该票据失效，防止同一票据被多次利用。

4. 时间窗口与防重放缓存

服务器维护一个近期已接收的 0-RTT 请求标识（如哈希值）的滑动窗口缓存，检测到重复标识时直接丢弃。窗口大小通常设置为 RTT 的数倍，兼顾安全与性能。

# 用 openssl 查看 TLS 1.3 会话票据和 0-RTT 支持
$ openssl s_client -connect api.feixiang.com:443 -tls1_3 -early_data /tmp/early_data.txt
# 观察服务器是否接受 early data，以及响应中是否包含重放风险提示

综上，0-RTT 是"性能与安全"的典型权衡。飞翔公司的最佳实践是：让 0-RTT 负责"快"，让完整握手负责"安全"，在应用层明确区分两者的使用边界。