全面理解DNS及HTTPDNS
[導(dǎo)讀]移動場景下DNS解析開銷是整個網(wǎng)絡(luò)請求中不可忽略的一部分。在弱網(wǎng)環(huán)境下，基于UDP的LocalDNS解析非常容易出現(xiàn)解析超時的問題，并且即使解析成功會消耗數(shù)百毫秒乃至更甚，對我們整個業(yè)務(wù)請求而言是非常不利的，它直接影響了客戶的體驗(yàn)。對于一個比較大眾的應(yīng)用而言，DNS的優(yōu)化對整個應(yīng)...
移動場景下DNS解析開銷是整個網(wǎng)絡(luò)請求中不可忽略的一部分。在弱網(wǎng)環(huán)境下，基于UDP的LocalDNS解析非常容易出現(xiàn)解析超時的問題，并且即使解析成功會消耗數(shù)百毫秒乃至更甚，對我們整個業(yè)務(wù)請求而言是非常不利的，它直接影響了客戶的體驗(yàn)。對于一個比較大眾的應(yīng)用而言，DNS的優(yōu)化對整個應(yīng)用的網(wǎng)絡(luò)優(yōu)化所占的權(quán)重是很大的。我們接下來從以下幾個方面全面理解DNS，相信對我們開發(fā)中的網(wǎng)絡(luò)優(yōu)化會有不小的幫助。
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ù)是用來將主機(jī)名和域名轉(zhuǎn)換為IP地址的工作。
作為網(wǎng)絡(luò)通信的最靠前的一個環(huán)節(jié)，其在整個網(wǎng)絡(luò)通信的過程中的重要性不言而喻。
1.2 DNS解析相關(guān)概念
1.2.2 權(quán)威DNS
在 DNS 的解析過程中，用戶向遞歸 DNS 發(fā)起請求，遞歸 DNS 向權(quán)威 DNS 請求解析結(jié)果，可以說遞歸 DNS 起到一種轉(zhuǎn)發(fā)的作用。ISP DNS 就是遞歸 DNS；同時一些個人或互聯(lián)網(wǎng)服務(wù)提供商也會架設(shè)自己的遞歸 DNS 開放給所有人使用，稱為公共 DNS。
全國DNS匯總: ?www.114dns.com/DNS_List.ht… ?ipip: tools.ipip.net/dns.php
1.2.5 轉(zhuǎn)發(fā)DNS可以理解為遞歸DNS和用戶之間的一個中轉(zhuǎn)站，它不提供直接解析域名的服務(wù)，它將請求轉(zhuǎn)發(fā)給遞歸DNS，然后將遞歸DNS的結(jié)果轉(zhuǎn)發(fā)一下，也提供緩存作用。比如，日常家用的路由器，它的DNS服務(wù)器一般都是192.168.1.1，只是轉(zhuǎn)發(fā)給遞歸DNS。
如果當(dāng)LocalDNS緩存的有baidu.com對應(yīng)的結(jié)果，那么他就不會像百度的權(quán)威服務(wù)器查詢其對應(yīng)的ip，而是直接返回緩存中的結(jié)果。如果此時權(quán)威服務(wù)器中的baidu.com對應(yīng)的ip發(fā)生了變化，LocalDNS沒有及時更新，這樣會導(dǎo)致用戶訪問不到服務(wù)器。4.3 轉(zhuǎn)發(fā)解析 你用手機(jī)訪問baidu.com時，會到當(dāng)前運(yùn)營商的DNS服務(wù)器查，然后運(yùn)營商的DNS服務(wù)再去百度權(quán)威服務(wù)器去查，最終把權(quán)威服務(wù)器中的正確ip返回。上面是正常的情況，但是如果當(dāng)前運(yùn)營商(比如聯(lián)通)的LocalDNS不訪問百度權(quán)威DNS服務(wù)器，而是直接訪問了其它運(yùn)營商(比如電信)的LocalDNS服務(wù)器，有些小的運(yùn)營商就是通過這樣做來降低成本。如果電信的LocalDNS對非自家ip的訪問限了速那么很明顯會影響你的DNS解析時間。如果你應(yīng)用中的某些服務(wù)需要運(yùn)營商信息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
HTTPDNS使用HTTP與DNS服務(wù)器交互，代替?zhèn)鹘y(tǒng)的基于UDP的DNS協(xié)議，域名解析請求直接發(fā)送到HTTPDNS服務(wù)端，從而繞過運(yùn)營商的Local DNS
上述過程中，和HTTPDNS有關(guān)的是第3步，客戶端需要驗(yàn)證服務(wù)端下發(fā)的證書，驗(yàn)證過程有以下兩個要點(diǎn)：
UDP通信過程簡單，只需要一個查詢包和一個響應(yīng)包。
版權(quán)申明：內(nèi)容來源網(wǎng)絡(luò)，版權(quán)歸原創(chuàng)者所有。除非無法確認(rèn)，都會標(biāo)明作者及出處，如有侵權(quán)煩請告知，我們會立即刪除并致歉。謝謝!
1. DNS
1.1 認(rèn)識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ù)是用來將主機(jī)名和域名轉(zhuǎn)換為IP地址的工作。
作為網(wǎng)絡(luò)通信的最靠前的一個環(huán)節(jié)，其在整個網(wǎng)絡(luò)通信的過程中的重要性不言而喻。
1.2 DNS解析相關(guān)概念
1.2.1 DNS域名層次結(jié)構(gòu)
DNS是一種分層結(jié)構(gòu)，在整個互聯(lián)網(wǎng)中組成一個樹狀系統(tǒng)，頂層是系統(tǒng)的根域名，下層為TLD以及二級域名，葉子就構(gòu)成了所謂的FQDN（Fully Qualified Domain Names），根域名通常使用"."來表示，其實(shí)際上也是由域名組成，全世界目前有13組域名根節(jié)點(diǎn)，由少數(shù)幾個國家進(jìn)行管理，而國內(nèi)僅有幾臺根節(jié)點(diǎn)鏡像。權(quán)威DNS是經(jīng)過上一級授權(quán)對域名進(jìn)行解析的服務(wù)器，同時它可以把解析授權(quán)轉(zhuǎn)授給其他人，如COM頂級服務(wù)器可以授權(quán)xxorg.com這個域名的的權(quán)威服務(wù)器為NS.ABC.COM，同時NS.ABC.COM還可以把授權(quán)轉(zhuǎn)授給NS.DDD.COM，這樣NS.DDD.COM就成了ABC.COM實(shí)際上的權(quán)威服務(wù)器了。平時我們解析域名的結(jié)果都源自權(quán)威DNS。eg: 阿里云云解析 ?[https://wanwang.aliyun.com/domain/dns](https://wanwang.aliyun.com/domain/dns)?
復(fù)制代碼1.2.3 遞歸DNS
遞歸DNS又稱為Local DNS，它沒有域名解析結(jié)果的決定權(quán)，但代理了用戶向權(quán)威DNS獲取域名解析結(jié)果的過程。遞歸DNS上有緩存模塊，當(dāng)目標(biāo)域名存在緩存解析結(jié)果并且TTL未過期時（每個域名都有TTL時間，即有效生存時間，若域名解析結(jié)果緩存的時間超過TTL，需要重新向權(quán)威DNS獲取解析結(jié)果），遞歸DNS會返回緩存結(jié)果，否則，遞歸DNS會一級一級地查詢各個層級域名的權(quán)威DNS直至獲取最終完整域名的解析結(jié)果。eg: 我們自己的電腦，運(yùn)營商提供的dns服務(wù)器等等。
1.2.4 公共DNS
公共DNS是遞歸DNS的一種特例，它是一種全網(wǎng)開放的遞歸DNS服務(wù)，而傳統(tǒng)的遞歸DNS信息一般由運(yùn)營商分發(fā)給用戶。在 DNS 的解析過程中，用戶向遞歸 DNS 發(fā)起請求，遞歸 DNS 向權(quán)威 DNS 請求解析結(jié)果，可以說遞歸 DNS 起到一種轉(zhuǎn)發(fā)的作用。ISP DNS 就是遞歸 DNS；同時一些個人或互聯(lián)網(wǎng)服務(wù)提供商也會架設(shè)自己的遞歸 DNS 開放給所有人使用，稱為公共 DNS。
全國DNS匯總: ?www.114dns.com/DNS_List.ht… ?ipip: tools.ipip.net/dns.php
1.2.5 轉(zhuǎn)發(fā)DNS可以理解為遞歸DNS和用戶之間的一個中轉(zhuǎn)站，它不提供直接解析域名的服務(wù)，它將請求轉(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,用來指定域名對應(yīng)的ip,例如將www.hello.com指定到 113.112.3.xxx, A記錄可以將多個域名解析到一個ip地址，但是不能講一個域名解析到多個ip地址 - MIX記錄：
Mail Exchange，就是可以將某個域名下的郵件服務(wù)器直線給自己的Mail Server - CNAME記錄：
Canonical Name，即別名解析。
所謂別名解析就是可以為一個域名設(shè)置一個或者多個別名，如將aaa.com解析到bbb.net、將ccc.com也解析到bbb.net，其中bbb.net分別是aaa.com和ccc.com的別名 - NS記錄：
為某個域名指定DNS解析服務(wù)器，也就是這個域名由指定的IP地址的DNS服務(wù)器解析 - TXT記錄：
為某個主機(jī)名或域名設(shè)置說明，如可以為ucloud.cn是指TXT記錄為“中立安全科信賴”這樣的說明
1.4 域名解析過程
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 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 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 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 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.
;; 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
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的過程：- 終端向 Local DNS發(fā)起域名解析請求
- Local DNS在獲取到域名請求后，首先從Root hins獲取根域名服務(wù)器的地址(Root hints包含了互聯(lián)網(wǎng)DNS根服務(wù)器的地址信息)
- 獲取到了根域名服務(wù)器地址后，Local DNS向根域名服務(wù)器發(fā)起DNS解析請求，根域名服務(wù)器返回頂級域名服務(wù)器地址(com或者cn或者其它)
- 隨后Local DNS向com域名服務(wù)器發(fā)起解析請求，并得到baidu.com二級域名服務(wù)器地址
- Local DNS向baidu.com二級域名服務(wù)器發(fā)起解析請求，并最終貨到了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)配，保證使用戶的請求能被離用戶最近或者服務(wù)質(zhì)量更好的服務(wù)器來處理。從而確保服務(wù)質(zhì)量。能通過判斷服務(wù)器的負(fù)載，包括CPU占用、帶寬占用等數(shù)據(jù)，決定服務(wù)器的可用性，同時能判斷用戶（訪問者）與服務(wù)器間的鏈路狀況，選擇鏈路狀況最好的服務(wù)器。因此GSLB是對服務(wù)器和鏈路進(jìn)行綜合判斷來決定由哪個地點(diǎn)的服務(wù)器來提供服務(wù)，實(shí)現(xiàn)異地服務(wù)器群服務(wù)質(zhì)量的保證。3.1 ?智能DNS
智能DNS是GSLB的一種應(yīng)用。4. DNS解析存在的問題
有時候我們在訪問百度或者在應(yīng)用中發(fā)出一個http請求時，如果DNS解析被劫持，我們可能最終訪問到的不是我們想要訪問的服務(wù)器。4.1 運(yùn)營商劫持
DNS劫持 就是通過劫持了 DNS 服務(wù)器，通過某些手段取得某域名的解析記錄控制權(quán)，進(jìn)而修改此域名的解析結(jié)果，導(dǎo)致對該域名的訪問由原 IP 地址轉(zhuǎn)入到修改后的指定 IP，其結(jié)果就是對特定的網(wǎng)址不能訪問或訪問的是假網(wǎng)址，從而實(shí)現(xiàn)竊取資料或者破壞原有正常服務(wù)的目的。4.2 DNS解析域名時緩存解析結(jié)果
我們在開發(fā)中有時候會遇到這樣的情況：你是一個聯(lián)通用戶，你在手機(jī)瀏覽器中輸入baidu.com，由一個LocalDNS服務(wù)器像百度權(quán)威服務(wù)器查應(yīng)該訪問哪一臺服務(wù)器，權(quán)威把結(jié)果返回給LocalDNS服務(wù)器,localDNS服務(wù)器返回結(jié)果給用戶。如果當(dāng)LocalDNS緩存的有baidu.com對應(yīng)的結(jié)果，那么他就不會像百度的權(quán)威服務(wù)器查詢其對應(yīng)的ip，而是直接返回緩存中的結(jié)果。如果此時權(quán)威服務(wù)器中的baidu.com對應(yīng)的ip發(fā)生了變化，LocalDNS沒有及時更新，這樣會導(dǎo)致用戶訪問不到服務(wù)器。
我直接ping百度的地址，然后用wireshark抓包結(jié)果，正常結(jié)果如下：
如果發(fā)生了轉(zhuǎn)發(fā)則邏輯如下：
5.1 什么是HTTPDNS
HTTPDNS使用HTTP與DNS服務(wù)器交互，代替?zhèn)鹘y(tǒng)的基于UDP的DNS協(xié)議，域名解析請求直接發(fā)送到HTTPDNS服務(wù)端，從而繞過運(yùn)營商的Local DNS
5.2 HTTPDNS的特性
5.2.1 防止域名劫持
由于 HttpDns 是通過 IP 直接請求 HTTP 獲取服務(wù)器 A 記錄地址，不存在向本地運(yùn)營商詢問 domain 解析過程，所以從根本避免了劫持問題。5.2.2 精準(zhǔn)調(diào)度
HTTPDNS能夠直接獲取到用戶的IP地址，從而實(shí)現(xiàn)精確定位與導(dǎo)流5.2.3 用戶連接失敗率下降
通過算法降低以往失敗率過高的服務(wù)器排序，通過時間近期訪問過的數(shù)據(jù)提高服務(wù)器排序，通過歷史訪問成功記錄提高服務(wù)器排序。原來的請求地址為 “apis.juhe.cn/simpleWeath…”，通過HTTPDNS替換域名后最終的結(jié)果如下：5.3 HTTPS IP Content
發(fā)送HTTPS請求首先要進(jìn)行SSL/TLS握手，握手過程大致如下：- 客戶端發(fā)起握手請求，攜帶隨機(jī)數(shù)、支持算法列表等參數(shù)。
- 服務(wù)端收到請求，選擇合適的算法，下發(fā)公鑰證書和隨機(jī)數(shù)。
- 客戶端對服務(wù)端證書進(jìn)行校驗(yàn)，并發(fā)送隨機(jī)數(shù)信息，該信息使用公鑰加密。
- 服務(wù)端通過私鑰獲取隨機(jī)數(shù)信息。
- 雙方根據(jù)以上交互的信息生成session ticket，用作該連接后續(xù)數(shù)據(jù)傳輸?shù)募用苊荑€。
上述過程中，和HTTPDNS有關(guān)的是第3步，客戶端需要驗(yàn)證服務(wù)端下發(fā)的證書，驗(yàn)證過程有以下兩個要點(diǎn)：
- 客戶端用本地保存的根證書解開證書鏈，確認(rèn)服務(wù)端下發(fā)的證書是由可信任的機(jī)構(gòu)頒發(fā)的。
- 客戶端需要檢查證書的domain域和擴(kuò)展域，看是否包含本次請求的host。
6.問題
6.1 主機(jī)是如何知道DNS服務(wù)器地的IP地址的？
通過DHCP動態(tài)獲得，或者手工配置的。DHCP協(xié)議：DHCP（Dynamic Host Configuration Protocol，動態(tài)主機(jī)配置協(xié)議）通常被應(yīng)用在大型的局域網(wǎng)絡(luò)環(huán)境中，主要作用是集中的管理、分配IP地址，使網(wǎng)絡(luò)環(huán)境中的主機(jī)動態(tài)的獲得IP地址、Gateway地址、DNS服務(wù)器地址等信息，并能夠提升地址的使用率。6.2 為什么DNS采用UDP協(xié)議 ？
TCP通信過程太復(fù)雜并且開銷大，一次TCP交換需要9個包：三個連接包，四個斷開包，一個request包，一個響應(yīng)包。UDP通信過程簡單，只需要一個查詢包和一個響應(yīng)包。
版權(quán)申明：內(nèi)容來源網(wǎng)絡(luò)，版權(quán)歸原創(chuàng)者所有。除非無法確認(rèn)，都會標(biāo)明作者及出處，如有侵權(quán)煩請告知，我們會立即刪除并致歉。謝謝!
下載文檔
