[導(dǎo)讀]移動(dòng)場(chǎng)景下DNS解析開銷是整個(gè)網(wǎng)絡(luò)請(qǐng)求中不可忽略的一部分。在弱網(wǎng)環(huán)境下，基于UDP的LocalDNS解析非常容易出現(xiàn)解析超時(shí)的問(wèn)題，并且即使解析成功會(huì)消耗數(shù)百毫秒乃至更甚，對(duì)我們整個(gè)業(yè)務(wù)請(qǐng)求而言是非常不利的，它直接影響了客戶的體驗(yàn)。對(duì)于一個(gè)比較大眾的應(yīng)用而言，DNS的優(yōu)化對(duì)整個(gè)應(yīng)...

移動(dòng)場(chǎng)景下DNS解析開銷是整個(gè)網(wǎng)絡(luò)請(qǐng)求中不可忽略的一部分。在弱網(wǎng)環(huán)境下，基于UDP的LocalDNS解析非常容易出現(xiàn)解析超時(shí)的問(wèn)題，并且即使解析成功會(huì)消耗數(shù)百毫秒乃至更甚，對(duì)我們整個(gè)業(yè)務(wù)請(qǐng)求而言是非常不利的，它直接影響了客戶的體驗(yàn)。對(duì)于一個(gè)比較大眾的應(yīng)用而言，DNS的優(yōu)化對(duì)整個(gè)應(yīng)用的網(wǎng)絡(luò)優(yōu)化所占的權(quán)重是很大的。我們接下來(lái)從以下幾個(gè)方面全面理解DNS，相信對(duì)我們開發(fā)中的網(wǎng)絡(luò)優(yōu)化會(huì)有不小的幫助。

1. DNS

1.1 認(rèn)識(shí)DNS

DNS(Domain Name System)是域名“系統(tǒng)”的英文縮寫，是一種組織成域?qū)哟谓Y(jié)構(gòu)的計(jì)算機(jī)和網(wǎng)絡(luò)服務(wù)命名系統(tǒng)，它用于TCP/IP網(wǎng)絡(luò)，它所提供的服務(wù)是用來(lái)將主機(jī)名和域名轉(zhuǎn)換為IP地址的工作。

作為網(wǎng)絡(luò)通信的最靠前的一個(gè)環(huán)節(jié)，其在整個(gè)網(wǎng)絡(luò)通信的過(guò)程中的重要性不言而喻。

ios10之后，apple提供的原生http請(qǐng)求方法能返回http請(qǐng)求各個(gè)階段的時(shí)間指標(biāo)，其中就包含DNS解析時(shí)間。

1.2 DNS解析相關(guān)概念

1.2.1 DNS域名層次結(jié)構(gòu)

DNS是一種分層結(jié)構(gòu)，在整個(gè)互聯(lián)網(wǎng)中組成一個(gè)樹狀系統(tǒng)，頂層是系統(tǒng)的根域名，下層為TLD以及二級(jí)域名，葉子就構(gòu)成了所謂的FQDN（Fully Qualified Domain Names），根域名通常使用"."來(lái)表示，其實(shí)際上也是由域名組成，全世界目前有13組域名根節(jié)點(diǎn)，由少數(shù)幾個(gè)國(guó)家進(jìn)行管理，而國(guó)內(nèi)僅有幾臺(tái)根節(jié)點(diǎn)鏡像。

1.2.2 權(quán)威DNS

