UDP 是一種極簡的無連線傳輸層協定，僅在 IP 之上提供連接埠多工與可選的資料同位檢查，不保證送達、不保證順序且無連線狀態開銷。 相較於 TCP 複雜的連線握手、重傳與流量控制，UDP 追求的是極致的低延遲、精簡的通訊標頭與對底層封包傳送節奏的直接控制力。
本文接續TCP 基礎：連線生命週期與流量控制並與封包交換與網路分層模型對照；同時為後續依賴 UDP 的應用如DNS 網域名稱解析系統提供底層通訊原理。
UDP 的設計哲學與標頭結構
UDP（User Datagram Protocol，定義於 RFC 768）的本質是對 IP 層能力的最輕量封裝。 IP 層僅負責將封包從「主機 A」送達「主機 B」；而 UDP 僅額外增加了一項核心能力：連接埠多工（Port Multiplexing），將資料精確遞交給主機上的「特定行程（Process）」。
UDP 的標頭僅有極其精簡的 8 個位元組（Bytes）：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 來源連接埠 (16 bits) | 目的連接埠 (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 長度 (Length, 16 bits)| 校驗和 (Checksum, 16) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| 資料有效負載 (Payload) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- 來源連接埠（Source Port）：發送行程的連接埠（可選，若不需要接收回覆可設為 0）。
- 目的連接埠（Destination Port）：接收行程監聽的連接埠。
- 長度（Length）：UDP 標頭加上資料負載的總長度（最小為 8 位元組）。
- 校驗和（Checksum）：涵蓋虛擬 IP 標頭、UDP 標頭與資料內容的校驗值。在 IPv4 中可選，但在 IPv6 中強制要求，用於偵測資料在傳輸過程中是否受損；若校驗失敗，接收端核心將默默丟棄該資料包。
UDP 與 TCP 的根本特徵對比
| 比較特性 | TCP（傳輸控制協定） | UDP（使用者資料包協定） |
|---|---|---|
| 連線狀態 | 連線導向（需三次交握建立狀態） | 無連線（Connectionless，隨發隨走） |
| 標頭大小 | 至少 20 位元組（可達 60 位元組） | 固定 8 位元組 |
| 可靠性 | 保證送達、逾時重傳、校驗 | 盡力而為（可能丟包、不重傳） |
| 資料順序 | 嚴格循序重組 | 不保證順序（可能後發先至） |
| 資料抽象 | 位元組串流（Byte Stream，無邊界） | 資料包（Datagram，保留明確訊息邊界） |
| 速率調節 | 具備流量控制與壅塞控制（主動降速） | 無速率限制（應用程式想發多快就發多快） |
| 廣播與多播 | 僅支援單播（Unicast，點對點） | 支援單播、廣播（Broadcast）與多播（Multicast） |
| 延遲特性 | 較高（交握延遲 + 隊頭阻塞隊列） | 極低（零交握延遲、即發即收） |
資料包邊界（Datagram Boundaries）的關鍵差異
在 TCP 中，應用程式兩次發送 100 位元組，接收端可能一次收到 200 位元組，或四次收到 50 位元組，應用層必須自行設計封包長度標頭或分隔符號來切分訊息。
而在 UDP 中，發送端每次透過系統呼叫 sendto() 發出一個資料包，接收端呼叫 recvfrom() 就必定精準接收這一個完整的獨立資料包（除非被截斷）；UDP 原生保留了應用程式的訊息邊界。
典型應用場景與權衡考量
UDP 並非「次等協定」，而是面對特定工程需求時的精確技術取捨：
1. 即時多媒體與通訊（VoIP、視訊會議、WebRTC）
在即時語音通話或 Zoom/Google Meet 視訊會議中，即時性（Real-Time）遠比絕對完整性更重要。 若網路發生短暫掉包，TCP 會暫停後續所有音訊播放、等待重傳（隊頭阻塞，Head-of-Line Blocking），使用者會聽到嚴重的卡頓與延遲；而使用 UDP 時，掉失的幾毫秒音訊直接跳過，人耳往往難以察覺，通話得以保持極佳的流暢度與即時性。
2. 即時多人線上遊戲
在第一人稱射擊（FPS）或競速遊戲中，伺服器每秒向玩家推播 60 次當前座標。 如果第 10 幀的座標封包遺失了，客戶端完全不需要等待重傳，因為第 11 幀更新的最新座標已經抵達；等待過期舊座標的重傳只會浪費頻寬並增加輸入延遲。
3. 極度簡單的單次請求／回應服務（DNS、DHCP、NTP、SNMP）
以 DNS 查詢 為例，客戶端只想問一個網域名稱的 IP。 若走 TCP，客戶端需要先發送 SYN、等 SYN-ACK、發送 ACK（耗費整整 1 個 RTT 交握），然後才送出查詢，查完還要四次揮手關閉；而使用 UDP，客戶端只發出一個封包，伺服器回傳一個封包即可結束通訊，極大幅度降低了伺服器維護連線狀態的記憶體開銷與網路往返時間。
現代協定演進：在 UDP 之上重構可靠傳輸（QUIC 與 HTTP/3）
長期以來，網際網路協定面臨嚴重的「協定僵化（Ossification）」：中間的防火牆、路由器與 NAT 設備只認得 TCP 與 UDP，任何想發明新傳輸層協定（如 SCTP）的企圖都會被中間設備丟棄。 同時，TCP 核心邏輯刻在作業系統核心中，更新極為緩慢，且 TCP 的全域連線循序保證造成了難以消除的隊頭阻塞。
為此，現代最頂尖的網路協定工程採取了全新路線——「以 UDP 為傳輸載體，在使用者空間（User Space）應用層實作精密控制」：
- QUIC（RFC 9000） 選擇建立在標準 UDP 之上，從而保證封包能通行全球所有中間網路設備。
- QUIC 在應用層實作了比 TCP 更優秀的特性：
- 零交握延遲（0-RTT 連線恢復）：結合 TLS 1.3，將傳輸層交握與密鑰交換合併為單一步驟。
- 徹底消除隊頭阻塞：在同一條 UDP 通道內並行多個獨立串流，單一串流丟包只會阻斷該串流，其餘串流不受任何影響。
- 連線遷移（Connection Migration）：以 Connection ID 取代傳統 IP:Port 四元組，使用者從 Wi-Fi 切換到 5G 行動網路時，連線不中斷無須重新交握。 這項架構已正式成為 HTTP/3 的基礎核心。
常見誤解與限制
- UDP 不代表發送端不會出錯：若發送端應用程式傳送速度遠超本機網卡的實體發送速率，作業系統核心的發送緩衝區依然會滿載，導致
sendto()拋出ENOBUFS錯誤。 - UDP 容易遭受反射放大與偽造攻擊：由於 UDP 無交握狀態，攻擊者極容易偽造封包的來源 IP。若伺服器（如開放的 DNS 或 NTP 伺服器）接收到小封包後回覆巨量資料，攻擊者便可將來源 IP 偽造為受害者 IP，發動嚴重的「分散式阻斷服務反射放大攻擊（DDoS Amplification）」。
- NAT 逾時更激進：因為 UDP 沒有連線建立與中斷標記，NAT 閘道只能依靠計時器（Timer）維持轉譯對應表；通常 UDP 的閒置逾時僅有 30 秒至 1 分鐘，長連線需要定時發送 Keep-Alive 心跳包以防止 NAT 映射被清除。
相關主題與參考來源
- 封包交換與網路分層模型：理解傳輸層與網路介面層的分工。
- TCP 基礎：連線生命週期與流量控制：對照可靠連線導向傳輸與壅塞控制機制。
- DNS 網域名稱解析系統：觀察 UDP 在全球基礎設施中的具體應用與 512 位元組邊界。
- RFC 768 - User Datagram Protocol：IETF 官方 UDP 協定規範。
- RFC 9000 - QUIC: A UDP-Based Multiplexed and Secure Transport：以 UDP 為基礎的新一代多路複用安全傳輸協定。