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