爲何 DNS 協議使用 UDP？只使用了 UDP 嗎？

爲何 DNS 協議使用 UDP 呢？這個問題可能大部分同窗在各類博客或者面試過程當中都或多或少碰見過，張口就來，UDP 快啊，DNS 使用 UDP 使得打開網頁速度更快。git

那各位有沒有想過，既然 UDP 更快，爲何 HTTP 不使用 UDP 呢？web

另外，爲何 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 協議自己並不能作出任何檢測或補救措施app

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，目前在維護一個教程類倉庫 CS-Wiki 「Gitee 官方推薦項目，現已 1.6k+ star，倉庫地址：https://gitee.com/veal98/CS-Wiki」，公衆號上的文章也會在此同步更新，歡迎各位前來交流學習。
準備春招秋招的小夥伴能夠參考個人這個論壇項目 Echo 「Gitee 官方推薦項目，現已 700+ star，倉庫地址：https://gitee.com/veal98/Echo」。配套教程正在同步更新中，公衆號後臺回覆 "Echo" 便可免費獲取。
另外，雖然如今本號仍然很小，不過我仍是建了一個交流羣『 小牛肉和它的小夥伴們 』，感興趣的各位能夠下方掃碼加我微信回覆 "進羣"，我拉你進羣：

本文分享自微信公衆號 - 飛天小牛肉（CS-Wiki）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。