一、背景

随着物联网的兴起，在万物互联的远景目标下，传统IPv4网络显得有些捉襟见肘。Internet的创始人之一文特.瑟夫曾说：“我觉得有点脸红，因为决定采用32位地址，并认为这足够满足Internet实验需求的那个家伙正式在下。我唯一想替自己做的辩解是，做出那个决定的时间是1977年，当时我以为那只不过是一场实验，可问题是这场试验根本就停不下来。”

IPv6网络的普及势不可挡，而从IPv4切换到IPv6，“就如同给一架正在飞行的飞机更换发动机”。IPv4和IPv6的并存必然是很长一段时间的状态。

那么问题来了，当IPv4和IPv6网络同时存在时，应用程序如何选择。假如优先选择其中一个，当所选的出现问题连接不上时，又该怎么办，有什么方法可以实现快速切换？在HappyEyeballs算法提出之前，传统的双栈交互方式如下：

图1

客户端优先发起IPv6请求，当未收到IPv6应答后，再发起IPv4的请求。可以看到，在等待IPv6的数据包返回期间（第8-10歩之间），会有一个延时，当IPv6连接超时后，才会执行第10歩的IPv4连接请求。这个延时会影响用户的体验。

同时我们可以看到，客户端在获取到域名的A和AAAA记录后，优先访问IPv6地址。这是由于IPv6是下一代互联网协议，为确保更大范围的推广，双栈环境优选IPv6，这样能最大限度的将IPv4流量向IPv6迁移。

双栈切换的延时问题不解决，用户对IPv6的体验将大打折扣，内容商和运营商都没有动力去推动IPv6的规模部署。为解决这一问题，2012年Cisco公司提出第一版HappyEyeballs算法【RFC6555】，2017年Apple公司提出第二版HappyEyeballs算法【RFC8305】。

二、第一版HappyEyeballs算法【RFC6555】

1、算法简介

1. 发送DNS请求A和AAAA记录，同时发起IPv6和IPv4连接请求。
2. 如果都有返回，优先选择使用IPv6进行连接，同时关闭IPv4的连接。

图2

1. 如果IPv6无返回，使用IPv4进行连接。

图3

2、存在的问题

以上算法能很好的解决双栈切换的延时问题。但是引入另一个问题：当大多数应用都支持IPv6时，并行发出的IPv4请求显得有些多余，在整个运营商大网内引入了非必要的IPv4流量，IPv4的流量不能大规模的降低。由于运营商投入的成本总体来说是一定的，如果IPv4的流量不能大规模减少，也就无法缩减IPv4的网络基础设施的投入，那也意味着无法投入更多成本到IPv6。

3、进一步优化

HappyEyeballs算法的本质是用更多带宽资源来确保双栈切换的延时足够低。如果在花费带宽资源和降低延时之间做到平衡是优化的主要思路。那就是在发送IPv6请求时，不同时发送IPv4请求，而是增加一个延时（上图第6-7歩之间）。在IPv6确实不可达后，才发送IPv4请求。根据用户对延时的直观感受，以及网络延时的经验，算法推荐的延时是150-250ms。应用终端在实现算法的时候，和这个值可能有些不同，如Firefox和Chrome浏览器使用的延时是300ms。

4、需要注意的几点

1）记录状态

在初始化某个TCP连接的时候，需要记录IPv6和IPv4地址的可用性并缓存。在缓存超时时间内，有访问相同的连接时，直接通过缓存的IP可用性来选择，不用重新按HappyEyeballs算法执行一遍。但如果缓存超时了，则需要重新执行一遍算法。推荐的缓存时间是10分钟。

2）网络重置

当网络重置时，比如Wifi热点更换、网卡重启等等，HappyEyeballs算法需要重新初始化一次。

三、第二版HappyEyeballs算法【RFC8305】

2012年第一版HappyEyeballs算法发布以后，经过几年有一定范围的应用。RFC8305是在第一版的基础上，进一步优化提升可靠性和通用性。算法主要分为DNS请求、地址排序和连接建立3个部分。

1、DNS请求

