DNS如何优化-百度APP移动端网络深度优化分享
发布时间：2025-07-30 点击：7
本文由百度技术团队“蔡锐”原创发表于“百度app技术”公众号，原题为《百度app网络深度优化系列《一》dns优化》，感谢原作者的无私分享。
本系列文章目录如下：
《百度app移动端网络深度优化实践分享(一)：dns优化篇》（* 本文）
《百度app移动端网络深度优化实践分享(二)：网络连接优化篇》
《百度app移动端网络深度优化实践分享(三)：移动端弱网优化篇》
希望对大家在网络方向的学习和实践有所帮助。
百度起家于搜索，整个公司的网络架构和部署都是基于标准的internet协议，目前已经是全栈https，来到移动互联网时代后，总的基础架构不变，但在客户端上需要做很多优化工作。
dns（domain name system），它的作用是根据域名查出ip地址，它是http协议的前提，只有将域名正确的解析成ip地址后，后面的http流程才能进行，所以一般做网络优化会选优化dns。
（本文同步发布于：http://www.52im.net/thread-2472-1-1.html）
域名系统》
《全面了解移动端dns域名劫持等杂症：技术原理、问题根源、解决方案等》
《美图app的移动端dns优化实践：https请求耗时减小近半》
《现代移动端网络短连接的优化手段总结：请求速度、弱网适应、安全保障》
《移动端im开发者必读(一)：通俗易懂，理解移动网络的“弱”和“慢”》
《移动端im开发者必读(二)：史上最全移动弱网络优化方法总结》
dns优化核心需要解决的问题有两点：
1）由于dns劫持或故障造成的服务不可用，进而影响用户体验，影响公司的收入；
2）由于dns调度不准确导致的性能退化，进而影响用户体验。
百度app承载着亿级流量，每年都会遇到运营商dns劫持或运营商dns故障，整体影响非常不好，所以dns优化刻不容缓，通过下图会更直观的了解运营商劫持或故障的原理。
▲ 运营商劫持或故障的原理
有关移动端dns劫持等各种疑难杂症，详见文章《全面了解移动端dns域名劫持等杂症：技术原理、问题根源、解决方案等》。
4.1 概述
既然我们面临这么严峻的问题，那么我们如何优化dns呢？答案就是httpdns。
大部分标准dns都是基于udp与dns服务器交互的，httpdns则是利用http协议与dns服务器交互，绕开了运营商的local dns服务，有效防止了域名劫持，提高域名解析效率，下图是httpdns的原理。
▲ httpdns原理
百度app httpdns端上的实现是基于百度sys团队的httpdns服务，下图介绍了httpdns的服务端部署结构。
▲ httpdns部署结构
httpdns服务是基于bgp接入的，bgp英文border gateway protocol，即边界网关协议，是一种在自治系统之间动态的交换路由信息的路由协议，bgp可以根据当前用户的运营商路由到百度服务点的对应集群上，对于第三方域名，服务点会通过百度部署在运营商的cdn节点向其他域名权威dns发起查询，查询这个运营商下域名的最优ip。
百度app独立实现了端的httpdns sdk，下图介绍了端httpdns的整体架构。
▲ 端httpdns的整体架构
更多httpdns的资料，请见：《全面了解移动端dns域名劫持等杂症：技术原理、问题根源、解决方案等》、《美图app的移动端dns优化实践：https请求耗时减小近半》。
4.2 dns接口层
dns接口层解决的问题是屏蔽底层的细节，对外提供简单整洁的api，降低使用者的上手成本，提高开发效率。
4.3 dns策略层
dns策略层通过多种策略的组合，使httpdns服务在性能，稳定性，可用性上均保持较高的水准，下面讲解下每个策略设计的初衷和具体实现。
【4.3.1 容灾策略】：
这是一个非常关键的策略，主要解决httpdns服务可用性的问题，实践证明，这个策略帮助百度app在异常情况下挽救回很多流量。
（1）当httpdns服务不可用并且本地也没有缓存或者缓存失效的时候，会触发降级策略，降级成运营商的localdns方案，虽然存在运营商事故或者劫持的风险，但保障了dns服务的可用性。
（2）当httpdns服务和localdns服务双双不可用的情况下，会触发backup策略，使用端上的backup ip。
什么是backup ip？backup ip是多组根据域名分类的ip列表，可云端动态更新，方便后续运维同学调整服务端的节点ip，不是所有域名都有对应的backup ip列表，目前百度app只能保证核心域名的可用性。
既然是一组ip，便有选取问题，backup ip选取机制是怎样的呢？我们的中心思想就是要在端上利用最小的代价，并且考虑服务端的负载均衡，得到相对正确或者合理的选取结果。通过运营商和地理信息，可以选择一个相对较优的ip，但获取地理信息需要很大耗时，外加频次很高，代价很大，所以我们选择了rr算法来代替上面的方法（rr算法是round-robin，轮询调度），这样客户端的代价降低到最小，服务端也实现了负载均衡。
【4.3.2 安全策略】：
（1）httpdns解决的核心问题就是安全，标准的dns查询大部分是基于udp的，但也有基于tcp的，如果udp被封禁，就需要使用tcp。不管是udp还是tcp，安全性都是没有保障的，httpdns查询是基于标准的http协议，为了保证安全我们会在http上加一层tls（安全传输层协议），这便是https；
（2）解决了传输层协议的安全性后，我们要解决下域名解析的问题，上面我们提到httpdns服务是基于bgp接入的，在端上采用vip方式请求httpdns数据（vip即virtual ip，vip并没有与某设备存在必定的绑定关系，会跟随主备切换之类的情况发生而变换，vip提供的服务是对应到某一台或若干台服务器的），既然请求原始数据需要使用ip直连的方式，那么就摆脱了运营商localdns的解析限制，这样即使运营商出现了故障或者被劫持，都不会影响百度app的可用性。
【4.3.3 任务调度策略】：
httpdns服务提供了两类http接口，用于请求最优域名结果。第一种是多域名接口，针对不同的产品线，下发产品线配置的域名，第二种是单域名接口，只返回你要查询的那个域名结果，这样的设计和标准的dns查询基本是一样的，只不过是从udp协议变成了http协议。
（1）多域名接口会在app冷启动和网络切换的时候请求一次，目的是在app的网络环境初始化或者变化的时候预先获取域名结果，这样也会减少单域名接口的请求次数。
（2）单域名接口会在本地cache过期后，由用户的操作触发网络请求，进而做一次单域名请求，用户这次操作的dns结果会降级成localdns的结果，但在没有过期的情况下，下次会返回httpdns的结果。
【4.3.4 ip选取策略】：
ip选取策略解决的核心问题是最优ip的选取，避免因为接入点的选取错误造成的跨运营商耗时。httpdns服务会将最优ip按照顺序下发，客户端默认选取第一个，这里没有做客户端的连通性校验的原因，主要还是担心端上的性能问题，不过有容灾策略兜底，综合评估还是可以接受的。
【4.3.5 缓存策略】：
大家对于dns缓存并不陌生，它主要是为了提升访问效率，操作系统，网络库等都会做dns缓存。
dns缓存中一个重要的概念就是ttl（time-to-live），在localdns中针对不同的域名，ttl的时间是不一样的，在httpdns中这个值由服务端动态下发，百度app目前所有的域名ttl的配置是5分钟，过期后如果没有新的ip将继续沿用老的ip，当然也可以选择不沿用老的ip，而降级成localdns的ip，那么这就取决于localdns对于过期ip的处理。
【4.3.6 命中率策略】：
如果httpdns的命中率是100%，在保证httpdns服务稳定高效的前提下，我们就可以做到防劫持，提升精准调度的能力。
（1）为了提升httpdns的命中率，我们选择使用多域名接口，在冷启动和网络切换的时候，批量拉取域名结果并缓存在本地，便于接下来的请求使用。
（2）为了再一次提升httpdns的命中率，当用户操作触发网络请求，获取域名对应的ip时，会提前进行本地过期时间判断，时间是60s，如果过期，会发起单域名的请求并缓存起来，这样会持续延长域名结果的过期时间。本地过期时间与上面提到的ttl是客户端和服务端的双重过期时间，目的是在异常情况下可以双重保证过期时间的准确性。
4.4 基础能力层
基础能力层主要提供给dns策略层所需要的基础能力，包括ipv4/ipv6协议栈探测的能力，数据传输的能力，缓存实现的能力，下面将讲解每种能力的具体实现。
【4.4.1 ipv4/ipv6协议栈探测】：
百度app的ipv6改造正在如火如荼的进行中，端上在httpdns的ip选取上如何知道目前属于哪个协议栈成为关键性问题，并且这种判断要求性能极高，因为ip选取的频次实在是太高了。
我们选取的方案是udp connect，那么何为udp connect？
大家都知道tcp是面向连接的，传输数据前客户端都要调用connect方法通过三次握手建立连接，udp是面向无连接的，无需建立连接便能收发数据，但是如果我们调用了udp的connect方法会发生什么呢？当我们调用udp的connect方法时，系统会检测其端口是否可用，地址是否正确，然后记录对端的ip地址和端口号，返回给调用者，所以udp connect不会像tcp connect发起三次握手，发生网络真实损耗，udp客户端只有调用send或者sendto方法后才会真正发起真实网络损耗。
▲ udp connect原理
有了udp connect的基础保障，我们在上层做了缓存机制，用来减少系统调用的损耗，时机上目前仅在冷启动和网络切换会触发探测，在同一种网络制式下探测一次基本可以确保当前网络是ipv4栈还是ipv6栈。
目前百度app客户端对于ipv4/ipv6双栈的策略是保守的，仅在ipv6-only的情况下使用v6的ip，其余使用的都是v4的ip，双栈下的方案后续需要优化，业内目前标准的做法是happy eyeball算法。
什么叫happy eyeball呢？
就是不会因为ipv4或ipv6的故障问题，导致用户的眼球一直在等待加载或者出错，这就是happy eyeball名字的由来。happy eyeball有v1版本rfc6555和v2版本rfc8305，前者是cisco提出来的，后者是苹果提出来的。happy eyeball解决的核心问题是，复杂环境下v4和v6 ip选取的问题，它是一套整体解决方案，对于域名查询的处理，地址的排序，连接的尝试等方面均做出了规定，感兴趣的同学可以查看参考资料里的【5】和【6】。
【4.4.2 数据传输】：
数据传输主要提供网络请求的能力和数据解析的能力。
（1）网络请求失败重试的机制，获取httpdns结果的成功率会大大影响httpdns的命中率，所以客户端会有一个三次重试的机制，保障成功率。
（2）数据解析异常的机制，如果获取的httpdns的结果存在异常，将不会覆盖端上的缓存。
【4.4.3 缓存实现】：
缓存的实现基本可以分为磁盘缓存和内存缓存，对于httpdns的缓存场景，我们是选其一还是都选择呢？
百度app选择的是内存缓存，目的是防止我们自己的服务出现问题，运维同学在紧急情况下切换流量，如果做了磁盘缓存，会导致百度app在重启后也可能不可用，但这种问题会导致app在冷启动期间，httpdns结果未返回前，还是存在故障或者劫持的风险，综合评估来看可以接受，如果出现这种极端情况，影响的是冷启动阶段的一些请求，但只要httpdns结果返回后便会恢复正常。
httpdns在android网络架构的位置及实践：
百度app的android网络流量都在okhttp之上，上层进行了网络门面的封装，封装内部的实现细节和对外友好的api，供各个业务和基础模块使用，在okhttp上我们扩展了dns模块，使用httpdns替换了原有的系统dns。
▲ httpdns在android网络架构的位置
httpdns在ios网络架构的位置及实践：
百度app的ios网络流量都在cronet（chromium的net模块）之上，上层我们使用aop的方式将cronet stack注入进urlsession里，这样我们就可以直接使用urlsession的api进行网络的操作而且更易于系统维护。
在上层封装了网络门面，供各个业务和基础模块使用，在cronet内部我们修改了dns模块，除了原有的系统dns逻辑外，还添加了httpdns的逻辑。
ios上还有一部分流量是在原生urlsession上，主要是有些第三方业务没有使用cronet但还想单独使用httpdns的能力，所以就有了下面的httpdns封装层，方法是在上层直接将域名替换成ip，域名对于底层很多机制是至关重要的，比如https校验，cookie，重定向，sni（server name indication）等，所以将域名修改成了ip直连后，我们又处理了以上三种情况，保证请求的可用性。
▲ httpdns在ios网络架构的位置
dns优化的收益主要有两点：
1）防止dns的劫持（在出问题时显得尤为重要）；
2）降低网络时延（在调度不准确的情况下，会增大网络的时延，降低用户的体验）。
这两点收益需要结合业务来说，以百度app feed业务为例：
1）第一点上我们取得了比较大的效果，ios劫持率由0.12%降低到0.0002%，android劫持率由0.25%降低到0.05%；
2）第二点的收益不明显，原因在于feed业务主要目标群体在国内，百度在国内节点布局相对丰富，服务整体质量也较高，即使出现调度不准确的情况，差值也不会太大，但如果在国外情况可能会差很多。
1）基础知识要了解学习，要夯实：网络相关的内容很多，很杂，不易学习，啃过ietf发布的rfc的同学应该深有感触。
2）学会将看不见的网络变成看得见的：很多自认为对于网络很了解的同学，动不动就背诵tcp协议原理，拥塞控制算法，滑动窗口大小等，但真正遇到线上问题，无从下手。对于客户端同学，我们在pc上要学会使用tcpdump和wireshark等工具，适当使用fiddler和charles等工具，很多时候电脑和手机的网络环境不见得一致，所以要在手机上使用inettools，ping&dns或终端工具。学会使用工具后，要学着创造不同的网络环境，有很多工具能帮助你完成这点，比如苹果的network link conditioner，facebook的atc（augmented traffic control）等。具备以上两个场景后，你的第一条储备就发挥了作用，你要能看懂握手过程，传输过程，异常断开过程等。
3）有了以上两点的准备，接下来需要一个会出现各种网络问题的平台，给你积累经验，让一个个高压下的线上问题锤炼你，折磨你。
4）网络优化是需要数据支撑的：但数据的采集和分析是需要经验的，有些数据一眼看下去就是不靠谱的，有些数据怎么分析都是负向收益的，一般来说是有三重奏来对数据进行分析的，一，线下数据的采集和分析，得出正向收益，二，灰度数据的采集和分析，得出正向收益，三，线上数据的采集和分析，得出正向收益。
5）数据的正向收益，不能完全证明提升了用户的体验，所以很多时候需要针对特定场景，特定case来分析和优化，就算是大家公认做的很好的微信，也不是在所有场景下都能保证体验上的好。
[1] https://chromium.googlesource.com/chromium/src/+/head/docs/android_build_instructions.md
[2] https://chromium.googlesource.com/chromium/src/+/head/docs/ios/build_instructions.md
[3] https://github.com/tencent/mars
[4] https://tools.ietf.org/html/rfc7858
[5] https://tools.ietf.org/html/rfc6555
[6] https://tools.ietf.org/html/rfc8305
（原文链接：点此进入）
《tcp/ip详解 - 第11章·udp：用户数据报协议》
《tcp/ip详解 - 第17章·tcp：传输控制协议》
《tcp/ip详解 - 第18章·tcp连接的建立与终止》
《tcp/ip详解 - 第21章·tcp的超时与重传》
《技术往事：改变世界的tcp/ip协议（珍贵多图、手机慎点）》
《通俗易懂-深入理解tcp协议（上）：理论基础》
《通俗易懂-深入理解tcp协议（下）：rtt、滑动窗口、拥塞处理》
《理论经典：tcp协议的3次握手与4次挥手过程详解》
《理论联系实际：wireshark抓包分析tcp 3次握手、4次挥手过程》
《计算机网络通讯协议关系图（中文珍藏版）》
《udp中一个包的大小大能多大？》
《p2p技术详解(一)：nat详解——详细原理、p2p简介》
《p2p技术详解(二)：p2p中的nat穿越(打洞)方案详解》
《p2p技术详解(三)：p2p技术之stun、turn、ice详解》
《通俗易懂：快速理解p2p技术中的nat穿透原理》
《高性能网络编程(一)：单台服务器并发tcp连接数到底可以有多少》
《高性能网络编程(二)：上一个10年，著名的c10k并发连接问题》
《高性能网络编程(三)：下一个10年，是时候考虑c10m并发问题了》
《高性能网络编程(四)：从c10k到c10m高性能网络应用的理论探索》
《高性能网络编程(五)：一文读懂高性能网络编程中的i/o模型》
《高性能网络编程(六)：一文读懂高性能网络编程中的线程模型》
《不为人知的网络编程(一)：浅析tcp协议中的疑难杂症(上篇)》
《不为人知的网络编程(二)：浅析tcp协议中的疑难杂症(下篇)》
《不为人知的网络编程(三)：关闭tcp连接时为什么会time_wait、close_wait》
《不为人知的网络编程(四)：深入研究分析tcp的异常关闭》
《不为人知的网络编程(五)：udp的连接性和负载均衡》
《不为人知的网络编程(六)：深入地理解udp协议并用好它》
《不为人知的网络编程(七)：如何让不可靠的udp变的可靠？》
《不为人知的网络编程(八)：从数据传输层深度解密http》
《网络编程懒人入门(一)：快速理解网络通信协议（上篇）》
《网络编程懒人入门(二)：快速理解网络通信协议（下篇）》
《网络编程懒人入门(三)：快速理解tcp协议一篇就够》
《网络编程懒人入门(四)：快速理解tcp和udp的差异》
《网络编程懒人入门(五)：快速理解为什么说udp有时比tcp更有优势》
《网络编程懒人入门(六)：史上最通俗的集线器、交换机、路由器功能原理入门》
《网络编程懒人入门(七)：深入浅出，全面理解http协议》
《网络编程懒人入门(八)：手把手教你写基于tcp的socket长连接》
《网络编程懒人入门(九)：通俗讲解，有了ip地址，为何还要用mac地址？》
《技术扫盲：新一代基于udp的低延时网络传输层协议——quic详解》
《让互联网更快：新一代quic协议在腾讯的技术实践分享》
《现代移动端网络短连接的优化手段总结：请求速度、弱网适应、安全保障》
《聊聊ios中网络编程长连接的那些事》
《移动端im开发者必读(一)：通俗易懂，理解移动网络的“弱”和“慢”》
《移动端im开发者必读(二)：史上最全移动弱网络优化方法总结》
《ipv6技术详解：基本概念、应用现状、技术实践（上篇）》
《ipv6技术详解：基本概念、应用现状、技术实践（下篇）》
《从http/0.9到http/2：一文读懂http协议的历史演变和设计思路》
《脑残式网络编程入门(一)：跟着动画来学tcp三次握手和四次挥手》
《脑残式网络编程入门(二)：我们在读写socket时，究竟在读写什么？》
《脑残式网络编程入门(三)：http协议必知必会的一些知识》
《脑残式网络编程入门(四)：快速理解http/2的服务器推送(server push)》
《脑残式网络编程入门(五)：每天都在用的ping命令，它到底是什么？》
《脑残式网络编程入门(六)：什么是公网ip和内网ip？nat转换又是什么鬼？》
《以网游服务端的网络接入层设计为例，理解实时通信的技术挑战》
《迈向高阶：优秀android程序员必知必会的网络基础》
《全面了解移动端dns域名劫持等杂症：技术原理、问题根源、解决方案等》
《美图app的移动端dns优化实践：https请求耗时减小近半》
《android程序员必知必会的网络通信传输层协议——udp和tcp》
《im开发者的零基础通信技术入门(一)：通信交换技术的百年发展史(上)》
《im开发者的零基础通信技术入门(二)：通信交换技术的百年发展史(下)》
《im开发者的零基础通信技术入门(三)：国人通信方式的百年变迁》
《im开发者的零基础通信技术入门(四)：手机的演进，史上最全移动终端发展史》
《im开发者的零基础通信技术入门(五)：1g到5g，30年移动通信技术演进史》
《im开发者的零基础通信技术入门(六)：移动终端的接头人——“基站”技术》
《im开发者的零基础通信技术入门(七)：移动终端的千里马——“电磁波”》
《im开发者的零基础通信技术入门(八)：零基础，史上最强“天线”原理扫盲》
《im开发者的零基础通信技术入门(九)：无线通信网络的中枢——“核心网”》
《im开发者的零基础通信技术入门(十)：零基础，史上最强5g技术扫盲》
《im开发者的零基础通信技术入门(十一)：为什么wifi信号差？一文即懂！》
《im开发者的零基础通信技术入门(十二)：上网卡顿？网络掉线？一文即懂！》
《im开发者的零基础通信技术入门(十三)：为什么手机信号差？一文即懂！》
《im开发者的零基础通信技术入门(十四)：高铁上无线上网有多难？一文即懂！》
《im开发者的零基础通信技术入门(十五)：理解定位技术，一篇就够》
《百度app移动端网络深度优化实践分享(一)：dns优化篇》
《百度app移动端网络深度优化实践分享(二)：网络连接优化篇》
>> 更多同类文章 ……
（本文同步发布于：http://www.52im.net/thread-2472-1-1.html）
解答怎么提升seo转化的一个标准答案
常州网站建设_常州商城下单网站开发要有哪些功能？
建设网站要注意哪些细节
网站建设怎样建设企业网站呢？怎样进行域名注册？步骤介绍网站墟建设攻广州
企业应当要明白搜索引擎更喜欢什么样的网站建设？
网络推广的有效方式以及分类
如何运营微信公众号
合理的设计外贸网站
本系列文章目录如下：
《百度app移动端网络深度优化实践分享(一)：dns优化篇》（* 本文）
《百度app移动端网络深度优化实践分享(二)：网络连接优化篇》
《百度app移动端网络深度优化实践分享(三)：移动端弱网优化篇》
希望对大家在网络方向的学习和实践有所帮助。
百度起家于搜索，整个公司的网络架构和部署都是基于标准的internet协议，目前已经是全栈https，来到移动互联网时代后，总的基础架构不变，但在客户端上需要做很多优化工作。
dns（domain name system），它的作用是根据域名查出ip地址，它是http协议的前提，只有将域名正确的解析成ip地址后，后面的http流程才能进行，所以一般做网络优化会选优化dns。
（本文同步发布于：http://www.52im.net/thread-2472-1-1.html）
域名系统》
《全面了解移动端dns域名劫持等杂症：技术原理、问题根源、解决方案等》
《美图app的移动端dns优化实践：https请求耗时减小近半》
《现代移动端网络短连接的优化手段总结：请求速度、弱网适应、安全保障》
《移动端im开发者必读(一)：通俗易懂，理解移动网络的“弱”和“慢”》
《移动端im开发者必读(二)：史上最全移动弱网络优化方法总结》
dns优化核心需要解决的问题有两点：
1）由于dns劫持或故障造成的服务不可用，进而影响用户体验，影响公司的收入；
2）由于dns调度不准确导致的性能退化，进而影响用户体验。
百度app承载着亿级流量，每年都会遇到运营商dns劫持或运营商dns故障，整体影响非常不好，所以dns优化刻不容缓，通过下图会更直观的了解运营商劫持或故障的原理。
▲ 运营商劫持或故障的原理
有关移动端dns劫持等各种疑难杂症，详见文章《全面了解移动端dns域名劫持等杂症：技术原理、问题根源、解决方案等》。
4.1 概述
既然我们面临这么严峻的问题，那么我们如何优化dns呢？答案就是httpdns。
大部分标准dns都是基于udp与dns服务器交互的，httpdns则是利用http协议与dns服务器交互，绕开了运营商的local dns服务，有效防止了域名劫持，提高域名解析效率，下图是httpdns的原理。
▲ httpdns原理
百度app httpdns端上的实现是基于百度sys团队的httpdns服务，下图介绍了httpdns的服务端部署结构。
▲ httpdns部署结构
httpdns服务是基于bgp接入的，bgp英文border gateway protocol，即边界网关协议，是一种在自治系统之间动态的交换路由信息的路由协议，bgp可以根据当前用户的运营商路由到百度服务点的对应集群上，对于第三方域名，服务点会通过百度部署在运营商的cdn节点向其他域名权威dns发起查询，查询这个运营商下域名的最优ip。
百度app独立实现了端的httpdns sdk，下图介绍了端httpdns的整体架构。
▲ 端httpdns的整体架构
更多httpdns的资料，请见：《全面了解移动端dns域名劫持等杂症：技术原理、问题根源、解决方案等》、《美图app的移动端dns优化实践：https请求耗时减小近半》。
4.2 dns接口层
dns接口层解决的问题是屏蔽底层的细节，对外提供简单整洁的api，降低使用者的上手成本，提高开发效率。
4.3 dns策略层
dns策略层通过多种策略的组合，使httpdns服务在性能，稳定性，可用性上均保持较高的水准，下面讲解下每个策略设计的初衷和具体实现。
【4.3.1 容灾策略】：
这是一个非常关键的策略，主要解决httpdns服务可用性的问题，实践证明，这个策略帮助百度app在异常情况下挽救回很多流量。
（1）当httpdns服务不可用并且本地也没有缓存或者缓存失效的时候，会触发降级策略，降级成运营商的localdns方案，虽然存在运营商事故或者劫持的风险，但保障了dns服务的可用性。
（2）当httpdns服务和localdns服务双双不可用的情况下，会触发backup策略，使用端上的backup ip。
什么是backup ip？backup ip是多组根据域名分类的ip列表，可云端动态更新，方便后续运维同学调整服务端的节点ip，不是所有域名都有对应的backup ip列表，目前百度app只能保证核心域名的可用性。
既然是一组ip，便有选取问题，backup ip选取机制是怎样的呢？我们的中心思想就是要在端上利用最小的代价，并且考虑服务端的负载均衡，得到相对正确或者合理的选取结果。通过运营商和地理信息，可以选择一个相对较优的ip，但获取地理信息需要很大耗时，外加频次很高，代价很大，所以我们选择了rr算法来代替上面的方法（rr算法是round-robin，轮询调度），这样客户端的代价降低到最小，服务端也实现了负载均衡。
【4.3.2 安全策略】：
（1）httpdns解决的核心问题就是安全，标准的dns查询大部分是基于udp的，但也有基于tcp的，如果udp被封禁，就需要使用tcp。不管是udp还是tcp，安全性都是没有保障的，httpdns查询是基于标准的http协议，为了保证安全我们会在http上加一层tls（安全传输层协议），这便是https；
（2）解决了传输层协议的安全性后，我们要解决下域名解析的问题，上面我们提到httpdns服务是基于bgp接入的，在端上采用vip方式请求httpdns数据（vip即virtual ip，vip并没有与某设备存在必定的绑定关系，会跟随主备切换之类的情况发生而变换，vip提供的服务是对应到某一台或若干台服务器的），既然请求原始数据需要使用ip直连的方式，那么就摆脱了运营商localdns的解析限制，这样即使运营商出现了故障或者被劫持，都不会影响百度app的可用性。
【4.3.3 任务调度策略】：
httpdns服务提供了两类http接口，用于请求最优域名结果。第一种是多域名接口，针对不同的产品线，下发产品线配置的域名，第二种是单域名接口，只返回你要查询的那个域名结果，这样的设计和标准的dns查询基本是一样的，只不过是从udp协议变成了http协议。
（1）多域名接口会在app冷启动和网络切换的时候请求一次，目的是在app的网络环境初始化或者变化的时候预先获取域名结果，这样也会减少单域名接口的请求次数。
（2）单域名接口会在本地cache过期后，由用户的操作触发网络请求，进而做一次单域名请求，用户这次操作的dns结果会降级成localdns的结果，但在没有过期的情况下，下次会返回httpdns的结果。
【4.3.4 ip选取策略】：
ip选取策略解决的核心问题是最优ip的选取，避免因为接入点的选取错误造成的跨运营商耗时。httpdns服务会将最优ip按照顺序下发，客户端默认选取第一个，这里没有做客户端的连通性校验的原因，主要还是担心端上的性能问题，不过有容灾策略兜底，综合评估还是可以接受的。
【4.3.5 缓存策略】：
大家对于dns缓存并不陌生，它主要是为了提升访问效率，操作系统，网络库等都会做dns缓存。
dns缓存中一个重要的概念就是ttl（time-to-live），在localdns中针对不同的域名，ttl的时间是不一样的，在httpdns中这个值由服务端动态下发，百度app目前所有的域名ttl的配置是5分钟，过期后如果没有新的ip将继续沿用老的ip，当然也可以选择不沿用老的ip，而降级成localdns的ip，那么这就取决于localdns对于过期ip的处理。
【4.3.6 命中率策略】：
如果httpdns的命中率是100%，在保证httpdns服务稳定高效的前提下，我们就可以做到防劫持，提升精准调度的能力。
（1）为了提升httpdns的命中率，我们选择使用多域名接口，在冷启动和网络切换的时候，批量拉取域名结果并缓存在本地，便于接下来的请求使用。
（2）为了再一次提升httpdns的命中率，当用户操作触发网络请求，获取域名对应的ip时，会提前进行本地过期时间判断，时间是60s，如果过期，会发起单域名的请求并缓存起来，这样会持续延长域名结果的过期时间。本地过期时间与上面提到的ttl是客户端和服务端的双重过期时间，目的是在异常情况下可以双重保证过期时间的准确性。
4.4 基础能力层
基础能力层主要提供给dns策略层所需要的基础能力，包括ipv4/ipv6协议栈探测的能力，数据传输的能力，缓存实现的能力，下面将讲解每种能力的具体实现。
【4.4.1 ipv4/ipv6协议栈探测】：
百度app的ipv6改造正在如火如荼的进行中，端上在httpdns的ip选取上如何知道目前属于哪个协议栈成为关键性问题，并且这种判断要求性能极高，因为ip选取的频次实在是太高了。
我们选取的方案是udp connect，那么何为udp connect？
大家都知道tcp是面向连接的，传输数据前客户端都要调用connect方法通过三次握手建立连接，udp是面向无连接的，无需建立连接便能收发数据，但是如果我们调用了udp的connect方法会发生什么呢？当我们调用udp的connect方法时，系统会检测其端口是否可用，地址是否正确，然后记录对端的ip地址和端口号，返回给调用者，所以udp connect不会像tcp connect发起三次握手，发生网络真实损耗，udp客户端只有调用send或者sendto方法后才会真正发起真实网络损耗。
▲ udp connect原理
有了udp connect的基础保障，我们在上层做了缓存机制，用来减少系统调用的损耗，时机上目前仅在冷启动和网络切换会触发探测，在同一种网络制式下探测一次基本可以确保当前网络是ipv4栈还是ipv6栈。
目前百度app客户端对于ipv4/ipv6双栈的策略是保守的，仅在ipv6-only的情况下使用v6的ip，其余使用的都是v4的ip，双栈下的方案后续需要优化，业内目前标准的做法是happy eyeball算法。
什么叫happy eyeball呢？
就是不会因为ipv4或ipv6的故障问题，导致用户的眼球一直在等待加载或者出错，这就是happy eyeball名字的由来。happy eyeball有v1版本rfc6555和v2版本rfc8305，前者是cisco提出来的，后者是苹果提出来的。happy eyeball解决的核心问题是，复杂环境下v4和v6 ip选取的问题，它是一套整体解决方案，对于域名查询的处理，地址的排序，连接的尝试等方面均做出了规定，感兴趣的同学可以查看参考资料里的【5】和【6】。
【4.4.2 数据传输】：
数据传输主要提供网络请求的能力和数据解析的能力。
（1）网络请求失败重试的机制，获取httpdns结果的成功率会大大影响httpdns的命中率，所以客户端会有一个三次重试的机制，保障成功率。
（2）数据解析异常的机制，如果获取的httpdns的结果存在异常，将不会覆盖端上的缓存。
【4.4.3 缓存实现】：
缓存的实现基本可以分为磁盘缓存和内存缓存，对于httpdns的缓存场景，我们是选其一还是都选择呢？
百度app选择的是内存缓存，目的是防止我们自己的服务出现问题，运维同学在紧急情况下切换流量，如果做了磁盘缓存，会导致百度app在重启后也可能不可用，但这种问题会导致app在冷启动期间，httpdns结果未返回前，还是存在故障或者劫持的风险，综合评估来看可以接受，如果出现这种极端情况，影响的是冷启动阶段的一些请求，但只要httpdns结果返回后便会恢复正常。
httpdns在android网络架构的位置及实践：
百度app的android网络流量都在okhttp之上，上层进行了网络门面的封装，封装内部的实现细节和对外友好的api，供各个业务和基础模块使用，在okhttp上我们扩展了dns模块，使用httpdns替换了原有的系统dns。
▲ httpdns在android网络架构的位置
httpdns在ios网络架构的位置及实践：
百度app的ios网络流量都在cronet（chromium的net模块）之上，上层我们使用aop的方式将cronet stack注入进urlsession里，这样我们就可以直接使用urlsession的api进行网络的操作而且更易于系统维护。
在上层封装了网络门面，供各个业务和基础模块使用，在cronet内部我们修改了dns模块，除了原有的系统dns逻辑外，还添加了httpdns的逻辑。
ios上还有一部分流量是在原生urlsession上，主要是有些第三方业务没有使用cronet但还想单独使用httpdns的能力，所以就有了下面的httpdns封装层，方法是在上层直接将域名替换成ip，域名对于底层很多机制是至关重要的，比如https校验，cookie，重定向，sni（server name indication）等，所以将域名修改成了ip直连后，我们又处理了以上三种情况，保证请求的可用性。
▲ httpdns在ios网络架构的位置
dns优化的收益主要有两点：
1）防止dns的劫持（在出问题时显得尤为重要）；
2）降低网络时延（在调度不准确的情况下，会增大网络的时延，降低用户的体验）。
这两点收益需要结合业务来说，以百度app feed业务为例：
1）第一点上我们取得了比较大的效果，ios劫持率由0.12%降低到0.0002%，android劫持率由0.25%降低到0.05%；
2）第二点的收益不明显，原因在于feed业务主要目标群体在国内，百度在国内节点布局相对丰富，服务整体质量也较高，即使出现调度不准确的情况，差值也不会太大，但如果在国外情况可能会差很多。
1）基础知识要了解学习，要夯实：网络相关的内容很多，很杂，不易学习，啃过ietf发布的rfc的同学应该深有感触。
2）学会将看不见的网络变成看得见的：很多自认为对于网络很了解的同学，动不动就背诵tcp协议原理，拥塞控制算法，滑动窗口大小等，但真正遇到线上问题，无从下手。对于客户端同学，我们在pc上要学会使用tcpdump和wireshark等工具，适当使用fiddler和charles等工具，很多时候电脑和手机的网络环境不见得一致，所以要在手机上使用inettools，ping&dns或终端工具。学会使用工具后，要学着创造不同的网络环境，有很多工具能帮助你完成这点，比如苹果的network link conditioner，facebook的atc（augmented traffic control）等。具备以上两个场景后，你的第一条储备就发挥了作用，你要能看懂握手过程，传输过程，异常断开过程等。
3）有了以上两点的准备，接下来需要一个会出现各种网络问题的平台，给你积累经验，让一个个高压下的线上问题锤炼你，折磨你。
4）网络优化是需要数据支撑的：但数据的采集和分析是需要经验的，有些数据一眼看下去就是不靠谱的，有些数据怎么分析都是负向收益的，一般来说是有三重奏来对数据进行分析的，一，线下数据的采集和分析，得出正向收益，二，灰度数据的采集和分析，得出正向收益，三，线上数据的采集和分析，得出正向收益。
5）数据的正向收益，不能完全证明提升了用户的体验，所以很多时候需要针对特定场景，特定case来分析和优化，就算是大家公认做的很好的微信，也不是在所有场景下都能保证体验上的好。
[1] https://chromium.googlesource.com/chromium/src/+/head/docs/android_build_instructions.md
[2] https://chromium.googlesource.com/chromium/src/+/head/docs/ios/build_instructions.md
[3] https://github.com/tencent/mars
[4] https://tools.ietf.org/html/rfc7858
[5] https://tools.ietf.org/html/rfc6555
[6] https://tools.ietf.org/html/rfc8305
（原文链接：点此进入）
《tcp/ip详解 - 第11章·udp：用户数据报协议》
《tcp/ip详解 - 第17章·tcp：传输控制协议》
《tcp/ip详解 - 第18章·tcp连接的建立与终止》
《tcp/ip详解 - 第21章·tcp的超时与重传》
《技术往事：改变世界的tcp/ip协议（珍贵多图、手机慎点）》
《通俗易懂-深入理解tcp协议（上）：理论基础》
《通俗易懂-深入理解tcp协议（下）：rtt、滑动窗口、拥塞处理》
《理论经典：tcp协议的3次握手与4次挥手过程详解》
《理论联系实际：wireshark抓包分析tcp 3次握手、4次挥手过程》
《计算机网络通讯协议关系图（中文珍藏版）》
《udp中一个包的大小大能多大？》
《p2p技术详解(一)：nat详解——详细原理、p2p简介》
《p2p技术详解(二)：p2p中的nat穿越(打洞)方案详解》
《p2p技术详解(三)：p2p技术之stun、turn、ice详解》
《通俗易懂：快速理解p2p技术中的nat穿透原理》
《高性能网络编程(一)：单台服务器并发tcp连接数到底可以有多少》
《高性能网络编程(二)：上一个10年，著名的c10k并发连接问题》
《高性能网络编程(三)：下一个10年，是时候考虑c10m并发问题了》
《高性能网络编程(四)：从c10k到c10m高性能网络应用的理论探索》
《高性能网络编程(五)：一文读懂高性能网络编程中的i/o模型》
《高性能网络编程(六)：一文读懂高性能网络编程中的线程模型》
《不为人知的网络编程(一)：浅析tcp协议中的疑难杂症(上篇)》
《不为人知的网络编程(二)：浅析tcp协议中的疑难杂症(下篇)》
《不为人知的网络编程(三)：关闭tcp连接时为什么会time_wait、close_wait》
《不为人知的网络编程(四)：深入研究分析tcp的异常关闭》
《不为人知的网络编程(五)：udp的连接性和负载均衡》
《不为人知的网络编程(六)：深入地理解udp协议并用好它》
《不为人知的网络编程(七)：如何让不可靠的udp变的可靠？》
《不为人知的网络编程(八)：从数据传输层深度解密http》
《网络编程懒人入门(一)：快速理解网络通信协议（上篇）》
《网络编程懒人入门(二)：快速理解网络通信协议（下篇）》
《网络编程懒人入门(三)：快速理解tcp协议一篇就够》
《网络编程懒人入门(四)：快速理解tcp和udp的差异》
《网络编程懒人入门(五)：快速理解为什么说udp有时比tcp更有优势》
《网络编程懒人入门(六)：史上最通俗的集线器、交换机、路由器功能原理入门》
《网络编程懒人入门(七)：深入浅出，全面理解http协议》
《网络编程懒人入门(八)：手把手教你写基于tcp的socket长连接》
《网络编程懒人入门(九)：通俗讲解，有了ip地址，为何还要用mac地址？》
《技术扫盲：新一代基于udp的低延时网络传输层协议——quic详解》
《让互联网更快：新一代quic协议在腾讯的技术实践分享》
《现代移动端网络短连接的优化手段总结：请求速度、弱网适应、安全保障》
《聊聊ios中网络编程长连接的那些事》
《移动端im开发者必读(一)：通俗易懂，理解移动网络的“弱”和“慢”》
《移动端im开发者必读(二)：史上最全移动弱网络优化方法总结》
《ipv6技术详解：基本概念、应用现状、技术实践（上篇）》
《ipv6技术详解：基本概念、应用现状、技术实践（下篇）》
《从http/0.9到http/2：一文读懂http协议的历史演变和设计思路》
《脑残式网络编程入门(一)：跟着动画来学tcp三次握手和四次挥手》
《脑残式网络编程入门(二)：我们在读写socket时，究竟在读写什么？》
《脑残式网络编程入门(三)：http协议必知必会的一些知识》
《脑残式网络编程入门(四)：快速理解http/2的服务器推送(server push)》
《脑残式网络编程入门(五)：每天都在用的ping命令，它到底是什么？》
《脑残式网络编程入门(六)：什么是公网ip和内网ip？nat转换又是什么鬼？》
《以网游服务端的网络接入层设计为例，理解实时通信的技术挑战》
《迈向高阶：优秀android程序员必知必会的网络基础》
《全面了解移动端dns域名劫持等杂症：技术原理、问题根源、解决方案等》
《美图app的移动端dns优化实践：https请求耗时减小近半》
《android程序员必知必会的网络通信传输层协议——udp和tcp》
《im开发者的零基础通信技术入门(一)：通信交换技术的百年发展史(上)》
《im开发者的零基础通信技术入门(二)：通信交换技术的百年发展史(下)》
《im开发者的零基础通信技术入门(三)：国人通信方式的百年变迁》
《im开发者的零基础通信技术入门(四)：手机的演进，史上最全移动终端发展史》
《im开发者的零基础通信技术入门(五)：1g到5g，30年移动通信技术演进史》
《im开发者的零基础通信技术入门(六)：移动终端的接头人——“基站”技术》
《im开发者的零基础通信技术入门(七)：移动终端的千里马——“电磁波”》
《im开发者的零基础通信技术入门(八)：零基础，史上最强“天线”原理扫盲》
《im开发者的零基础通信技术入门(九)：无线通信网络的中枢——“核心网”》
《im开发者的零基础通信技术入门(十)：零基础，史上最强5g技术扫盲》
《im开发者的零基础通信技术入门(十一)：为什么wifi信号差？一文即懂！》
《im开发者的零基础通信技术入门(十二)：上网卡顿？网络掉线？一文即懂！》
《im开发者的零基础通信技术入门(十三)：为什么手机信号差？一文即懂！》
《im开发者的零基础通信技术入门(十四)：高铁上无线上网有多难？一文即懂！》
《im开发者的零基础通信技术入门(十五)：理解定位技术，一篇就够》
《百度app移动端网络深度优化实践分享(一)：dns优化篇》
《百度app移动端网络深度优化实践分享(二)：网络连接优化篇》
>> 更多同类文章 ……
（本文同步发布于：http://www.52im.net/thread-2472-1-1.html）
解答怎么提升seo转化的一个标准答案
常州网站建设_常州商城下单网站开发要有哪些功能？
建设网站要注意哪些细节
网站建设怎样建设企业网站呢？怎样进行域名注册？步骤介绍网站墟建设攻广州
企业应当要明白搜索引擎更喜欢什么样的网站建设？
网络推广的有效方式以及分类
如何运营微信公众号
合理的设计外贸网站
上一篇：SEO较新的优化心得