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

用戶資料報協定

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

用戶封包協定英語: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+  
資料
 

參考文獻[編輯]