計算機網絡協議(五)——DNS、HTTPDNS

概述

---

這個專欄的計算機網絡協議，我是在極客時間上學習 已經有三萬多人購買的劉超老師的趣談網絡協議專欄，講的特別好，像看小說一樣學習到了平時很枯燥的知識點，計算機網絡的書籍太枯燥，感興趣的同學可以去付費購買，絕對物超所值，本文就是對自己學習專欄的總結,評論區可以留下你的問題，咱們一起討論！

上面介紹了應用層的協議，包含了看新聞、支付、直播、下載等場景；每個人平時常用的網站有二三十個吧，全部用IP地址訪問肯定記不住啊，那就需要一個地址簿，根據名稱來查看具體的地址。本文將分爲兩個部分來進行介紹：

• DNS協議；
• HTTPDNS協議；

---

一、DNS協議：網絡世界的地址簿

DNS服務器就是充當地址簿的角色，根據域名查看對應的ip地址；

DNS服務器要設置成高可用、高併發和分佈式的才能應對每天全球各地的人的訪問；

DNS服務器的樹狀層次結構如下：

• 根DNS服務器 ：返回頂級域DNS服務器的IP地址；
• 頂級域DNS服務器：返回權威DNS服務器的IP地址；
• 權威DNS服務器 ：返回相應主機的IP地址；

---

1.1 DNS解析流程

爲了提高DNS的解析性能，很多網絡都會就近部署DNS緩存服務器，解析流程如下：

1. 客戶端向本地域名服務器發送DNS請求，www.taobao.com的IP是啥；如果本地DNS是通過DHCP配置，那麼本地DNS就由你的網絡服務商(ISP)，電信、移動等自動分配；
2. 本地DNS收到來自客戶端的請求，如果在其緩存的地址簿裏找到了www.taobao的ip地址，直接返回即可；沒找到，本地DNS會去找他的老大，根域名服務器；根域名服務器全球有13套，是最高層次的；
3. 根域名服務器收到請求後，發現後綴是.com,就讓你去找.com的頂級域名服務器去查找；
4. 本地DNS轉到頂級域名服務器說，二哥好，大哥讓我來找你的！頂級域名服務器
   就是大名鼎鼎的比如 .com、.net、 .org這些一級域名，它負責管理二級域名；
5. 頂級域名服務器說：：“我給你負責 www.taobao.com 區域的權威DNS服務器的地址，你去問它應該能問到。”
6. 本地DNS轉到權威DNS服務器，請問對應的ip地址是多少；
7. 權限DNS服務器查詢後將對應的IP地址X.X.X.X告訴本地DNS，
8. 本地DNS再將IP地址返回客戶端，客戶端和目標建立連接。

過程圖如下所示，步驟序號相對應：

---

1.2 負載均衡

DNS在遞歸查詢的過程中，除了可以通過名稱映射爲IP地址，還可以進行負載均衡；

以喫肯德基爲例，肯德基在全國各地都有門店，如果你想喫肯德基了，不用都跑到一家去，直接就近找一家店喫，這就是負載均衡；

---

DNS首先需要進行內部負載均衡

舉例：如果一個應用訪問數據庫，那應用裏面配置數據庫的IP地址還是對應的域名呢？

顯然是配置域名，因爲數據庫如果因爲某種原因，轉換到別的服務器上，那麼所有連接應用中配置的IP地址都要改變，極大的增大了運維的壓力；

所以當多個應用之間相互進行訪問的時候，只要配置爲域名，就可以在域名解析的時候根據配置策略，返回對應的IP地址，實現內部負載均衡；

---

DNS還可以做全局負載均衡

爲了保證應用高可用，往往會部署在多個機房，每個地方都會有自己的IP地址。當用戶訪問某個域名的時候，這個IP地址可以輪詢訪問多個數據中心。如果一個數據中心因爲某種原因掛了，只要在DNS服務器裏面，將這個數據中心對應的IP地址刪除，就可以實現一定的高可用。

當然，希望的是上海的用戶只訪問上海的數據中心，北京的用戶只訪問北京的數據中心；

舉例：DNS訪問數據中心中對象存儲上的靜態資源

