摘要：也就是說，在域名解析的時候，不會將用戶導(dǎo)向真正的網(wǎng)站，而是指向這個緩存的服務(wù)器。什么是其實很簡單是基于協(xié)議和域名解析的流量調(diào)度解決方案。這就相當(dāng)于每家基于協(xié)議，自己實現(xiàn)自己的域名解析，做一個自己的地址簿，而不使用統(tǒng)一的地址簿。

【前五篇】系列文章傳送門：

網(wǎng)絡(luò)協(xié)議 12 - HTTP 協(xié)議：常用而不簡單

網(wǎng)絡(luò)協(xié)議 13 - HTTPS 協(xié)議：加密路上無盡頭

網(wǎng)絡(luò)協(xié)議 14 - 流媒體協(xié)議：要說愛你不容易

網(wǎng)絡(luò)協(xié)議 15 - P2P 協(xié)議：小種子大學(xué)問

網(wǎng)絡(luò)協(xié)議 16 - DNS 協(xié)議：網(wǎng)絡(luò)世界的地址簿

????全球統(tǒng)一的 DNS 是很權(quán)威，但是我們都知道“適合自己的，才是最好的”。很多時候，標(biāo)準(zhǔn)統(tǒng)一化的 DNS 并不能滿足我們定制的需求，這個時候就需要 HTTPDNS 了。

????上一節(jié)我們知道了 DNS 可以根據(jù)名稱查地址，也可以針對多個地址做負(fù)載均衡。然而，我們信任的地址簿也會存在指錯路的情況。明明離你 500 米就有個吃飯的地方，非要把你推薦到 5 公里外。為什么會出現(xiàn)這樣的情況呢？

????還記得嗎？由我們發(fā)出請求解析 DNS 的時候，首先會連接到運營商本地的 DNS 服務(wù)器，由這個服務(wù)器幫我們?nèi)フ?“DNS 樹” 上進(jìn)行解析，然后將解析的結(jié)果返回給客戶端。但是本地的 DNS 服務(wù)器，作為一個本地導(dǎo)游，往往會有自己的“小心思”。

1）域名緩存問題
????它可以在本地做一個緩存。也就是說，不是每一個請求，它都會去訪問權(quán)威 DNS 服務(wù)器，而是把訪問過一次的結(jié)果緩存到本地，當(dāng)其他人來問的時候，直接返回緩存的內(nèi)容。

????這就相當(dāng)于導(dǎo)游去過一個飯店，自己記住了地址，當(dāng)有一個游客問的時候，他就憑記憶回答了，不用再去查地址簿。這樣會存在一個問題，游客問的那個飯店如果已經(jīng)搬走了，然而因為導(dǎo)游沒有刷新“記憶緩存”，導(dǎo)致游客白跑一趟。

????另外，有的運營商會把一些靜態(tài)頁面，緩存到本運營商的服務(wù)器內(nèi)，這樣用戶請求的時候，就不用跨運營商進(jìn)行訪問，既加快了速度，也減少了運營商直接流量計算的成本。也就是說，在域名解析的時候，不會將用戶導(dǎo)向真正的網(wǎng)站，而是指向這個緩存的服務(wù)器。

????緩存的問題，很多情況下是看不出問題的，但是當(dāng)頁面更新，用戶訪問到老的頁面，問題就出來了。

????再就是本地的緩存，往往使得全局負(fù)載均衡失敗。上次進(jìn)行緩存的時候，緩存中的地址不一定是客戶此次訪問離客戶最近的地方，如果把這個地址返回給客戶，就會讓客戶繞遠(yuǎn)路了。
2）域名轉(zhuǎn)發(fā)問題
????還記得我們域名解析的過程嗎？捂臉是本地域名解析，還是去權(quán)威 DNS 服務(wù)器中查找，都可以認(rèn)為是一種外包形式。有了請求，直接轉(zhuǎn)發(fā)給其他服務(wù)去解析。如果轉(zhuǎn)發(fā)的是權(quán)威 DNS 服務(wù)器還好說，但是如果因為“偷懶”轉(zhuǎn)發(fā)給了鄰居服務(wù)器去解析，就容易產(chǎn)生跨運營商訪問的問題。

