產(chǎn)品知識庫-泠茗-移動(dòng)互聯(lián)網(wǎng)時(shí)代,如何優(yōu)化你地網(wǎng)絡(luò)-域名解析篇

移動(dòng)互聯(lián)網(wǎng)時(shí)代，如何優(yōu)化你的網(wǎng)絡(luò)——域名解析篇域名(DomainName)，是由一串用點(diǎn)分隔的名字組成的互聯(lián)網(wǎng)上某臺計(jì)算機(jī)或某組計(jì)算機(jī)的標(biāo)識，它的目的是為了方便人們更簡單便捷地訪問互聯(lián)網(wǎng)上的服務(wù)。在實(shí)際的系統(tǒng)實(shí)現(xiàn)中，域名通過DNS（DomainNameSystem）系統(tǒng)轉(zhuǎn)化為服務(wù)器的IP地址，以方便機(jī)器通過IP進(jìn)行尋址和通信。上述行為，我們稱之為域名解析。作為一次網(wǎng)絡(luò)通信最前置的環(huán)節(jié)，域名解析的重要性不言而喻。在傳統(tǒng)的基于瀏覽器的網(wǎng)站訪問場景下，域名解析環(huán)節(jié)由瀏覽器內(nèi)核實(shí)現(xiàn)，網(wǎng)站開發(fā)者無需關(guān)心域名解析的細(xì)節(jié)。Buttherearealwaystwosidestoeverycoin，一旦域名解析環(huán)節(jié)發(fā)生異常，開發(fā)者面對這樣的黑盒架構(gòu)就會(huì)顯得束手無策，一個(gè)很典型的例子即域名劫持問題，關(guān)于這一點(diǎn)我們在后文會(huì)有更詳細(xì)的介紹。進(jìn)入移動(dòng)互聯(lián)網(wǎng)時(shí)代，大量的應(yīng)用基于C/S架構(gòu)構(gòu)建。相較于傳統(tǒng)的面向?yàn)g覽器的WebApp，C/S架構(gòu)的應(yīng)用賦予了我們非常大的軟件定制空間，開發(fā)者甚至可以滲透到整個(gè)應(yīng)用的底層網(wǎng)絡(luò)實(shí)現(xiàn)當(dāng)中，域名解析環(huán)節(jié)的優(yōu)化因此變?yōu)榱丝赡?。本篇文章我們就一起來看一看傳統(tǒng)域名解析存在的問題，對應(yīng)的根源，以及可能的優(yōu)化方案。關(guān)于域名解析，你應(yīng)該知道的基本概念在了解傳統(tǒng)域名解析的流程之前，有幾個(gè)專有名詞我們需要了解一下：根域、頂級域、二級域DNS系統(tǒng)一般采用樹狀結(jié)構(gòu)進(jìn)行組織，以為例，org為頂級域名，wikipedia為二級域名，ru為三級域名，域名樹狀組織結(jié)構(gòu)如下圖所示。權(quán)威DNS權(quán)威DNS即最終決定域名解析結(jié)果的服務(wù)器，開發(fā)者可以在權(quán)威DNS上配置、變更、刪除具體域名的對應(yīng)解析結(jié)果信息。阿里云云解析（

/domain/dns