1）发送A和AAAA记录请求后，不能等2个解析应答全都到齐后再执行后面的连接操作。终端需要支持异步DNS API。如果不支持异步，需要用2个线程分别发送A和AAAA记录请求：

2）如果AAAA应答先到，则不等A应答，先执行IPv6的请求连接；

3）如果A应答先到，则等待一段时间（Resolution Delay），等AAAA应答到来。推荐的等待时间是50ms；

4）如果等待时间内，有效的AAAA应答到来，则客户端立即执行IPv6的请求连接；

5）如果在等待时间内收到无效的AAAA应答，或者没有收到应答，则客户端执行地址排序（sorting addresses），以及使用解析到的IPv4地址进行交错请求连接；

6）如果在连接建立阶段，但还未建立成功时，有效的AAAA应答到来，则解析到的IPv6地址会加入到可用地址列表中用于发起连接；

1. 同时存在IPv6和IPv4 DNS服务器的情况
2. 优先向IPv6 DNS服务器发送DNS请求
3. 如果没有收到IPv6 DNS服务器的应答，则将该DNS服务器设置低优先级，而向IPv4的DNS服务器发送请求。

2、地址排序

地址排序包含2部分：本协议簇地址排序、地址合并，最终生成地址列表。

1）本协议簇地址排序

A）在发起连接请求之前，先执行地址排序，将所有解析到的IPv6和IPv4地址加入到可用地址列表中并进行排序（包括多个A记录或者多个AAAA记录），之后按照一定的算法向这些地址发起连接请求（“连接建立”部分）。

B）如果客户端能记录连接状态，并且知道某个IP的历史连接平均响应时间，则选择选择时间更小的地址去建立连接。

C）如果客户端能记录曾经使用过的IP地址，则优先选择已经使用过的，而非未使用过的地址。这是因为保持相同地址的连接对应用交互更有利，不会经常改变连接的地址。

D）当网络状态发生变化时，如终端4G变Wifi等，客户端之前存储的历史信息和记录不能再使用，需要全部清掉。

1. 2）地址合并

A）协议簇交替方式：地址列表的顺序使用IPv6和IPv4协议簇交替的方式。如列表的第一个地址使用IPv6的第一个地址，那第二个地址则使用IPv4的第二个地址，这样交替排序。

1. 协议簇优先方式：将所有IPv6地址优先排在IPv4地址前面，即优先使用IPv6协议。

C）算法推荐使用第1种交替方式。他可避免当IPv6通道失效时，仍然反复的向多个IPv6地址发起连接，需要等待多个连接超时才改用IPv4连接，降低了延时。

D）考虑到有些应用可能选择第2种方式，所以算法推荐设定可配置的参数“优先协议簇地址数量”（First Address Family Count）。如count=1，则是第一种交替方式，count=2，则先排2个IPv6地址，再排2个IPv4地址，再排另外2个IPv6地址，以此类推。当count的数量较大时，多余每个协议簇包含的地址，则为第二种方式。

1. 3、连接建立：
2. 一次向一个地址发送连接请求，非并行，2个连接请求之间间隔一段时间。

2）一旦有连接建立（一般TCP三次握手建立），终止其他还未成功建立的连接，同样也不会发起未开始的连接。异步DNS请求也会终止，不会发送新的DNS请求。但是连接建立后一段时间之内（推荐1s）返回的DNS应答还是会去做解析，解析的结果可以用于以后使用。

3）地址列表中2个连接请求之间的间隔时间，推荐250ms。如果有历史响应时间的记录，此间隔时间可以微调。但间隔时间需要有最小值和最大值。最小值不应小于10ms，推荐100ms，以防在高丢包率网络下的数据包拥塞。最大值不应超过2s。

4）如果在建立连接的过程中，DNS解析结果和已经生成的地址列表有差异，则连接动作会有相应的调整：

A）如果已经向IP1发起了连接，但此时最新的DNS解析结果不包含IP1，则发起的连接会继续下去，不终止。

B）如果还未向IP1发起连接，但此时最新的DNS解析结果不包含IP1，则IP1会从地址列表删除

C）如果最新的DNS解析结果增加了IP2，则会将IP2添加到地址列表中。

四、两个版本的简单对比