按 RFC 768 的定義，UDP 假設下層使用 IP 協定，提供的是「交易導向」（transaction oriented）的數據報服務：應用程式把一段資料交給 UDP，UDP 加上僅 8 個位元組的標頭便直接交由 IP 發送，過程沒有握手、沒有連線狀態、沒有確認與重傳。標頭只有四個欄位：來源埠、目的埠、長度與校驗和。校驗和用於檢測傳輸錯誤，錯誤的封包會被直接丟棄而不通知發送方。
正因為狀態與機制極少，UDP 的單機並發能力與轉發效率都很高，亦不會像 TCP 般因等待確認而增加延遲。RFC 768 同時說明：需要有序、可靠的資料流傳輸的應用，應使用 TCP。
| 特性 | UDP | TCP |
|---|---|---|
| 連線 | 無連接，直接發送 | 三向握手建立連線 |
| 可靠性 | 不保證送達、不重傳 | 確認與重傳保證送達 |
| 順序 | 不保證到達順序 | 按序交付 |
| 標頭開銷 | 8 位元組 | 最少 20 位元組 |
| 擁塞控制 | 協定本身沒有，由應用負責 | 內建擁塞控制 |
| 適合場景 | 即時視音訊、查詢式短訊息 | 網頁、檔案傳輸、電郵 |
簡單而言：資料「完整」比「即時」重要用 TCP；「即時」比「完整」重要用 UDP。詳細對比見TCP 與 UDP 有什麼分別一頁。
RTP 媒體流傳統上以 UDP 傳送，遲到的畫面直接跳過，維持最低延遲的實時預覽；跨互聯網時亦可改行 TCP 模式換取畫面完整性。
語音對延遲極敏感，RTP 語音封包以 UDP 傳送，配合抖動緩衝與封包遺失隱藏技術維持通話質素。
查詢式短訊息一來一回即完成，用 UDP 省卻建立連線的往返時間，是這類基礎服務的預設傳輸方式。
新一代網頁傳輸協定 QUIC 建基於 UDP，在其上自行實現加密、多路複用與可靠傳輸，兼得低延遲與可靠性。
IETF 在 RFC 8085（UDP Usage Guidelines，最佳現行實務 BCP 145）中為使用 UDP 的應用訂明指引：應用必須自行實現合理的擁塞控制，避免對其他流量造成不公平擠壓；單個數據報大小應顧及路徑 MTU，避免 IP 分片；並應妥善處理封包遺失、重複與亂序。企業網絡部署上，防火牆對 UDP 的狀態追蹤與 NAT 映射壽命一般比 TCP 短，長時間的 UDP 會話（例如 VoIP）需要保活機制；QoS 政策亦應為即時 UDP 流量劃定優先級，同時限制其頻寬上限以保護其他業務。
本文核對資料：RFC 768；RFC 8085（BCP 145）。
不確定如何應用於實際環境？我們的工程師可按現場情況提供建議，免費解答及報價。
WhatsApp 即時查詢若閣下正計劃相關工程或需要選購設備，歡迎瀏覽網絡工程服務了解方案詳情，或透過網上快速報價與我們的工程師聯絡。
產品規格以原廠最新文件為準；有需要請聯絡我們工程師。