百度App网络深度优化系列(番外篇):IPv6下Happy Eyeballs的最佳实践

一、前言

IPv6是当下如火如荼的话题,由于IPv4地址的耗尽,所以IPv6的切换已经势在必行。但在IPv6的初期,由于基础建设还不完善,IPv6可能会出现连通性或可靠性的问题,那我们该如何从IPv4平稳过渡到IPv6呢?

目前业内标准的做法叫Happy Eyeballs,什么叫Happy Eyeballs呢?就是不会因为IPv4或IPv6的故障问题,导致用户的眼球一直在等待加载或者出错,这就是Happy Eyeballs名字的由来。

二、背景

Happy Eyeballs解决的核心问题是,复杂环境下v4和v6 IP选取的问题,它是一套整体解决方案,对于域名查询的处理,地址的排序,连接的尝试等方面均做出了规定。

Happy Eyeballs有v1版本RFC6555(Cisco提出来的)和v2版本RFC8305(Apple提出来的)。具体的协议规范可参考资料【1】和【2】。我们从百度App对于Happy Eyeballs的实践出发,剖析下百度App是如何实现Happy Eyeballs的。

三、最佳实践

百度App的Happy Eyeballs最佳实践,如下图所示。

Happy Eyeballs最佳实践

最佳实践包括自有业务和核心组件(图片组件,音视频组件,WebView组件)底层网络库的流量接管。

网络库包括FFmpeg的网络模块(实现了RFC8305的Happy Eyeballs),okhttp(实现了RFC6555的Happy Eyeballs),统一网络库cronet(实现了RFC6555的Happy Eyeballs)。下面我们来看下这三个网络库的Happy Eyeballs的实现机制。

1.FFmpeg的Happy Eyeballs实现机制

我们从域名查询的处理、地址的排序、连接的尝试三个方面来说明。

FFmpeg Happy Eyeballs实现机制

域名查询的处理,FFmpeg主要流量走的是localDNS,会将v4和v6地址一并查询回来,DNS query中A记录表示v4查询,Type是1,AAAA记录表示v6查询,Type是28。具体协议可以参考下面两图。

IPv4的Query

IPv6的Query

地址的排序,如果查询回来是多个v4和v6的地址,会将查询结果保存在addrinfo这个结构体里,它是一个链表结构,会将这个链表交替排序,v6在前,v4在后,比如查询回来的是[第一个v4地址,第二个v4地址,第一个v6地址,第二个v6地址],排序之后变成[第一个v6地址,第一个v4地址,第二个v6地址,第二个v4地址]。

连接的尝试,立即连接v6地址,FFmpeg可以让使用者设置连接超时时间,会将这个超时时间和200ms(这是RFC8305建议的值)进行取小操作,如果在较小值以内v6建连成功,则结束,若以外将发起下一个v4连接,与此同时关闭当前的v6连接。延迟发送的v4连接将重复上面的操作,如果成功则结束,如果超时将发起下一个v6连接,与此同时关闭当前的v4连接。直到没有ip地址。

2.cronet的Happy Eyeballs实现机制

我们从域名查询的处理、地址的排序、连接的尝试三个方面来说明。

cronet Happy Eyeballs实现机制

域名查询的处理,百度App的cronet主要流量走的是HTTPDNS,HTTPDNS请求会将一个域名的v4地址和v6地址同时返回。

地址的排序,cronet开启Happy Eyeballs有两个条件,一是查询结果第一个地址是v6的,二是查询结果里包含v4和v6的地址。cronet会优先将v6地址放入结果列表,保证了第一点。

连接的尝试,立即连接v6地址并开启一个延迟300ms(这是RFC6555建议的值)发起v4的建连任务,如果在300ms以内v6建连成功,延迟任务直接终止,流程结束。若以外会将结果列表进行rotate,按顺序将列表里的第一个v4地址旋转到第一个,发起v4连接,此时将开启一个竞争模式,当v4开始建立连接和建连成功后,都会去检查v6是否成功,只要v6在竞争模式内建连成功,则使用v6的连接,v6没有建连成功,则使用v4连接。

3.okhttp的Happy Eyeballs实现机制

okhttp Happy Eyeballs实现机制

百度App依照cronet的实现细节,遵循RFC6555的规范,实现了okhttp版本的Happy Eyeballs,由于实现细节和cronet类似,所以就不在这里进行讲解。主体流程如上图,通过okhttp的请求并发控制模块(核心定义了最大线程数64个和单域名的最大并发数5个),再来到核心拦截器模块,包括对于Header和Cookie处理的拦截器,对于Cache处理的拦截器,对于连接处理的拦截器,在连接处理的拦截器里首先是从连接池获取连接,获取不到就会新创建连接,Happy Eyeballs的实现就会加到这里。

4.WKWebView的Happy Eyeballs实现

在某些场景下WKWebView没有被cronet网络库进行接管,所以还需要依赖苹果自身的Happy Eyeballs机制,在这里就不多赘,感兴趣的同学可以参考资料【3】,苹果的工程师会详细讲解如何实现Happy Eyeballs的机制以及Happy Eyeballs下走v6的测试结果。

四、结语

IPv6的进程是任重而道远的,Happy Eyeballs做为从v4过渡到v6的重要规范必然会起到它应有的使命,详尽了解它并使用它应该是每个相关工程师的职责,希望本次番外篇对大家有帮助,感谢大家的辛苦阅读。

参考资料

[1]https://tools.ietf.org/html/rfc6555

[2]https://tools.ietf.org/html/rfc8305

[3]https://mailarchive.ietf.org/arch/msg/v6ops/DYiI9v_O66RNbMJsx0NsatFkubQ

[4]https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/9b4c3f5aadf54ffd2a6e15746b1fd736379883c4

作者介绍:

蔡锐,9 年移动端开发经验,在百度先后主导过订制 ROM 领域、多屏互动领域、Hybrid 跨平台领域等多个技术领域的开发,目前担任百度 App 的客户端资深工程师,参与基础技术的研究,专攻动态化、性能和网络优化方向。获得2019软件绿色联盟最佳人气讲师、2019ArchSummit大前端专题明星讲师。

相关文章:

百度App网络深度优化系列(一):DNS优化

百度App网络深度优化系列(二):连接优化

百度App网络深度优化系列(三):弱网优化

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章