UDP 協議的那點事兒

最近在回顧計算機網絡的知識，之前上課沒有認真學，只記得幾個高大上的術語，因此趁着此次回顧，把學到的知識用博客的形式記錄下來，一來加深本身的印象，二來但願讓你對這些基礎知識有一個更深刻的瞭解。固然，我會盡可能把 UDP 協議講清楚，講明白，讓你「不枉此行」。

---

UDP（ User Datagram Protocol ）協議，翻譯過來就是用戶數據報協議 ，跟 TCP 協議同樣，都是位於 OSI 模型的傳輸層。不過比起 TCP 協議，UDP 協議就顯得簡單多了，由於它沒有「流量控制」、「擁塞控制」等複雜的處理機制。它甚至沒有重傳機制，也就是說，若是你的數據包半路走丟了，那就是真找不回來了，因此說 UDP 協議是不可靠的。固然了，這個重傳機制是針對傳輸層而言的，你徹底能夠在應用層寫一個協議來進行丟包處理，好比說像 TCP 同樣，增長 ACK 和序列號機制。

那你可能會疑惑了，爲何放着可靠的 TCP 協議不用，而選擇 UDP 協議？

UDP 報文段結構

這固然要根據應用的需求來，不過在說這個話題以前，咱們先來詳細瞭解一下 UDP 協議。

說實話，UDP 的報文段結構比 TCP 報文段簡潔多了（見下圖），畢竟 UDP 協議就沒有什麼多餘的機制。

言歸正傳，報文段裏的「源端口號」和「目的端口號」是爲了告訴傳輸層，我這個報文是從哪兒（哪一個進程）來的，要到哪兒（哪一個進程）去。但要注意一點：一個 UDP 套接字是由一個二元組標識的，這個二元組指的是目的 IP 地址和目的端口號，也就是說，服務器上對應的進程，不在意你是從哪一個客戶端來的，我都放進一個套接字處理，處理完了再根據源端口號和源 IP 地址，把應答信息發送給客戶端。相較而言，TCP 套接字須要一個四元組來標識：源 IP 地址，源端口號，目的 IP 地址和目的端口號。這一點在講 TCP 協議的時候還會細講，因此這裏就不贅述了。

PS：你可能會問，這報文段裏怎麼沒有 IP 地址啊？這是由於IP 地址保存在網絡層的 IP 協議段裏，傳輸層的報文段裏固然就沒有了。

無鏈接

每次提到 TCP 協議，咱們最早想到的就是三次握手和四次揮手，對 UDP 協議來講，這都是沒有的事兒~ 使用 UDP 協議的時候，若是客戶端要發送報文段給服務端，不用握手，直接就發出去了，也正由於這樣，UDP 協議被稱爲是無鏈接的。

很容易想到，不須要握手這一過程的話，就沒有由於創建鏈接而形成的時延，一個字，快！這也是 DNS（域名系統）運行在 UDP 協議之上的很大一部分緣由。

可是 UDP 協議不可靠啊，傳輸過程當中丟包了怎麼辦？最簡單的作法就是——忽略它！（不然就得像文章開頭說的那樣，在應用層實現重傳機制）就拿 DNS 來講吧，若是數據包丟失，客戶端重發就是了（有超時機制），並且在正常狀況下，丟包的機率很低。但若是使用 TCP 協議的話，由於要創建鏈接，域名查詢就會慢不少，除此以外，使用 UDP 協議的網絡開銷更小——UDP 報文段有 8 個字節的首部開銷，而 TCP 協議有 20 字節的開銷（看前面的關於報文段的兩張圖）。 網絡開銷小，意味着 DNS 服務器能接受更多客戶端的請求。

還有一個方面，TCP 協議有擁塞控制機制，它會在網絡擁塞時遏制 TCP 發送方，以致於延遲報文段的傳送，因此對於一些要求傳輸延遲小，且可以容忍一些數據丟失的實時程序來講，UDP 協議多是一個更好的選擇。路由選擇協議（RIP）、 網絡管理協議（SNMP） 也都選擇了 UDP 來做爲底層的傳輸協議。

最後，這是一張客戶端與服務端利用 UDP 協議通訊的流程圖：

​

UDP 協議要講的內容很少，下次要講的 TCP 協議，就比較燒腦了，作好準備吧！

若是本文對你有幫助，歡迎關注個人公衆號 tobe的囈語 ，帶你深刻計算機的世界～ 公衆號後臺回覆關鍵詞【計算機】有驚喜哦~