? 盡人事，聽天命。博主東南大學碩士在讀，攜程 Java 後臺開發暑期實習生，熱愛健身和籃球，樂於分享技術相關的所見所得，關注公眾號 @ 飛天小牛肉，第一時間獲取文章更新，成長的路上我們一起進步
? 本文已收錄於 「CS-Wiki」Gitee 官方推薦專案，現已累計 1.6k+ star，致力打造完善的後端知識體系，在技術的路上少走彎路，歡迎各位小夥伴前來交流學習
? 如果各位小夥伴春招秋招沒有拿得出手的專案的話，可以參考我寫的一個專案「開源社群系統 Echo」Gitee 官方推薦專案，目前已累計 700+ star，基於 SpringBoot + MyBatis + MySQL + Redis + Kafka + Elasticsearch + Spring Security + ... 並提供詳細的開發文件和配套教程。公眾號後臺回覆 Echo 可以獲取配套教程，目前尚在更新中
為什麼 DNS 協議使用 UDP 呢？這個問題可能大部分同學在各種部落格或者面試過程中都或多或少遇見過，張口就來，UDP 快啊，DNS 使用 UDP 使得開啟網頁速度更快。
那各位有沒有想過，既然 UDP 更快，為什麼 HTTP 不使用 UDP 呢？
另外，為什麼 DNS 協議使用 UDP 這個問題本身其實並不完全正確，DNS 並非只使用 UDP 協議，它同時佔用了 UDP 和 TCP 的 53 埠，作為單個應用層的協議，DNS 同時使用兩種傳輸協議也屬實是個另類了。
DNS 為什麼同時使用 TCP 和 UDP
我們從 TCP 與 UDP 的比較說起，老生常談的話題，不過相信大部分同學都會忽略掉一個點，等下會指出來。
OK，輕鬆環節，閉著眼睛背：
1）TCP 需要三次握手建立連線，四次揮手釋放連線；UDP 不需要，面向無連線
2）TCP 首部需要 20 個位元組；而 UDP 首部只有 8 個位元組
3）TCP 具有一系列保證可靠傳輸的機制；而 UDP 盡最大努力交付，不提供可靠傳輸的機制，如果在資料傳輸的過程中出現部分資料的丟失，UDP 協議本身並不能做出任何檢測或補救措施
4）正是由於 UDP 沒有了可靠傳輸機制，所以速度遠遠快於 TCP，在某些情況下 UDP 是一種最有效的工作方式，一般用於即時通訊，比如： 語音電話、 直播等等；而 TCP 一般用於檔案傳輸、傳送和接收郵件、遠端登入等準確性要求比較高的場景
上面這些是最基本的吧。
接下來講的這個點，也就是很多人容易忽略的點，和 DNS 為什麼需要同時使用 UDP 和 TCP 這個問題息息相關：
- 那就是 TCP 是面向位元組流的，而 UDP 是面向報文的
解釋一下這句話，我們知道，TCP 具有序列號機制，傳送方會把一個大的 HTTP 報文按序號分割成若干報文段並加上 TCP 首部，也就是封裝成 TCP 報文段。那麼接收方在收到這些 TCP 報文段後，就會按照序號以原來的順序重組 HTTP 報文。這就是面向位元組流的 TCP。
而所謂 UDP 面向報文，傳送方的 UDP 對應用層交付下來的 HTTP 報文， 在新增 UDP 首部後也就是封裝成 UDP 報文，就向下交付給網路層 IP 協議。不做任何的拆分與合併，主要就是因為 UDP 沒有像 TCP 一樣的序列號機制來標識報文，所以預設只有一個 UDP 報文。
UDP 這麼做就會導致一個問題。
網際網路上物理鏈路的最小傳輸單元 = 576 位元組，為了在物理鏈路上順利傳輸，UDP 報文不能超過 576 位元組，為此，UDP 報文被限制在 512 位元組以內。
而 DNS 由於大面積使用了 UDP，這樣一旦 DNS 報文超過 512 位元組，基於 UDP 的 DNS 報文就只有拋棄多出來的 64 位元組，截短為 512 位元組，那麼使用者得到的 DNS 報文就是不完整的。
如何解決這個問題呢？
沒錯，最簡單的方式就是使用 TCP。儘管速度可能相之 UDP 較慢，但對於得到完整的 DNS 報文，速度慢一點也可以忍受。
DNS 分別在什麼情況下使用 UDP 和 TCP
瞭解了 TCP 面向位元組流而 UDP 面向報文的這個特性之後，在域名解析的時候，也就是客戶端向 DNS 伺服器查詢域名獲取 IP 地址的時候，DNS 協議關於 UDP 和 TCP 的選擇通常可以分為以下兩種情況：
1）若客戶端事先知道 DNS 響應報文的長度會大於 512 位元組，則應當直接使用 TCP 建立連線
2）若客戶端事先不知道 DNS 響應報文的長度，一般會先使用 UDP 協議傳送 DNS 查詢報文，若 DNS 伺服器發現 DNS 響應報文的長度大於 512 位元組，則多出來的部分會被 UDP 拋棄（截斷 TrunCation），那麼伺服器會把這個部分被拋棄的 DNS 報文首部中的 TC 標誌位置為 1，以通知客戶端該 DNS 報文已經被截斷。客戶端收到之後會重新發起一次 TCP 請求，從而使得它將來能夠從 DNS 伺服器收到完整的響應報文。
當然了，在域名解析的時候，一般返回的 DNS 響應報文都不會超過 512 位元組，用 UDP 傳輸即可。事實上，很多 DNS 伺服器進行配置的時候，也僅支援 UDP 查詢包。
不過，DNS 不僅存在域名解析的過程，還有區域傳輸的過程，而在進行區域傳輸的時候 DNS 會強制使用 TCP 協議。
什麼是區域傳輸？
這就不得不提一下主域名伺服器和輔助域名伺服器。
設定域名伺服器時，伺服器管理員可以選擇將域名伺服器指定為主伺服器還是輔助伺服器（也稱為從伺服器）。
主域名伺服器負責維護一個區域的所有域名資訊，是特定的所有資訊的權威資訊源，資料可以修改。主伺服器直接從本地檔案獲取此資訊。只能在主伺服器上更改區域的 DNS 記錄，然後主伺服器才能更新輔助伺服器。
當主域名伺服器出現故障、關閉或負載過重時，輔助域名伺服器作為主域名伺服器的備份提供域名解析服務。輔助域名伺服器中的區域檔案中的資料是從主域名伺服器中複製過來的，無法自行修改。
其實就是主從的概念，各位應該也都比較熟悉了。主域名伺服器用來寫，輔助域名伺服器用來讀，提供負載均衡的能力，緩解主域名伺服器的壓力。
那麼所謂區域傳輸（zone transfer）呢，就是輔助域名伺服器與主域名伺服器通訊，並同步資料資訊的過程。
輔域名伺服器會定時向主域名伺服器進行查詢以便了解資料是否有變動。如有變動，則會執行一次區域傳輸。區域傳輸使用 TCP 而不是 UDP，因為資料同步傳送的資料量比一個 DNS 請求和響應報文的資料量要多得多。
文章開頭提到的既然 UDP 更快，為什麼 HTTP 不使用 UDP 呢？這個問題的答案也大抵如此。
由於網際網路的不安全性，我們需要數字證照並攜帶數字簽名來保證資料的安全性，為此，整個 HTTP 報文的大小已經遠遠超過 512 位元組，無法使用 UDP 傳輸。
小結
綜上，總結下，雖然 UDP 速度更快，DNS 協議也確實大面積使用了 UDP，但是由於 UDP 面向報文、只能傳輸小於 512 位元組的特性，DNS 並非只使用了 UDP，具體的 TCP 和 UDP 使用場景如下：
- DNS 在域名解析的過程中，會根據 DNS 響應報文的大小選擇使用 TCP 還是 UDP。但是一般情況下，返回的 DNS 響應報文都不會超過 512 位元組，所以事實上，很多 DNS 伺服器進行配置的時候，也僅支援 UDP 查詢包；
- DNS 在進行區域傳輸的時候使用 TCP 協議。
? 關注公眾號 | 飛天小牛肉，即時獲取更新
- 博主東南大學碩士在讀，攜程 Java 後臺開發暑期實習生，利用課餘時間運營一個公眾號『 飛天小牛肉 』，2020/12/29 日開通，專注分享計算機基礎（資料結構 + 演算法 + 計算機網路 + 資料庫 + 作業系統 + Linux）、Java 技術棧等相關原創技術好文。本公眾號的目的就是讓大家可以快速掌握重點知識，有的放矢。希望大家多多支援哦，和小牛肉一起成長 ?
- 並推薦個人維護的開源教程類專案： CS-Wiki（Gitee 推薦專案，現已累計 1.6k+ star）, 致力打造完善的後端知識體系，在技術的路上少走彎路，歡迎各位小夥伴前來交流學習 ~ ?
- 如果各位小夥伴春招秋招沒有拿得出手的專案的話，可以參考我寫的一個專案「開源社群系統 Echo」Gitee 官方推薦專案，目前已累計 700+ star，基於 SpringBoot + MyBatis + MySQL + Redis + Kafka + Elasticsearch + Spring Security + ... 並提供詳細的開發文件和配套教程。公眾號後臺回覆 Echo 可以獲取配套教程，目前尚在更新中。