權(quán)威DNS是經(jīng)過(guò)上一級(jí)授權(quán)對(duì)域名進(jìn)行解析的服務(wù)器，同時(shí)它可以把解析授權(quán)轉(zhuǎn)授給其他人，如COM頂級(jí)服務(wù)器可以授權(quán)xxorg.com這個(gè)域名的的權(quán)威服務(wù)器為NS.ABC.COM，同時(shí)NS.ABC.COM還可以把授權(quán)轉(zhuǎn)授給NS.DDD.COM，這樣NS.DDD.COM就成了ABC.COM實(shí)際上的權(quán)威服務(wù)器了。平時(shí)我們解析域名的結(jié)果都源自權(quán)威DNS。eg: 阿里云云解析 ?[https://wanwang.aliyun.com/domain/dns](https://wanwang.aliyun.com/domain/dns)?
復(fù)制代碼

1.2.3 遞歸DNS

遞歸DNS又稱為L(zhǎng)ocal DNS，它沒(méi)有域名解析結(jié)果的決定權(quán)，但代理了用戶向權(quán)威DNS獲取域名解析結(jié)果的過(guò)程。遞歸DNS上有緩存模塊，當(dāng)目標(biāo)域名存在緩存解析結(jié)果并且TTL未過(guò)期時(shí)（每個(gè)域名都有TTL時(shí)間，即有效生存時(shí)間，若域名解析結(jié)果緩存的時(shí)間超過(guò)TTL，需要重新向權(quán)威DNS獲取解析結(jié)果），遞歸DNS會(huì)返回緩存結(jié)果，否則，遞歸DNS會(huì)一級(jí)一級(jí)地查詢各個(gè)層級(jí)域名的權(quán)威DNS直至獲取最終完整域名的解析結(jié)果。eg: 我們自己的電腦，運(yùn)營(yíng)商提供的dns服務(wù)器等等。

1.2.4 公共DNS

公共DNS是遞歸DNS的一種特例，它是一種全網(wǎng)開放的遞歸DNS服務(wù)，而傳統(tǒng)的遞歸DNS信息一般由運(yùn)營(yíng)商分發(fā)給用戶。
在 DNS 的解析過(guò)程中，用戶向遞歸 DNS 發(fā)起請(qǐng)求，遞歸 DNS 向權(quán)威 DNS 請(qǐng)求解析結(jié)果，可以說(shuō)遞歸 DNS 起到一種轉(zhuǎn)發(fā)的作用。ISP DNS 就是遞歸 DNS；同時(shí)一些個(gè)人或互聯(lián)網(wǎng)服務(wù)提供商也會(huì)架設(shè)自己的遞歸 DNS 開放給所有人使用，稱為公共 DNS。

全國(guó)DNS匯總: ?www.114dns.com/DNS_List.ht… ?ipip: tools.ipip.net/dns.php
1.2.5 轉(zhuǎn)發(fā)DNS

可以理解為遞歸DNS和用戶之間的一個(gè)中轉(zhuǎn)站，它不提供直接解析域名的服務(wù)，它將請(qǐng)求轉(zhuǎn)發(fā)給遞歸DNS，然后將遞歸DNS的結(jié)果轉(zhuǎn)發(fā)一下，也提供緩存作用。比如，日常家用的路由器，它的DNS服務(wù)器一般都是192.168.1.1，只是轉(zhuǎn)發(fā)給遞歸DNS。

1.3 域名解析記錄方式

域名解析記錄主要分為A記錄、MIX記錄、CNAME記錄、NS記錄和TXT記錄：

A記錄：
A代表Address,用來(lái)指定域名對(duì)應(yīng)的ip,例如將www.hello.com指定到 113.112.3.xxx, A記錄可以將多個(gè)域名解析到一個(gè)ip地址，但是不能講一個(gè)域名解析到多個(gè)ip地址
MIX記錄：
Mail Exchange，就是可以將某個(gè)域名下的郵件服務(wù)器直線給自己的Mail Server
CNAME記錄：
Canonical Name，即別名解析。
所謂別名解析就是可以為一個(gè)域名設(shè)置一個(gè)或者多個(gè)別名，如將aaa.com解析到bbb.net、將ccc.com也解析到bbb.net，其中bbb.net分別是aaa.com和ccc.com的別名
NS記錄：
為某個(gè)域名指定DNS解析服務(wù)器，也就是這個(gè)域名由指定的IP地址的DNS服務(wù)器解析
TXT記錄：
為某個(gè)主機(jī)名或域名設(shè)置說(shuō)明，如可以為ucloud.cn是指TXT記錄為“中立安全科信賴”這樣的說(shuō)明

1.4 域名解析過(guò)程

以下是在終端中dig百度顯示的具體過(guò)程：

macdeiMac:~ ethan$ dig trace www.baidu.com?

; <<>> DiG 9.10.6 <<>> trace www.baidu.com;; global options: cmd. 1615 IN NS a.root-servers.net.. 1615 IN NS g.root-servers.net.. 1615 IN NS f.root-servers.net.. 1615 IN NS l.root-servers.net.. 1615 IN NS m.root-servers.net.. 1615 IN NS j.root-servers.net.. 1615 IN NS k.root-servers.net.. 1615 IN NS c.root-servers.net.. 1615 IN NS b.root-servers.net.. 1615 IN NS d.root-servers.net.. 1615 IN NS i.root-servers.net.. 1615 IN NS e.root-servers.net.. 1615 IN NS h.root-servers.net.;; Received 239 bytes from 114.114.114.114#53(114.114.114.114) in 10 ms

com. 172800 IN NS a.gtld-servers.net.com. 172800 IN NS b.gtld-servers.net.com. 172800 IN NS c.gtld-servers.net.com. 172800 IN NS d.gtld-servers.net.com. 172800 IN NS e.gtld-servers.net.com. 172800 IN NS f.gtld-servers.net.com. 172800 IN NS g.gtld-servers.net.com. 172800 IN NS h.gtld-servers.net.com. 172800 IN NS i.gtld-servers.net.com. 172800 IN NS j.gtld-servers.net.com. 172800 IN NS k.gtld-servers.net.com. 172800 IN NS l.gtld-servers.net.com. 172800 IN NS m.gtld-servers.net.com. 86400 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766

com.      86400  IN  RRSIG  DS 8 1 86400 20191112050000 20191030040000 22545 . Sr1g7h DSqi ekBQQS2ZBc/jt0zL IR Od/R9TnMjcy8Mw9RxLrMY2pm 1VYNqL5cAME1stSAfRUKwjD/vixnCeVLoJ6idCFOZeB t/tTFQF/jfk1 td66pW9V/WgLIvslAwEZjidVeUFYERc7hZXr10BgzryZthizHISimuiQ qBjoIQN/uYULTnmePkIW07mnJXc9/AVZrjeI1AmvYC7wE0uR7DWNg1Ig dL4DaLDOM30qN7FBAD7K091uEgctpdxd/8G5XoYclSqroN4G6RibvkWT /vPCFRUzoaxembT5tR7gIz7gxdhN1r8NBD468JTG180MNUvb16Z/87U6 7UkMrg==

;; Received 1173 bytes from 192.58.128.30#53(j.root-servers.net) in 77 ms

baidu.com. 172800 IN NS ns2.baidu.com.baidu.com. 172800 IN NS ns3.baidu.com.baidu.com. 172800 IN NS ns4.baidu.com.baidu.com. 172800 IN NS ns1.baidu.com.baidu.com. 172800 IN NS ns7.baidu.com.

CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A? NS SOA RRSIG DNSKEY NSEC3PARAM

CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20191103044815 20191027033815 12163 com. U/FwNWeuKzR/uT2X/8Cf9TQmnaMdWf6XwBrFIIOCQ/kfKaOExEiT8LSQ 13OaEjtvFOOlIPK0XIbsL dgGPYb/UV6sipBeQ1n8KuK18m3bYk47Ely oe 3VVp0zaiXt9DZrmRRenBB13o0DPqCbRHAHq1pj5zG5VkMufu9L/TT g80XlNukAMcu4GrV4VP8OimOQxz7HJbadci2oYn3beiHqQ==

HPVV2B5N85O7HJJRB7690IB5UVF9O9UA.com. 86400 IN NSEC3 1 1 0 - HPVVN3Q5E5GOQP2QFE2LEM4SVB9C0SJ6? NS DS RRSIG

HPVV2B5N85O7HJJRB7690IB5UVF9O9UA.com. 86400 IN RRSIG NSEC3 8 2 86400 20191105055359 20191029034359 12163 com. J5Dq0lGkcejjg1vPqWDBvNYaAhqFF3Ck8trKj4tgW5Z1bmoXsHGU6/Cl y3GlLfzb49xjiXzxVLCuAQJ9uLuKSX5cn kesc8rwYqcVXU4nXbD5jzo u3CK2yHD3FqPDCOKlMSNy3KKkL03bB3DfmvAae/qQs7xSe6VTpCkR6v/ lo3UA/pMfTYBjSIOvR2KmpM9yFLmN5LXAQW3rNH8sW91BA==

;; Received 761 bytes from 192.26.92.30#53(c.gtld-servers.net) in 241 ms

www.baidu.com. 1200 IN CNAME www.a.shifen.com.a.shifen.com. 1200 IN NS ns2.a.shifen.com.a.shifen.com. 1200 IN NS ns3.a.shifen.com.a.shifen.com. 1200 IN NS ns4.a.shifen.com.a.shifen.com. 1200 IN NS ns5.a.shifen.com.a.shifen.com. 1200 IN NS ns1.a.shifen.com.

通過(guò)上面命令我們可以看到DNS解析的逐步過(guò)程，其中最后一步我們可以看到www.baidu.com 被CNAME到 www.a.shifen.com 所以我們?cè)俨橐幌?www.a.shifen.com 即可看到其ip.

