說起 DNS 協議，相信大家都能說出來幾句，不是很陌生。

它主要做兩個功能：根據名稱查到具體的地址;針對多個地址做負載均衡，而且可以在多個地址中選擇一個距離我最近的地方，讓我訪問。

看起來這種方式無懈可擊，但其實也有些問題。

[[323995]]

傳統 DNS 存在的問題

1. 域名緩存問題

客戶端想要訪問一個網址的時候，其實它首先是去看本地的緩存里面有沒有這個地址，如果有就直接訪問，如果沒有才會去詢問上級領導。

但是這個時候就會有個問題：比如在阿粉上高中的時候，我知道學校旁邊有個超好吃的店，后來阿粉再想吃的時候，想都沒想，直接去了那家店，結果發現人家關門了，當時阿粉的心情是非常失望。

[[323996]]

同樣，本地緩存也會出現這個問題，有的時候那個地址已經換掉了，但是因為本地緩存中有原來的地址，所以不會向上一級詢問，將你導向原來的地址，結果就是訪問不到界面，由此帶來的用戶體驗不是很好。

還有個問題：假設我在北京海淀區，淘寶的應用因為某種原因沒有在海淀區設置數據中心，然后我訪問的時候，一直都是將我的訪問請求發送到朝陽區。后來呢，淘寶在海淀區增加了數據中心，但是當我訪問的時候，本地緩存依舊會將我的請求，導向到朝陽區那邊，這樣造成的結果就是：

• 對于客戶來說，讓他繞遠路了。明明一個區域就可以解決的事情，偏偏要跨區域。就像明明在這里可以買到東西，偏偏讓你跑到另外的地方去買，你開心嘛?
• 對于商家來說，也就是淘寶，我設置了新的數據中心，結果呢，客戶的請求沒能到這里，那我還費錢費力的去做這件事干嘛?又沒有提高用戶的體驗，對不對。

2. 出口 NAT 問題

在網關那里，很多機房都會在出口配置 NAT ( Network Address Translation )，即：網絡地址轉換。

也就是說，從這個網關出去的包，都會換成新的 IP 地址，當請求返回的時候，在網關這里，再將 IP 地址轉換回去，這樣造成的結果就是，權威的 DNS 服務器，沒辦法通過這個地址，來判斷用戶到底是來自哪個運營商，而且極有可能因為誤判運營商，導致跨運營商訪問，從而導致網速極慢。

3. 解析延遲問題

DNS 的查詢過程，需要遞歸遍歷多個 DNS 服務器，才能得到最終的解析結果，這會帶來一定的時延，甚至是解析超時。

HTTPDNS 的工作模式

DNS 解析有很多問題，那怎么辦呢?再回到最初的起點：直接 IP 地址?顯然不合適啊。

這就引出了 HTTPDNS 。說白了就是，它不走傳統的 DNS 解析，而是走自己搭建基于 HTTP 協議的 DNS 服務器集群。這些集群分布在多個地點，當客戶端需要 DNS 解析的時候，直接通過 HTTP 協議進行請求這個服務器集群，就可以得到最近的地址。這樣做就相當于每個客戶端都是基于 HTTP 協議的，自己實現自己的域名解析，自己做一個自己專屬的地址簿，而不是使用統一的地址簿。

但是默認的域名解析都是走 DNS ，所以如果想要使用 HTTPDNS 的話，就需要繞過默認的 DNS 路徑，這樣就不能使用默認的客戶端。

使用 HTTPDNS 的，一般都是手機應用，所以只需要在手機端嵌入支持 HTTPDNS 的客戶端 SDK 就 OK 了。這樣就可以通過自己的 HTTPDNS 服務器和相關的 SDK ，實現了從依賴別人，到自己上網查詢，自己想去哪兒去哪兒，想干什么干什么，豈不是快哉~

[[323997]]

HTTPDNS 工作模式具體可以描述如下：當手機要訪問一個地址的時候，我會先看本地緩存里面有沒有，如果有就直接訪問，這個緩存是手機應用自己做的，至于如何更新，何時更新，那是手機應用的客戶端的事情;如果沒有的話呢，就需要請求 HTTPDNS 服務器，在本地 HTTPDNS 服務器的 IP 列表中，選擇一個發出 HTTP 的請求，會返回一個要訪問的網站的 IP 列表。因為是直接的 HTTP 通信，所以 HTTPDNS 服務器能夠準確知道這些信息，所以可以做到精準的全局負載均衡。

寫到這里，這篇文章想要表達的是兩點：

• 傳統的 DNS 有很多問題:比如域名緩存問題，出口 NAT 問題，解析延遲問題
• 為了解決上述問題， HTTPDNS 通過客戶端 SDK 和服務端，通過 HTTP 的形式，直接調用解析 DNS 的方式，繞過了傳統的 DNS 的這些缺點，從而實現了智能的調度。