????這就好像，如果 A 運營商的客戶，訪問自己運營商的 DNS 服務(wù)器，A 運營商去權(quán)威 DNS 服務(wù)器查詢的話，會查到客戶的 A 運營商的，返回一個部署在 A 運營商的網(wǎng)站地址，這樣針對相同運營商的訪問，速度就會快很多。

????但是如果 A 運營商偷懶，沒有轉(zhuǎn)發(fā)給權(quán)威 DNS ，而是轉(zhuǎn)發(fā)給了 B 運營商，讓 B 運營商再去權(quán)威 DNS 服務(wù)器查詢，這樣就會讓權(quán)威服務(wù)器誤認(rèn)為客戶是 B 運營商的，返回一個 B 運營商的服務(wù)器地址，導(dǎo)致客戶每次都要跨運營商訪問，訪問速度就會慢下來。

3）出口 NAT 問題
????前面了解網(wǎng)關(guān)的時候，我們知道，出口的時候，很多機(jī)房都會配置 NAT，也就是網(wǎng)絡(luò)地址轉(zhuǎn)換，使得從這個網(wǎng)關(guān)出去的包，都換成新的 IP 地址。

????這種情況下，權(quán)威 DNS 服務(wù)器就沒辦法通過請求 IP 來判斷客戶到底是哪個運營商的，很有可能誤判運營商，導(dǎo)致跨運營商訪問。

4）域名更新問題
????本地 DNS 服務(wù)器是由不同地區(qū)、不同運營商獨立部署的。對域名解析緩存的處理上，實現(xiàn)策略也有區(qū)別。有的會偷懶，忽略域名解析結(jié)構(gòu)的 TTL 時間限制，在權(quán)威 DNS 服務(wù)器解析變更的時候，解析結(jié)果在全網(wǎng)生效的周期非常漫長。但是有的場景，在 DNS 的切換中，對生效時間要求比較高。

????例如雙機(jī)房部署的是，跨機(jī)房的負(fù)載均衡和容災(zāi)多使用 DNS 來做。當(dāng)一個機(jī)房出問題之后，需要修改權(quán)威 DNS，將域名指向新的 IP 地址。但是如果更新太慢，很多用戶都會訪問一次。

5）解析延遲問題
????從 DNS 的查詢過程來看，DNS 的查詢過程需要遞歸遍歷多個 DNS 服務(wù)器，才能獲得最終的解析結(jié)果，這帶來一定的延時，甚至?xí)馕龀瑫r。

????上面總結(jié)了 DNS 的五個問題。問題有了，總得有解決辦法，就像因為 HTTP 的安全問題，才火了 HTTPS 協(xié)議一樣，對應(yīng)的，也有 HTTPDNS 來解決上述 DNS 出現(xiàn)的問題。

什么是 HTTPDNS ？其實很簡單：

HTTPDNS 是基于 HTTP 協(xié)議和域名解析的流量調(diào)度解決方案。它不走傳統(tǒng)的 DNS 解析，而是自己搭建基于 HTTP 協(xié)議的 DNS 服務(wù)器集群，分布在多個地點和多個運營商。當(dāng)客戶端需要 DNS 解析的時候，直接通過 HTTP 請求這個服務(wù)器集群，得到就近的地址。

????這就相當(dāng)于每家基于 HTTP 協(xié)議，自己實現(xiàn)自己的域名解析，做一個自己的地址簿，而不使用統(tǒng)一的地址簿。但是我們知道，域名解析默認(rèn)都是走 DNS 的，因而使用 HTTPDNS 需要繞過默認(rèn)的 DNS 路徑，也就不能使用默認(rèn)的客戶端。**使用 HTTPDNS 的，往往是手機(jī)應(yīng)用，需要在手機(jī)端嵌入支持 HTTPDNS 的客戶端 SDK。

????接下來，我們一起來認(rèn)識下 HTTPDNS 的工作流程。

????HTTPDNS 會在客戶端的 SDK 里動態(tài)請求服務(wù)端，獲取 HTTPDNS 服務(wù)器的 IP 列表，緩存在本地。隨著不斷地解析域名，SDK 也會在本地緩存 DNS 域名解析的結(jié)果。