全國有多個數據中心託管在運營商下，每個數據中心三個可用區（Available Zone）。對象存儲通過跨可用區部署，實現高可用性。在每個數據中心中，都至少部署兩個內部負載均衡器，內部負載均衡器後面對接多個對象存儲的前置服務器（Proxy-server）。

如下圖所示：

簡單的應用通過步驟1-7就是上面說到的DNS遞歸查詢的過程；

對於複雜的應用，尤其是跨地域跨運營商的大型應用，則需要更加複雜的全局負載均衡機制上圖中配置了兩層全局負載均衡器（GSLB，Global Server Load Balance）

給object.yourcompany.com起一個別名，例如 object.vip.yourcomany.com，然後告訴本地DNS服務器，讓它請求GSLB解析這個域名；

兩層的原因是因爲分運營商和地域，不同運營商的客戶不可以訪問相同運營商機房中的資源，這樣不跨運營商訪問，有利於提高吞吐量，減少時延。

• 第一層GSLB：通過查看請求它的本地DNS服務器所在的運營商，假設是移動，採取CNAME的方式，通過另一個別名 object.yd.yourcompany.com，告訴本地DNS服務器去請求第二層的GSLB；
• 第二層GSLB：通過查看請求它的本地DNS服務器所在的地址，就知道用戶所在的地理位置，然後將距離用戶位置比較近的Region裏面，**六個內部負載均衡（SLB，Server Load Balancer）**的地址，返回給本地DNS服務器；
• 本地DNS服務器將結果返回給本地DNS解析器，本地DNS解析器將結果緩存，返回給客戶端；
• 客戶端訪問屬於同一個運營商下距離較近的Region1中的對象存儲，客戶端得到了六個IP地址，通過負載均衡、隨機或者輪詢選擇一個可用的區進行訪問，對象存儲一般會有三個備份，從而可以實現對存儲讀寫的負載均衡。

---

總結

• DNS是網絡世界的地址簿，通過域名尋址，域名服務器是按照樹狀結構組織的，因而域名查找是使用遞歸的方法，並通過緩存的方式增強性能；
• 在域名和IP的映射過程中，給了應用基於域名做負載均衡的機會，可以是簡單的負載均衡，也可以根據地址和運營商做全局的負載均衡；

---

二、HTTPDNS

網絡世界中的DNS地址簿也會出錯，本來附近就有肯德基，但是把你推薦幾公里開外的肯德基店；

傳統DNS中的問題：

1、域名緩存問題
每個請求訪問權威服務器，訪問過一次就會在本地緩存，當其他人來問的時候，直接返回緩存的數據；

就像是你之前去喫過肯德基，假如這家店已經關了，別人問你哪裏有肯德基，你憑藉着記憶告訴他了地址，結果別人白跑一趟啥都沒找到；

此外，運營商會把一些靜態頁面，緩存到本運營商的服務器內，這樣用戶請求的時候，就不用跨運營商進行訪問，這樣既加快了速度，也減少了運營商之間流量計算的成本。

這種情況大部分是正常的，但是頁面更新之後，用戶訪問到的就是老的頁面；就像是肯德基新推出了一個口味的漢堡，你想去喫，但是你的朋友告訴你在這喫也一樣，對於想喫新口味的你就會很失望；

本地的緩存，往往使得全局負載均衡失敗，因爲上次進行緩存的時候，緩存中的地址不一定是這次訪問離客戶最近的地方，如果把這個地址返回給客戶，那肯定就會繞遠路。

2、域名轉發問題
如果你是A運營商的用戶，訪問A運營商的DNS服務器，權威服務器根據是A運營商的返回部署在A運營商中的網址，但是如果A運營商將請求轉到B運營商，跨運營商訪問，速度會很慢；
3、出口NAT問題
網絡地址的轉換，權威的DNS服務器，就沒辦法通過這個地址，來判斷客戶到底是來自哪個運營商，而且極有可能因爲轉換過後的地址，誤判運營商，導致跨運營商的訪問。
4、域名更新問題
本地DNS服務器是由不同地區、不同運營商獨立部署的。對域名解析緩存的處理上，實現策略也有區別，有的會偷懶，忽略域名解析結果的TTL時間限制，在權威DNS服務器解析變更的時候，解析結果在全網生效的週期非常漫長。
5、解析延遲問題
DNS的查詢過程需要遞歸遍歷多個DNS服務器，才能獲得最終的解析結果，這會帶來一定的時延，甚至會解析超時。

