目錄
一、UDP簡介
UDP協議全稱是用戶數據報協議（User Datagram Protocol），在網絡中它與TCP協議一樣用於處理數據包，是一種無連接的協議。在OSI模型中，在第四層——傳輸層，處於IP協議的上一層。UDP有不提供數據包分組、組裝和不能對數據包進行排序的缺點，也就是說，當報文發送之後，是無法得知其是否安全完整到達的。
UDP傳輸與IP傳輸非常類似。你可以將UDP協議看作IP協議暴露在傳輸層的一個接口。UDP協議同樣以數據包的方式傳輸，它的傳輸方式也是"Best Effort"的（盡最大努力交付，但不保證可靠交付），所以UDP協議也是不可靠的。
那麼，我們爲什麼不直接使用IP協議而要額外增加一個UDP協議呢？ 一個重要的原因是IP協議中並沒有端口(port)的概念。IP協議進行的是IP地址到IP地址的傳輸，這意味者兩臺計算機之間的對話。但每臺計算機中需要有多個通信通道，並將多個通信通道分配給不同的進程使用，一個端口就代表了這樣的一個通信通道。
二、UDP的特點
2.1 面向無連接
首先 UDP 是不需要和 TCP一樣在發送數據前進行三次握手建立連接的，想發數據就可以開始發送了。並且也只是數據報文的搬運工，不會對數據報文進行任何拆分和拼接操作。
UDP無連接，時間上不存在建立連接需要的時延。空間上，TCP需要在端系統中維護連接狀態，需要一定的開銷。此連接裝入包括接收和發送緩存，擁塞控制參數和序號與確認號的參數。UCP不維護連接狀態，也不跟蹤這些參數，開銷小。空間和時間上都具有優勢。
具體來說就是：
- 在發送端，應用層將數據傳遞給傳輸層的 UDP 協議，UDP 只會給數據增加一個 UDP 頭標識下是 UDP 協議，然後就傳遞給網絡層了
- 在接收端，網絡層將數據傳遞給傳輸層，UDP 只去除 IP 報文頭就傳遞給應用層，不會任何拼接操作
舉個例子：
- DNS如果運行在TCP之上而不是UDP，那麼DNS的速度將會慢很多。
- HTTP使用TCP而不是UDP，是因爲對於基於文本數據的Web網頁來說，可靠性很重要。
- 同一種專用應用服務器在支持UDP時，一定能支持更多的活動客戶機。
2.2 有單播，多播，廣播的功能
UDP 不止支持一對一的傳輸方式，同樣支持一對多，多對多，多對一的方式，也就是說 UDP 提供了單播，多播，廣播的功能。
2.3 UDP是面向報文的
發送方的UDP對應用程序交下來的報文，在添加首部後就向下交付IP層。UDP對應用層交下來的報文，既不合並，也不拆分，而是保留這些報文的邊界。因此，應用程序必須選擇合適大小的報文。
對IP層交上來UDP用戶數據報，在去除首部後就原封不動地交付給上層應用進程，報文不可分割，是UDP數據報處理的最小單位。
正是因爲這樣，UDP顯得不夠靈活，不能控制讀寫數據的次數和數量。比如我們要發送100個字節的報文，我們調用一次sendto函數就會發送100字節，對端也需要用recvfrom函數一次性接收100字節，不能使用循環每次獲取10個字節，獲取十次這樣的做法。
2.4 不可靠性（無擁塞控制）
首先不可靠性體現在無連接上，通信都不需要建立連接，想發就發，這樣的情況肯定不可靠。
並且收到什麼數據就傳遞什麼數據，並且也不會備份數據，發送數據也不會關心對方是否已經正確接收到數據了。
再者網絡環境時好時壞，但是 UDP 因爲沒有擁塞控制，一直會以恆定的速度發送數據。即使網絡條件不好，也不會對發送速率進行調整。這樣實現的弊端就是在網絡條件不好的情況下可能會導致丟包，但是優點也很明顯，在某些實時性要求高的場景（比如電話會議）就需要使用 UDP 而不是 TCP。
從上面的動態圖可以得知，UDP只會把想發的數據報文一股腦的丟給對方，並不在意數據有無安全完整到達。
總的來說：
- UDP沒有擁塞控制，應用層能夠更好的控制要發送的數據和發送時間，網絡中的擁塞控制也不會影響主機的發送速率。某些實時應用要求以穩定的速度發送，能容忍一些數據的丟失，但是不能允許有較大的時延（比如實時視頻，直播等）
- UDP提供盡最大努力的交付，不保證可靠交付。因此主機不需要維持複雜的連接狀態表。所有維護傳輸可靠性的工作需要用戶在應用層來完成。沒有TCP的確認機制、重傳機制。如果因爲網絡原因沒有傳送到對端，UDP也不會給應用層返回錯誤信息
2.5 首部開銷小，傳輸數據報文時是很高效的
UDP 頭部包含了以下幾個數據：
- 兩個十六位的端口號，分別爲源端口（可選字段）和目標端口
- 整個數據報文的長度
- 整個數據報文的檢驗和（IPv4 可選 字段），該字段用於發現頭部信息和數據中的錯誤
因此 UDP 的頭部開銷小，只有八字節，相比 TCP 的至少二十字節要少得多，在傳輸數據報文時是很高效的。
三、UDP首部
UDP首部有8個字節，由4個字段構成，每個字段都是兩個字節，
- 源端口： 源端口號，需要對方回信時選用，不需要時全部置0。長度爲16bit
- 目的端口：目的端口號，在終點交付報文的時候需要用到。長度爲16bit
- 長度：UDP的數據報的長度（包括首部和數據），其最小值爲8byte（只有首部）。長度爲16bit
- 校驗和（Checksum）：檢測UDP數據報在傳輸中是否有錯，有錯則丟棄。該字段是可選的，當源主機不想計算校驗和，則直接令該字段全爲0。UDP和TCP的校驗和都覆蓋到了他們的首部和數據，而IP報文首部的校驗和只覆蓋了IP首部。長度爲16bit
16bit的源端口和目的端口用來標記發送和接受的應用進程。因爲UDP不需要應答，所以源端口是可選的，如果源端口不用，那麼置爲零。當運輸層從IP層收到UDP數據報時，就是根據首部中的目的端口，把UDP數據報通過相應的端口，上交最後的終點——應用程序。
如果接收方UDP發現收到的報文中的目的端口號不正確（不存在對應端口號的應用進程0,），就丟棄該報文，並由ICMP發送“端口不可達”差錯報文給對方。ICMP應用Traceroute,就是讓發送的UDP用戶數據報故意使用一個非法的UDP端口，結果ICMP返回“端口不可達”差錯報文，因而達到了測試的目的。
以下爲這四部分的示意圖：
四、UDP校驗
4.1 UDP校驗和
在計算校驗和的時候，需要在UDP數據報之前增加12字節的僞首部，僞首部並不是UDP真正的首部。只是在計算校驗和時，臨時添加在UDP數據報的前面，得到一個臨時的UDP數據報。校驗和就是按照這個臨時的UDP數據報計算的。僞首部既不向下傳送也不向上遞交（但是會在發送方和接收方之間進行同層次[運輸層]的傳送），而僅僅是爲了計算校驗和。這樣的校驗和，既檢查了UDP數據報，又對IP數據報的源IP地址和目的IP地址進行了檢驗。
UDP校驗和的計算方法和IP數據報首部校驗和的計算方法相似，都使用二進制反碼運算求和再取反，但不同的是：IP數據報的校驗和只檢驗IP數據報的首部，但UDP的校驗和是把首部和數據部分一起校驗。
在發送端，首先是將全零放入檢驗和字段，並且添加僞首部。再將僞首部以及UDP用戶數據報（包括UDP首部和數據部分）看成是由許多16bit的字串接起來。 若UDP用戶數據報的數據部分不是偶數個字節，則要填入一個全零字節(即：最後一個基數字節應是16位數的高字節而低字節填0)。 然後按二進制反碼計算出這些16bit字的和(兩個數進行二進制反碼求和的運算的規則是：從低位到高位逐列進行計算。 0和0相加是0，0和1相加是1，1和1相加是0但要產生一個進位1，加到下一列。若最高位相加後產生進位，則最後得到的結果要加1)，即將僞首部、UDP首部、UDP數據部分的所有二級制數按照16位爲一組分割出來，將所有的16位的二進制數求加和，然後將得到的結果取反存入到UDP報文的校驗和字段中（修改初始的全零校驗和），然後發送此UDP用戶數據報。 在接收端，將收到的UDP首部、UDP數據連同僞首部(以及可能的填充全零字節)一起，按照上面相同的方法進行計算，求分割出來的16bit數據的二進制和，並且將結果取反。 當無差錯時其結果應全爲1。否則就表明有差錯出現， 接收端就應將此UDP用戶數據報丟棄(也可以上交給應用層，但附上出現了差錯的警告)。
這種差錯檢驗的檢錯能力不強，但是簡單，速度快
4.2 TCP協議、IP協議、ICMP協議的校驗方法
4.2.1 TCP協議
TCP 的校驗和計算方法同UDP一樣，同樣要加上一個僞頭部，區別是僞頭部的協議碼是0x06，長度是整個TCP報文的長度（包含TCP頭部）。
4.2.2 IP協議
IP協議的首部檢驗和佔16位。這個字段只檢驗數據報的首部，但不包括數據部分。這是因爲數據報每經過一個路由器，路由器都要重新計算一下首部檢驗和（一些字段，如生存 時間、標誌、片偏移等都可能發生變化)。不檢驗數據部分可減少計算的工作量。爲了進一步減小計算檢驗和的工作量，IP首部的檢驗和不採用複雜的CRC檢驗碼而採用下面的簡單計算方法：在發送方，先把IP數據報首部劃分爲許多16位字的序列，並把檢驗和字段置零。用反碼算術運算把所有16位字相加後，將得到的和的反碼寫入檢驗和字段。接收方收到數據報後，將首部的所有16位字再使用反碼算術運算相加一次。將得到的和取反碼，即得出接收方檢驗和的計算結果。若首部未發生任何變化，則此結果必爲0，於是就保留這個數據報。否則即認爲出差錯，並將此數據報丟棄。下圖說明了 IP數據報首部檢驗和的計算過程。
4.2.3 ICMP協議
ICMP校驗和的計算方法一樣，只不過只是對ICMP包整個進行校驗和，沒有僞頭部，也不包括IP包頭部。
四、UDP協議使用場景
- 需要資源少，在網絡情況比較好的內網，或者對於丟包不敏感的應用。如DHCP協議就是基於UDP的。一般的獲取IP地址都是內網請求，而且一次獲取不到IP又沒事。
- 不需要一對一溝通，建立連接，而是可以廣播的應用。DHCP就是一種廣播的形式。VXLAN也是需要用到組播，也是基於UDP協議的。
- 需要處理速度快，時延低，可以容忍少數丟包，但是要求即便網絡擁塞，也毫不退縮，一往無前的時候。
- QUIC是Google提出的一種基於UDP改進的通信協議，其目的是降低網絡通信的延遲，提供更好的用戶互動體驗。
- UDP常用一次性傳輸比較少量數據的網絡應用，如DNS,SNMP等，因爲對於這些應用，若是採用TCP，爲連接的創建，維護和拆除帶來不小的開銷。UDP也常用於多媒體應用（如IP電話，實時視頻會議，流媒體等）數據的可靠傳輸對他們而言並不重要，TCP的擁塞控制會使他們有較大的延遲，也是不可容忍的
參考資料：https://www.linuxidc.com/Linux/2018-09/154366.htm
計算機網絡（第7版）-謝希仁