本頁使用了標題或全文手工轉換

用戶數據報協議

維基百科,自由的百科全書
前往: 導覽搜尋

用戶數據包協議英語:User Datagram Protocol,縮寫為UDP),又稱使用者資料包協定,是一個簡單的面向數據報的傳輸層協議,正式規範為RFC 768。

在TCP/IP模型中,UDP為網絡層以上和應用層以下提供了一個簡單的接口。UDP只提供數據的不可靠傳遞,它一旦把應用程序發給網絡層的數據發送出去,就不保留數據備份(所以UDP有時候也被認為是不可靠的數據報協議)。UDP在IP數據報的頭部僅僅加入了復用和數據校驗(字段)。

UDP首部字段由4個部分組成,其中兩個是可選的。各16bit的來源端口和目的端口用來標記發送和接受的應用進程。因為UDP不需要應答,所以來源端口是可選的,如果來源端口不用,那麼置為零。在目的端口後面是長度固定的以字節為單位的長度域,用來指定UDP數據報包括數據部分的長度,長度最小值為8byte。首部剩下地16bit是用來對首部和數據部分一起做校驗和(Checksum)的,這部分是可選的,但在實際應用中一般都使用這一功能。

由於缺乏可靠性且屬於非連接導向協定,UDP應用一般必須允許一定量的丟包、出錯和複製貼上。但有些應用,比如TFTP,如果需要則必須在應用層增加根本的可靠機制。但是絕大多數UDP應用都不需要可靠機制,甚至可能因為引入可靠機制而降低性能。流媒體(串流技術)、即時多媒體遊戲和IP電話(VoIP)一定就是典型的UDP應用。如果某個應用需要很高的可靠性,那麼可以用傳輸控制協議(TCP協議)來代替UDP。

由於缺乏擁塞控制(congestion control),需要基於網絡的機制來減少因失控和高速UDP流量負荷而導致的擁塞崩潰效應。換句話說,因為UDP發送者不能夠檢測擁塞,所以像使用包隊列和丟棄技術的路由器這樣的網絡基本設備往往就成為降低UDP過大通信量的有效工具。數據報擁塞控制協議(DCCP)設計成通過在諸如流媒體類型的高速率UDP流中,增加主機擁塞控制,來減小這個潛在的問題。

典型網絡上的眾多使用UDP協議的關鍵應用一定程度上是相似的。這些應用包括域名系統(DNS)、簡單網絡管理協議(SNMP)、動態主機配置協議(DHCP)、路由信息協議(RIP)和某些影音串流服務等等。

UDP的分組結構[編輯]

UDP報頭
偏移 字節 0 1 2 3
字節  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 來源連接端口 目的連接端口
4 32 報文長度 校驗和

UDP報頭包括4個字段,每個字段占用2個字節(即16個二進制位)。在IPv4中,「來源連接端口」和「校驗和」是可選字段(以粉色背景標出)。在IPv6中,只有來源連接端口是可選字段。

報文長度
該字段指定UDP報頭和數據總共占用的長度。可能的最小長度是8字節,因為UDP報頭已經占用了8字節。由於這個字段的存在,UDP報文總長不可能超過65535字節(包括8字節的報頭,和65527字節的數據)。實際上通過IPv4協議傳輸時,由於IPv4的頭部信息要占用20字節,因此數據長度不可能超過65507字節(65,535 − 8字節UDP報頭 − 20字節IP頭部)。
在IPv6的jumbogram中,是有可能傳輸超過65535字節的UDP數據包的。依據RFC 2675,如果這種情況發生,報文長度應被填寫為0。
校驗和
校驗和字段可以用於發現頭部信息和數據中的傳輸錯誤。該字段在IPv4中是可選的,在IPv6中則是強制的。如果不使用校驗和,該字段應被填充為全0。

UDP校驗和計算[編輯]

IPv4偽頭部[編輯]

當UDP運行在IPv4之上時,為了能夠計算校驗和,需要在UDP數據包前添加一個「偽頭部」。偽頭部包括了IPv4頭部中的一些信息,但它並不是發送IP數據包時使用的IP數據包的頭部,而只是一個用來計算校驗和而已。

0 – 7 8 – 15 16 – 23 24 – 31
0 來源地址
32 目的地址
64 全零 協議名 UDP報文長度
96 來源連接端口 目的連接端口
128 報文長度 檢驗和
160+  
數據
 

IPv6偽頭部[編輯]

0 – 7 8 – 15 16 – 23 24 – 31
0 來源地址
32
64
96
128 目的地址
160
192
224
256 UDP報文長
288 全零 下一個指針位置
320 來源連接端口 目的連接端口
352 報文長 校驗和
384+  
數據
 

參考文獻[編輯]