---

HTTPDNS的工作模式

HTTPNDS其實就是，不走傳統的DNS解析，而是自己搭建基於HTTP協議的DNS服務器集羣，分佈在多個地點和多個運營商。當客戶端需要DNS解析的時候，直接通過HTTP協議進行請求這個服務器集羣，得到就近的地址。

使用HTTPDNS的，往往是手機應用，需要在手機端嵌入支持HTTPDNS的客戶端SDK。

• 客戶端的SDK裏動態請求服務端，獲取HTTPDNS服務器的IP列表，緩存到本地。隨着不斷地解析域名，SDK也會在本地緩存DNS域名解析的結果。
• 當手機應用要訪問一個地址的時候，首先看是否有本地的緩存，如果有就直接返回。緩存屬於手機應用，並非整個運營商來統一。如何更新、何時更新，手機應用的客戶端可以和服務器協調來做這件事情；
• 如果本地沒有，就需要請求HTTPDNS的服務器，在本地HTTPDNS服務器的IP列表中，選擇一個發出HTTP的請求，會返回一個要訪問的網站的IP列表；

---

HTTPDNS的緩存設計

HTTPDNS緩存設計策略，分爲客戶端、緩存、數據源三層。

• 對於應用架構來講，就是應用、緩存、數據庫。常見的是Tomcat 、Redis、MySQL。
• 對於HTTPDNS來講，就是手機客戶端、DNS緩存、HTTPDNS服務器
  
  只要是緩存模式，就需要解決緩存的過期、更新、不一致的問題；

SDK中的緩存會嚴格按照緩存過期時間，如果緩存沒有命中，或者已經過期，而且客戶端不允許使用過期的記錄，則會發起一次解析，保障記錄是更新的；

同步解析：

• 直接調用HTTPDNS的接口，返回最新的記錄，更新緩存；
• 優點：實時性好，缺點：如果有多個請求都發現過期的時候，同時會請求HTTPDNS多次；
• 更新方式：Cache-Aside機制，先讀緩存，不命中讀數據庫，同時寫入緩存；
  
  異步解析：
• 添加一個解析任務到後臺，由後臺任務調用HTTPDNS的接口；
• 優點：可以將多個請求都發現過期的情況，合併爲一個對於HTTPDNS的請求任務，只執行一次，減少HTTPDNS的壓力。同時創建一個任務進行預加載，防止過期之後刷新；**缺點：**當前請求拿到過期數據的時候，如果客戶端允許使用過期數據，需要冒一次風險。如果過期的數據還能請求，就沒問題；如果不能請求，則失敗一次，等下次緩存更新後，再請求方能成功；
• 更新方式：Refresh-Ahead機制，業務僅僅訪問緩存，當過期的時候定期刷新；
  

---

HTTPDNS的調度設計

客戶端
客戶端中嵌入了SDK，，HTTPDNS服務端可以根據手機是哪個國家、哪個運營商、哪個省，甚至哪個市，選擇最佳的服務節點返回；

多個節點還需要考慮慮錯誤率、請求時間、服務器壓力、網絡狀況等，並非只有地理位置；

服務端
應用可以通過調用HTTPDNS的管理接口，配置不同服務質量的優先級、權重。

• HTTPDNS會根據這些策略綜合地理位置和線路狀況算出一個排序，優先訪問當前那些優質的、時延低的IP地址。
• HTTPDNS通過智能調度之後返回的結果，也會緩存在客戶端。爲了不讓緩存使得調度失真，客戶端可以根據不同的移動網絡運營商WIFI的SSID來分維度緩存。不同的運營商或者WIFI解析出來的結果會不同。

---

總結

• 傳統的DNS：解析慢、更新不及時。因爲緩存、轉發、NAT問題導致客戶端誤會自
  己所在的位置和運營商，從而影響流量的調度。
• HTTPDNS通過客戶端SDK和服務端，通過HTTP直接調用解析DNS的方式，繞過了傳統DNS的這些缺點，實現了智能的調度。