文中由百度技术性精英团队“蔡锐”原創发布于“百度App技术性”微信公众号，原名为《百度App互联网深层优化系列产品《一》DNS优化》，谢谢创作者的不求回报共享。
互联网优化是手机客户端几大技术性方位中认可的一个深层行业，因此 百度App给大伙儿产生互联网深层优化系列产品文章内容。
本系列产品文章内容文件目录以下：
期待对大伙儿在互联网方位的学习培训和实践活动有一定的协助。
百度发家于检索，全部企业的网络结构和布署全是根据规范的internet协议书，现阶段早已是全栈开发HTTPS，赶到移动互联时期后，总的系统架构不会改变，但在手机客户端上必须做许多优化工作中。
DNS（Domain Name System），它的功效是依据域名查出来IP地址，它是HTTP协议书的前提条件，仅有将域名恰当的分析成IP地址后，后边的HTTP步骤才可以开展，因此 一般做互联网优化会优选优化DNS。
（文中同歩公布于：
《TCP/IP详细说明 卷1：协议书-第14章 DNS:域名系统软件》
《全方位掌握手机端DNS域名被劫持等杂症：技术性原理、难题根本原因、解决方法等》
《美图照片App的手机端DNS优化实践活动：HTTPS要求用时减少近半》
《当代手机端互联网短连接的优化方式小结：要求速率、弱网融入、安全防范措施》
《移动端IM开发者必读(一)：通俗易懂，理解移动网络的“弱”和“慢”》
《手机端IM开发人员必看(二)：史上*牛全挪动弱互联网优化方式 小结》
DNS优化关键必须处理的难题有二点：
1）因为DNS被劫持或常见故障导致的服务项目不能用，从而危害客户体验，危害企业的收益；
2）因为DNS生产调度不精确造成 的特性衰退，从而危害客户体验。
百度App安装着亿级总流量，每一年都是会碰到营运商DNS被劫持或营运商DNS常见故障，总体危害十分不太好，因此 DNS优化势在必行，根据下面的图会更形象化的掌握运营商劫持或常见故障的原理。
▲ 运营商劫持或常见故障的原理
相关手机端DNS被劫持等各种各样疑难病症，详细文章内容《全方位掌握手机端DNS域名被劫持等杂症：技术性原理、难题根本原因、解决方法等》。
即然大家遭遇那么不容乐观的难题，那麼大家怎样优化DNS呢？回答便是HTTPDNS。
绝大多数规范DNS全是根据UDP与DNS网络服务器互动的，HTTPDNS则是运用HTTP协议书与DNS网络服务器互动，避开了营运商的Local DNS服务项目，合理避免了域名被劫持，提升域名分析高效率，下面的图是HTTPDNS的原理。
▲ HTTPDNS原理
百度App HTTPDNS端上的完成是根据百度SYS精英团队的HTTPDNS服务项目，下面的图详细介绍了HTTPDNS的服务器端布署构造。
▲ HTTPDNS布署构造
HTTPDNS服务项目是根据BGP连接的，BGP英语Border Gateway Protocol，即界限网关ip协议书，是一种在自治系统中间动态性的互换路由器信息内容的ospf协议，BGP能够依据当今客户的营运商路由器到百度服务项目点的相匹配群集上，针对第三方域名，服务项目点会根据百度布署在营运商的CDN连接点向别的域名权威性DNS进行查看，查看这一营运商下域名的*优化IP。
百度App单独完成了端HTTPDNS SDK，下面的图详细介绍了端HTTPDNS的总体构架。
▲ 端HTTPDNS的总体构架
大量HTTPDNS的材料，请见：《全方位掌握手机端DNS域名被劫持等杂症：技术性原理、难题根本原因、解决方法等》、《美图照片App的手机端DNS优化实践活动：HTTPS要求用时减少近半》。
DNS插口层处理的难题是屏蔽掉*底层的关键点，对外开放出示简易干净整洁的API，减少使用人的入门成本费，提升开发设计高效率。
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选择体制是如何的呢？大家的主题思想便是要在端出运用*少的成本，而且考虑到服务器端的web服务，获得相对性恰当或是有效的选择結果。根据营运商和空间信息，能够挑选一个相对性较好的IP，但获得空间信息必须非常大用时，另加次数很高，成本非常大，因此 大家挑选了RR优化算法来替代上边的方式 （RR优化算法是Round-Robin，轮询生产调度），那样手机客户端的成本减少到*少，服务器端也完成了web服务。
【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的配备是五分钟，到期后要是没有新的IP将再次延用老的IP，自然还可以挑选不延用老的IP，而退级成localDNS的IP，那麼这就在于localDNS针对到期IP的解决。
【4.3.6 准确率对策】：
假如HTTPDNS的准确率是100%，在确保HTTPDNS服务项目平稳高效率的前提条件下，大家就可以保证防劫持，提高精确生产调度的能力。
（1）为了更好地提高HTTPDNS的准确率，大家挑选应用多域名插口，在冷启和互联网转换的情况下，大批量获取域名結果并缓存在当地，便于下面的要求应用。
（2）为了更好地再一次提高HTTPDNS的准确率，当客户实际操作开启互联网要求，获得域名相匹配的IP时，会提早开展当地到期時间分辨，时间60s，假如到期，会进行单域名的要求并缓存起來，那样会不断增加域名結果的到期時间。当地到期時间与上边提及的TTL是手机客户端和服务器端的双向到期時间，目地是在异常现象下能够双向确保到期時间的精确性。
基本能力层关键出示给DNS对策层所必须的基本能力，包含IPv4/IPv6tcp协议检测的能力，传输数据的能力，缓存完成的能力，下边将解读每个能力的实际完成。
【4.4.1 IPv4/IPv6tcp协议检测】：
百度App的IPv6更新改造已经热火朝天的进行中，端出在HTTPDNS的IP选择上如何知道现阶段归属于哪一个tcp协议变成至关重要难题，而且这类分辨规定特性极高，由于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明确提出来的，后面一种是iPhone明确提出来的。happy eyeball处理的关键难题是，繁杂自然环境下v4和v6 IP选择的难题，它是一套总体解决方法，针对域名查看的解决，详细地址的排列，联接的试着等层面均作出了要求，很感兴趣的同学们能够查询参考文献里的【5】和【6】。
【4.4.2 传输数据】：
传输数据关键出示互联网要求的能力和数据信息分析的能力。
（1）互联网要求不成功再试的体制，获得HTTPDNS結果的通过率会大大的危害HTTPDNS的准确率，因此 手机客户端会有一个三次再试的体制，确保通过率。
（2）数据信息分析出现异常的体制，假如获得的HTTPDNS的結果存有出现异常，将不容易遮盖端上的缓存。
【4.4.3 缓存完成】：
缓存的完成基础能够分成硬盘缓存和运行内存缓存，针对HTTPDNS的缓存情景，我们都是选其一還是都挑选呢？
百度App挑选的是运行内存缓存，目地是避免我们自己的服务项目发生难题，运维管理同学们在紧急状况下转换总流量，假如干了硬盘缓存，会造成 百度App在重新启动后也很有可能不能用，但这类难题会造成 APP在冷启期内，HTTPDNS結果未回到前，還是存有常见故障或是被劫持的风险性，综合性评定看来能够接纳，假如发生这类极端化状况，危害的是冷启环节的一些要求，但只需HTTPDNS結果回到后便会恢复过来。
百度App现阶段手机客户端网络结构因为历史时间缘故还未统一，但是大家正向着这一总体目标勤奋，下面着重介绍下HTTPDNS在Android和iOS网络架构中的位置及实践。
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业务主要目标群体在国内，百度在国内节点布局相对丰富，服务整体质量也较高，即使出现调度不准确的情况，差值也不会太大，但如果在国外情况可能会差很多。
DNS优化是个持续性的话题，上面介绍的百度App的一些经验和做法并不见得完美，但我们会持续深入的优化下去，为百度App的DNS能力保驾护航。*后感谢大家的辛苦阅读，希望对你有所帮助，后面会继续推出《百度APP移动端网络深度优化实践分享(二)：网络连接优化篇》，敬请期待。
做为一个工程师，如何才能做好网络优化这件事情，是个值得我们交流探讨的话题，个人认为应该从以下五方面入手。
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]
[2]
[3]
[4]
[5]
[6]
（原文链接：点此进入）
《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移动端网络深度优化实践分享(二)：网络连接优化篇》
>>更多同类文章 ……
（本文同步发布于：
