摘要

  • preferred_address 认证的是服务器为本连接提供的参数，不是客户端能够到达该地址的证明。
  • 握手确认后，客户端选择 IPv4 或 IPv6 地址，使用此前未用过的连接 ID，并在迁移前完成路径验证。
  • 路径验证、MTU、拥塞与 RTT、应用连续性和业务结果必须分别记录。

最容易发生的错误，是资产清单在客户端测试路径之前，就把服务器公布的 preferred address 标成“在线端点”。QUIC 允许服务器先在一个 IP 地址上接受连接，再在握手后不久提供另一个地址。初始地址可能由多个服务器共享，而单播地址可能适合提供更稳定的连接；但这一设计意图并不等于目标路径已经被测量。

只有服务器发送 preferred_address 传输参数，该参数随 TLS 握手传递。认证地收到它，说明本连接的对端提供了这些参数值。它不证明客户端可以到达所公布的 IPv4 或 IPv6 地址，不证明路径验证会成功，也不证明路径拥有可用 MTU、当前容量、未来可用性、应用连续性或业务成功。

参数可以携带 IPv4 地址和端口，也可以携带 IPv6 地址和端口。服务器可以用全零地址和端口省略一个地址族。这给客户端提供了适合其网络接入方式的选择，并不表示两个路径都已经从该客户端测试过。握手确认后，由客户端选择地址并启动路径验证；服务器不是迁移的发起者。客户端应使用 preferred_address 或 NEW_CONNECTION_ID 提供的、此前未使用的活动连接 ID。该替代 ID 的序号为 1，同时携带 16 字节 Stateless Reset Token。连接 ID 不与 preferred address 绑定，可以在任何路径上使用。

使用零长度连接 ID 的服务器不能提供 preferred address，而 preferred-address 参数也不能包含零长度连接 ID；违规属于 TRANSPORT_PARAMETER_ERROR。验证完成前，客户端不得向 preferred address 发送非探测帧，这限制了请求伪造暴露面。PATH_CHALLENGE 与 PATH_RESPONSE 是验证过程的一部分。即便之后验证成功，也不能把原先的公布倒推成一次测量。

验证成功后，客户端应使用新的连接 ID 向新服务器地址发送后续数据，并停止使用旧服务器地址。验证失败时，客户端必须继续向原始服务器 IP 发送。服务器还有独立的切换条件：它必须从 preferred address 向客户端探测，并继续从原地址发送非探测数据，直到收到客户端在 preferred address 上发送的非探测包且验证新路径。只有两个条件都满足后，服务器才专门从新地址发送非探测流量；它仍可能处理旧地址上迟到的数据包。

preferred address 只对提供它的连接有效，不能用于其他连接，包括恢复连接。disable_active_migration 不会禁止客户端响应对端提供的 preferred address。如果客户端先移动，它应从新的客户端地址同时验证原始和 preferred 服务器地址。不同的 NAT 绑定可能使服务器在 preferred address 看到不同的客户端源地址，此时服务器会执行迁移防欺骗措施，并向该源地址发起验证。

运营账本应分别记录：认证的参数接收；IPv4/IPv6 地址和端口，包括全零的缺失族；序号 1 连接 ID 的隐私安全摘要和 reset-token 引用；握手确认；客户端地址族及选择决定；实际使用且此前未使用的连接 ID；验证开始、证据、结果和放弃原因；客户端切换、原地址回退；服务器探测、服务器验证和首个非探测包；NAT 绑定变化；MTU；拥塞/RTT；应用连续性；业务结果。摘要和访问控制是运营建议，不是 QUIC 要求。

这一区分也不能与 TR-027 的迁移收敛、TR-040 的连接 ID 路由清单、TR-059 的接收上限与路径 MTU、TR-062 的已完成路径返回性证据、TR-047 的空闲超时边界混为一谈。一次已完成验证有明确而有限的含义；它不会让原始邀请变成保证。