UDP
用戶數據報協議
UDP是UserDatagramProtocol的簡稱，中文名是用戶數據報協議，是OSI（OpenSystemInterconnection，開放式系統互聯）參考模型中一種無連接的傳輸層協議，提供面向事務的簡單不可靠信息傳送服務，IETFRFC768是UDP的正式規範。UDP在IP報文的協議號是17。UDP協議全稱是用戶數據報協議，在網路中它與TCP協議一樣用於處理數據包，是一種無連接的協議。在OSI模型中，在第四層——傳輸層，處於IP協議的上一層。UDP有不提供數據包分組、組裝和不能對數據包進行排序的缺點，也就是說，當報文發送之後，是無法得知其是否安全完整到達的。UDP用來支持那些需要在計算機之間傳輸數據的網路應用。包括網路視頻會議系統在內的眾多的客戶，伺服器模式的網路應用都需要使用UDP協議。UDP協議從問世至今已經被使用了很多年，雖然其最初的光彩已經被一些類似協議所掩蓋，但是即使是在今天UDP仍然不失為一項非常實用和可行的網路傳輸層協議。
UDP
UDP提供了無連接通信，且不對傳送數據包進行可靠性保證，適合於一次傳輸少量數據，UDP傳輸的可靠性由應用層負責。常用的UDP埠號有：
應用協議 埠號
DNS 53
TFTP 69
SNMP 161
UDP報文沒有可靠性保證、順序保證和流量控制欄位等，可靠性較差。但是正因為UDP協議的控制選項較少，在數據傳輸過程中延遲小、數據傳輸效率高，適合對可靠性要求不高的應用程序，或者可以保障可靠性的應用程序，如DNS、TFTP、SNMP等。
在選擇使用協議的時候，選擇UDP必須要謹慎。在網路質量令人十分不滿意的環境下，UDP協議數據包丟失會比較嚴重。但是由於UDP的特性：它不屬於連接型協議，因而具有資源消耗小，處理速度快的優點，所以通常音頻、視頻和普通數據在傳送時使用UDP較多，因為它們即使偶爾丟失一兩個數據包，也不會對接收結果產生太大影響。比如我們聊天用的ICQ和QQ就是使用的UDP協議。
UDP報頭由4個域組成，其中每個域各佔用2個位元組，具體如下：
源埠號
目標埠號
數據報長度
校驗值
UDP協議使用埠號為不同的應用保留其各自的數據傳輸通道。UDP和TCP協議正是採用這一機制實現對同一時刻內多項應用同時發送和接收數據的支持。數據發送一方（可以是客戶端或伺服器端）將UDP數據包通過源埠發送出去，而數據接收一方則通過目標埠接收數據。有的網路應用只能使用預先為其預留或註冊的靜態埠；而另外一些網路應用則可以使用未被註冊的動態埠。因為UDP報頭使用兩個位元組存放埠號，所以埠號的有效範圍是從0到65535。一般來說，大於49151的埠號都代表動態埠。
數據報的長度是指包括報頭和數據部分在內的總位元組數。因為報頭的長度是固定的，所以該域主要被用來計算可變長度的數據部分（又稱為數據負載）。數據報的最大長度根據操作環境的不同而各異。從理論上說，包含報頭在內的數據報的最大長度為65535位元組。不過，一些實際應用往往會限制數據報的大小，有時會降低到8192位元組。
UDP協議使用報頭中的校驗值來保證數據的安全。校驗值首先在數據發送方通過特殊的演演算法計算得出，在傳遞到接收方之後，還需要再重新計算。如果某個數據報在傳輸過程中被第三方篡改或者由於線路噪音等原因受到損壞，發送和接收方的校驗計算值將不會相符，由此UDP協議可以檢測是否出錯。這與TCP協議是不同的，後者要求必須具有校驗值。
許多鏈路層協議都提供錯誤檢查，包括流行的乙太網協議，也許你想知道為什麼UDP也要提供檢查和校驗。其原因是鏈路層以下的協議在源端和終端之間的某些通道可能不提供錯誤檢測。雖然UDP提供有錯誤檢測，但檢測到錯誤時，UDP不做錯誤校正，只是簡單地把損壞的消息段扔掉，或者給應用程序提供警告信息。
UDP Helper是實現對指定UDP埠廣播報文的中繼轉發，即將指定UDP埠的廣播報文轉換為單播報文發送給指定的伺服器，起到中繼的作用.
UDP
使用UDP協議包括：TFTP、SNMP、NFS、DNS、BOOTP
UDP使用底層的網際網路協議來傳送報文，同IP一樣提供不可靠的無連接數據包傳輸服務。它不提供報文到達確認、排序、及流量控制等功能。
每個UDP報文分UDP報頭和UDP數據區兩部分。報頭由四個16位長（2位元組）欄位組成，分別說明該報文的源埠、目的埠、報文長度以及校驗值。
在TCP/IP協議層次模型中，UDP位於IP層之上。應用程序訪問UDP層然後使用IP層傳送數據報。IP層的報頭指明了源主機和目的主機地址，而UDP層的報頭指明了主機上的源埠和目的埠。
UDP的復用、分解與埠
UDP軟體應用程序之間的復用與分解都要通過埠機制來實現。每個應用程序在發送數據報之前必須與操作系統協商以獲得協議埠和相應的埠號。
UDP分解操作：從IP層接收了數據報之後，根據UDP的目的埠號進行分解操作。
UDP埠號指定有兩種方式：由管理機構指定埠和動態綁定的方式。
1.1.1 display udp-helper server
【命令】
display udp-helper server[interfaceinterface-type interface-number]
【視圖】
任意視圖
【預設級別】
2：系統級
【參數】
interfaceinterface-type interface-number：顯示指定介面的UDP中繼轉發相關信息。interface-type interface-number為介面類型和介面編號。
【描述】
display udp-helper server命令用來顯示UDP中繼轉發的相關信息。
如果不選擇參數，則顯示所有介面的UDP中繼轉發相關信息。
【舉例】
# 顯示VLAN介面1的UDP中繼轉發相關信息。
Interface name Server address Packets sent
Vlan-interface1 192.1.1.2 0
以上顯示信息表示VLAN介面1對應的目的伺服器的IP地址為192.1.1.2，中繼轉發到該目的伺服器的報文數為0。
1.1.2 reset udp-helper packet
【命令】
reset udp-helper packet
【視圖】
用戶視圖
【預設級別】
2：系統級
【參數】
無
【描述】
reset udp-helper packet命令用來清除UDP中繼轉發的報文統計數目。
【舉例】
# 清除UDP中繼轉發的報文統計數目。
1.1.3 udp-helper enable
【命令】
udp-helper enable
undo udp-helper enable
【視圖】
系統視圖
【預設級別】
2：系統級
【參數】
無
【描述】
udp-helper enable命令用來使能UDP Helper功能，設備會將指定UDP埠的廣播報文轉換為單播報文發送給指定的目的伺服器，起到中繼的作用。undo udp-helper enable命令用來關閉UDP Helper功能。
預設情況下，UDP Helper功能處於關閉狀態。
【舉例】
# 使能UDP Helper功能。
[Sysname] udp-helper enable
1.1.4 udp-helper port
【命令】
udp-helper port{port-number|dns|netbios-ds|netbios-ns|tacacs|tftp|time}
undo udp-helper port{port-number|dns|netbios-ds|netbios-ns|tacacs|tftp|time}
【視圖】
系統視圖
【預設級別】
2：系統級
【參數】
port-number：需要中繼轉發的UDP埠號，取值範圍為1～65535（不支持67和68）。
dns：對DNS的數據報文進行中繼轉發，對應的UDP埠號為53。
netbios-ds：對NetBIOS數據報服務的數據報文進行中繼轉發，對應的UDP埠號為138。
netbios-ns：對NetBIOS名字服務的數據報文進行中繼轉發，對應的UDP埠號為137。
tacacs：對終端訪問控制器訪問控制系統的數據報文進行中繼轉發，對應的UDP埠號為49。
tftp：對簡單文件傳輸協議的數據報文進行中繼轉發，對應的UDP埠號為69。
time：對時間服務的數據報文進行中繼轉發，對應的UDP埠號為37。
【描述】
udp-helper port命令用來配置需要中繼轉發的UDP埠。undo udp-helper port命令用來取消對需要中繼轉發的UDP埠的配置。
預設情況下，沒有配置中繼轉發的UDP埠。
關閉UDP Helper功能后，所有已配置的UDP埠都被取消。
【舉例】
# 配置對目的UDP埠號為100的廣播報文進行中繼轉發。
[Sysname] udp-helper port 100
1.1.5 udp-helper server
【命令】
udp-helper serverip-address
undo udp-helper server[ip-address]
【視圖】
三層乙太網介面視圖/VLAN介面視圖
【預設級別】
2：系統級
【參數】
ip-address：目的伺服器的IP地址，為點分十進位形式。
【描述】
udp-helper server命令用來配置中繼轉發的目的伺服器。undo udp-helper server命令用來刪除中繼轉發的目的伺服器。
預設情況下，沒有配置中繼轉發的目的伺服器。
目前，一個介面上最多可以配置20個中繼轉發的目的伺服器。
需要注意的是，undo udp-helper server命令后不加參數時，將會刪除該介面下配置的所有目的伺服器。
相關配置可參考命令display udp-helper server。
（1） UDP是一個無連接協議，傳輸數據之前源端和終端不建立連接，當它想傳送時就簡單地去抓取來自應用程序的數據，並儘可能快地把它扔到網路上。在發送端，UDP傳送數據的速度僅僅是受應用程序生成數據的速度、計算機的能力和傳輸帶寬的限制；在接收端，UDP把每個消息段放在隊列中，應用程序每次從隊列中讀一個消息段。
（2）由於傳輸數據不建立連接，因此也就不需要維護連接狀態，包括收髮狀態等，因此一台服務機可同時向多個客戶機傳輸相同的消息。
（3） UDP信息包的標題很短，只有8個位元組，相對於TCP的20個位元組信息包的額外開銷很小。
（4）吞吐量不受擁擠控制演演算法的調節，只受應用軟體生成數據的速率、傳輸帶寬、源端和終端主機性能的限制。
（5）UDP使用盡最大努力交付，即不保證可靠交付，因此主機不需要維持複雜的鏈接狀態表（這裡面有許多參數）。
（6）UDP是面向報文的。發送方的UDP對應用程序交下來的報文，在添加首部后就向下交付給IP層。既不拆分，也不合併，而是保留這些報文的邊界，因此，應用程序需要選擇合適的報文大小。
雖然UDP是一個不可靠的協議，但它是分發信息的一個理想協議。例如，在屏幕上報告股票市場、在屏幕上顯示航空信息等等。UDP也用在路由信息協議RIP（Routing Information Protocol）中修改路由表。在這些應用場合下，如果有一個消息丟失，在幾秒之後另一個新的消息就會替換它。UDP廣泛用在多媒體應用中，例如，Progressive Networks公司開發的RealAudio軟體，它是在網際網路上把預先錄製的或者現場音樂實時傳送給客戶機的一種軟體，該軟體使用的RealAudio audio-on-demand protocol協議就是運行在UDP之上的協議，大多數網際網路電話軟體產品也都運行在UDP之上。
UDP和TCP協議的主要區別是兩者在如何實現信息的可靠傳遞方面不同。TCP協議中包含了專門的傳遞保證機制，當數據接收方收到發送方傳來的信息時，會自動向發送方發出確認消息；發送方只有在接收到該確認消息之後才繼續傳送其它信息，否則將一直等待直到收到確認信息為止。與TCP不同，UDP協議並不提供數據傳送的保證機制。如果在從發送方到接收方的傳遞過程中出現數據報的丟失，協議本身並不能做出任何檢測或提示。因此，通常人們把UDP協議稱為不可靠的傳輸協議。
相對於TCP協議，UDP協議的另外一個不同之處在於如何接收突發性的多個數據報。不同於TCP，UDP並不能確保數據的發送和接收順序。例如，一個位於客戶端的應用程序向伺服器發出了以下4個數據報
D1
D22
D333
D4444
但是UDP有可能按照以下順序將所接收的數據提交到服務端的應用：
D333
D1
D4444
D22
事實上，UDP協議的這種亂序性基本上很少出現，通常只會在網路非常擁擠的情況下才有可能發生。
既然UDP是一種不可靠的網路協議，那麼還有什麼使用價值或必要呢？其實不然，在有些情況下UDP協議可能會變得非常有用。因為UDP具有TCP所望塵莫及的速度優勢。雖然TCP協議中植入了各種安全保障功能，但是在實際執行的過程中會佔用大量的系統開銷，無疑使速度受到嚴重的影響。反觀UDP由於排除了信息可靠傳遞機制，將安全和排序等功能移交給上層應用來完成，極大降低了執行時間，使速度得到了保證。
關於UDP協議的最早規範是RFC768，1980年發布。儘管時間已經很長，但是UDP協議仍然繼續在主流應用中發揮著作用。包括視頻電話會議系統在內的許多應用都證明了UDP協議的存在價值。因為相對於可靠性來說，這些應用更加註重實際性能，所以為了獲得更好的使用效果（例如，更高的畫面幀刷新速率）往往可以犧牲一定的可靠性（例如，畫面質量）。這就是UDP和TCP兩種協議的權衡之處。根據不同的環境和特點，兩種傳輸協議都將在今後的網路世界中發揮更加重要的作用。
UDP Server程序
(1)使用socket()來建立一個UDP socket，第二個參數為SOCK_DGRAM。
(2)初始化sockaddr_in結構的變數，並賦值。sockaddr_in結構定義：
struct sockaddr_in {
uint8_t sin_len ;
sa_family_t sin_family;
in_port_t sin_port ;
structin_addrsin_addr;
char sin_zero;
};
這裡使用“8888”作為服務程序的埠，使用“INADDR_ANY”作為綁定的IP地址即任何主機上的地址。
(3)使用bind()把上面的socket和定義的IP地址和埠綁定。這裡檢查bind()是否執行成功，如果有錯誤就退出。這樣可以防止服務程序重複運行的問題。
(4)進入無限循環程序，使用recvfrom()進入等待狀態，直到接收到客戶程序發送的數據，就處理收到的數據，並向客戶程序發送反饋。這裡是直接把收到的數據發回給客戶程序。
1、編譯例子程序
使用如下命令來編譯例子程序：
gcc -Wall -o udpserv udpserv.c
gcc -Wall -o udpclient udpclient.c
編譯完成生成了udpserv和udpclient兩個可執行程序。
2、運行UDP Server程序
執行./udpserv &命令來啟動服務程序。我們可以使用netstat -ln命令來觀察服務程序綁定的IP地址和埠，部分輸出信息如下：
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:32768 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:6000 0.0.0.0:* LISTEN
tcp 0 0127.0.0.1:631 0.0.0.0:* LISTEN
udp 0 0 0.0.0.0:32768 0.0.0.0:*
udp 0 0 0.0.0.0:8888 0.0.0.0:*
udp 0 0 0.0.0.0:111 0.0.0.0:*
udp 0 0 0.0.0.0:882 0.0.0.0:*
可以看到udp處有“0.0.0.0:8888”的內容，說明服務程序已經正常運行，可以接收主機上任何IP地址且埠為8888的數據。
如果這時再執行./udpserv &命令，就會看到如下信息：
bind error: Address already in use
說明已經有一個服務程序在運行了。
執行./udpclient 127.0.0.1命令來啟動客戶程序，使用127.0.0.1來連接服務程序，執行效果如下：
Hello,World!
Hello,World!
this is a test
this is a test
^d
輸入的數據都正確從服務程序返回了，按ctrl+d可以結束輸入，退出程序。
如果服務程序沒有啟動，而執行客戶程序，就會看到如下信息：
$ ./udpclient 127.0.0.1
test
read error: Connection refused
說明指定的IP地址和埠沒有服務程序綁定，客戶程序就退出了。這就是使用connect()的好處，注意，這裡錯誤信息是在向服務程序發送數據后收到的，而不是在調用connect()時。如果使用tcpdump程序來抓包，會發現收到的是ICMP的錯誤信息。
基本信息
- 中文名
- 用戶數據報協議
- 外文名
- User Datagram Protocol
- 別名
- UDP
- 支持語言
- 英文
- 特點
- 快速傳輸但不可靠
- 基礎
- IP數據包服務上增加一點功能
- 類別
- 傳輸層協議
- 用途
- 發送IP數據包