HTTP/3 的 0-RTT 使 keepalive 失去存在必要，因 QUIC 内置连接复用、网络切换续连、轻量保活及 0-RTT 快速请求等机制已覆盖其全部功能。
HTTP/3 的 0-RTT 并不替代 keepalive，而是让 keepalive 在多数场景下失去存在必要——这不是调优逻辑的“颠覆”，而是范式的迁移。
keepalive 的原始目标已被 QUIC 内置机制覆盖
HTTP/1.1 的 keepalive 解决的是 TCP 连接反复建立销毁的开销：三次握手 + TLS 握手（传统需 2–3 RTT）。而 QUIC 将连接管理、加密协商、流复用全部整合进协议层，天然支持：
- 连接 ID 绑定而非 IP+端口，支持网络切换（如 Wi-Fi 切 5G）后自动续连
- 单个 UDP 套接字承载多路并发流，无需为每个请求新建连接
- 连接空闲时保活靠轻量级 PING 帧，不依赖应用层心跳或长连接维持逻辑
0-RTT 消除了“首次请求延迟焦虑”，也消解了 keepalive 的预热价值
keepalive 常被用于“预热连接池”，避免用户首屏请求撞上冷连接。但 0-RTT 让每次新连接都像“热连接”：
- 客户端携带缓存的会话票据（session ticket）和早期密钥，首个 UDP 包即含 HTTP 请求
- 服务端验证票据有效后，可立即解密并处理，无需等待握手完成
- 实测在 100ms RTT 网络下，0-RTT 首包响应比 keepalive 维持的 HTTP/1.1 连接快 200ms+（省去完整握手）
服务端不再需要维护连接生命周期，运维逻辑大幅简化
传统 keepalive 调优涉及大量参数博弈：timeout、max requests、idle time、probe interval……而 QUIC 连接由内核或运行时直接管理：
- 连接超时由 QUIC 协议栈控制（默认 30 秒无活动则关闭），无需应用层定时器干预
- 没有 FIN/RST 状态机干扰，不存在 TIME_WAIT 或 CLOSE_WAIT 积压问题
- 连接复用率接近 100%，因每个客户端连接天然支持数千并发流，不再依赖连接池扩容
真正要重构的不是 keepalive 参数，而是幂等性与重放防护设计
放弃 keepalive 后，系统重心从“连接保活”转向“0-RTT 数据安全”：
- 所有走 0-RTT 的请求必须幂等（如 GET /api/status、HEAD /health），禁止 POST 支付、PUT 用户资料等非幂等操作
- 敏感接口显式禁用 0-RTT：uWebSockets 中可通过 h3options.disable_early_data = true 控制
- 服务端增加轻量级重放窗口（如 5 秒滑动时间戳 + 请求 ID 去重缓存），成本远低于维护长连接状态
