通用面试：QUIC 连接迁移如何跨网络保持连接？
题干与适用场景
移动客户端正在下载或保持长连接，网络从 Wi-Fi 切到蜂窝网络，源 IP 和 UDP 端口发生变化。请解释 QUIC 如何识别仍是同一连接、如何验证新路径，以及什么时候必须重连。范围限定在 QUIC v1 传输层；应用层重试、HTTP 会话恢复和 0-RTT 复用单独说明，不能把它们混成“迁移自动成功”。
面试官考察点
强回答会区分四元组和 QUIC Connection ID：地址变化不必然意味着连接状态丢失，但新路径必须验证。面试官会追问握手尚未确认、对端设置 disableactivemigration、NAT 重绑定、连接 ID 耗尽、服务器 preferred address，以及 0-RTT 的重放风险。只说“UDP 不连接所以能切换”说明没有理解 QUIC 的状态和安全边界。
回答前需要澄清的问题
- 是客户端主动切网还是 NAT 被动换端口？ 主动迁移和 NAT 重绑定的触发与验证路径不同。
- 握手是否已确认？ QUIC v1 在握手确认前不能主动迁移，必须继续使用原地址。
- 对端是否禁用了主动迁移？ 收到
disableactivemigration后，不能从新本地地址主动发包，除非使用服务器声明的 preferred address。 - 连接 ID 是否为零长度？ 零长度 ID 无法用新的 ID 隔离路径，隐私和多路径路由能力更弱。
- 应用能否接受短暂无数据？ 若旧路径失效且新路径验证失败，只能等待、关闭连接或由应用重建会话。
30 秒回答框架
“QUIC 不把连接绑定在 TCP 四元组上，而是使用由对端提供的 Connection ID。握手确认后，客户端从新地址发送探测包，服务端通过 PATHCHALLENGE/PATHRESPONSE 验证新路径，验证成功后才把数据迁移过去。NAT 重绑定也要做路径验证。Connection ID 不能跨多个路径复用，且对端可以禁用主动迁移。迁移失败不等于协议立刻丢状态：有可用旧路径就继续，没有就等待或重连。0-RTT 是恢复握手能力，不等于迁移安全，应用必须防重放。”
分步骤深入解答
QUIC 的连接状态由 Connection ID、加密密钥、流状态和拥塞控制等组成。Connection ID 让接收方在 IP 或端口变化后仍能把数据包映射到同一连接；它不是认证凭据，也不能单独证明新地址属于原客户端。
握手确认后，端点可以从新本地地址探测路径。新路径先发 PATHCHALLENGE，收到 PATHRESPONSE 后才视为可用；验证失败只代表该路径不可用，不必立刻结束还有其他有效路径的连接。对端地址突然变化（例如 NAT 重绑定）也要执行路径验证，避免任意伪造源地址把流量导向攻击者。
每条发送路径应使用没有在另一条路径使用过的 Destination Connection ID。这样既帮助多实例服务路由，也减少观察者把两个网络路径关联起来的机会。端点应提前提供多个可用 ID；ID 耗尽时无法探测新路径或响应迁移。若客户端选择零长度 ID，服务端必须依靠地址等其他信息分流，迁移和隐私边界更差。
迁移会影响拥塞控制。地址改变可能让对端重置拥塞状态，因此协议建议不要频繁换地址。服务端可以在握手中提供 preferred address；客户端仍需先验证它，失败时继续使用原地址。若对端设置 disableactivemigration，客户端不能随意从新地址发包，防止协议语义被绕过。
0-RTT 解决的是恢复连接时提前发送应用数据，RFC 明确它没有重放保护。切网后的迁移应使用已经确认的 1-RTT 状态；应用若把重试请求设计成非幂等，不能因为“QUIC 保持连接”就跳过幂等键或服务端去重。
高质量示范回答
“我会先区分连接标识和网络路径。QUIC 使用 Connection ID 映射连接，所以 Wi-Fi 到蜂窝网络导致 IP 或端口变化时，状态仍可能保留。握手确认后，端点从新地址发 PATHCHALLENGE，只有收到 PATHRESPONSE 才把该路径当作可用；NAT 重绑定同样需要验证。不能复用同一个 ID 跨不同发送路径，也要考虑 ID 池耗尽和 disableactivemigration。迁移失败时，如果旧路径还活着就继续，否则等待路径恢复或重建应用会话。最后我会把 0-RTT 当成重放敏感的恢复机制，而不是迁移的安全证明。”
常见错误
- 错误表现 → 说 UDP 天生支持迁移；失败原因 → UDP 没有连接语义，QUIC 仍需管理连接 ID、密钥和流状态；修正方法 → 解释 Connection ID 与路径验证。
- 错误表现 → 地址一变就立即接受数据；失败原因 → 攻击者可伪造源地址造成放大或劫持；修正方法 → 用 PATHCHALLENGE/PATHRESPONSE 验证。
- 错误表现 → 把 0-RTT 当成迁移；失败原因 → 0-RTT 允许提前发数据但没有重放保护；修正方法 → 分开讨论恢复握手与迁移。
- 错误表现 → 同一 Connection ID 在多条路径同时发送；失败原因 → 违反路径关联规则并损害隐私；修正方法 → 每条发送路径使用未在其他路径使用的 ID。
- 错误表现 → 忽略
disableactivemigration；失败原因 → 对端明确禁止主动换本地地址；修正方法 → 仅在 preferred address 等协议条件满足时迁移。
追问及应对
如果新路径验证一直失败，连接会怎样？
失败只说明新路径不可用；仍有旧路径时继续使用旧路径。若没有任何有效路径，可以等待新路径、报告不可用并关闭，或由应用层重新建立会话。不要把一次 PATH_RESPONSE 超时直接等同于数据丢失。
为什么要准备多个 Connection ID？
迁移或路径探测时需要未使用过的 ID；如果 ID 池耗尽，端点既不能安全探测新路径，也无法正确响应对端迁移。服务端应按 activeconnectionid_limit 补充 ID。
迁移怎样降低可关联性？
在新路径换用新的 Connection ID，并通过头部保护避免直接用包号关联；但时序、包大小等流量特征仍可能被观察者关联，不能声称完全匿名。
迁移是否保留拥塞窗口？
实现可以根据路径变化重置或调整拥塞控制状态，因为新路径容量未知。换地址应节制，探测成功后重新估计可用带宽；应用层只应依赖传输层最终交付，不假设瞬时吞吐不变。