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

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

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

其實其中一個最重要的原因就是IP協(xié)議中沒有端口(port)的概念，它只是規(guī)定了兩臺主機之間的通信，并沒有解決不同主機上應用程序之間的通信。如果一個主機上的多個應用程序需要通信，直接用IP協(xié)議就無法數(shù)據(jù)區(qū)分數(shù)據(jù)到底哪個應用程序了。

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

• UDP無連接，沒有連接。所以它的發(fā)送和接受的開銷就會小很多。
• UDP不保證數(shù)據(jù)可靠交付，只是盡***可能。所以不需要維護復雜的連接關(guān)系。
• UDP是面向報文的，添加在應用層下來數(shù)據(jù)頭部，直接塞給IP層。
• UDP沒有擁塞控制
• UDP至支持多播。
• UDP頭部小，說明傳輸更多的數(shù)據(jù)內(nèi)容

下圖展示是UDP和上下層的關(guān)系：

UDP的首部到底是怎樣的呢?

先看下圖：

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

• 各16bit的來源端口和目的端口用來標記發(fā)送和接受的應用進程。因為UDP不需要應答，所以來源端口是可選的，如果來源端口不用，那么置為零。當運輸層從IP層收到UDP數(shù)據(jù)報時，就是根據(jù)首部中的目的端口，把UDP數(shù)據(jù)報通過相應的端口，上交***的終點--應用程序。如果接收方UDP發(fā)現(xiàn)收到的報文中的目的端口號不正確，就會丟棄改報文，并由網(wǎng)際控制協(xié)議ICMP發(fā)送“端口不可達”差錯報文給發(fā)送方。ICMP應用Traceroute,就是讓發(fā)送的UDP用戶數(shù)據(jù)報故意使用一個非法的UDP端口，結(jié)果ICMP返回“端口不可達”差錯報文，因而達到了測試的目的。



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

UDP和socket怎樣配合使用

隨著我們進入傳輸層，我們也可以調(diào)用操作系統(tǒng)中的API，來構(gòu)建socket。Socket是操作系統(tǒng)提供的一個編程接口，它用來代表某個網(wǎng)絡(luò)通信。應用程序通過socket來調(diào)用系統(tǒng)內(nèi)核中處理網(wǎng)絡(luò)協(xié)議的模塊，而這些內(nèi)核模塊會負責具體的網(wǎng)絡(luò)協(xié)議的實施。

這樣，我們可以讓內(nèi)核來接收網(wǎng)絡(luò)協(xié)議的細節(jié)，而我們只需要提供所要傳輸?shù)膬?nèi)容就可以了，內(nèi)核會幫我們控制格式，并進一步向底層封裝。因此，在實際應用中，我們并不需要知道具體怎么構(gòu)成一個UDP包，而只需要提供相關(guān)信息(比如IP地址，比如端口號，比如所要傳輸?shù)男畔?，操作系統(tǒng)內(nèi)核會在傳輸之前會根據(jù)我們提供的相關(guān)信息構(gòu)成一個合格的UDP包(以及下層的包和幀)。看下圖吧。

UDP使用場景

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

結(jié)語

UDP沒有TCP那么復雜，但是網(wǎng)絡(luò)體系中不可缺少的協(xié)議。需要熟練的掌握該協(xié)議。