通用面试：QUIC 连接迁移如何跨网络保持连接？

题干与适用场景

移动客户端正在下载或保持长连接，网络从 Wi-Fi 切到蜂窝网络，源 IP 和 UDP 端口发生变化。请解释 QUIC 如何识别仍是同一连接、如何验证新路径，以及什么时候必须重连。范围限定在 QUIC v1 传输层；应用层重试、HTTP 会话恢复和 0-RTT 复用单独说明，不能把它们混成“迁移自动成功”。

面试官考察点

强回答会区分四元组和 QUIC Connection ID：地址变化不必然意味着连接状态丢失，但新路径必须验证。面试官会追问握手尚未确认、对端设置 disableactivemigration、NAT 重绑定、连接 ID 耗尽、服务器 preferred address，以及 0-RTT 的重放风险。只说“UDP 不连接所以能切换”说明没有理解 QUIC 的状态和安全边界。

回答前需要澄清的问题

1. 是客户端主动切网还是 NAT 被动换端口？ 主动迁移和 NAT 重绑定的触发与验证路径不同。
2. 握手是否已确认？ QUIC v1 在握手确认前不能主动迁移，必须继续使用原地址。
3. 对端是否禁用了主动迁移？ 收到 disableactivemigration 后，不能从新本地地址主动发包，除非使用服务器声明的 preferred address。
4. 连接 ID 是否为零长度？ 零长度 ID 无法用新的 ID 隔离路径，隐私和多路径路由能力更弱。
5. 应用能否接受短暂无数据？ 若旧路径失效且新路径验证失败，只能等待、关闭连接或由应用重建会话。

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，并通过头部保护避免直接用包号关联；但时序、包大小等流量特征仍可能被观察者关联，不能声称完全匿名。

迁移是否保留拥塞窗口？

实现可以根据路径变化重置或调整拥塞控制状态，因为新路径容量未知。换地址应节制，探测成功后重新估计可用带宽；应用层只应依赖传输层最终交付，不假设瞬时吞吐不变。