;; Received 215 bytes from 220.181.33.31#53(ns2.baidu.com) in 28 ms

www.a.shifen.com. 300 IN A 180.101.49.12www.a.shifen.com. 300 IN A 180.101.49.11a.shifen.com. 1200 IN NS ns4.a.shifen.com.a.shifen.com. 1200 IN NS ns5.a.shifen.com.a.shifen.com. 1200 IN NS ns1.a.shifen.com.a.shifen.com. 1200 IN NS ns2.a.shifen.com.a.shifen.com. 1200 IN NS ns3.a.shifen.com.;; Received 236 bytes from 180.76.76.95#53(ns5.a.shifen.com) in 9 ms

然后我們?cè)儆胣slookup命令查看一下百度的ip是不是上面顯示的兩個(gè):

macdeiMac:~ ethan$ nslookup www.baidu.comServer: 114.114.114.114Address: 114.114.114.114#53

Non-authoritative answer:www.baidu.com canonical name = www.a.shifen.com.Name: www.a.shifen.comAddress: 180.101.49.11Name: www.a.shifen.comAddress: 180.101.49.12圖示DNS解析baidu的過(guò)程：

終端向 Local DNS發(fā)起域名解析請(qǐng)求
Local DNS在獲取到域名請(qǐng)求后，首先從Root hins獲取根域名服務(wù)器的地址(Root hints包含了互聯(lián)網(wǎng)DNS根服務(wù)器的地址信息)
獲取到了根域名服務(wù)器地址后，Local DNS向根域名服務(wù)器發(fā)起DNS解析請(qǐng)求，根域名服務(wù)器返回頂級(jí)域名服務(wù)器地址(com或者cn或者其它)
隨后Local DNS向com域名服務(wù)器發(fā)起解析請(qǐng)求，并得到baidu.com二級(jí)域名服務(wù)器地址
Local DNS向baidu.com二級(jí)域名服務(wù)器發(fā)起解析請(qǐng)求，并最終貨到了www.baidu.com 的ip地址信息
Local DNS將遞歸查詢獲得的IP地址信息緩存并返回給客戶端

