题干与适用场景
移动客户端正在下载大文件，网络从 Wi-Fi 切换到蜂窝网络，源 IP 和 UDP 端口发生变化。请解释 QUIC connection migration 如何识别同一连接、何时允许迁移、如何验证新路径，以及验证失败时如何保护连接和服务端资源。
面试官考察什么
- 能否区分连接标识与网络地址，不把四元组变化等同于新连接。
- 能否说明握手确认、路径验证、
PATH_CHALLENGE和PATH_RESPONSE的先后关系。 - 能否处理 NAT rebinding、Connection ID 耗尽、服务器禁用迁移和异常流量。
- 能否讨论迁移对隐私、拥塞控制、计费和观测的影响。
回答前要澄清的问题
- 是客户端主动切换网络，还是 NAT 只改变了外部端口？
- 连接是否已经完成握手，服务端是否设置了
disable_active_migration？ - 业务能否接受短暂重传和路径探测开销？
- 是否需要减少不同网络地址之间的可关联性？
- 新路径验证失败时，是继续旧路径还是重新建立连接？
30 秒回答框架
QUIC 用 Connection ID 关联连接状态，而不是依赖源 IP 和端口不变。握手确认后，客户端从新地址发送探测包，服务端用 PATH_CHALLENGE 和 PATH_RESPONSE 验证可达性；验证成功才发送普通数据。NAT rebinding 可在现有连接上处理，但主动迁移受 transport parameter 限制。新路径失败时保留旧路径或重新建连，并限制未验证地址的状态和放大风险。
分步骤深入解答
第一步：区分连接状态与地址
TLS、流和拥塞控制状态属于 QUIC 连接，IP 地址和 UDP 端口只是路径属性。Connection ID 让服务端在地址变化后仍能找到连接状态；没有合适的非零长度 ID 时，迁移和路径探测能力会受限。负载均衡器也必须按 Connection ID 路由，而不能只按五元组哈希。
第二步：确认迁移时机
端点在握手确认前不能主动迁移。客户端发现本地地址变化后，可在新路径上发送探测；若服务端声明 disable_active_migration，客户端不能主动从不同地址发送普通数据，除非使用服务器提供的 preferred address。这个限制避免把握手期间的地址变化当成已验证路径。
第三步：执行路径验证
新地址先发送只含探测帧的包，服务端回送 PATH_RESPONSE。验证成功表示对端能收到并返回路径上的包；失败只说明该路径不可用，不应立即终止仍有有效路径的连接。实现要设置探测超时、重试上限和未验证路径的资源预算。
第四步：处理 NAT rebinding
NAT 可能在连接空闲后更换客户端外部端口，服务端看到地址变化但仍收到带有效 Connection ID 的包。应先验证新路径，再更新路径状态；不能要求客户端每次端口变化都重新握手。对异常频繁变化设置速率和状态上限，避免攻击者消耗探测资源。
第五步：保护拥塞与放大边界
迁移后继续使用旧的拥塞控制上下文可能不适合新路径；实现应按协议和测量结果处理拥塞窗口、丢包和 RTT。服务端不能向未验证地址发送大量非探测数据，避免 UDP 放大。新路径验证期间保留旧路径，直到新路径具备可用性证据。
第六步：考虑隐私与可关联性
同一个 Connection ID 让服务端关联地址变化，但观察者也可能据此关联用户活动。客户端可更换新的 Connection ID，并避免频繁或可预测的地址切换；服务端应遵守连接 ID 生命周期和加密要求，不能把公开 ID 当作用户身份。
第七步：定义回退和观测
记录路径验证成功率、探测 RTT、迁移中断时间、旧路径保活、Connection ID 余量、丢包和重新建连比例。验证失败时继续旧路径并指数退避；旧路径不可用且无验证新路径时，关闭连接或重新握手。演练 Wi-Fi 切换、NAT rebinding、服务端禁用迁移和恶意探测。
高质量示范回答
我会把 QUIC 连接状态与地址路径分开处理：Connection ID 让服务端在客户端 IP 或端口变化后识别同一连接。握手确认后，客户端从新地址发送 PATH_CHALLENGE，收到 PATH_RESPONSE 才把新路径标记为可用；验证期间继续使用旧路径并限制未验证地址的状态和发送量。NAT rebinding 可沿用连接，但要验证新端口；若服务端设置 disable_active_migration，客户端不能主动迁移。连接 ID 要由负载均衡器支持，隐私场景更换 ID 并避免可预测关联。监控验证成功率、切换中断、探测 RTT、丢包和重连，失败时回退旧路径或重新建连。
常见错误
- 把 QUIC 连接绑定到源 IP 和端口，网络切换就直接新建连接。
- 在握手未确认时主动迁移，或跳过路径验证直接发送大量数据。
- 把 NAT rebinding 当成协议异常，要求每次端口变化都重新握手。
- 忽略
disable_active_migration和服务器 preferred address 的限制。 - 迁移后无视新路径 RTT、丢包和拥塞窗口，继续假设旧网络条件。
- 复用可预测 Connection ID，或让负载均衡器只按五元组路由。
追问及应对
追问一：为什么不能只看 Connection ID 就信任新路径？
Connection ID 关联连接，但不能证明新地址上的对端可达。路径挑战和响应用于验证返回路径，避免向伪造地址发送数据。
追问二：验证失败会破坏连接吗？
不会，只要旧路径仍有效。失败表示新路径不可用，端点应回退或继续探测；只有没有任何可用路径时才关闭或重建连接。
追问三：服务器为什么要限制未验证地址的发送？
攻击者可能伪造源地址诱导服务器放大流量。未验证路径只允许有限探测和受控状态，验证成功后才提高发送预算。
追问四：迁移后拥塞窗口是否必须清零？
不能只凭地址变化做固定结论。新路径的 RTT、带宽和丢包可能不同，实现应遵循 QUIC 恢复机制并以测量校准，避免过度发送或过度保守。
追问五：如何减少网络观察者的关联？
使用新的 Connection ID、合理轮换并避免可预测模式；同时仍需满足服务端路由和连接状态管理，不能把 ID 当作身份凭证。
追问六：负载均衡器要改什么？
它必须根据加密后的 Connection ID 或专用路由机制把迁移前后的包送到同一连接状态所在的服务端，不能假设地址变化代表新会话。