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

/domain/dns

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

/product/httpdns

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

/doc/rfc7871

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

/product/httpdns

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

/domain/dns

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