3. 全局負(fù)載均衡GSLB

GSLB是Global Server load Blance的縮寫，即全局負(fù)載均衡。目的是實(shí)現(xiàn)互聯(lián)網(wǎng)上不同地域的服務(wù)器間的流量調(diào)配，保證使用戶的請(qǐng)求能被離用戶最近或者服務(wù)質(zhì)量更好的服務(wù)器來(lái)處理。從而確保服務(wù)質(zhì)量。能通過(guò)判斷服務(wù)器的負(fù)載，包括CPU占用、帶寬占用等數(shù)據(jù)，決定服務(wù)器的可用性，同時(shí)能判斷用戶（訪問(wèn)者）與服務(wù)器間的鏈路狀況，選擇鏈路狀況最好的服務(wù)器。因此GSLB是對(duì)服務(wù)器和鏈路進(jìn)行綜合判斷來(lái)決定由哪個(gè)地點(diǎn)的服務(wù)器來(lái)提供服務(wù)，實(shí)現(xiàn)異地服務(wù)器群服務(wù)質(zhì)量的保證。

3.1 ?智能DNS

智能DNS是GSLB的一種應(yīng)用。

4. DNS解析存在的問(wèn)題

有時(shí)候我們?cè)谠L問(wèn)百度或者在應(yīng)用中發(fā)出一個(gè)http請(qǐng)求時(shí)，如果DNS解析被劫持，我們可能最終訪問(wèn)到的不是我們想要訪問(wèn)的服務(wù)器。