）即權(quán)威DNS服務(wù)提供商。遞歸DNS遞歸DNS又稱為LocalDNS，它沒有域名解析結(jié)果的決定權(quán)，但代理了用戶向權(quán)威DNS獲取域名解析結(jié)果的過程。遞歸DNS上有緩存模塊，當(dāng)目標(biāo)域名存在緩存解析結(jié)果并且TTL未過期時(shí)（每個(gè)域名都有TTL時(shí)間，即有效生存時(shí)間，若域名解析結(jié)果緩存的時(shí)間超過TTL，需要重新向權(quán)威DNS獲取解析結(jié)果），遞歸DNS會(huì)返回緩存結(jié)果，否則，遞歸DNS會(huì)一級一級地查詢各個(gè)層級域名的權(quán)威DNS直至獲取最終完整域名的解析結(jié)果。關(guān)于域名解析的具體流程下文會(huì)舉例說明。公共DNS公共DNS是遞歸DNS的一種特例，它是一種全網(wǎng)開放的遞歸DNS服務(wù)，而傳統(tǒng)的遞歸DNS信息一般由運(yùn)營商分發(fā)給用戶。一個(gè)比較典型的公共DNS即Google的，我們可以通過在操作系統(tǒng)配置文件中配置公共DNS來代替LocalDNS完成域名解析流程。在實(shí)際的使用過程中，我們通常不需要手工指定自己的LocalDNS地址。運(yùn)營商會(huì)通過DHCP協(xié)議在系統(tǒng)網(wǎng)絡(luò)初始化階段將LocalDNS地址分配給我們的計(jì)算機(jī)。當(dāng)我們需要使用公共DNS服務(wù)時(shí)，我們就必須手工指定這些服務(wù)的地址。以Linux為例，我們可以通過在'/etc/resolv.conf'中添加LocalDNS地址項(xiàng)來改變本機(jī)LocalDNS的地址。了解了上述域名解析相關(guān)的常見術(shù)語，我們再來仔細(xì)看一看一次域名解析流程具體是如何發(fā)生的。如上圖所示，以訪問為例，一次完整的域名解析流程包括：終端向LocalDNS發(fā)起域名解析請求；LocalDNS在獲取到域名解析請求后首先從Roothints獲取根域名服務(wù)器的地址（Roothints包含了互聯(lián)網(wǎng)DNS根服務(wù)器的地址信息）；獲取了根域名服務(wù)器地址后LocalDNS向根域名服務(wù)器發(fā)起DNS解析請求，根域名服務(wù)器返回com頂級域名服務(wù)器地址；隨后LocalDNS向com域名服務(wù)器發(fā)起解析請求，并得到二級域名服務(wù)器的地址；LocalDNS向二級域名服務(wù)器發(fā)起解析請求，并最終獲得了的IP地址信息；LocalDNS將遞歸查詢獲得的IP地址信息緩存并返回給客戶端；LocalDNS服務(wù)器包含緩存模塊，在實(shí)際域名解析過程中LocalDNS服務(wù)器會(huì)首先查詢緩存，緩存命中且解析結(jié)果TTL未過期的情況下直接返回，否則才啟動(dòng)遞歸查詢的流程。傳統(tǒng)的域名解析面臨的問題了解了域名解析的基本概念和整體流程，我們再一起來探究一下傳統(tǒng)域名解析存在的一系列問題。域名劫持域名劫持一直是困擾許多開發(fā)者的問題之一，其表現(xiàn)即域名A應(yīng)該返回的DNS解析結(jié)果IP1被惡意替換為了IP2，導(dǎo)致A的訪問失敗或訪問了一個(gè)不安全的站點(diǎn)。下面我們一起看看幾種常見的域名劫持的場景。一種可能的域名劫持方式即黑客侵入了寬帶路由器并對終端用戶的LocalDNS進(jìn)行篡改，指向黑客自己偽造的LocalDNS，進(jìn)而通過控制LocalDNS的邏輯返回錯(cuò)誤的IP信息進(jìn)行域名劫持。另一方面，由于DNS解析主要是基于UDP協(xié)議，除了上述攻擊行為外，攻擊者還可以監(jiān)聽終端用戶的域名解析請求，并在LocalDNS返回正確結(jié)果之前將偽造的DNS解析響應(yīng)傳遞給終端用戶，進(jìn)而控制終端用戶的域名訪問行為。上述攻擊行為的影響面相對比較有限，另一種我們最常碰到的域名劫持現(xiàn)象是緩存污染。我們知道在接收到域名解析請求時(shí)，LocalDNS首先會(huì)查找緩存，如果緩存命中就會(huì)直接返回緩存結(jié)果，不再進(jìn)行遞歸DNS查詢。這時(shí)候如果LocalDNS針對部分域名的緩存進(jìn)行更改，比如將緩存結(jié)果指向第三方的廣告頁，就會(huì)導(dǎo)致用戶的訪問請求被引導(dǎo)到這些廣告頁地址上。對比第一種攻擊，這類緩存污染往往能帶來更明顯的群體傷害，比如某個(gè)省份某個(gè)運(yùn)營商的用戶群可能因?yàn)樵摰貐^(qū)LocalDNS的緩存污染而導(dǎo)致訪問服務(wù)異常。這類緩存污染行為往往是間歇性、局部性發(fā)生的，沒有明顯的規(guī)律，導(dǎo)致開發(fā)者很難對其進(jìn)行量化、評估、預(yù)防。有的同學(xué)可能會(huì)問，“我使用了HTTPS，是否就可以避免域名劫持的問題”，答案是否定的。域名解析環(huán)節(jié)發(fā)生在網(wǎng)絡(luò)加密請求交互之前，試想一下，如果客戶端還沒有服務(wù)端的確切地址信息，我們又如何知道應(yīng)該和誰進(jìn)行加密的握手協(xié)商與通信呢？調(diào)度不精準(zhǔn)除了域名劫持問題，基于傳統(tǒng)LocalDNS的域名解析還會(huì)帶來域名調(diào)度精準(zhǔn)性的問題。對于類似CDN域名訪問這類需要按地域、運(yùn)營商進(jìn)行智能解析調(diào)度的場景，精準(zhǔn)調(diào)度的訴求是十分強(qiáng)烈的。關(guān)于調(diào)度不精準(zhǔn)的原因，我們主要可以從兩個(gè)方面來探究一下。第一個(gè)常見的問題即解析轉(zhuǎn)發(fā)。部分LocalDNS供應(yīng)商為了降低運(yùn)營成本，會(huì)將請求到自己節(jié)點(diǎn)的域名解析請求轉(zhuǎn)發(fā)給其他供應(yīng)商的LocalDNS節(jié)點(diǎn)，如上圖所示。假如用戶請求解析一個(gè)CDN域名，用戶分配到的LocalDNSA為了節(jié)省成本，把該次請求轉(zhuǎn)發(fā)給了另一運(yùn)營商的LocalDNSB，權(quán)威DNS在進(jìn)行域名解析時(shí)會(huì)根據(jù)LocalDNS的IP信息進(jìn)行智能調(diào)度，即權(quán)威DNS會(huì)根據(jù)LocalDNSB的IP進(jìn)行調(diào)度，分配與相同運(yùn)營商并且地理位置最近的CDN節(jié)點(diǎn)，然而這個(gè)CDN節(jié)點(diǎn)對于終端而言并不是最優(yōu)的CDN節(jié)點(diǎn)，他們分屬不同的運(yùn)營商，并且地理位置上可能相隔很遠(yuǎn)。這類解析轉(zhuǎn)發(fā)行為會(huì)嚴(yán)重影響域名解析的精準(zhǔn)性并對用戶業(yè)務(wù)訪問延遲帶來影響。除了解析轉(zhuǎn)發(fā)對調(diào)度精準(zhǔn)性帶來的影響外，LocalDNS的布署情況同樣影響著域名智能解析的精準(zhǔn)性。如上圖所示，部分運(yùn)營商LocalDNS的布點(diǎn)受成本因素制約分布并不均勻，比如在東部地區(qū)部署比較密集，但在西部地區(qū)部署比較稀疏。這時(shí)候當(dāng)一位西藏的用戶準(zhǔn)備訪問CDN節(jié)點(diǎn)時(shí)，我們預(yù)期他應(yīng)該會(huì)被調(diào)度到西藏的CDN節(jié)點(diǎn)A上以實(shí)現(xiàn)就近接入和訪問加速。但由于LocalDNS的資源有限，西部地區(qū)的終端用戶被統(tǒng)一調(diào)度到青海的LocalDNSB上，這時(shí)候權(quán)威DNS根據(jù)LocalDNSB的IP進(jìn)行CDN域名的智能解析，并將青海的CDN節(jié)點(diǎn)B返回給西藏用戶，導(dǎo)致用戶的網(wǎng)絡(luò)訪問延遲上升。另一種我們實(shí)際發(fā)現(xiàn)的情況是LocalDNS的分配甚至并非遵循就近原則，比如有實(shí)際案例顯示西藏的用戶甚至被分配了北京的LocalDNS節(jié)點(diǎn)C，導(dǎo)致西藏的用戶在進(jìn)行CDN資源訪問時(shí)被調(diào)度到了北京的CDN節(jié)點(diǎn)C上，類似的由于調(diào)度精度的缺失帶來的訪問體驗(yàn)的影響是非常嚴(yán)重的。解析生效滯后部分業(yè)務(wù)場景下開發(fā)者對域名解析結(jié)果變更的生效時(shí)間非常敏感（這部分變更操作是開發(fā)者在權(quán)威DNS上完成的），比如當(dāng)業(yè)務(wù)服務(wù)器受到攻擊時(shí)，我們需要最快速地將業(yè)務(wù)IP切換到另一組集群上，這樣的訴求在傳統(tǒng)域名解析體系下是無法完成的。LocalDNS的部署是由各個(gè)地區(qū)的各個(gè)運(yùn)營商獨(dú)立部署的，因此各個(gè)LocalDNS的服務(wù)質(zhì)量參差不齊。在對域名解析緩存的處理上，各個(gè)獨(dú)立節(jié)點(diǎn)的實(shí)現(xiàn)策略也有區(qū)別，比如部分節(jié)點(diǎn)為了節(jié)省開支忽略了域名解析結(jié)果的TTL時(shí)間限制，導(dǎo)致用戶在權(quán)威DNS變更的解析結(jié)果全網(wǎng)生效的周期非常漫長（我們已知的最長生效時(shí)間甚至高達(dá)48小時(shí)）。這類延遲生效可能直接導(dǎo)致用戶業(yè)務(wù)訪問的異常。延遲大DNS首次查詢或緩存過期后的查詢，需要遞歸遍歷多個(gè)DNS服務(wù)器以獲取最終的解析結(jié)果，這增加了網(wǎng)絡(luò)請求的前置延時(shí)時(shí)間。特別是在移動(dòng)互聯(lián)網(wǎng)場景下，移動(dòng)網(wǎng)絡(luò)質(zhì)量參差不齊，弱網(wǎng)環(huán)境的RTT時(shí)間可能高達(dá)數(shù)百毫秒，對于一次普通的業(yè)務(wù)請求而言，上述延時(shí)是非常沉重的負(fù)擔(dān)。另一方面，弱網(wǎng)環(huán)境下的解析超時(shí)、解析失敗等現(xiàn)象屢見不鮮，如何合理優(yōu)化DNS解析對于整體網(wǎng)絡(luò)訪問質(zhì)量的提升至關(guān)重要。HTTPDNS通過上文的介紹，聰明的讀者應(yīng)該可以發(fā)現(xiàn)，傳統(tǒng)域名解析面臨的諸多問題與挑戰(zhàn)本質(zhì)根源在于LocalDNS的服務(wù)質(zhì)量不可控，如果有一個(gè)更安全、穩(wěn)定、高效的遞歸DNS服務(wù)幫助我們代理了域名解析的過程，上述問題看起來就可以徹底地得到解決。HTTPDNS在這樣的背景下應(yīng)運(yùn)而生。我們一起來看看HTTPDNS的基本概念以及它是如何解決傳統(tǒng)DNS解析面臨的問題的。防域名劫持HTTPDNS使用HTTP協(xié)議進(jìn)行域名解析，代替現(xiàn)有基于UDP的DNS協(xié)議，域名解析請求直接發(fā)送到HTTPDNS服務(wù)端，從而繞過運(yùn)營商的LocalDNS，如下圖所示。HTTPDNS代替了傳統(tǒng)的LocalDNS完成遞歸解析的功能，基于HTTP協(xié)議的設(shè)計(jì)可以適用于幾乎所有的網(wǎng)絡(luò)環(huán)境，同時(shí)保留了鑒權(quán)、HTTPS等更高安全性的擴(kuò)展能力，避免惡意攻擊劫持行為。另一方面，商業(yè)化的HTTPDNS服務(wù)（

