每一個程序員應該都知道TCP,UDP協議。UDP是用戶數據報文協議，屬于OSI模型中的傳輸層。它是一種無連接的協議，也就說上一報文和下一報文在協議層沒有任何聯系，同時提供了簡單的不可靠的傳輸服務。

也就是說UDP是不可靠的，如果要想讓數據可靠，就需要在業務層做糾錯和檢錯功能。比如：TFTP。

那可能就會有同學問了，既然是不可靠的，為什麼不直接使用IP協議呢？還要這麼大費周章增加一種協議UDP呢？

其實其中一個最重要的原因就是IP協議中沒有端口（port）的概念，它隻是規定了兩台主機之間的通信，并沒有解決不同主機上應用程序之間的通信。如果一個主機上的多個應用程序需要通信，直接用IP協議就無法數據區分數據到底哪個應用程序了。

可以理解為一個端口就是一個通信通道，當然UDP在IP協議的基礎上增加了一些功能，所以我們來總結下：

1. UDP無連接，沒有連接。所以它的發送和接受的開銷就會小很多。
2. UDP不保證數據可靠交付，隻是盡最大可能。所以不需要維護複雜的連接關系。
3. UDP是面向報文的，添加在應用層下來數據頭部，直接塞給IP層。
4. UDP沒有擁塞控制
5. UDP至支持多播。
6. UDP頭部小，說明傳輸更多的數據内容

下圖展示是UDP和上下層的關系

先看下圖：

從圖中可以看出，UDP的首部由四部分組成：

• 各16bit的來源端口和目的端口用來标記發送和接受的應用進程。因為UDP不需要應答，所以來源端口是可選的，如果來源端口不用，那麼置為零。當運輸層從IP層收到UDP數據報時，就是根據首部中的目的端口，把UDP數據報通過相應的端口，上交最後的終點--應用程序。
• 如果接收方UDP發現收到的報文中的目的端口号不正确，就會丢棄改報文，并由網際控制協議ICMP發送“端口不可達”差錯報文給發送方。ICMP應用Traceroute,就是讓發送的UDP用戶數據報故意使用一個非法的UDP端口，結果ICMP返回“端口不可達”差錯報文，因而達到了測試的目的。

• 在目的端口後面是長度固定的以字節為單位的報文長度域，用來指定UDP數據報包括數據部分的長度，長度最小值為8byte。
• 首部剩下地16bit是用來對首部和數據部分一起做校驗和（Checksum）的，這部分是可選的，但在實際應用中一般都使用這一功能。
• UDP和TCP的校驗和都覆蓋到了他們的首部和數據，而IP首部的校驗和隻覆蓋了IP首部。

随着我們進入傳輸層，我們也可以調用操作系統中的API，來構建socket。Socket是操作系統提供的一個編程接口，它用來代表某個網絡通信。應用程序通過socket來調用系統内核中處理網絡協議的模塊，而這些内核模塊會負責具體的網絡協議的實施。

這樣，我們可以讓内核來接收網絡協議的細節，而我們隻需要提供所要傳輸的内容就可以了，内核會幫我們控制格式，并進一步向底層封裝。因此，在實際應用中，我們并不需要知道具體怎麼構成一個UDP包，而隻需要提供相關信息(比如IP地址，比如端口号，比如所要傳輸的信息)，操作系統内核會在傳輸之前會根據我們提供的相關信息構成一個合格的UDP包(以及下層的包和幀)。看下圖吧。

1. 需要資源少，在網絡情況比較好的内網，或者對于丢包不敏感的應用。如DHCP協議就是基于UDP的。一般的獲取IP地址都是内網請求，而且一次獲取不到IP又沒事。又比如基于UDP的RTP，TFTP，丢一幀數據問題也不大。再比如一些設備發現協議等等。
2. 不需要一對一溝通，建立連接，而是可以廣播的應用。DHCP就是一種廣播的形式。VXLAN也是需要用到組播，也是基于UDP協議的。
3. 需要處理速度快，時延低，可以容忍少數丢包，但是要求即便網絡擁塞，也毫不退縮，一往無前的時候。
4. QUIC是Google提出的一種基于UDP改進的通信協議，其目的是降低網絡通信的延遲，提供更好的用戶互動體驗。

UDP沒有TCP那麼複雜，但是網絡體系中不可缺少的協議。需要熟練的掌握該協議。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!