目錄

1、概念

2、報文結構

3、核心特性

3.1 無連接

3.2 不可靠交付

3.3 面向數據報

3.4 輕量級&高效

3.5 支持廣播和組播

4、典型應用場景

5、優缺點分析

6、與TCP的區別

---

1、概念

UDP（User Datagram Protocol，用戶數據報協議）

主要目的：供一種簡單、高效、無連接的數據傳輸服務。

2、報文結構

UDP 頭部：?(8 字節)

• 源端口：?(2 字節) 發送方應用程序的端口號。可選（可置為 0），用于接收方回復時知道發給誰。

• 目的端口：?(2 字節) 接收方應用程序的端口號。必需。

• 長度：?(2 字節) UDP 數據報的總長度（頭部 + 數據），以字節為單位。最小值是 8（只有頭部）。

• 校驗和：?(2 字節) 用于檢測頭部和數據在傳輸過程中是否出錯（可選，但強烈推薦使用）。覆蓋頭部、數據和偽頭部（包含源/目標IP地址、協議號等）。如果接收方計算校驗和不匹配，數據報會被靜默丟棄（不通知發送方）。

數據：?(長度可變) 應用程序要發送的有效載荷。

3、核心特性

3.1 無連接

這是 UDP 最顯著的特點。在發送數據之前，不需要像 TCP 那樣先建立連接（三次握手）。

應用程序只需構造好數據報（Datagram），指定目標 IP 地址和端口號，就可以直接發送出去。

同樣，接收方也不需要事先同意或準備好接收連接。它只是監聽某個端口，等待數據報的到來。（雖然UDP可以有校驗和檢查錯誤，但不保證送達）

3.2 不可靠交付

UDP?不保證數據報一定能到達目的地。

它不提供以下 TCP 具有的可靠性機制：

• 數據包確認：?接收方不會發送 ACK 確認收到數據。

• 超時重傳：?發送方在超時后不會自動重發丟失的數據包。

• 數據包排序：?接收到的數據包順序可能與發送順序不同，UDP 不會重新排序。

• 重復數據檢測：?可能會收到重復的數據包（例如，網絡路徑變化導致），UDP 不會去重。

• 流量控制：?不會根據接收方的處理能力調整發送速率。

• 擁塞控制：?不會主動檢測和避免網絡擁塞。

結果：?數據包可能丟失、重復、亂序到達，或者被網絡設備（如路由器）靜默丟棄（例如在擁塞時）。應用程序需要自己處理這些問題（如果需要）。

3.3 面向數據報

數據是以離散的、獨立的?“數據報”?為單位發送和接收的（完整的）。

• 發送方應用程序的每次寫操作（例如一個?sendto()?調用）通常會產生一個獨立的 UDP 數據報。

• 接收方應用程序的每次讀操作（例如一個?recvfrom()?調用）通常接收一個完整的 UDP 數據報。

關鍵：?UDP?不會像 TCP 那樣將應用層的數據流拆分成多個段（Segments）或重新組裝成流。它保留消息邊界。

3.4 輕量級&高效

• 協議頭非常小（只有 8 字節），開銷遠低于 TCP（通常 20 字節，帶選項更多）。

• 沒有連接建立/拆除的開銷（三次握手、四次揮手）。

• 沒有復雜的確認、重傳、排序、流量控制、擁塞控制邏輯。這使得 UDP 的協議棧處理非常快，消耗的 CPU 和網絡資源更少。

結果：?延遲更低，傳輸速度理論上可以更快（尤其是在低丟包率的網絡上）。

3.5 支持廣播和組播

UDP 可以將數據報發送到：

• 單播：?單個目標主機。

• 廣播：?同一局域網內的所有主機（例如?255.255.255.255?或子網廣播地址）。

• 組播：?加入特定組播組的所有主機。

TCP 是嚴格的一對一連接，只支持單播。

4、典型應用場景

1> 對延遲極其敏感，能容忍少量丟包：

• 實時音視頻傳輸：?VoIP (如 Skype, Zoom 的部分傳輸)、視頻會議、在線直播。偶爾丟幀或短暫聲音中斷比延遲高導致卡頓更可接受。