4.1 運(yùn)營(yíng)商劫持

DNS劫持就是通過(guò)劫持了 DNS 服務(wù)器，通過(guò)某些手段取得某域名的解析記錄控制權(quán)，進(jìn)而修改此域名的解析結(jié)果，導(dǎo)致對(duì)該域名的訪問(wèn)由原 IP 地址轉(zhuǎn)入到修改后的指定 IP，其結(jié)果就是對(duì)特定的網(wǎng)址不能訪問(wèn)或訪問(wèn)的是假網(wǎng)址，從而實(shí)現(xiàn)竊取資料或者破壞原有正常服務(wù)的目的。

4.2 DNS解析域名時(shí)緩存解析結(jié)果

我們?cè)陂_發(fā)中有時(shí)候會(huì)遇到這樣的情況：你是一個(gè)聯(lián)通用戶，你在手機(jī)瀏覽器中輸入baidu.com，由一個(gè)LocalDNS服務(wù)器像百度權(quán)威服務(wù)器查應(yīng)該訪問(wèn)哪一臺(tái)服務(wù)器，權(quán)威把結(jié)果返回給LocalDNS服務(wù)器,localDNS服務(wù)器返回結(jié)果給用戶。

如果當(dāng)LocalDNS緩存的有baidu.com對(duì)應(yīng)的結(jié)果，那么他就不會(huì)像百度的權(quán)威服務(wù)器查詢其對(duì)應(yīng)的ip，而是直接返回緩存中的結(jié)果。如果此時(shí)權(quán)威服務(wù)器中的baidu.com對(duì)應(yīng)的ip發(fā)生了變化，LocalDNS沒(méi)有及時(shí)更新，這樣會(huì)導(dǎo)致用戶訪問(wèn)不到服務(wù)器。

4.3 轉(zhuǎn)發(fā)解析你用手機(jī)訪問(wèn)baidu.com時(shí)，會(huì)到當(dāng)前運(yùn)營(yíng)商的DNS服務(wù)器查，然后運(yùn)營(yíng)商的DNS服務(wù)再去百度權(quán)威服務(wù)器去查，最終把權(quán)威服務(wù)器中的正確ip返回。上面是正常的情況，但是如果當(dāng)前運(yùn)營(yíng)商(比如聯(lián)通)的LocalDNS不訪問(wèn)百度權(quán)威DNS服務(wù)器，而是直接訪問(wèn)了其它運(yùn)營(yíng)商(比如電信)的LocalDNS服務(wù)器，有些小的運(yùn)營(yíng)商就是通過(guò)這樣做來(lái)降低成本。如果電信的LocalDNS對(duì)非自家ip的訪問(wèn)限了速那么很明顯會(huì)影響你的DNS解析時(shí)間。如果你應(yīng)用中的某些服務(wù)需要運(yùn)營(yíng)商信息isp(eg:只能dns, cdn等服務(wù)).下面截圖是我手機(jī)的網(wǎng)路環(huán)境(NetPing開源地址：github.com/mediaios/ne…)

