1、引言

對(duì)于互聯(lián)網(wǎng)，域名是訪問(wèn)的第一跳，而這一跳很多時(shí)候會(huì)“失足”（尤其是移動(dòng)端網(wǎng)絡(luò)），導(dǎo)致訪問(wèn)錯(cuò)誤內(nèi)容、失敗連接等，讓用戶在互聯(lián)網(wǎng)上暢游的爽快瞬間消失。

而對(duì)于這關(guān)鍵的第一跳，包括鵝廠在內(nèi)的國(guó)內(nèi)互聯(lián)網(wǎng)大廠，都在持續(xù)深入地研究和思考對(duì)策，本文將就鵝廠團(tuán)隊(duì)在這一塊的技術(shù)實(shí)踐，做一個(gè)深度的總結(jié)和技術(shù)分享，希望給大家?guī)?lái)些許啟發(fā)。

學(xué)習(xí)交流：

- 即時(shí)通訊/推送技術(shù)開(kāi)發(fā)交流4群：101279154[推薦]

- 移動(dòng)端IM開(kāi)發(fā)入門(mén)文章：《新手入門(mén)一篇就夠：從零開(kāi)發(fā)移動(dòng)端IM》

（本文同步發(fā)布于：http://www.52im.net/thread-2121-1-1.html）

2、相關(guān)文章

《網(wǎng)絡(luò)編程懶人入門(mén)(一)：快速理解網(wǎng)絡(luò)通信協(xié)議（上篇）》

《網(wǎng)絡(luò)編程懶人入門(mén)(二)：快速理解網(wǎng)絡(luò)通信協(xié)議（下篇）》

《網(wǎng)絡(luò)編程懶人入門(mén)(六)：史上最通俗的集線器、交換機(jī)、路由器功能原理入門(mén)》

《網(wǎng)絡(luò)編程懶人入門(mén)(七)：深入淺出，全面理解HTTP協(xié)議》

《網(wǎng)絡(luò)編程懶人入門(mén)(九)：通俗講解，有了IP地址，為何還要用MAC地址？》

《技術(shù)掃盲：新一代基于UDP的低延時(shí)網(wǎng)絡(luò)傳輸層協(xié)議——QUIC詳解》

《現(xiàn)代移動(dòng)端網(wǎng)絡(luò)短連接的優(yōu)化手段總結(jié)：請(qǐng)求速度、弱網(wǎng)適應(yīng)、安全保障》

《移動(dòng)端IM開(kāi)發(fā)者必讀(一)：通俗易懂，理解移動(dòng)網(wǎng)絡(luò)的“弱”和“慢”》

《移動(dòng)端IM開(kāi)發(fā)者必讀(二)：史上最全移動(dòng)弱網(wǎng)絡(luò)優(yōu)化方法總結(jié)》

《腦殘式網(wǎng)絡(luò)編程入門(mén)(五)：每天都在用的Ping命令，它到底是什么？》

《腦殘式網(wǎng)絡(luò)編程入門(mén)(六)：什么是公網(wǎng)IP和內(nèi)網(wǎng)IP？NAT轉(zhuǎn)換又是什么鬼？》

3、正文概述

但凡使用域名來(lái)給用戶提供服務(wù)的互聯(lián)網(wǎng)企業(yè)，都或多或少地?zé)o法避免在有中國(guó)特色的互聯(lián)網(wǎng)環(huán)境中遭遇到各種域名被緩存、用戶跨網(wǎng)訪問(wèn)緩慢等問(wèn)題。那么對(duì)于騰訊這樣的域名數(shù)量在10萬(wàn)級(jí)別的互聯(lián)網(wǎng)公司來(lái)講，域名解析異常的情況到底有多嚴(yán)重呢？

每天騰訊的分布式域名解析監(jiān)測(cè)系統(tǒng)在不停地對(duì)全國(guó)所有的重點(diǎn)LocalDNS（指運(yùn)營(yíng)商的DNS服務(wù)）進(jìn)行探測(cè)，騰訊域名在全國(guó)各地的日解析異常量是已經(jīng)超過(guò)了80萬(wàn)條（這方面，來(lái)自移動(dòng)端的異常尤為突出）。這給騰訊的業(yè)務(wù)帶來(lái)了巨大的損失。為此騰訊建立了專業(yè)的團(tuán)隊(duì)與各個(gè)運(yùn)營(yíng)商進(jìn)行了深度溝通，但是由于各種原因，處理效率及效果均不能達(dá)到騰訊各業(yè)務(wù)部門(mén)的需求。

除了和運(yùn)營(yíng)商進(jìn)行溝通，有沒(méi)有一種技術(shù)上的方案，能從根源上解決域名解析異常及用戶訪問(wèn)跨網(wǎng)的問(wèn)題呢？這是包括騰訊在內(nèi)的很多國(guó)內(nèi)互聯(lián)網(wǎng)大廠技術(shù)團(tuán)隊(duì)一直在思考的問(wèn)題。

4、首先，什么是DNS？

要想理解本文將要討論的DNS各種問(wèn)題，我們需要首先來(lái)復(fù)習(xí)一下DNS的基本原理和相關(guān)知識(shí)。

4.1 DNS的工作原理

