摘要

  • 匹配的 PATH_RESPONSE 验证对应 PATH_CHALLENGE 所走的路径，证据范围是特定的本地与对端 IP 地址、端口组合。
  • 新路径不会继承旧路径的容量或 RTT 证明；尺寸不足的探测还可能只验证地址而没有验证路径 MTU。
  • 运维应把“路径已验证”和“应用负载已就绪”分开记录，再用更完整的收据关联两者。

这盏绿灯只回答一个问题

RFC 9000 要求端点在 PATH_CHALLENGE 中放入不可预测的数据。对端必须在收到挑战的路径上，用 PATH_RESPONSE 原样返回这些数据。收到匹配响应后，发起方获得了一个明确结论：规定的验证交换已经穿过被测试的地址对。

这项机制很重要。它限制攻击者利用伪造源地址放大流量，也让连接在地址变化后保留连续性。但仪表盘常把窄结论扩大成“路径健康”。标准没有赋予它这样的含义。

如果反放大限制使挑战报文无法扩展到至少 1200 字节，响应仍可验证对端地址，但路径 MTU 仍未验证，端点必须再做一次更大报文的验证。即便 1200 字节通过，也只证明一个下限，不等于已经找到了长期可靠的最大报文尺寸。

迁移后的性能证据必须重新积累

连接带着加密身份和流状态迁移，却不能把旧网络的容量搬过去。RFC 9000 明确提醒：新路径可能无法承受当前发送速率。因此，除仅端口变化这一特定情形外，确认新地址后应把拥塞控制器与 RTT 估计器重置到初始值。

旧路径上的数据包不能参与新路径的拥塞控制或 RTT 估算；ECN 能力也要另行验证。协议本身已经把“能到达”与“能以原有条件运行”分开。

RFC 9002 描述了拥塞控制和丢失恢复如何持续吸收 ACK、时间和丢失证据。PATH_RESPONSE 回显的挑战数据不包含这些测量。因此，验证成功可以与较大数据报黑洞、不同排队行为、保守的初始拥塞窗口或应用超时同时存在。

来源