UDP（使用者資料報協定）
/ you-dee-pee /
UDP 是網際網路的明信片。你寫一段短訊息，投進信箱，它通常會送達——但沒有追蹤、沒有送達證明，如果兩張明信片次序顛倒，或有一張遺失，也沒有人會重寄。UDP 是一個刻意設計得很薄、毫無花俏的傳輸協定：它幾乎沒在網路層已做的事上多加什麼，除了盡力而為之外不做任何承諾。
機制上，UDP 把你的資料包進一個只有 8 位元組的小標頭，裡頭只有四個欄位：來源埠、目的埠、長度、檢查碼。就這樣。它不建立連線（是無連線的），不替位元組編號，不確認也不重送，更不控制自己的送出速率。檢查碼讓接收端能偵測（但無法修復）損毀，損毀的資料報就直接丟棄。每個 UDP 資料報都是獨立的——要嘛完整到達、要嘛完全沒到，彼此之間沒有次序保證。
為什麼重要：UDP 不是「壞掉的 TCP」——當應用程式偏好即時性與掌控、而非保證且依序的傳遞時，它正是對的工具。DNS 用它，因為一次快速的查詢加回覆，比建立一條完整連線便宜。即時語音與視訊（VoIP、視訊會議）用它，因為遲到的封包反正也沒用——與其讓整個串流停下來等重送，不如直接跳過它。線上遊戲也基於同樣理由用它。想在 UDP 之上要可靠性的應用程式得自己建（QUIC 就是這麼做）。誠實的提醒：UDP 沒有壅塞控制，所以一個行為不良的 UDP 洪泛可能擠掉守規矩的流量——負責任的 UDP 應用程式會自行加上速率控制。
當你在瀏覽器輸入一個網域，你的機器通常會朝 DNS 伺服器的 port 53 射出一個小小的 UDP 資料報，再收回一個。如果遺失了，解析器只要再問一次——遠比 TCP 連線所需的三向交握便宜。
DNS：一個小查詢、一個回覆——不需建立連線。
迷思：「UDP 不可靠所以很爛。」UDP 是一個特性，不是缺陷——它用各種保證換取低延遲與簡單。需要可靠性的應用程式要嘛用 TCP，要嘛在 UDP 之上疊自己的機制。