移動場景下DNS解析開銷是整個網絡請求中不可忽略的一部分。在弱網環境下，基于UDP的解析非常容易出現解析超時的問題，并且即使解析成功會消耗數百毫秒乃至更甚，對我們整個業務請求而言是非常不利的，它直接影響了客戶的體驗。對于一個比較大眾的應用而言，DNS的優化對整個應用的網絡優化所占的權重是很大的。我們接下來從以下幾個方面全面理解DNS，相信對我們開發中的網絡優化會有不小的幫助。1. DNS1.1 認識DNS
DNS( Name )是域名“系統”的英文縮寫，是一種組織成域層次結構的計算機和網絡服務命名系統，它用于TCP/IP網絡，它所提供的服務是用來將主機名和域名轉換為IP地址的工作。
作為網絡通信的最靠前的一個環節，其在整個網絡通信的過程中的重要性不言而喻。
ios10之后，apple提供的原生http請求方法能返回http請求各個階段的時間指標路由器dns根域名解失敗網不能用，其中就包含DNS解析時間。
1.2 DNS解析相關概念
1.2.1 DNS域名層次結構DNS是一種分層結構，在整個互聯網中組成一個樹狀系統，頂層是系統的根域名，下層為TLD以及二級域名，葉子就構成了所謂的FQDN（Fully Names），根域名通常使用"."來表示，其實際上也是由域名組成，全世界目前有13組域名根節點，由少數幾個國家進行管理，而國內僅有幾臺根節點鏡像。
1.2.2 權威DNS
權威DNS是經過上一級授權對域名進行解析的服務器，同時它可以把解析授權轉授給其他人，如COM頂級服務器可以授權xxorg.com這個域名的的權威服務器為NS.ABC.COM，同時NS.ABC.COM還可以把授權轉授給NS.DDD.COM，這樣NS.DDD.COM就成了ABC.COM實際上的權威服務器了。平時我們解析域名的結果都源自權威DNS。eg: 阿里云云解析 ?[https://wanwang.aliyun.com/domain/dns](https://wanwang.aliyun.com/domain/dns)?
復制代碼
1.2.3 遞歸DNS遞歸DNS又稱為Local DNS，它沒有域名解析結果的決定權，但代理了用戶向權威DNS獲取域名解析結果的過程。遞歸DNS上有緩存模塊，當目標域名存在緩存解析結果并且TTL未過期時（每個域名都有TTL時間，即有效生存時間，若域名解析結果緩存的時間超過TTL，需要重新向權威DNS獲取解析結果），遞歸DNS會返回緩存結果，否則，遞歸DNS會一級一級地查詢各個層級域名的權威DNS直至獲取最終完整域名的解析結果。eg: 我們自己的電腦，運營商提供的dns服務器等等。1.2.4 公共DNS公共DNS是遞歸DNS的一種特例，它是一種全網開放的遞歸DNS服務，而傳統的遞歸DNS信息一般由運營商分發給用戶。
在 DNS 的解析過程中，用戶向遞歸 DNS 發起請求，遞歸 DNS 向權威 DNS 請求解析結果，可以說遞歸 DNS 起到一種轉發的作用。ISP DNS 就是遞歸 DNS；同時一些個人或互聯網服務提供商也會架設自己的遞歸 DNS 開放給所有人使用，稱為公共 DNS。
全國DNS匯總: … ipip: /dns.php
1.2.5 轉發DNS
可以理解為遞歸DNS和用戶之間的一個中轉站，它不提供直接解析域名的服務，它將請求轉發給遞歸DNS，然后將遞歸DNS的結果轉發一下，也提供緩存作用。比如，日常家用的路由器，它的DNS服務器一般都是192.168.1.1，只是轉發給遞歸DNS。1.3 域名解析記錄方式域名解析記錄主要分為A記錄、MIX記錄、CNAME記錄、NS記錄和TXT記錄：
1.4 域名解析過程
以下是在終端中dig百度顯示的具體過程：
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 mscom. 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 C41A5766com. 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 msbaidu.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 NSEC3PARAMCK0POJMG874LJREF7EFN8430QVIT8BSM.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 RRSIGHPVV2B5N85O7HJJRB7690IB5UVF9O9UA.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 mswww.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.通過上面命令我們可以看到DNS解析的逐步過程，其中最后一步我們可以看到 被CNAME到 所以我們再查一下 即可看到其ip.
;; Received 215 bytes from 220.181.33.31#53(ns2.baidu.com) in 28 mswww.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然后我們再用命令查看一下百度的ip是不是上面顯示的兩個:
macdeiMac:~ ethan$ nslookup www.baidu.comServer: 114.114.114.114Address: 114.114.114.114#53Non-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的過程：
終端向 Local DNS發起域名解析請求Local DNS在獲取到域名請求后，首先從Root hins獲取根域名服務器的地址(Root hints包含了互聯網DNS根服務器的地址信息)獲取到了根域名服務器地址后，Local DNS向根域名服務器發起DNS解析請求，根域名服務器返回頂級域名服務器地址(com或者cn或者其它)隨后Local DNS向com域名服務器發起解析請求，并得到二級域名服務器地址Local DNS向二級域名服務器發起解析請求，并最終貨到了 的ip地址信息Local DNS將遞歸查詢獲得的IP地址信息緩存并返回給客戶端
3. 全局負載均衡是 load 的縮寫，即全局負載均衡。目的是實現互聯網上不同地域的服務器間的流量調配，保證使用戶的請求能被離用戶最近或者服務質量更好的服務器來處理。從而確保服務質量。能通過判斷服務器的負載，包括CPU占用、帶寬占用等數據，決定服務器的可用性，同時能判斷用戶（訪問者）與服務器間的鏈路狀況，選擇鏈路狀況最好的服務器。因此GSLB是對服務器和鏈路進行綜合判斷來決定由哪個地點的服務器來提供服務，實現異地服務器群服務質量的保證。
3.1 智能DNS智能DNS是GSLB的一種應用。
4. DNS解析存在的問題有時候我們在訪問百度或者在應用中發出一個http請求時，如果DNS解析被劫持，我們可能最終訪問到的不是我們想要訪問的服務器。
4.1 運營商劫持DNS劫持 就是通過劫持了 DNS 服務器，通過某些手段取得某域名的解析記錄控制權，進而修改此域名的解析結果，導致對該域名的訪問由原 IP 地址轉入到修改后的指定 IP，其結果就是對特定的網址不能訪問或訪問的是假網址，從而實現竊取資料或者破壞原有正常服務的目的。
4.2 DNS解析域名時緩存解析結果我們在開發中有時候會遇到這樣的情況：你是一個聯通用戶，你在手機瀏覽器中輸入，由一個服務器像百度權威服務器查應該訪問哪一臺服務器，權威把結果返回給服務器,服務器返回結果給用戶。
如果當緩存的有對應的結果，那么他就不會像百度的權威服務器查詢其對應的ip，而是直接返回緩存中的結果。如果此時權威服務器中的對應的ip發生了變化，沒有及時更新，這樣會導致用戶訪問不到服務器。
4.3 轉發解析你用手機訪問時路由器dns根域名解失敗網不能用，會到當前運營商的DNS服務器查，然后運營商的DNS服務再去百度權威服務器去查，最終把權威服務器中的正確ip返回。上面是正常的情況，但是如果當前運營商(比如聯通)的不訪問百度權威DNS服務器，而是直接訪問了其它運營商(比如電信)的服務器，有些小的運營商就是通過這樣做來降低成本。如果電信的對非自家ip的訪問限了速那么很明顯會影響你的DNS解析時間。如果你應用中的某些服務需要運營商信息isp(eg:只能dns, cdn等服務).下面截圖是我手機的網路環境(開源地址：//ne…)
我直接ping百度的地址，然后用抓包結果，正常結果如下：
如果發生了轉發則邏輯如下：