摘要

  • 2012 年的 RFC 6555 用一个跨地址族的短时竞赛解决双栈回退问题；2017 年的 RFC 8305 将其扩展为涵盖异步 DNS、目的地址排序、错峰连接和取消的完整调度器。
  • RFC 8305 推荐的 250 毫秒连接尝试延迟，是用户等待与网络冗余负载之间的定价参数，而不是固定不变的性能秘诀。
  • 竞赛能掩盖初始 TCP/IP 路径故障，却也可能削弱运维人员发现和修复故障的动力，并延长对稀缺 IPv4 资源的依赖。

双栈过渡最棘手的地方，不是主机没有两个选择，而是“正确的首选”可能给用户带来错误的体验。主机按照地址选择规则优先尝试 IPv6；一旦该路径缓慢或失效，明明可用的 IPv4 仍要等在后面。2012 年 4 月发布为 Proposed Standard 的 RFC 6555，把这段等待从用户面前移到了客户端内部。

它给出的示例很克制：保留主机原有的地址偏好顺序，先启动第一个连接；经过一个短暂间隔，再启动另一地址族中的第一个地址。当时 Firefox 和 Chrome 使用 300 毫秒。最先建立的连接被采用，另一个被丢弃。没有历史信息时仍然偏好 IPv6；规范同时提醒，实现不应在漫长过渡期里无谓地制造 IPv4 流量。

因此，计时器从一开始就是资源分配工具。等待太久，用户继续替失效的首选路径付费；等待太短，大量本可由第一次尝试完成的连接也会启动第二条线路，增加报文、套接字和服务器处理。客户端用额外负载购买尾部时延保险，而延迟参数就是保费。

规模部署后的经验说明，真实世界远不止“一条 IPv6 对一条 IPv4”。2017 年 12 月发布为 Proposed Standard 的 RFC 8305 废止了 RFC 6555，把流程拆成四个互相联动的阶段：异步发出 DNS 查询；对所有已解析目的地址排序；错开启动异步连接尝试；保留一个成功连接并取消其余尝试。

竞赛在发送连接报文以前已经开始。RFC 8305 建议先发 AAAA 查询，紧接着立即发 A 查询，而不是等前一个查询结束。若 A 先返回，推荐使用 50 毫秒的 Resolution Delay，给 AAAA 一个很短的到达窗口。这不是强迫客户端等待两份答案，也不是让最快 DNS 响应自动决定地址族。连接建立期间若出现新的答案，调度器还应能把新目的地址纳入候选。

排序阶段决定谁获得先手。目的地址选择规则提供基础顺序，实现可以参考同一网络上的历史往返时间或以往成功使用记录。不同地址族需要交错排列，避免一个地址族里连续多个坏地址占满整个尝试队列。历史也不能脱离网络上下文：办公室网络上的胜者，并不天然是移动网络上的胜者。

RFC 8305 推荐默认 Connection Attempt Delay 为 250 毫秒，推荐最小值为 100 毫秒，明确不得低于 10 毫秒，并推荐最大值为 2 秒；推荐的 First Address Family Count 是 1。这些数字来自经验测量，规范预期实现会随网络变化进行调整。较小延迟缩短失败回退的可见时间，却扩大并行尝试；较大延迟降低冗余负载，却放大首选路径出错时的用户等待。

新算法还处理多个地址、建立过程中的 DNS 答案变化、历史信息，以及使用 NAT64/DNS64 的纯 IPv6 网络。它的边界同样清楚：所处理的是最初的 TCP/IP 连接失败。传输连接成功，不等于应用层一定工作；它也不会修复刚刚输掉竞赛的路径。

这形成一个运维悖论。用户看到页面打开，于是认为网络正常；客户端知道首选路径败了，负责该路径的运营者却未必收到足够强的信号。RFC 6555 已承认竞赛会增加按地址族诊断故障的难度。RFC 8305 继续提醒，路径 MTU 等运行问题可能被另一条可用路径掩盖。整体可用性越好，部件故障有时反而越不显眼。

“快乐眼球”因而是一项兼容性交易：在保留 IPv6 偏好的同时，不强迫用户成为过渡期的故障测试员；IPv4 则继续扮演保险资产。保险会改变激励。若回退足够快，坏掉的 IPv6 带来的投诉更少；若 IPv4 经常取胜，应用和运营者就更有理由保留昂贵且稀缺的 IPv4 能力。调度器不能替行业结束这种依赖，只能把取舍落实为顺序、延迟、历史和可观测性。