????當(dāng)手機(jī)應(yīng)用要訪問一個地址的時候，首先看是否有本地的緩存，如果有直接返回。這個緩存和本地 DNS 的緩存不一樣的是，這個是手機(jī)應(yīng)用自己做的，而非整個運營商統(tǒng)一做。如何更新以及何時更新緩存，手機(jī)應(yīng)用的客戶端可以和服務(wù)器協(xié)調(diào)來做這件事情。

????如果本地沒有，就需要請求 HTTPDNS 的服務(wù)器，在本地 HTTPDNS 服務(wù)器的 IP 列表中，選擇一個發(fā)出 HTTP 請求，獲取一個要訪問的網(wǎng)站的 IP 列表。

請求的方式是這樣的：

curl http://123.4.5.6/d?dn=c.m.cnb...

????手機(jī)客戶端之道手機(jī)在哪個運營商、哪個地址。由于是直接的 HTTP 通信，HTTPDNS 服務(wù)器能夠準(zhǔn)確知道這些信息，因而可以做精準(zhǔn)的全局負(fù)載均衡。

????上面五個問題，歸結(jié)起來就兩大問題。一是解析速度和更新速度的平衡問題，二是智能調(diào)度的問題。HTTPDNS 對應(yīng)的解決方案是 HTTPDNS 的緩存設(shè)計和調(diào)度設(shè)計。

????解析 DNS 過程復(fù)雜，通信此時多，對解析速度造成很大影響。為了加快解析，因而有了緩存，但是這又會產(chǎn)生緩存更新速度不及時的問題。最要命的是，這兩個方面都掌握在別人手中，也就是本地 DNS 服務(wù)器手中，它不會為你定制，作為客戶端干著急也沒辦法。

????而 HTTPDNS 就是將解析速度和更新速度全部掌控在自己手中。

????一方面，解析的過程，不需要本地 DNS 服務(wù)遞歸的調(diào)用一大圈，一個 HTTP 的請求直接搞定。要實時更新的時候，馬上就能起作用。

另一方面，為了提高解析速度，本地也有緩存，緩存是在客戶端 SDK 維護(hù)的，過期時間、更新時間，都可以自己控制。

HTTPDNS 的緩存設(shè)計策略也是咱們做應(yīng)用架構(gòu)中常用的緩存設(shè)計模式，也即分為客戶端、緩存、數(shù)據(jù)源三層。

對于應(yīng)用架構(gòu)來講，就是應(yīng)用、緩存、數(shù)據(jù)庫。常見的是 Tomcat、Redis、Mysql；

對于 HTTPDNS 來講，就是手機(jī)客戶端、DNS 緩存、HTTPDNS 服務(wù)器。

只要是緩存模式，就存在緩存的過期、更新、不一致的問題，解決思路也是相似的。

例如，DNS 緩存在內(nèi)存中，也可以持久化到存儲上，從而 APP 重啟之后，能夠盡快從存儲中加載上次累積的經(jīng)常訪問的網(wǎng)站的解析結(jié)果，就不需要每次都全部解析一遍，再變成緩存。這有點像 Redis 是基于內(nèi)存的緩存，但是同樣提供持久化的能力，使得重啟或者主備切換的時候，數(shù)據(jù)不會完全丟失。

SDK 中的緩存會嚴(yán)格按照緩存過期時間，如果緩存沒有命中，或者已經(jīng)過期，而且客戶端不允許使用過期的幾率，則會發(fā)起一次解析，保證緩存記錄是更新的。

解析可以同步進(jìn)行，也就是直接調(diào)用 HTTPDNS 的接口，返回最新的記錄，更新緩存。也可以異步進(jìn)行，添加一個解析任務(wù)到后臺，由后臺任務(wù)調(diào)用 HTTPDNS 的接口。

同步更新的優(yōu)點是實時性好，缺點是如果有多個請求都發(fā)現(xiàn)過期的時候，會同時請求 HTTPDNS 多次，造成資源浪費。

同步更新的方式對應(yīng)到應(yīng)用架構(gòu)緩存的 Cache-Aside 機(jī)制，也就是先讀緩存，不命中讀數(shù)據(jù)庫，同時將結(jié)果寫入緩存。

