UDP 通訊端（UDP socket）
如果 TCP 通訊端是一通電話，UDP 通訊端就是把明信片投進郵筒。你在每張明信片上寫地址然後寄出；它通常會到，但可能遺失、可能順序顛倒，沒有鈴響、沒有交握、也沒有掛斷。UDP 通訊端是一個端點，收發各自獨立、自成一體的封包，叫做資料報（datagram），沒有連線、也沒有傳遞保證。
你把它建成一個資料報通訊端（socket(AF_INET, SOCK_DGRAM, 0)）。因為沒有連線，你不會先 connect 再 send；而是每次呼叫都說明要送去哪：sendto(fd, data, address) 把一個資料報送到那個地址，recvfrom(fd, buffer) 收下一個資料報並告訴你它來自誰。一個關鍵性質：UDP 保留訊息邊界。一次 sendto 恰好變成一次 recvfrom——你送一個 200 位元組的資料報，對方就把它讀成單一個 200 位元組的單位，絕不會只讀到一半、也不會把兩個黏在一起。核心只加上連接埠與檢查碼；它不重送、不重排、也不調節任何速率。
為什麼重要：UDP 並非壞掉或低等——它是給那些寧可要及時性與簡單、而非保證依序傳遞的應用程式的刻意選擇。DNS 查詢、線上遊戲、語音與視訊通話（VoIP），以及像 QUIC 這類較新的傳輸協定，都用 UDP，因為遲到的、重送的舊語音樣本或舊遊戲位置，比直接往前走更糟。代價是：如果你的應用需要可靠性或排序，你得自己在 UDP 之上建立它——QUIC 在使用者空間做的正是這件事。
一個 DNS 用戶端用 sendto() 送一個小小的查詢資料報到 port 53 的解析器，然後在 recvfrom() 裡等一個回應資料報。沒有交握、沒有終止——請求與回答各是單一個封包，這正是 DNS 快速又輕量的原因。
一次 sendto、一次 recvfrom：UDP 完整保留訊息邊界。
UDP 不提供可靠性、排序或壅塞控制。資料報遺失了，就是沒了——沒有東西會重送它。需要這些保證的應用必須自己加上去，或改用 TCP。