DNS（Domain Name System，域名系統(tǒng)），DNS 服務(wù)用于在網(wǎng)絡(luò)請(qǐng)求時(shí)，將域名轉(zhuǎn)為 IP 地址。能夠使用戶更方便的訪問(wèn)互聯(lián)網(wǎng)，而不用去記住能夠被機(jī)器直接讀取的 IP 數(shù)串。

DNS的基一原理如下圖所示：

傳統(tǒng)的基于 UDP 協(xié)議的公共 DNS 服務(wù)極易發(fā)生 DNS 劫持，從而造成安全問(wèn)題。

4.2 DNS 域名系統(tǒng)結(jié)構(gòu)

如上圖所示，典型DNS域名系統(tǒng)的結(jié)構(gòu)如下：

1）Root 域名：DNS 域名使用時(shí)，規(guī)定由尾部句號(hào)來(lái)指定名稱位于根或更高級(jí)別的域?qū)哟谓Y(jié)構(gòu)；

2）Top Level 頂級(jí)域名：用來(lái)指示某個(gè)國(guó)家、地區(qū)或組織使用的名稱的類型名稱。如 .net；

3）Second Level 域名：個(gè)人或組織在 Internet 上使用的注冊(cè)名稱。如 52im.net；

4）Third Level 域名：已注冊(cè)的二級(jí)域名派生的域名。如 docs.52im.net。

4.3 DNS 解析過(guò)程

如上圖所示，這是一個(gè)典型的域名解析過(guò)程：

1）瀏覽器中輸入 www.52im.net，發(fā)出解析請(qǐng)求；

2）本機(jī)的域名解析器 resolver 程序查詢本地緩存和 host 文件中是否為域名的映射關(guān)系，如果有則調(diào)用這個(gè) IP 地址映射，完成解析；

3）如果 hosts 與本地解析器緩存都沒(méi)有相應(yīng)的網(wǎng)址映射關(guān)系，則本地解析器會(huì)向 TCP/IP 參數(shù)中設(shè)置的首選 DNS 服務(wù)器（我們叫它 Local DNS 服務(wù)器）發(fā)起一個(gè)遞歸的查詢請(qǐng)求；

4）服務(wù)器收到查詢時(shí)，如果要查詢的域名由本機(jī)負(fù)責(zé)解析，則返回解析結(jié)果給客戶機(jī)，完成域名解析，此解析具有權(quán)威性。如果要查詢的域名，不由 Local DNS 服務(wù)器解析，但該服務(wù)器已緩存了此網(wǎng)址映射關(guān)系，則調(diào)用這個(gè) IP 地址映射，完成域名解析，此解析不具有權(quán)威性；

5）如果 Local DNS 服務(wù)器本地區(qū)域文件與緩存解析都失效，則根據(jù) Local DNS 服務(wù)器的設(shè)置（是否遞歸）進(jìn)行查詢，如果未用開(kāi)啟模式，Local DNS 就把請(qǐng)求發(fā)至13臺(tái) Root DNS。如果用的是遞歸模式，此 DNS 服務(wù)器就會(huì)把請(qǐng)求轉(zhuǎn)發(fā)至上一級(jí) DNS 服務(wù)器，由上一級(jí)服務(wù)器進(jìn)行解析，上一級(jí)服務(wù)器如果不能解析，或找根 DNS 或把轉(zhuǎn)請(qǐng)求轉(zhuǎn)至上上級(jí)，以此循環(huán)；

6）Root DNS 服務(wù)器收到請(qǐng)求后會(huì)判斷這個(gè)域名是誰(shuí)來(lái)授權(quán)管理，并會(huì)返回一個(gè)負(fù)責(zé)該頂級(jí)域名服務(wù)器的一個(gè) IP；

7）Local DNS 服務(wù)器收到 IP 信息后，將會(huì)聯(lián)系負(fù)責(zé) .net 域的這臺(tái)服務(wù)器；

8）負(fù)責(zé) .com 域的服務(wù)器收到請(qǐng)求后，如果自己無(wú)法解析，它就會(huì)找一個(gè)管理 .net 域的下一級(jí) DNS 服務(wù)器地址給本地 DNS 服務(wù)器；

9）當(dāng) Local DNS 服務(wù)器收到這個(gè)地址后，就會(huì)找 52im.net 域服務(wù)器，10、11重復(fù)上面的動(dòng)作，進(jìn)行查詢；

10）最后 www.52im.net 返回需要解析的域名的 IP 地址給 Local DNS 服務(wù)器；

11）Local DNS 服務(wù)器緩存這個(gè)解析結(jié)果（同時(shí)也會(huì)緩存，6、8、10返回的結(jié)果）；

12）Local DNS 服務(wù)器同時(shí)將結(jié)果返回給本機(jī)域名解析器；

13）本機(jī)緩存解析結(jié)果；

14）本機(jī)解析器將結(jié)果返回給瀏覽器；

15）瀏覽器通過(guò)返回的 IP 地址發(fā)起請(qǐng)求。

4.4 DNS的遞歸查詢和迭代查詢

遞歸查詢：如果主機(jī)所詢問(wèn)的本地域名服務(wù)器不知道被查詢域名的 IP 地址，那么本地域名服務(wù)器就以 DNS 客戶的身份，向其他根域名服務(wù)器繼續(xù)發(fā)出查詢請(qǐng)求報(bào)文，而不是讓該主機(jī)自己進(jìn)行下一步的查詢。

