你知道 DNS，那我猜你一定不知道 HTTPDNS
說起 DNS 協(xié)議，相信大家都能說出來幾句，不是很陌生。
它主要做兩個功能：根據(jù)名稱查到具體的地址;針對多個地址做負載均衡，而且可以在多個地址中選擇一個距離我最近的地方，讓我訪問。
看起來這種方式無懈可擊，但其實也有些問題。
傳統(tǒng) DNS 存在的問題
1. 域名緩存問題
客戶端想要訪問一個網(wǎng)址的時候，其實它首先是去看本地的緩存里面有沒有這個地址，如果有就直接訪問，如果沒有才會去詢問上級領導。
但是這個時候就會有個問題：比如在阿粉上高中的時候，我知道學校旁邊有個超好吃的店，后來阿粉再想吃的時候，想都沒想，直接去了那家店，結果發(fā)現(xiàn)人家關門了，當時阿粉的心情是非常失望。
同樣，本地緩存也會出現(xiàn)這個問題，有的時候那個地址已經(jīng)換掉了，但是因為本地緩存中有原來的地址，所以不會向上一級詢問，將你導向原來的地址，結果就是訪問不到界面，由此帶來的用戶體驗不是很好。
還有個問題：假設我在北京海淀區(qū)，淘寶的應用因為某種原因沒有在海淀區(qū)設置數(shù)據(jù)中心，然后我訪問的時候，一直都是將我的訪問請求發(fā)送到朝陽區(qū)。后來呢，淘寶在海淀區(qū)增加了數(shù)據(jù)中心，但是當我訪問的時候，本地緩存依舊會將我的請求，導向到朝陽區(qū)那邊，這樣造成的結果就是：
- 對于客戶來說，讓他繞遠路了。明明一個區(qū)域就可以解決的事情，偏偏要跨區(qū)域。就像明明在這里可以買到東西，偏偏讓你跑到另外的地方去買，你開心嘛?
- 對于商家來說，也就是淘寶，我設置了新的數(shù)據(jù)中心，結果呢，客戶的請求沒能到這里，那我還費錢費力的去做這件事干嘛?又沒有提高用戶的體驗，對不對。
2. 出口 NAT 問題
在網(wǎng)關那里，很多機房都會在出口配置 NAT ( Network Address Translation )，即：網(wǎng)絡地址轉(zhuǎn)換。
也就是說，從這個網(wǎng)關出去的包，都會換成新的 IP 地址，當請求返回的時候，在網(wǎng)關這里，再將 IP 地址轉(zhuǎn)換回去，這樣造成的結果就是，權威的 DNS 服務器，沒辦法通過這個地址，來判斷用戶到底是來自哪個運營商，而且極有可能因為誤判運營商，導致跨運營商訪問，從而導致網(wǎng)速極慢。
3. 解析延遲問題
DNS 的查詢過程，需要遞歸遍歷多個 DNS 服務器，才能得到最終的解析結果，這會帶來一定的時延，甚至是解析超時。
HTTPDNS 的工作模式
DNS 解析有很多問題，那怎么辦呢?再回到最初的起點：直接 IP 地址?顯然不合適啊。
這就引出了 HTTPDNS 。說白了就是，它不走傳統(tǒng)的 DNS 解析，而是走自己搭建基于 HTTP 協(xié)議的 DNS 服務器集群。這些集群分布在多個地點，當客戶端需要 DNS 解析的時候，直接通過 HTTP 協(xié)議進行請求這個服務器集群，就可以得到最近的地址。這樣做就相當于每個客戶端都是基于 HTTP 協(xié)議的，自己實現(xiàn)自己的域名解析，自己做一個自己專屬的地址簿，而不是使用統(tǒng)一的地址簿。
但是默認的域名解析都是走 DNS ，所以如果想要使用 HTTPDNS 的話，就需要繞過默認的 DNS 路徑，這樣就不能使用默認的客戶端。
使用 HTTPDNS 的，一般都是手機應用，所以只需要在手機端嵌入支持 HTTPDNS 的客戶端 SDK 就 OK 了。這樣就可以通過自己的 HTTPDNS 服務器和相關的 SDK ，實現(xiàn)了從依賴別人，到自己上網(wǎng)查詢，自己想去哪兒去哪兒，想干什么干什么，豈不是快哉~
HTTPDNS 工作模式具體可以描述如下：當手機要訪問一個地址的時候，我會先看本地緩存里面有沒有，如果有就直接訪問，這個緩存是手機應用自己做的，至于如何更新，何時更新，那是手機應用的客戶端的事情;如果沒有的話呢，就需要請求 HTTPDNS 服務器，在本地 HTTPDNS 服務器的 IP 列表中，選擇一個發(fā)出 HTTP 的請求，會返回一個要訪問的網(wǎng)站的 IP 列表。因為是直接的 HTTP 通信，所以 HTTPDNS 服務器能夠準確知道這些信息，所以可以做到精準的全局負載均衡。
寫到這里，這篇文章想要表達的是兩點：
- 傳統(tǒng)的 DNS 有很多問題:比如域名緩存問題，出口 NAT 問題，解析延遲問題
- 為了解決上述問題， HTTPDNS 通過客戶端 SDK 和服務端，通過 HTTP 的形式，直接調(diào)用解析 DNS 的方式，繞過了傳統(tǒng)的 DNS 的這些缺點，從而實現(xiàn)了智能的調(diào)度。
