網際網路筆記:UDP
UDP 和 TCP 一樣是一種傳輸層的通訊協定,由 RFC 768 定義,一般考試大概不會去翻 RFC 的內容。相較於 TCP,UDP 的結構比較簡單,只管送不管到,所以不像 TCP 有什麼三次握手、四次揮手、壅塞控制、流量控制等,多用於需要低延遲、即時性或廣播。
UDP 的託運單 (Header)
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| Source Port (來源 Port) | Destination Port (目的地 Port) | ||||||||||||||||||||||||||||||
| Data 長度 | Checksum | ||||||||||||||||||||||||||||||
Data 長度:UDP 報文總長不可能超過 65535 bytes,Data 的長度最多為 65535 bytes - 8 bytes (UDP Header) - 20 bytes (IP Header) = 65507 bytes
Checksum:如果不使用,該欄位為 0;在 IPv4 可用可不用,在 IPv6 中必需使用
UDP 的特性
只要封包有送出,工作就做完了
所以不會有重傳封包這種事,也不管接收端能否接到每個封包都是獨立的、亦沒有順序
如果有需要封包順序、判斷封包是否丟失、封包是否需要重傳……等功能,還是可以透過應用程式實作出來。
UDP 的應用場景
雖然上面把 UDP 描述得像一個只管做不管質量的工人,但因為 header 小、速度快,若能接受封包少量丟失、或是重傳成本 > 丟失成本時,UDP 還是很實用的。
影音串流
即時通訊 (VoIP, Video Call)
線上遊戲
DNS (Domain Name System)
查詢結果通常只有幾十 bytes,用 TCP 郵票有點大DHCP(Dynamic Host Configuration Protocol)
廣播來自動分配 IP 位址IoT
原以為整理起來會很多,想不到內容這麼少。
留言
張貼留言