迭代查詢：當(dāng)根域名服務(wù)器收到本地域名服務(wù)器發(fā)出的迭代查詢請(qǐng)求報(bào)文時(shí)，要么給出所要查詢的 IP 地址，要么告訴本地域名服務(wù)器：你下一步應(yīng)當(dāng)向哪一個(gè)域名服務(wù)器進(jìn)行查詢。然后讓本地域名服務(wù)器進(jìn)行后續(xù)的查詢，而不是替本地域名服務(wù)器進(jìn)行后續(xù)的查詢。

由此可見(jiàn)，客戶端到 Local DNS 服務(wù)器，Local DNS 與上級(jí) DNS 服務(wù)器之間屬于遞歸查詢；DNS 服務(wù)器與根 DNS 服務(wù)器之前屬于迭代查詢。

實(shí)際環(huán)境中，因?yàn)椴捎眠f歸模式會(huì)導(dǎo)致 DNS 服務(wù)器流量很大，所以現(xiàn)在大多數(shù)的 DNS 都是迭代模式。

5、國(guó)內(nèi)移動(dòng)端網(wǎng)絡(luò)所面臨的各種DNS雜癥

總結(jié)下來(lái)，DNS的這些咋整主要的帶來(lái)了三類問(wèn)題：

1）LocalDNS劫持；

2）平均訪問(wèn)延遲下降；

3）用戶連接失敗率下降。

LocalDNS劫持: 由于HttpDNS是通過(guò)ip直接請(qǐng)求http獲取服務(wù)器A記錄地址，不存在向本地運(yùn)營(yíng)商詢問(wèn)domain解析過(guò)程，所以從根本避免了劫持問(wèn)題。 （對(duì)于http內(nèi)容tcp/ip層劫持，可以使用驗(yàn)證因子或者數(shù)據(jù)加密等方式來(lái)保證傳輸數(shù)據(jù)的可信度）

平均訪問(wèn)延遲下降: 由于是ip直接訪問(wèn)省掉了一次domain解析過(guò)程，（即使系統(tǒng)有緩存速度也會(huì)稍快一些‘毫秒級(jí)’）通過(guò)智能算法排序后找到最快節(jié)點(diǎn)進(jìn)行訪問(wèn)。

用戶連接失敗率下降: 通過(guò)算法降低以往失敗率過(guò)高的服務(wù)器排序，通過(guò)時(shí)間近期訪問(wèn)過(guò)的數(shù)據(jù)提高服務(wù)器排序，通過(guò)歷史訪問(wèn)成功記錄提高服務(wù)器排序。如果ip(a)訪問(wèn)錯(cuò)誤，在下一次返回ip(b)或者ip(c) 排序后的記錄。

那么，追根溯源，到底為什么會(huì)存在這些問(wèn)題？這就是下一節(jié)要討論的問(wèn)題。

6、追根溯源，國(guó)內(nèi)DNS問(wèn)題的根源是什么？

我們得先得了解下現(xiàn)在國(guó)內(nèi)各ISP運(yùn)營(yíng)商的LocalDNS的基本情況。

國(guó)內(nèi)運(yùn)營(yíng)商LocalDNS造成的這些問(wèn)題，可以歸為下以下3種原因：

1）域名緩存；

2）解析轉(zhuǎn)發(fā)；

3）LocalDNS遞歸出口NAT。

下面，我們來(lái)逐一分析。

6.1 域名緩存

域名緩存很好理解，就是LocalDNS緩存了騰訊的域名的解析結(jié)果，不向騰訊權(quán)威DNS發(fā)起遞歸。

示意圖如下：

為何LocalDNS要把域名解析結(jié)果進(jìn)行緩存呢？原因有以下幾個(gè)：

1）保證用戶訪問(wèn)流量在本網(wǎng)內(nèi)消化：國(guó)內(nèi)的各互聯(lián)網(wǎng)接入運(yùn)營(yíng)商的帶寬資源、網(wǎng)間結(jié)算費(fèi)用、IDC機(jī)房分布、網(wǎng)內(nèi)ICP資源分布等存在較大差異。為了保證網(wǎng)內(nèi)用戶的訪問(wèn)質(zhì)量，同時(shí)減少跨網(wǎng)結(jié)算，運(yùn)營(yíng)商在網(wǎng)內(nèi)搭建了內(nèi)容緩存服務(wù)器，通過(guò)把域名強(qiáng)行指向內(nèi)容緩存服務(wù)器的IP地址，就實(shí)現(xiàn)了把本地本網(wǎng)流量完全留在了本地的目的；

2）推送廣告：有部分LocalDNS會(huì)把部分域名解析結(jié)果的所指向的內(nèi)容緩存，并替換成第三方廣告聯(lián)盟的廣告。

以上類型的行為就是我們常說(shuō)的域名緩存，域名緩存會(huì)導(dǎo)致用戶產(chǎn)生以下的訪問(wèn)異常：

A、僅對(duì)80端口的http服務(wù)做了緩存，如果域名是通過(guò)https協(xié)議或其它端口提供服務(wù)的，用戶訪問(wèn)就會(huì)出現(xiàn)失敗。比如支付服務(wù)、游戲通過(guò)指定端口連接connect server服務(wù)等；

B、緩存服務(wù)器的運(yùn)維水平參差不齊，時(shí)有出現(xiàn)緩存服務(wù)器故障導(dǎo)致用戶訪問(wèn)異常的問(wèn)題。

