摘要

  • Happy Eyeballs 通过重叠候选连接减少用户可见延迟；胜者只证明自身可达。
  • A/AAAA 到达、候选排序、启动时间、失败和取消原因都应按地址族保存。
  • 应用成功与双栈健康是两种不同的运营结论。

以一个示例场景为例：客户端得到 AAAA 和 A 应答后先启动 IPv6，再启动 IPv4，最终 IPv4 率先完成，页面也正常打开。用户没有感到中断，只统计成功会话的看板也保持绿色。然而 IPv6 可能遇到路径或服务问题，也可能只是在来得及回答之前被取消。胜出的连接无法说明是哪一种情况。

RFC 8305 规定了一套可能产生这种观测歧义的竞速行为：A 与 AAAA 解析异步进行，目的地址按 RFC 6724 排序并交错两个地址族，连接尝试按受控间隔启动；一个尝试成功后，其余尝试取消。本文的编辑分析认为，这种机制可以保护可用性，因为故障候选不必把完整超时转嫁给用户。

但在 IPv4 胜出后标记为“已取消”的 IPv6，既不是成功，也未必是失败，而是被竞速结果截断的证据。IPv4 胜出也不等于策略偏好 IPv4；DNS 应答顺序、RFC 6724 排序和历史往返时间都会改变竞速结果。

常见的 250 毫秒也不是通用服务目标。RFC 8305 只把它列为连接尝试间隔的一个推荐默认值，允许自适应并规定安全边界；它还区别了 A 先于 AAAA 到达时使用的解析等待。因此有效回执应记录实际参数和时间戳，而不是一个“已启用”开关。

标准专门把“隐藏运营问题”列为限制。正确做法不是关闭竞速，而是在不拖慢用户的前提下观测落败路径。每次连接应保留网络环境、解析器路径、A/AAAA 到达时间、候选顺序、地址族、配置的 Resolution Delay、配置或自适应后的 Connection Attempt Delay、实际启动偏移、握手里程碑、每次尝试的结果、应用结果、取消原因、胜者，以及算法所用缓存连接历史的网络适用范围和有效期。作为本文的运营建议，这些证据应在限定期限内聚合，而不应形成永久的个人浏览记录。

RFC 6555 最初针对损坏 IPv6 带来的等待；RFC 8305 改进了补救办法。两者都没有把一次被救回的会话定义为落败地址族的健康证书。RFC 6724 同样描述选择政策，而非可达性探测结果。