異步更新的優(yōu)點是，可以將多個請求都發(fā)現(xiàn)過期的情況，合并為一個對于 HTTPDNS 的請求任務(wù)，只執(zhí)行一次，減少 HTTPDNS 的壓力。同時，可以在即將過期的時候，就創(chuàng)建一個任務(wù)進(jìn)行預(yù)加載，防止過期之后再刷新，稱為預(yù)加載。

它的缺點是，當(dāng)前請求拿到過期數(shù)據(jù)的時候，如果客戶端允許使用過期時間，需要冒一次風(fēng)險。這次風(fēng)險是指，如果過期的請求還能請求，就沒問題，如果不能請求，就會失敗一次，等下次緩存更新后，才能請求成功。

異步更新的機(jī)制，對應(yīng)到應(yīng)用架構(gòu)緩存的 Refresh-Ahead 機(jī)制，即業(yè)務(wù)僅僅訪問緩存，當(dāng)過期的時候定期刷新。在著名的應(yīng)用緩存 Guava Cache 中，有個 RefreshAfterWrite 機(jī)制，對于并發(fā)情況下，多個緩存訪問不命中從而引發(fā)并發(fā)回源的請求，可以采取只有一個請求回源的模式。在應(yīng)用架構(gòu)的緩存中，也常常用數(shù)據(jù)預(yù)熱或者預(yù)加載的機(jī)制。

由于客戶端嵌入了 SDK，因而就不會因為本地 DNS 的各種緩存、轉(zhuǎn)發(fā)、NAT，讓權(quán)威 DNS 服務(wù)器誤會客戶端所在的位置和運營商，從而可以拿到第一手資料。

在客戶端，可以知道手機(jī)是哪個國家、哪個運營商、哪個省、甚至是哪個市，HTTPDNS 服務(wù)端可以根據(jù)這些信息，選擇最佳的服務(wù)節(jié)點返回。

如果有多個節(jié)點，還會考慮錯誤率、請求時間、服務(wù)器壓力、網(wǎng)絡(luò)狀態(tài)等，進(jìn)行綜合選擇，而非僅僅考慮地理位置。當(dāng)有一個節(jié)點宕機(jī)或者性能下降的時候，可以盡快進(jìn)行切換。

要做到這一點，需要客戶端使用 HTTPDNS 返回的 IP 訪問業(yè)務(wù)應(yīng)用。客戶端的 SDK 會收集網(wǎng)絡(luò)請求數(shù)據(jù)，如錯誤率、請求時間等網(wǎng)絡(luò)請求質(zhì)量數(shù)據(jù)，并發(fā)送到統(tǒng)計后臺，進(jìn)行分析、聚合，以此查看不同 IP 的服務(wù)質(zhì)量。

在服務(wù)端，應(yīng)用可以通過調(diào)用 HTTPDNS 的管理接口，配置不同服務(wù)質(zhì)量的優(yōu)先級、權(quán)重。HTTPDNS 會根據(jù)這些策略綜合地理位置和線路狀況算出一個排序，優(yōu)先訪問當(dāng)前那些優(yōu)質(zhì)的、時延低的 IP 地址。

HTTPDNS 通過智能調(diào)度之后返回的結(jié)果，也會緩存在客戶端。為了不讓緩存使得調(diào)度失真，客戶端可以根據(jù)不同的移動網(wǎng)絡(luò)運營商的 SSID 來分維度緩存。不同的運營商解析出來的結(jié)果會不同。

傳統(tǒng) DNS 會因為緩存、轉(zhuǎn)發(fā)、NAT 等問題導(dǎo)致客戶端誤會自己所在的位置和運營商，從而影響流量的調(diào)度；

HTTPDNS 通過客戶端 SDK 和服務(wù)端，通過 HTTP 直接調(diào)用解析 DNS 的方式，繞過了傳統(tǒng) DNS 的缺點，實現(xiàn)了智能的調(diào)度。

參考：

HTTPDNS 的原理；

劉超 - 趣談網(wǎng)絡(luò)協(xié)議系列課；