6.2 解析轉(zhuǎn)發(fā)

除了域名緩存以外，運(yùn)營(yíng)商的LocalDNS還存在解析轉(zhuǎn)發(fā)的現(xiàn)象。解析轉(zhuǎn)發(fā)是指運(yùn)營(yíng)商自身不進(jìn)行域名遞歸解析，而是把域名解析請(qǐng)求轉(zhuǎn)發(fā)到其它運(yùn)營(yíng)商的遞歸DNS上的行為。

正常的LocalDNS遞歸解析過(guò)程是這樣的：

而部分小運(yùn)營(yíng)商為了節(jié)省資源，就直接將解析請(qǐng)求轉(zhuǎn)發(fā)到了其它運(yùn)營(yíng)的遞歸LocalDNS上去了：

這樣的直接后果就是騰訊權(quán)威DNS收到的域名解析請(qǐng)求的來(lái)源IP就成了其它運(yùn)營(yíng)商的IP，最終導(dǎo)致用戶流量被導(dǎo)向了錯(cuò)誤的IDC，用戶訪問(wèn)變慢。

6.3 LocalDNS遞歸出口NAT

LocalDNS遞歸出口NAT指的是運(yùn)營(yíng)商的LocalDNS按照標(biāo)準(zhǔn)的DNS協(xié)議進(jìn)行遞歸，但是因?yàn)樵诰W(wǎng)絡(luò)上存在多出口且配置了目標(biāo)路由NAT，結(jié)果導(dǎo)致LocalDNS最終進(jìn)行遞歸解析的時(shí)候的出口IP就有概率不為本網(wǎng)的IP地址。

如下圖所示：

這樣的直接后果就是GSLB DNS收到的域名解析請(qǐng)求的來(lái)源IP還是成了其它運(yùn)營(yíng)商的IP，最終導(dǎo)致用戶流量被導(dǎo)向了錯(cuò)誤的IDC，用戶訪問(wèn)變慢。

7、必須著手解決這些問(wèn)題，但傳統(tǒng)解決方案問(wèn)題太多

運(yùn)營(yíng)商的LocalDNS解析域名異常，給對(duì)用戶訪問(wèn)騰訊互聯(lián)網(wǎng)業(yè)務(wù)的體驗(yàn)造成了非常大的損害。

那么以前，我們是如何處理這些域名解析異常的問(wèn)題的呢？

1）實(shí)時(shí)監(jiān)控+商務(wù)推動(dòng)：

這種方案是目前騰訊的運(yùn)營(yíng)團(tuán)隊(duì)一直在使用的方案。這種方案就是周期比較長(zhǎng)，畢竟通過(guò)行政手段來(lái)推動(dòng)運(yùn)營(yíng)商來(lái)解決這個(gè)問(wèn)題是比較耗時(shí)的。另外我們通過(guò)大數(shù)據(jù)分析，得出的結(jié)論是Top 3的問(wèn)題用戶均為移動(dòng)互聯(lián)網(wǎng)用戶。對(duì)于這部分用戶，我們有什么技術(shù)手段可以解決以上的問(wèn)題呢？

2）繞過(guò)自動(dòng)分配DNS，使用114dns或Google public DNS：

這個(gè)方案看上去很美好，114dns是國(guó)內(nèi)最大的中立緩存DNS，而Google又是秉承不作惡理念的互聯(lián)網(wǎng)工程帝國(guó)巨鱷，而且騰訊的權(quán)威DNS又支持edns-client-subnet功能，能直接識(shí)別使用Google publicDNS解析騰訊域名的用戶的IP地址，不會(huì)出現(xiàn)流量調(diào)度失效。

但是問(wèn)題來(lái)了：

a. 如何在用戶側(cè)構(gòu)造域名請(qǐng)求：對(duì)于PC端的客戶端來(lái)說(shuō)，構(gòu)造一個(gè)標(biāo)準(zhǔn)的DNS請(qǐng)求包并不算什么難事。但在移動(dòng)端要向一個(gè)指定的LocalDNS上發(fā)送標(biāo)準(zhǔn)的DNS請(qǐng)求包，而且要兼容各種iOS和android的版本的話，技術(shù)上是可行的，只是兼容的成本會(huì)很高；

b. 推動(dòng)用戶修改配置極高：如果要推動(dòng)用戶手動(dòng)修改PC的DNS配置的話，在PC端和手機(jī)客戶端的WiFI下面還算勉強(qiáng)可行。但是要用戶修改在移動(dòng)互聯(lián)網(wǎng)環(huán)境下的DNS配置，其難度不言而喻。

3）完全拋棄域名，自建connectcenter進(jìn)行流量調(diào)度：

如果要采用這種這種方案的話，首先你就得要拿到一份準(zhǔn)確的IP地址庫(kù)來(lái)判斷用戶的歸屬，然后再制定個(gè)協(xié)議搭個(gè)connect center來(lái)做調(diào)度，然后再對(duì)接入層做調(diào)度改造。這種方案和2種方案一樣，不是不能做，只是成本會(huì)比較高，尤其對(duì)于騰訊這種業(yè)務(wù)規(guī)模如此龐大的公司而言。

既然上面的這些傳統(tǒng)方案都存在那么多的問(wèn)題，那有沒(méi)有一種調(diào)度精準(zhǔn)、成本低廉、配置方便的基于域名的流量調(diào)度系統(tǒng)呢？答案是肯定的，我們?cè)谙乱徊嚼^續(xù)分享。

