用戶數據報協議

使用者資料包協定（英語：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]