题干与适用场景
移动客户端在 Wi-Fi 与蜂窝网络间切换时，如何保持 QUIC 连接并避免 0-RTT 重放带来的重复写入？你会如何设计路径验证、负载均衡、监控和 TCP 回退？
这道题适合后端、网络、边缘和平台岗位。QUIC 使用 Connection ID 将连接与 UDP 四元组分离，因此地址变化可以触发迁移；RFC 9001 明确 0-RTT 缺少完整的重放保护。重点是把协议约束转成服务端状态、幂等接口和部署策略。
面试官考察点
- 是否区分连接 ID、路径、地址验证和连接迁移时机。
- 是否知道握手确认前不能主动迁移，并能解释 PATHCHALLENGE/PATHRESPONSE。
- 是否把 0-RTT 仅用于可安全重放的请求，而不是直接允许任意写操作。
- 是否考虑负载均衡器、连接 ID 路由、密钥轮换和状态共享。
- 是否为 UDP 被阻断、NAT 重绑定、丢包和迁移失败设计回退。
- 是否用指标证明迁移成功，而非只看握手成功率。
30 秒回答框架
“我会让 Connection ID 标识连接，收到新源地址后先做路径验证，再切换发送路径；握手确认前不主动迁移。0-RTT 请求按重放风险分类，只允许幂等读或带去重令牌的写，服务端保存 anti-replay 窗口与业务幂等键。边缘层按 Connection ID 路由并支持密钥轮换，监控迁移、验证、重绑定和回退指标；UDP 不可用时协商 HTTP/2 或 HTTP/1.1。”
分步骤深入解答
第一步：分离连接与路径
TCP 通常由地址和端口四元组识别连接；QUIC 使用 Connection ID 识别连接，源地址变化不必然创建新连接。服务端收到来自新路径的数据时，不能立即把它当作可信路径；应用数据发送前要完成路径验证，并处理 NAT 重绑定与临时网络切换。
第二步：设计路径验证状态机
旧路径继续承载数据时，端点向候选路径发送 PATHCHALLENGE，并等待 PATHRESPONSE。为每条候选路径记录令牌、发送时间、验证状态和失败次数；验证超时不应立刻销毁连接。迁移前后都要遵守拥塞控制和放大限制，避免向未经验证的地址放大流量。
第三步：处理 Connection ID 与负载均衡
边缘负载均衡器需要从 Connection ID 得到稳定的后端路由，或使用可验证的路由令牌把连接转发到持有状态的节点。服务端应按协议发放、撤销和轮换 Connection ID，避免暴露拓扑或让旧 ID 无限有效。连接状态、令牌和密钥的共享边界要明确，不能依赖单机内存却允许任意迁移。
第四步：划定 0-RTT 的业务边界
0-RTT 数据可能被攻击者重放，服务器不能把它当作只执行一次的证明。默认只接受幂等 GET 或可安全重试的请求；若必须支持写操作，使用客户端生成的幂等键、请求时间窗、账户与资源约束，并在服务端原子去重。支付、扣库存、发放权益等副作用应等待 1-RTT 确认。
第五步：观察迁移和失败路径
记录 Connection ID、旧新路径摘要、验证耗时、迁移成功率、NAT 重绑定、丢包、拥塞窗口、0-RTT 接受与拒绝、重复请求命中和回退原因。日志不记录完整地址或敏感令牌；使用哈希或分桶维度。告警应区分客户端网络变化、服务端验证失败、负载均衡路由错误和 UDP 被阻断。
第六步：建立回退与灰度策略
HTTP/3 客户端应能在 QUIC 建连失败、UDP 被阻断或路径验证持续失败时尝试 TCP 版本。灰度先按地区、客户端版本和边缘节点启用，比较迁移成功率、p99 延迟、CPU、丢包和业务重复率。回退不应让同一请求在 HTTP/3 和 HTTP/2 两条路径各执行一次，应用层仍需幂等。
取舍、边界与信息增益
QUIC 连接迁移改善移动网络切换体验，但增加了路径状态、路由、反放大和观测复杂度。0-RTT 降低首包等待，却牺牲重放安全边界。高质量设计把协议层的“可能重复”传递到业务层，用幂等和审计吸收风险，并保留可靠的 TCP 回退。
高质量示范回答
“我会用 Connection ID 而非 UDP 四元组识别连接。收到新源地址后先进入候选路径状态，发送 PATHCHALLENGE 并验证 PATHRESPONSE；验证成功才切换发送路径，同时遵守拥塞控制和放大限制。负载均衡器要能按 Connection ID 路由，或者把连接状态放到可共享的边界，Connection ID 还要支持轮换和撤销。
0-RTT 没有完整重放保护，所以只允许幂等读取或带时间窗和幂等键的安全请求。支付、库存和权益写入等待 1-RTT；服务端原子记录幂等键并审计重复命中。指标覆盖验证耗时、迁移成功率、NAT 重绑定、0-RTT 接受率、重复请求和回退原因。
最后按客户端、地区和节点灰度，QUIC 失败时回退 HTTP/2 或 HTTP/1.1，并保证应用层幂等，避免两条协议路径重复执行同一副作用。”
常见错误
- 看到新地址就立即切换 → 新路径尚未验证 → 先完成 PATHCHALLENGE/PATHRESPONSE。
- 把 0-RTT 当作一次性请求 → 数据可能被重放 → 限制方法并使用幂等键和时间窗。
- 只在单机内存保存连接状态 → 迁移到另一节点会失败 → 设计 Connection ID 路由或共享状态。
- 忽略放大限制 → 未验证地址可能被放大攻击 → 遵守验证和发送额度。
- 只监控握手成功 → 迁移、重绑定和回退问题被隐藏 → 记录完整生命周期指标。
- 回退时重复执行写操作 → HTTP/3 与 HTTP/2 可能各到达一次 → 业务层使用同一幂等键。
追问及应对
为什么不能在握手确认前主动迁移？
RFC 9000 规定端点在握手确认前不能主动发起迁移；此时连接密钥和路径信任仍在建立。先完成握手，再按路径验证状态切换。
NAT 重绑定和主动迁移有什么区别？
NAT 重绑定是外部网络设备改变映射，端点可能继续使用同一 Connection ID；主动迁移是端点有意改变地址或接口。两者都需要验证新路径，但触发原因和可观测标签不同。
如何判断一个 0-RTT 写请求安全？
确认重复执行不会改变最终结果，或由服务端以幂等键、资源版本和时间窗原子去重。不可逆副作用默认等待 1-RTT，不把 TLS 会话票据当作业务授权。
UDP 被企业网络阻断时怎么办？
客户端回退到 HTTP/2 或 HTTP/1.1，并保留相同的认证、幂等和超时语义。监控回退比例与地区分布，避免把 UDP 阻断误判为服务端故障。