8、當(dāng)前主流的解決方案：HttpDNS出現(xiàn)了

8.1 什么HttpDNS？

HTTPDNS 利用 HTTP 協(xié)議與 DNS 服務(wù)器交互，代替了傳統(tǒng)的基于 UDP 協(xié)議的 DNS 交互，繞開(kāi)了運(yùn)營(yíng)商的 Local DNS，有效防止了域名劫持，提高域名解析效率。另外，由于 DNS 服務(wù)器端獲取的是真實(shí)客戶端 IP 而非 Local DNS 的 IP，能夠精確定位客戶端地理位置、運(yùn)營(yíng)商信息，從而有效改進(jìn)調(diào)度精確性。

HTTPDNS的原理如下圖所示：

8.2 HttpDns 主要解決的問(wèn)題

Local DNS 劫持：由于 HttpDns 是通過(guò) IP 直接請(qǐng)求 HTTP 獲取服務(wù)器 A 記錄地址，不存在向本地運(yùn)營(yíng)商詢問(wèn) domain 解析過(guò)程，所以從根本避免了劫持問(wèn)題。

平均訪問(wèn)延遲下降：由于是 IP 直接訪問(wèn)省掉了一次 domain 解析過(guò)程，通過(guò)智能算法排序后找到最快節(jié)點(diǎn)進(jìn)行訪問(wèn)。

用戶連接失敗率下降：通過(guò)算法降低以往失敗率過(guò)高的服務(wù)器排序，通過(guò)時(shí)間近期訪問(wèn)過(guò)的數(shù)據(jù)提高服務(wù)器排序，通過(guò)歷史訪問(wèn)成功記錄提高服務(wù)器排序。

8.3 騰訊的HttpDNS思路

經(jīng)過(guò)努力，騰訊公司的GSLB 團(tuán)隊(duì)推出的HttpDNS是為移動(dòng)客戶端量身定做的基于Http協(xié)議和域名解析的流量調(diào)度解決方案，專治LocalDNS解析異常以及流量調(diào)度不準(zhǔn)。

詳細(xì)介紹如下。

騰訊的HttpDNS基本原理：

HttpDNS的原理非常簡(jiǎn)單，主要有兩步：

A、客戶端直接訪問(wèn)HttpDNS接口，獲取業(yè)務(wù)在域名配置管理系統(tǒng)上配置的訪問(wèn)延遲最優(yōu)的IP。（基于容災(zāi)考慮，還是保留次選使用運(yùn)營(yíng)商LocalDNS解析域名的方式）；

B、客戶端向獲取到的IP后就向直接往此IP發(fā)送業(yè)務(wù)協(xié)議請(qǐng)求。以Http請(qǐng)求為例，通過(guò)在header中指定host字段，向HttpDNS返回的IP發(fā)送標(biāo)準(zhǔn)的Http請(qǐng)求即可。

HttpDNS帶來(lái)的優(yōu)勢(shì)：

從原理上來(lái)講，HttpDNS只是將域名解析的協(xié)議由DNS協(xié)議換成了Http協(xié)議，并不復(fù)雜。

但是這一微小的轉(zhuǎn)換，卻帶來(lái)了無(wú)數(shù)的收益：

A、根治域名解析異常：由于繞過(guò)了運(yùn)營(yíng)商的LocalDNS，用戶解析域名的請(qǐng)求通過(guò)Http協(xié)議直接透?jìng)鞯搅蓑v訊的HttpDNS服務(wù)器IP上，用戶在客戶端的域名解析請(qǐng)求將不會(huì)遭受到域名解析異常的困擾；

B、調(diào)度精準(zhǔn)：HttpDNS能直接獲取到用戶IP，通過(guò)結(jié)合騰訊自有專利技術(shù)生成的IP地址庫(kù)以及測(cè)速系統(tǒng)，可以保證將用戶引導(dǎo)的訪問(wèn)最快的IDC節(jié)點(diǎn)上；

C、實(shí)現(xiàn)成本低廉：接入HttpDNS的業(yè)務(wù)僅需要對(duì)客戶端接入層做少量改造，無(wú)需用戶手機(jī)進(jìn)行root或越獄；而且由于Http協(xié)議請(qǐng)求構(gòu)造非常簡(jiǎn)單，兼容各版本的移動(dòng)操作系統(tǒng)更不成問(wèn)題；另外HttpDNS的后端配置完全復(fù)用現(xiàn)有權(quán)威DNS配置，管理成本也非常低。總而言之，就是以最小的改造成本，解決了業(yè)務(wù)遭受域名解析異常的問(wèn)題，并滿足業(yè)務(wù)精確流量調(diào)度的需求；

D、擴(kuò)展性強(qiáng)：HttpDNS提供可靠的域名解析服務(wù)，業(yè)務(wù)可將自有調(diào)度邏輯與HttpDNS返回結(jié)果結(jié)合，實(shí)現(xiàn)更精細(xì)化的流量調(diào)度。比如指定版本的客戶端連接請(qǐng)求的IP地址，指定網(wǎng)絡(luò)類型的用戶連接指定的IP地址等。