/product/httpdns

）緩存管理有嚴(yán)格的SLA保障，避免了類似LocalDNS的緩存污染的問題。精準(zhǔn)調(diào)度傳統(tǒng)域名解析的調(diào)度精準(zhǔn)性問題，本質(zhì)根源在于LocalDNS的部署和分配機(jī)制上。由于碎片化的管理方式，這些環(huán)節(jié)的服務(wù)質(zhì)量同樣很難得到保障。HTTPDNS在遞歸解析實(shí)現(xiàn)上優(yōu)化了與權(quán)威DNS的交互，通過edns-client-subnet協(xié)議（

/doc/rfc7871

）將終端用戶的IP信息直接交付給權(quán)威DNS，這樣權(quán)威DNS就可以忽略LocalDNSIP信息，根據(jù)終端用戶的IP信息進(jìn)行精準(zhǔn)調(diào)度，避免LocalDNS的坐標(biāo)干擾（當(dāng)然上述精準(zhǔn)調(diào)度方案的前提是權(quán)威DNS需要支持edns-client-subnet，可喜的是當(dāng)前主流的權(quán)威DNS服務(wù)都已支持該協(xié)議）。精準(zhǔn)調(diào)度的流程示例如下。實(shí)時(shí)生效在域名解析生效周期方面，HTTPDNS也有著傳統(tǒng)域名解析體系所無法具備的能力。前文中我們提到由于各個(gè)地區(qū)的LocalDNS是獨(dú)立維護(hù)的，服務(wù)質(zhì)量參差不齊，緩存實(shí)現(xiàn)不一，因此導(dǎo)致的解析變更全網(wǎng)生效滯后的問題，在商業(yè)化的HTTPDNS服務(wù)上就不會(huì)存在（HTTPDNS嚴(yán)格遵循DNSTTL限制進(jìn)行緩存更新）。另一方面，即便我們假設(shè)LocalDNS嚴(yán)格遵循域名TTL時(shí)間進(jìn)行緩存管理（這里我們假設(shè)開發(fā)者配置的域名TTL時(shí)間為5min），當(dāng)開發(fā)者業(yè)務(wù)受到攻擊并需要快速進(jìn)行切換時(shí)，LocalDNS也會(huì)遵循域名TTL，在持續(xù)5min的時(shí)間段內(nèi)返回舊IP信息，這5min的業(yè)務(wù)影響對于中大型企業(yè)而言是一個(gè)不小的損失（對于電商類的大型企業(yè)，5min的訪問異常可能意味著幾百萬的交易額下跌）。以阿里云HTTPDNS服務(wù)（

