4.1 UDP là gì?
UDP (User Datagram Protocol) gửi data từ máy A đến máy B mà không cần connection, không đảm bảo gì. "Fire and forget".
3 tính chất chính:
- Connectionless: không có handshake. Cứ gửi.
- Unreliable: packet có thể mất, lặp, đến lộn xộn — UDP không quan tâm.
- No flow / congestion control: gửi với tốc độ bao nhiêu cũng được.
Nghe tệ, nhưng đó cũng là điểm mạnh: không overhead, latency thấp, đơn giản.
4.2 UDP Header — chỉ 8 byte (so với TCP 20+ byte)
0 7 8 15 16 23 24 31
+--------+--------+--------+--------+
| Source Port | Destination Port| ← 4 byte
+--------+--------+--------+--------+
| Length | Checksum | ← 4 byte
+--------+--------+--------+--------+
| Data (variable) |
+-----------------------------------+
Total header: 8 byte (TCP: 20+)4 trường, không có sequence, không có ACK, không có window — toàn bộ "luggage" mà TCP mang theo, UDP bỏ.
Hệ quả:
- Header overhead nhỏ → nhiều data hơn trong cùng MTU
- CPU xử lý ít hơn
- Không state lưu trong kernel → server có thể handle nhiều flow hơn
4.3 UDP vs TCP — bảng đối chiếu
| Tính chất | TCP | UDP |
|---|---|---|
| Connection | Có (3-way handshake) | Không (connectionless) |
| Reliability | Có (retransmit, ACK) | Không (mất là mất) |
| Ordering | Đảm bảo | Không đảm bảo |
| Flow control | Có (sliding window) | Không |
| Congestion control | Có (slow start, AIMD) | Không |
| Header size | 20-60 byte | 8 byte |
| Setup latency | 1.5 RTT | 0 RTT |
| Throughput | Cao nhưng có overhead | Có thể cao hơn (less overhead) |
| Use case | HTTP, SSH, file, email | DNS, video, game, voice |
| Broadcast/multicast | Không | Có |
Quote nổi tiếng
"TCP gives you reliability you may not need, at a cost you may not want to pay."
Đôi khi chậm 100ms vì TCP retransmit còn tệ hơn mất 1 frame video.
4.4 Use cases — UDP "lên ngôi" ở đâu?
4.4.1 DNS
Mỗi DNS query là 1 request nhỏ (domain name) + 1 response nhỏ (IP). Dùng TCP tốn 1.5 RTT handshake mới gửi được query. UDP: gửi ngay, nhận ngay = 1 RTT total.
Nếu UDP packet mất → client tự retry. Đơn giản hơn nhiều.
(DNS có dùng TCP cho response > 512 byte hoặc DNSSEC — nhưng default là UDP)
4.4.2 Video / Voice (streaming, VoIP)
Video 30fps = 1 frame mỗi 33ms. Nếu mất 1 frame, retransmit qua TCP mất ~100-500ms — lúc đó user đã thấy frame mới hơn rồi. Bỏ qua frame mất, chạy tiếp = trải nghiệm tốt hơn.
Apps: Zoom, Skype, Discord voice, Twitch, YouTube live, RTMP, RTP.
4.4.3 Online Game
Position update mỗi 50ms. Mất 1 update không sao — update sau đè lên. Reliability không quan trọng bằng latency.
Ngược lại, TCP head-of-line blocking (xem 4.5) sẽ "freeze" game khi packet mất.
4.4.4 NTP, DHCP, mDNS
Các giao thức infrastructure short-message. Tránh overhead TCP.
4.4.5 Multicast / Broadcast
TCP yêu cầu connection 1-1 → không broadcast được. UDP có thể gửi 1 packet đến nhiều receiver (vd discovery, IPTV).
4.4.6 IoT / Sensor
Device tài nguyên hạn chế. Connection-state TCP tốn RAM. UDP nhẹ hơn.
4.5 Head-of-Line Blocking — gót chân Asin của TCP
TCP đảm bảo data đúng thứ tự. Nếu segment thứ 5 trong 10 segment bị mất:
- Receiver đã có segment 1-4 và 6-10
- Nhưng không thể đẩy lên app vì chưa có 5 (sẽ mất thứ tự)
- Sender phải retransmit segment 5
- App phải đợi đến khi segment 5 đến → mọi data sau bị "block" theo
Đây là head-of-line blocking (HOL). Tệ hơn: HTTP/2 multiplex nhiều stream trên 1 TCP connection — 1 packet mất block mọi stream.
UDP không có vấn đề này vì không guarantee order — app tự xử lý.
4.6 QUIC — HTTP/3 chạy trên UDP
QUIC (Quick UDP Internet Connections, Google 2012) là protocol "tái implement" reliability + ordering ở user space trên UDP, kèm mã hoá và stream multiplexing.
Tại sao xây trên UDP?
- TCP "đông cứng" trong kernel — khó deploy thuật toán mới
- Phần cứng router xử lý UDP/IP → QUIC chạy được trên Internet hiện tại
- Có thể update QUIC chỉ cần update trình duyệt + server, không cần đụng OS
Lợi ích QUIC
- 0-RTT connection với resumption (vs TCP+TLS = 3 RTT)
- Per-stream HOL blocking: 1 stream mất packet không block stream khác
- Connection migration: đổi mạng (Wi-Fi → 4G) không phải reconnect
- Encryption built-in: TLS 1.3 luôn luôn
Browser/server hiện đại đều support: Chrome, Firefox, Safari, nginx (qua module), Cloudflare. HTTP/3 = HTTP-over-QUIC.
4.7 WebRTC — peer-to-peer trên browser
WebRTC cho phép browser-to-browser không qua server để truyền video/audio/data. Dùng UDP (qua DTLS để mã hoá).
NAT traversal — vấn đề hard
Cả 2 peer đều ở sau NAT → không direct connect được. WebRTC dùng:
- STUN: peer hỏi server "IP public của tôi là gì?", lấy được IP+port public của mình sau NAT
- TURN: nếu STUN không đủ (NAT khó), relay qua server (peer ↔ TURN server ↔ peer)
- ICE: thử mọi candidate path, chọn cái tốt nhất
Use case
Google Meet, Discord voice, ưng dụng video call, P2P file sharing trên browser.
Bài tập
Server: nc -ul 8080 (UDP listen). Client: nc -u localhost 8080. Gõ message — quan sát.
Khác gì so với TCP nc -l + nc localhost?
Wireshark filter udp.port==53. Chạy dig google.com. Quan sát: 1 query packet, 1 response packet, không có handshake.
Mỗi scenario sau dùng TCP hay UDP, tại sao? (a) Bank transfer; (b) Live stream YouTube; (c) Online chess; (d) Video call Zoom; (e) DNS query; (f) git clone; (g) FPS game.
Giải thích head-of-line blocking. Vẽ ví dụ HTTP/2 trên TCP bị HOL.
Browse 1 trang Cloudflare-hosted (vd cloudflare.com). Chrome DevTools → Network → cột Protocol. Có thấy h3?
Mở Wireshark, filter quic. Truy cập google.com. Quan sát các packet UDP đến port 443.
🧪 Quiz cuối chương
Câu 1. UDP header bao nhiêu byte?
Đáp án: 8 byte. 4 field × 2 byte: src port, dst port, length, checksum. TCP 20+ byte.
Câu 2. DNS dùng UDP vì?
Đáp án: short message + low latency. 1 RTT cho cả query+response. Nếu mất packet → client retry, đơn giản hơn handshake.
Câu 3. Tại sao game online thường dùng UDP?
Đáp án: latency > reliability. TCP HOL blocking sẽ "freeze" game khi packet mất.
Câu 4. Head-of-Line blocking trong TCP là?
Đáp án: HOL block do guaranteed ordering. Đặc biệt tệ với HTTP/2 nhiều stream trên 1 TCP.
Câu 5. QUIC build trên UDP để?
Đáp án: deploy + per-stream HOL. TCP "đông" trong kernel; UDP cho phép QUIC update qua browser/server.
Câu 6. HTTP/3 chạy trên?
Đáp án: QUIC. HTTP/1.1, HTTP/2 trên TCP. HTTP/3 trên QUIC (UDP).
Câu 7. WebRTC dùng UDP và NAT traversal qua?
Đáp án: STUN/TURN/ICE. STUN tìm public IP, TURN relay nếu STUN fail, ICE chọn path tốt nhất.
Câu 8. UDP có thể broadcast/multicast, TCP thì không. Tại sao?
Đáp án: TCP yêu cầu connection 1-1. 1-nhiều cần dùng UDP (mDNS, IGMP).
Tổng kết chương 4
- ✅ UDP = connectionless, unreliable, no flow/congestion control — "fire and forget"
- ✅ Header chỉ 8 byte (TCP 20+); 0 RTT setup
- ✅ Use case: DNS, video, game, voice, NTP, DHCP, IoT, multicast
- ✅ Head-of-line blocking: gót chân Asin của TCP — đặc biệt tệ với HTTP/2 multiplex
- ✅ QUIC: reliable + ordered ở user space trên UDP; per-stream HOL; 0-RTT resume; HTTP/3 dùng nó
- ✅ WebRTC: peer-to-peer browser, dùng UDP + STUN/TURN/ICE NAT traversal
- ✅ Quy tắc chọn: cần reliability + ordering → TCP; cần latency thấp + chấp nhận mất → UDP