當(dāng)然各位可能會(huì)問(wèn)：用戶將首選的域名解析方式切換到了HttpDNS，那么HttpDNS的高可用又是如何保證的呢？另外不同運(yùn)營(yíng)商的用戶訪問(wèn)到同一個(gè)HttpDNS的服務(wù)IP，用戶的訪問(wèn)延遲如何保證？

為了保證高可用及提升用戶體驗(yàn)，HttpDNS通過(guò)接入了騰訊公網(wǎng)交換平臺(tái)的BGP Anycast網(wǎng)絡(luò)，與全國(guó)多個(gè)主流運(yùn)營(yíng)商建立了BGP互聯(lián)，保證了這些運(yùn)營(yíng)商的用戶能夠快速地訪問(wèn)到HttpDNS服務(wù)；另外HttpDNS在多個(gè)數(shù)據(jù)中心進(jìn)行了部署，任意一個(gè)節(jié)點(diǎn)發(fā)生故障時(shí)均能無(wú)縫切換到備份節(jié)點(diǎn)，保證用戶解析正常。

接入效果及未來(lái)展望：

當(dāng)前騰訊的HttpDNS方案已在騰訊內(nèi)部接入了多個(gè)業(yè)務(wù)，覆蓋數(shù)億用戶，并已持續(xù)穩(wěn)定運(yùn)行超過(guò)一年時(shí)間。而接入了HttpDNS的業(yè)務(wù)在用戶訪問(wèn)體驗(yàn)方面都有了非常大的提升。

以某個(gè)接入HttpDNS的業(yè)務(wù)為例，該業(yè)務(wù)僅通過(guò)接入HttpDNS，在未做任何其它優(yōu)化的情況下，用戶平均訪問(wèn)延遲下降超過(guò)10%，訪問(wèn)失敗率下降了超過(guò)五分之一，用戶訪問(wèn)體驗(yàn)的效果提升非常顯著。另外騰訊的HttpDNS服務(wù)除了在騰訊內(nèi)部被廣泛使用以外，也受到了業(yè)務(wù)同行的肯定。國(guó)內(nèi)最大的publicDNS服務(wù)商114dns在受到騰訊DNS的啟發(fā)下，也推出了HttpDNS服務(wù)。

在未來(lái)的日子里，騰訊GSLB團(tuán)隊(duì)將會(huì)在騰訊內(nèi)部進(jìn)一步推廣HttpDNS服務(wù)，并將在實(shí)際業(yè)務(wù)的需求下對(duì)HttpDNS服務(wù)進(jìn)行升級(jí)，如提供更為通用、安全、簡(jiǎn)單的接入?yún)f(xié)議，進(jìn)一步提升接入用戶的網(wǎng)絡(luò)訪問(wèn)體驗(yàn)等等。希望HttpDNS能為各位在解決域名解析異常及全局流量調(diào)度失效方面提供一個(gè)簡(jiǎn)單、可行的思路。

9、作為創(chuàng)業(yè)團(tuán)隊(duì)，如何改造APP并支持HttpDNS？

作為創(chuàng)業(yè)團(tuán)隊(duì)，人力、財(cái)力、技術(shù)力量可能都無(wú)暇顧及這一塊，但是移動(dòng)端APP卻實(shí)實(shí)在在面臨文中提到的各種DNS問(wèn)題，我們?cè)撛趺崔k呢？

9.1 使用第3方云服務(wù)商提供的HttpDNS接口

目前，國(guó)內(nèi)有一部分廠商已經(jīng)提供了這個(gè)解析服務(wù)，可以直接使用第三方服務(wù)。

目前，提供 HttpDns 解析服務(wù)的第3方服務(wù)商越來(lái)多，比如：阿里云HttpDNS、騰訊云HttpDNS、華為云HttpDNS等。

以阿里云的 HttpDNS為便，它的API 比較標(biāo)準(zhǔn)，直接發(fā)一個(gè) Get 請(qǐng)求，帶上請(qǐng)求參數(shù)，返回結(jié)果以 json 返回：

http://203.107.1.1/d?host=www.52im.net

請(qǐng)求成功時(shí)，返回結(jié)果如下：

{

  "host": "www.linkedkeeper.com",

  "ips": [

    "115.238.23.241",

    "115.238.23.251"

  ],

  "ttl": 57

}

在移動(dòng)端，將由 HttpDns 獲得的 IP 地址在原有 URL 的基礎(chǔ)上，將域名替換為 IP，然后用新的 URL 發(fā)起 HTTP 請(qǐng)求。

9.2 新浪微博團(tuán)隊(duì)分享的開(kāi)源HttpDNS庫(kù)：HTTPDNSLib

HTTPDNSLib的Github地址：https://github.com/CNSRE/HTTPDNSLib

HTTPDNSLib中實(shí)現(xiàn)的HttpDNS交互流程原理：

從上圖中可以看出來(lái) 整個(gè)業(yè)務(wù)的交互流程，用戶向查詢模塊傳入一個(gè)URL地址，然后查詢模塊會(huì)檢查緩存是否存在，不存在從httpdnsapi接口查詢， 然后經(jīng)過(guò)評(píng)估模塊返回。在用戶請(qǐng)求URL過(guò)程完畢時(shí)，需要將這次請(qǐng)求的結(jié)果反饋給 lib庫(kù)的評(píng)估模塊由評(píng)估模塊入庫(kù)記錄本次質(zhì)量數(shù)據(jù)。

