用戶數據報協議（英語：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報頭偏移字節0123字節位?0?1?2?3?4?5?6?7?8?91011121314151617181920212223242526272829303100432

來源連接端口

目的連接端口

報文長度

校驗和

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 – 78 – 1516 – 2324 – 310326496128160+

來源地址

目的地址

全零

協議名

UDP報文長度

來源連接端口

目的連接端口

報文長度

檢驗和

? 數據 ?

IPv6偽頭部

位0 – 78 – 1516 – 2324 – 310326496128160192224256288320352384+

來源地址

目的地址

UDP報文長

全零

下一個指針位置

來源連接端口

目的連接端口

報文長

校驗和

? 數據 ?

轉自**百科。

總結

以上是生活随笔為你收集整理的UDP：用户数据报协议 是什么的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。