• 在線游戲：?特別是快節奏的 FPS、MOBA 等。玩家位置、動作指令需要極快送達，丟失個別數據包（如非關鍵位置更新）影響相對較小，而延遲高（Lag）會嚴重影響體驗。

• 實時流媒體：?部分直播協議（如某些 RTP 實現）。

2> 簡單查詢/響應模型，且請求/響應本身很小：

• DNS（域名系統）：?查詢域名對應的 IP 地址。請求和響應通常很小，一次查詢一個響應，重試成本低且快速（客戶端負責超時重試）。

• DHCP（動態主機配置協議）：?獲取 IP 地址、網關等信息。使用廣播/組播，且過程本身包含重試機制。

• SNMP（簡單網絡管理協議）：?網絡設備監控和管理。查詢和陷阱（Trap）消息。

• TFTP（簡單文件傳輸協議）：?輕量級文件傳輸（如路由器固件升級），協議簡單，自帶簡單的確認機制（ACK）。

3> 廣播/組播應用：

• 服務發現：?設備在局域網內廣播宣告自身服務（如 Bonjour/mDNS）。

• 路由協議：?如 RIP。

• 多媒體分發：?組播視頻流。

4> 在可靠傳輸之上構建自定義協議：

• 應用層可以在 UDP 基礎上實現自己需要的、更貼合應用特性的可靠性、順序、擁塞控制邏輯。這提供了極大的靈活性：

  • QUIC：?HTTP/3 的底層傳輸協議，基于 UDP，整合了 TLS 加密，并實現了更快速、更靈活的連接建立、可靠傳輸和擁塞控制。

  • DTN（容斷網）協議：?用于高延遲、易中斷的網絡環境（如太空通信）。

  • 特定游戲網絡協議：?針對游戲狀態同步特性優化的可靠性和順序機制。

5、優缺點分析

優點：

• 低延遲：?無連接建立開銷，無等待確認的延遲。

• 低開銷：?頭部小，協議邏輯簡單，節省帶寬和計算資源。

• 高效率：?在低丟包率網絡中，吞吐量可以非常高。

• 簡單：?協議本身簡單，API 也相對簡單。

• 支持廣播/組播：?實現一對多通信的基礎。

• 無連接狀態：?服務器端無需為每個客戶端維護連接狀態，能支持更多并發“連接”（實際是無連接的會話）。

• 靈活性：?為應用層提供基礎傳輸，允許在其上構建自定義的可靠性等機制。

缺點：

• 不可靠：?數據可能丟失、重復、亂序。應用程序必須自行處理（如果需要可靠性）。

• 無擁塞控制：?發送方可能以過高速度發送數據淹沒網絡，導致擁塞崩潰。應用層需要謹慎設計發送速率。

• 數據報大小限制：?單個 UDP 數據報的有效載荷通常不能超過 64KB（減去 IP 和 UDP 頭部）。更大的數據需要應用層分片和重組（易丟失）。

• 易受 DDoS 攻擊：?偽造源 IP 地址發送大量 UDP 數據報進行反射放大攻擊（如 DNS/NTP反射攻擊）非常容易。

6、與TCP的區別

特性	UDP	TCP
連接	無連接	面向連接?(需三次握手)
可靠性	不可靠?(不保證送達、順序、不重復)	可靠?(保證送達、順序、無重復)
傳輸單位	數據報?(保留消息邊界)	字節流?(無消息邊界)
速度	更快?(低延遲、低開銷)	相對較慢?(連接管理、確認、控制機制)
開銷	低?(頭部小，8字節)	高?(頭部大，通常20字節+)
流量控制	無	有?(滑動窗口)
擁塞控制	無	有?(多種算法)
廣播/組播	支持	不支持?(僅單播)
復雜性	簡單	復雜
典型應用	實時音視頻、游戲、DNS、廣播、QUIC/HTTP3	Web瀏覽(HTTP/HTTPS)、文件傳輸(FTP)、郵件(SMTP/POP/IMAP)、遠程登錄(SSH)