/product/httpdns

）為例，HTTPDNS在快速生效方面有專有的方案，配合阿里云的權(quán)威DNS服務(wù)云解析（

/domain/dns

），用戶在權(quán)威DNS變更的解析結(jié)果將快速同步給HTTPDNS，覆蓋原有的緩存記錄，幫助用戶實(shí)現(xiàn)秒級的域名解析切換。在DNS解析延遲方面，由于HTTPDNS基于HTTP協(xié)議，而HTTP基于TCP協(xié)議，對比傳統(tǒng)的UDP傳輸多了一些冗余的握手環(huán)節(jié)，因此從原理上而言網(wǎng)絡(luò)請求方面的開銷并沒有降低。但在實(shí)際使用過程中，我們可以通過端上的策略來實(shí)現(xiàn)一個(gè)零延遲DNS解析的方案。接下來我們一起來看看HTTPDNS服務(wù)在移動(dòng)端的最佳實(shí)踐方案。實(shí)時(shí)生效的流程如下圖所示。域名解析最佳實(shí)踐通過HTTPDNS服務(wù)，我們可以實(shí)現(xiàn)包括防止域名劫持、精準(zhǔn)調(diào)度、實(shí)時(shí)解析生效等功能，但在DNS解析開銷的優(yōu)化上，我們需要客戶端一起配合。預(yù)解析絕大多數(shù)的APP在應(yīng)用初始化階段都有一個(gè)啟動(dòng)期，我們可以在這個(gè)啟動(dòng)期做一些preflight工作，即在初始化階段我們可以針對業(yè)務(wù)的熱點(diǎn)域名在后臺發(fā)起異步的HTTPDNS解析請求。這部分預(yù)解析結(jié)果在后續(xù)的業(yè)務(wù)請求中可以直接使用，進(jìn)而消除首次業(yè)務(wù)請求的DNS解析開銷，提升APP首頁的加載速度。在客戶端實(shí)際使用HTTPDNS的過程中，有一個(gè)大家需要關(guān)注的點(diǎn)。標(biāo)準(zhǔn)的Web服務(wù)器（以Nginx為例）一般會(huì)將HTTP請求頭中的Host頭的值作為請求的域名信息進(jìn)行處理（取決于服務(wù)端的配置，但一般情況都如此）。比如當(dāng)我們通過標(biāo)準(zhǔn)的網(wǎng)絡(luò)庫訪問/index.html這個(gè)地址時(shí)，發(fā)出的網(wǎng)絡(luò)請求一般是這樣的：>GET/index.htmlHTTP/1.1>Host:>User-Agent:curl/7.43.0>Accept:*/*使用HTTPDNS后，我們需要將HTTP請求URL中的Host域（注意這里的Host域指的是URL中的Host字段，而非HTTP請求頭中的Host頭）替換為HTTPDNS解析獲得的IP，這時(shí)由于標(biāo)準(zhǔn)的網(wǎng)絡(luò)庫會(huì)將URL中的Host域賦值給HTTP請求頭中的Host頭，發(fā)出的網(wǎng)絡(luò)請求如下：>GET/index.htmlHTTP/1.1>Host:>User-Agent:curl/7.43.0>Accept:*/*上述Host信息將導(dǎo)致服務(wù)端的解析異常（服務(wù)端配置的是域名信息，而非IP信息，試想一下如果我們的服務(wù)端服務(wù)了兩個(gè)域名和，這時(shí)候它接收到一個(gè)/index.html請求，它如何判斷應(yīng)該返回a的首頁還是b的首頁信息呢？）。為了解決這個(gè)問題，我們需要主動(dòng)設(shè)置HTTP請求Host頭的值，以Android的官方網(wǎng)絡(luò)庫HttpURLConnection為例：StringoriginalUrl=“/index.html";URLurl=newURL(originalURL);StringoriginalHost=url.getHost();//同步獲取IPStringip=httpdns.getIpByHost(originalHost);HttpURLConnectionconn;if(ip!=null){//通過HTTPDNS獲取IP成功，進(jìn)行URL替換和Host頭設(shè)置url=newURL(originalUrl.replaceFirst(originalHost,ip));conn=(HttpURLConnection)url.openConnection();//設(shè)置請求Host頭conn.setRequestProperty("Host",originHost);}else{conn=(HttpURLConnection)url.openConnection();}主動(dòng)設(shè)置Host頭后，發(fā)出的網(wǎng)絡(luò)請求就與未替換URL的網(wǎng)絡(luò)請求一模一樣了。智能緩存通過預(yù)解析獲取的IP有一定的TTL有效時(shí)間，我們需要合理地緩存下來進(jìn)行管理。操作系統(tǒng)本身的DNS緩存粒度比較粗，在客戶端我們可以應(yīng)用更細(xì)粒度的緩存管理來提升解析效率。比如在不同的網(wǎng)絡(luò)運(yùn)營商環(huán)境下，對CDN域名的解析結(jié)果會(huì)發(fā)生變化，當(dāng)我們使用電信WIFI時(shí)，DNS解析會(huì)返回就近的電信CDN節(jié)點(diǎn)IP，當(dāng)我們使用聯(lián)通3G時(shí)，DNS解析會(huì)返回就近的聯(lián)通CDN節(jié)點(diǎn)IP，針對不同運(yùn)營商的解析結(jié)果緩存可以確保我們在網(wǎng)絡(luò)切換時(shí)能夠快速地進(jìn)行網(wǎng)絡(luò)請求，減免DNS解析帶來的額外開銷。甚至更激