用戶資料報協定

使用者資料包協定（英語：User Datagram Protocol，縮寫：UDP；又稱用戶資料包協定）是一個簡單的面向資料包的通訊協定，位於OSI模型的傳輸層。該協定由David P. Reed（英語：David P. Reed）在1980年設計且在RFC 768中被規範。典型網絡上的眾多使用UDP協定的關鍵應用在一定程度上是相似的。

在TCP/IP模型中，UDP為網絡層以上和應用層以下提供了一個簡單的介面。UDP只提供資料的不可靠傳遞，它一旦把應用程式發給網絡層的資料傳送出去，就不保留資料備份（所以UDP有時候也被認為是不可靠的資料包協定）。UDP在IP資料包的頭部僅僅加入了復用和資料校驗欄位。

UDP適用於不需要或在程式中執行錯誤檢查和糾正的應用，它避免了協定棧中此類處理的開銷（英語：Overhead (computing)）。對時間有較高要求的應用程式通常使用UDP，因為丟棄資料包比等待或重傳導致延遲更可取。

可靠性

由於UDP缺乏可靠性且屬於無連接協定，所以應用程式通常必須容許一些遺失、錯誤或重複的封包。某些應用程式（如TFTP）可能會根據需要在應用程式層中添加基本的可靠性機制。^[1]

一些應用程式不太需要可靠性機制，甚至可能因為引入可靠性機制而降低效能，所以它們使用UDP這種缺乏可靠性的協定。串流媒體，即時多人遊戲和IP語音（VoIP）是經常使用UDP的應用程式。在這些特定應用中，丟包通常不是重大問題。如果應用程式需要高度可靠性，則可以使用諸如TCP之類的協定。

例如，在VoIP中延遲和抖動是主要問題。如果使用TCP，那麼任何封包遺失或錯誤都將導致抖動，因為TCP在請求及重傳遺失資料時不向應用程式提供後續資料。如果使用TCP，那麼應用程式則需要提供必要的握手，例如即時確認已收到的訊息。

由於UDP缺乏擁塞控制，所以需要基於網絡的機制來減少因失控和高速UDP流量負荷而導致的擁塞崩潰效應。換句話說，因為UDP傳送端無法檢測擁塞，所以像使用包佇列和丟棄技術的路由器之類的網絡基礎裝置會被用於降低UDP過大流量。資料擁塞控制協定（DCCP）設計成通過在諸如串流媒體類型的高速率UDP流中增加主機擁塞控制，來減小這個潛在的問題。

應用

許多關鍵的互聯網應用程式使用UDP^[2]，包括：

域名系統（DNS），其中查詢階段必須快速，並且只包含單個請求，後跟單個回覆封包；
動態主機組態協定（DHCP），用於動態分配IP位址；
簡單網絡管理協定（SNMP）；
路由資訊協定（RIP）；
網絡時間協定（NTP）。

串流媒體、線上遊戲流量通常使用UDP傳輸。即時影片流和音頻流應用程式旨在處理偶爾遺失、錯誤的封包，因此只會發生質素輕微下降，而避免了重傳封包帶來的高延遲。由於TCP和UDP都在同一網絡上執行，因此一些企業發現來自這些即時應用程式的UDP流量影響了使用TCP的應用程式的效能，例如銷售、會計和資料庫系統。當TCP檢測到封包遺失時，它將限制其資料速率使用率。由於即時和業務應用程式對企業都很重要，因此一些人認為開發服務質素解決方案至關重要。^[3]

某些VPN應用（如OpenVPN）使用UDP並可以在應用程式級別實現可靠連接和錯誤檢查。

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中，只有來源連接埠是可選欄位。各16bit的來源埠和目的埠用來標記傳送和接受的應用行程。因為UDP不需要應答，所以來源埠是可選的，如果來源埠不用，那麼置為零。在目的埠後面是長度固定的以位元組為單位的長度域，用來指定UDP資料報包括資料部分的長度，長度最小值為8byte。首部剩下地16bit是用來對首部和資料部分一起做校驗和（Checksum）的，這部分是可選的，但在實際應用中一般都使用這一功能。

報文長度: 該欄位指定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
0	來源地址
32	目的地址
64	全零	協定名	UDP報文長度
96	來源連接埠		目的連接埠
128	報文長度		核對和
160+	資料

IPv6偽頭部

當UDP執行於IPV6之上時，校驗和是必須的，其計算方法位於RFC 2460:

任何包含來自IP頭地址的傳輸層或其他上層協定，其校驗和計算必須被修改，以適應IPv6的128位元ip地址。^[4]

IPv6偽頭部是生成校驗和所用的資料。

位	0 – 7	16 – 23	24 – 31
0	來源地址
32
64
96
128	目的地址
160
192
224
256	UDP報文長度
288	全零		下一個指標位置
320	來源連接埠	目的連接埠
352	報文長度	校驗和
384+	資料

參見

TCP/UDP埠列表
UDP-Lite——一種通過減少校驗和覆蓋程度來提升資料可達性的改進
Micro Transport Protocol
基於UDP的資料傳輸協定

參考文獻

^ Forouzan, B.A. (2000). TCP/IP: Protocol Suite, 1st ed. New Delhi, India: Tata McGraw-Hill Publishing Company Limited.
^ Kurose, J. F.; Ross, K. W. Computer Networking: A Top-Down Approach 5th. Boston, MA: Pearson Education. 2010. ISBN 978-0-13-136548-3.
^ The impact of UDP on Data Applications. Networkperformancedaily.com. [17 August 2011]. （原始內容存檔於31 July 2007）.
^ Deering S. & Hinden R. Internet Protocol, Version 6 (IPv6) Specification. Internet Engineering Task Force. December 1998 [2019-01-22]. RFC 2460  . （原始內容存檔於2011-04-06）.

外部連結

RFC768 Archive.is的存檔，存檔日期2012-07-22
UDP協定詳細資料（頁面存檔備份，存於互聯網檔案館）

[forouzan-1] Forouzan, B.A. (2000). TCP/IP: Protocol Suite, 1st ed. New Delhi, India: Tata McGraw-Hill Publishing Company Limited.

[kuroseross-2] Kurose, J. F.; Ross, K. W. Computer Networking: A Top-Down Approach 5th. Boston, MA: Pearson Education. 2010. ISBN 978-0-13-136548-3.

[3] The impact of UDP on Data Applications. Networkperformancedaily.com. [17 August 2011]. （原始內容存檔於31 July 2007）.

[rfc2460-4] Deering S. & Hinden R. Internet Protocol, Version 6 (IPv6) Specification. Internet Engineering Task Force. December 1998 [2019-01-22]. RFC 2460  . （原始內容存檔於2011-04-06）.

[1]

[2]

[3]

[4]