HttpDns Lib庫(kù)交互詳細(xì)流程：

上圖這張?jiān)敿?xì)流程圖就更深入的說(shuō)了下 lib的工作原理。有兩條豎線講圖片分為了三個(gè)區(qū)域，分別是左部分、中間部分 和 右部分。

左部分是app主線程操作的事情，中間部分是app調(diào)用者線程中處理lib庫(kù)事件邏輯的事情，右面部分是新線程獨(dú)立處理事件的邏輯。

開(kāi)始是里客戶端調(diào)用方，傳入一個(gè) url，獲取domain信息后由查詢模塊查詢domain記錄，查詢模塊會(huì)從內(nèi)存緩存層查詢，內(nèi)存緩存層沒(méi)有數(shù)據(jù)會(huì)，查詢數(shù)據(jù)庫(kù)，如果數(shù)據(jù)庫(kù)也沒(méi)有數(shù)據(jù)會(huì)請(qǐng)求本地 LocalDNS。從三個(gè)環(huán)節(jié)中任何一個(gè)環(huán)節(jié)拿到數(shù)據(jù)后， 都會(huì)進(jìn)入下一個(gè)環(huán)節(jié)，如果沒(méi)有拿到數(shù)據(jù)返回null結(jié)束。進(jìn)入評(píng)估模塊，根據(jù)五個(gè)插件進(jìn)行排序， 排序后返回?cái)?shù)據(jù)給客戶端。

lib模塊設(shè)定定時(shí)器，根據(jù)ttl過(guò)期時(shí)間來(lái)檢查domain是否需要更新。 定時(shí)器是獨(dú)立線程， 不會(huì)影響app主線程。 httpdns api請(qǐng)求數(shù)據(jù)， 先從自己配置的 httpdns api接口獲取數(shù)據(jù)，如果獲取不到會(huì)從 dnspod api接口獲取如果也獲取不到 直接從本地 localDNS獲取數(shù)據(jù)，（從本地localDNS獲取數(shù)據(jù)后期會(huì)改為發(fā)送UDP包封裝dns協(xié)議從公共dns服務(wù)器直接獲取，比如114dns等。dns服務(wù)器地址可自行設(shè)定。 ）獲取到數(shù)據(jù)后進(jìn)入測(cè)速模塊。 測(cè)速模塊最新版本可以配置兩種方式，一種是http空請(qǐng)求。 兩個(gè)http頭的交互，類似tcp首保耗時(shí)時(shí)間原理 ，用來(lái)測(cè)試鏈路最快。 另一種是ping命令，（icmp協(xié)議）來(lái)盡量最小化流量的消耗，考慮倒可能有的服務(wù)器禁ping就使用空http測(cè)速即可。 測(cè)速后將數(shù)據(jù)插入本地 cache 即可。

下面是測(cè)試Demo的截圖：

有關(guān)HttpDns Lib庫(kù)的詳細(xì)介紹，請(qǐng)見(jiàn)：《App域名劫持之DNS高可用 - 開(kāi)源版HttpDNS方案詳解》。

附錄：更多網(wǎng)絡(luò)通信方面的精華文章

《TCP/IP詳解 - 第11章·UDP：用戶數(shù)據(jù)報(bào)協(xié)議》

《TCP/IP詳解 - 第17章·TCP：傳輸控制協(xié)議》

《TCP/IP詳解 - 第18章·TCP連接的建立與終止》

《TCP/IP詳解 - 第21章·TCP的超時(shí)與重傳》

《技術(shù)往事：改變世界的TCP/IP協(xié)議（珍貴多圖、手機(jī)慎點(diǎn)）》

《通俗易懂-深入理解TCP協(xié)議（上）：理論基礎(chǔ)》

《通俗易懂-深入理解TCP協(xié)議（下）：RTT、滑動(dòng)窗口、擁塞處理》

《理論經(jīng)典：TCP協(xié)議的3次握手與4次揮手過(guò)程詳解》

《理論聯(lián)系實(shí)際：Wireshark抓包分析TCP 3次握手、4次揮手過(guò)程》

《計(jì)算機(jī)網(wǎng)絡(luò)通訊協(xié)議關(guān)系圖（中文珍藏版）》

《UDP中一個(gè)包的大小最大能多大？》

《P2P技術(shù)詳解(一)：NAT詳解——詳細(xì)原理、P2P簡(jiǎn)介》

《P2P技術(shù)詳解(二)：P2P中的NAT穿越(打洞)方案詳解》

《P2P技術(shù)詳解(三)：P2P技術(shù)之STUN、TURN、ICE詳解》

《通俗易懂：快速理解P2P技術(shù)中的NAT穿透原理》

《高性能網(wǎng)絡(luò)編程(一)：?jiǎn)闻_(tái)服務(wù)器并發(fā)TCP連接數(shù)到底可以有多少》

《高性能網(wǎng)絡(luò)編程(二)：上一個(gè)10年，著名的C10K并發(fā)連接問(wèn)題》

《高性能網(wǎng)絡(luò)編程(三)：下一個(gè)10年，是時(shí)候考慮C10M并發(fā)問(wèn)題了》

《高性能網(wǎng)絡(luò)編程(四)：從C10K到C10M高性能網(wǎng)絡(luò)應(yīng)用的理論探索》

《高性能網(wǎng)絡(luò)編程(五)：一文讀懂高性能網(wǎng)絡(luò)編程中的I/O模型》

