UDP協議-看這篇就夠了
每一個程序員應該都知道TCP，UDP協議。UDP是用戶數據報文協議，屬于OSI模型中的傳輸層。它是一種無連接的協議，也就說上一報文和下一報文在協議層沒有任何聯系，同時提供了簡單的不可靠的傳輸服務。
也就是說UDP是不可靠的，如果要想讓數據可靠，就需要在業務層做糾錯和檢錯功能。比如：TFTP。
那可能就會有同學問了，既然是不可靠的，為什么不直接使用IP協議呢?還要這么大費周章增加一種協議UDP呢?
其實其中一個最重要的原因就是IP協議中沒有端口(port)的概念，它只是規定了兩臺主機之間的通信，并沒有解決不同主機上應用程序之間的通信。如果一個主機上的多個應用程序需要通信，直接用IP協議就無法數據區分數據到底哪個應用程序了。
可以理解為一個端口就是一個通信通道，當然UDP在IP協議的基礎上增加了一些功能，所以我們來總結下：
- UDP無連接，沒有連接。所以它的發送和接受的開銷就會小很多。
- UDP不保證數據可靠交付，只是盡最大可能。所以不需要維護復雜的連接關系。
- UDP是面向報文的，添加在應用層下來數據頭部，直接塞給IP層。
- UDP沒有擁塞控制
- UDP至支持多播。
- UDP頭部小，說明傳輸更多的數據內容
下圖展示是UDP和上下層的關系：
UDP的首部到底是怎樣的呢?
先看下圖：
從圖中可以看出，UDP的首部由四部分組成：
- 各16bit的來源端口和目的端口用來標記發送和接受的應用進程。因為UDP不需要應答，所以來源端口是可選的，如果來源端口不用，那么置為零。當運輸層從IP層收到UDP數據報時，就是根據首部中的目的端口，把UDP數據報通過相應的端口，上交最后的終點--應用程序。
- 如果接收方UDP發現收到的報文中的目的端口號不正確，就會丟棄改報文，并由網際控制協議ICMP發送“端口不可達”差錯報文給發送方。ICMP應用Traceroute,就是讓發送的UDP用戶數據報故意使用一個非法的UDP端口，結果ICMP返回“端口不可達”差錯報文，因而達到了測試的目的。
在目的端口后面是長度固定的以字節為單位的報文長度域，用來指定UDP數據報包括數據部分的長度，長度最小值為8byte。
首部剩下地16bit是用來對首部和數據部分一起做校驗和(Checksum)的，這部分是可選的，但在實際應用中一般都使用這一功能。
UDP和TCP的校驗和都覆蓋到了他們的首部和數據，而IP首部的校驗和只覆蓋了IP首部。
UDP和socket怎樣配合使用
隨著我們進入傳輸層，我們也可以調用操作系統中的API，來構建socket。Socket是操作系統提供的一個編程接口，它用來代表某個網絡通信。應用程序通過socket來調用系統內核中處理網絡協議的模塊，而這些內核模塊會負責具體的網絡協議的實施。
這樣，我們可以讓內核來接收網絡協議的細節，而我們只需要提供所要傳輸的內容就可以了，內核會幫我們控制格式，并進一步向底層封裝。因此，在實際應用中，我們并不需要知道具體怎么構成一個UDP包，而只需要提供相關信息(比如IP地址，比如端口號，比如所要傳輸的信息)，操作系統內核會在傳輸之前會根據我們提供的相關信息構成一個合格的UDP包(以及下層的包和幀)。看下圖吧。
UDP使用場景
需要資源少，在網絡情況比較好的內網，或者對于丟包不敏感的應用。如DHCP協議就是基于UDP的。一般的獲取IP地址都是內網請求，而且一次獲取不到IP又沒事。又比如基于UDP的RTP，TFTP，丟一幀數據問題也不大。再比如一些設備發現協議等等。
不需要一對一溝通，建立連接，而是可以廣播的應用。DHCP就是一種廣播的形式。VXLAN也是需要用到組播，也是基于UDP協議的。
需要處理速度快，時延低，可以容忍少數丟包，但是要求即便網絡擁塞，也毫不退縮，一往無前的時候。
QUIC是Google提出的一種基于UDP改進的通信協議，其目的是降低網絡通信的延遲，提供更好的用戶互動體驗。
結語
UDP沒有TCP那么復雜，但是網絡體系中不可缺少的協議。需要熟練的掌握該協議。