我直接ping百度的地址，然后用wireshark抓包結(jié)果，正常結(jié)果如下：

如果發(fā)生了轉(zhuǎn)發(fā)則邏輯如下：

5. HTTPDNS

5.1 什么是HTTPDNS

HTTPDNS使用HTTP與DNS服務(wù)器交互，代替?zhèn)鹘y(tǒng)的基于UDP的DNS協(xié)議，域名解析請(qǐng)求直接發(fā)送到HTTPDNS服務(wù)端，從而繞過(guò)運(yùn)營(yíng)商的Local DNS

5.2 HTTPDNS的特性

5.2.1 防止域名劫持

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

5.2.2 精準(zhǔn)調(diào)度

HTTPDNS能夠直接獲取到用戶的IP地址，從而實(shí)現(xiàn)精確定位與導(dǎo)流

5.2.3 用戶連接失敗率下降

通過(guò)算法降低以往失敗率過(guò)高的服務(wù)器排序，通過(guò)時(shí)間近期訪問(wèn)過(guò)的數(shù)據(jù)提高服務(wù)器排序，通過(guò)歷史訪問(wèn)成功記錄提高服務(wù)器排序。原來(lái)的請(qǐng)求地址為 “apis.juhe.cn/simpleWeath…”，通過(guò)HTTPDNS替換域名后最終的結(jié)果如下：

5.3 HTTPS IP Content

發(fā)送HTTPS請(qǐng)求首先要進(jìn)行SSL/TLS握手，握手過(guò)程大致如下：

客戶端發(fā)起握手請(qǐng)求，攜帶隨機(jī)數(shù)、支持算法列表等參數(shù)。
服務(wù)端收到請(qǐng)求，選擇合適的算法，下發(fā)公鑰證書和隨機(jī)數(shù)。
客戶端對(duì)服務(wù)端證書進(jìn)行校驗(yàn)，并發(fā)送隨機(jī)數(shù)信息，該信息使用公鑰加密。
服務(wù)端通過(guò)私鑰獲取隨機(jī)數(shù)信息。
雙方根據(jù)以上交互的信息生成session ticket，用作該連接后續(xù)數(shù)據(jù)傳輸?shù)募用苊荑€。

上述過(guò)程中，和HTTPDNS有關(guān)的是第3步，客戶端需要驗(yàn)證服務(wù)端下發(fā)的證書，驗(yàn)證過(guò)程有以下兩個(gè)要點(diǎn)：

客戶端用本地保存的根證書解開證書鏈，確認(rèn)服務(wù)端下發(fā)的證書是由可信任的機(jī)構(gòu)頒發(fā)的。
客戶端需要檢查證書的domain域和擴(kuò)展域，看是否包含本次請(qǐng)求的host。

如果上述兩點(diǎn)都校驗(yàn)通過(guò)，就證明當(dāng)前的服務(wù)端是可信任的，否則就是不可信任，應(yīng)當(dāng)中斷當(dāng)前連接。當(dāng)客戶端使用HTTPDNS解析域名時(shí)，請(qǐng)求URL中的host會(huì)被替換成HTTPDNS解析出來(lái)的IP，所以在證書驗(yàn)證的第2步，會(huì)出現(xiàn)domain不匹配的情況，導(dǎo)致SSL/TLS握手不成功。

6.問(wèn)題

6.1 主機(jī)是如何知道DNS服務(wù)器地的IP地址的？

通過(guò)DHCP動(dòng)態(tài)獲得，或者手工配置的。DHCP協(xié)議：DHCP（Dynamic Host Configuration Protocol，動(dòng)態(tài)主機(jī)配置協(xié)議）通常被應(yīng)用在大型的局域網(wǎng)絡(luò)環(huán)境中，主要作用是集中的管理、分配IP地址，使網(wǎng)絡(luò)環(huán)境中的主機(jī)動(dòng)態(tài)的獲得IP地址、Gateway地址、DNS服務(wù)器地址等信息，并能夠提升地址的使用率。