《高性能網(wǎng)絡(luò)編程(六)：一文讀懂高性能網(wǎng)絡(luò)編程中的線程模型》

《不為人知的網(wǎng)絡(luò)編程(一)：淺析TCP協(xié)議中的疑難雜癥(上篇)》

《不為人知的網(wǎng)絡(luò)編程(二)：淺析TCP協(xié)議中的疑難雜癥(下篇)》

《不為人知的網(wǎng)絡(luò)編程(三)：關(guān)閉TCP連接時(shí)為什么會(huì)TIME_WAIT、CLOSE_WAIT》

《不為人知的網(wǎng)絡(luò)編程(四)：深入研究分析TCP的異常關(guān)閉》

《不為人知的網(wǎng)絡(luò)編程(五)：UDP的連接性和負(fù)載均衡》

《不為人知的網(wǎng)絡(luò)編程(六)：深入地理解UDP協(xié)議并用好它》

《不為人知的網(wǎng)絡(luò)編程(七)：如何讓不可靠的UDP變的可靠？》

《網(wǎng)絡(luò)編程懶人入門(mén)(一)：快速理解網(wǎng)絡(luò)通信協(xié)議（上篇）》

《網(wǎng)絡(luò)編程懶人入門(mén)(二)：快速理解網(wǎng)絡(luò)通信協(xié)議（下篇）》

《網(wǎng)絡(luò)編程懶人入門(mén)(三)：快速理解TCP協(xié)議一篇就夠》

《網(wǎng)絡(luò)編程懶人入門(mén)(四)：快速理解TCP和UDP的差異》

《網(wǎng)絡(luò)編程懶人入門(mén)(五)：快速理解為什么說(shuō)UDP有時(shí)比TCP更有優(yōu)勢(shì)》

《網(wǎng)絡(luò)編程懶人入門(mén)(六)：史上最通俗的集線器、交換機(jī)、路由器功能原理入門(mén)》

《網(wǎng)絡(luò)編程懶人入門(mén)(七)：深入淺出，全面理解HTTP協(xié)議》

《網(wǎng)絡(luò)編程懶人入門(mén)(八)：手把手教你寫(xiě)基于TCP的Socket長(zhǎng)連接》

《網(wǎng)絡(luò)編程懶人入門(mén)(九)：通俗講解，有了IP地址，為何還要用MAC地址？》

《技術(shù)掃盲：新一代基于UDP的低延時(shí)網(wǎng)絡(luò)傳輸層協(xié)議——QUIC詳解》

《讓互聯(lián)網(wǎng)更快：新一代QUIC協(xié)議在騰訊的技術(shù)實(shí)踐分享》

《現(xiàn)代移動(dòng)端網(wǎng)絡(luò)短連接的優(yōu)化手段總結(jié)：請(qǐng)求速度、弱網(wǎng)適應(yīng)、安全保障》

《聊聊iOS中網(wǎng)絡(luò)編程長(zhǎng)連接的那些事》

《移動(dòng)端IM開(kāi)發(fā)者必讀(一)：通俗易懂，理解移動(dòng)網(wǎng)絡(luò)的“弱”和“慢”》

《移動(dòng)端IM開(kāi)發(fā)者必讀(二)：史上最全移動(dòng)弱網(wǎng)絡(luò)優(yōu)化方法總結(jié)》

《IPv6技術(shù)詳解：基本概念、應(yīng)用現(xiàn)狀、技術(shù)實(shí)踐（上篇）》

《IPv6技術(shù)詳解：基本概念、應(yīng)用現(xiàn)狀、技術(shù)實(shí)踐（下篇）》

《從HTTP/0.9到HTTP/2：一文讀懂HTTP協(xié)議的歷史演變和設(shè)計(jì)思路》

《腦殘式網(wǎng)絡(luò)編程入門(mén)(一)：跟著動(dòng)畫(huà)來(lái)學(xué)TCP三次握手和四次揮手》

《腦殘式網(wǎng)絡(luò)編程入門(mén)(二)：我們?cè)谧x寫(xiě)Socket時(shí)，究竟在讀寫(xiě)什么？》

《腦殘式網(wǎng)絡(luò)編程入門(mén)(三)：HTTP協(xié)議必知必會(huì)的一些知識(shí)》

《腦殘式網(wǎng)絡(luò)編程入門(mén)(四)：快速理解HTTP/2的服務(wù)器推送(Server Push)》

《腦殘式網(wǎng)絡(luò)編程入門(mén)(五)：每天都在用的Ping命令，它到底是什么？》

《腦殘式網(wǎng)絡(luò)編程入門(mén)(六)：什么是公網(wǎng)IP和內(nèi)網(wǎng)IP？NAT轉(zhuǎn)換又是什么鬼？》

《以網(wǎng)游服務(wù)端的網(wǎng)絡(luò)接入層設(shè)計(jì)為例，理解實(shí)時(shí)通信的技術(shù)挑戰(zhàn)》

《邁向高階：優(yōu)秀Android程序員必知必會(huì)的網(wǎng)絡(luò)基礎(chǔ)》

《全面了解移動(dòng)端DNS域名劫持等雜癥：技術(shù)原理、問(wèn)題根源、解決方案等》

>> 更多同類文章 ……

（本文同步發(fā)布于：http://www.52im.net/thread-2121-1-1.html）