Giao diện
🎯 Mục tiêu
🎯 Sau bài này bạn sẽ nắm được:
- Hiểu deep mechanism của TCP: 3-way handshake, flow control, congestion control
- Hiểu khi nào UDP thắng TCP về mọi mặt
- Biết tại sao QUIC (HTTP/3) chọn UDP làm nền tảng
- Có framework quyết định TCP vs UDP cho từng use case
TCP vs UDP — Chọn đúng giao thức cho hệ thống
Câu chuyện mở đầu
Năm 2018, Google công bố kết quả nghiên cứu nội bộ: head-of-line blocking của TCP đang gây thêm 50–100ms latency trên mạng di động có packet loss cao. Với hàng tỷ request mỗi ngày, 50ms nghe có vẻ nhỏ — nhưng nhân lên quy mô Google, nó trở thành hàng triệu giờ chờ tích luỹ của người dùng. Kết quả? Google phát triển QUIC — một giao thức transport mới, được xây dựng trên UDP, không phải TCP.
Điều đáng suy nghĩ: TCP là giao thức "an toàn", được dạy trong mọi lớp networking. Nhưng khi bạn hiểu sâu trade-off, bạn nhận ra rằng lựa chọn "an toàn" không phải lúc nào cũng là lựa chọn "đúng". Bài học từ Google không phải "TCP tệ" — mà là hiểu cơ chế để chọn đúng công cụ cho đúng bài toán.
Bài này sẽ trang bị cho bạn tư duy đó — không phải để trả lời đúng trong interview, mà để thiết kế hệ thống production chịu được tải thực tế.
🧠 Bức tranh tư duy
TCP giống gửi hàng qua Grab Express, UDP giống phát tờ rơi.
TCP — Grab Express
Xác nhận đơn → shipper lấy hàng → giao tận tay → người nhận ký → xác nhận hoàn thành. Chắc chắn nhận được, nhưng quy trình phức tạp, tốn thời gian. Nếu shipper bị kẹt xe (network congestion), cả đơn hàng phải chờ.
UDP — Phát tờ rơi
In 10,000 tờ rơi → phát khắp phố → ai nhận thì nhận, ai không thì thôi. Nhanh, rẻ, nhưng không biết ai nhận được, không biết tờ nào bị rơi.
⚠️ Giống mọi analogy, đây là điểm khởi đầu. TCP phức tạp hơn Grab Express rất nhiều — nó còn có congestion control (điều khiển tắc nghẽn), flow control (điều khiển luồng), và retransmission strategies (chiến lược gửi lại). Hãy đi sâu hơn.
🔬 Cốt lõi kỹ thuật
TCP Deep Dive
Three-Way Handshake — Bắt tay 3 bước
Trước khi gửi bất kỳ byte dữ liệu nào, TCP yêu cầu client và server phải "bắt tay" để thiết lập connection. Quá trình này tốn 1 RTT (Round Trip Time):
Chi phí thực tế:
- TCP handshake: 1 RTT (~50ms trên mạng di động)
- Thêm TLS 1.2: +2 RTT (ClientHello → ServerHello → Finished)
- Thêm TLS 1.3: +1 RTT (tối ưu hơn)
- Tổng cho HTTPS (TLS 1.2): 3 RTT trước khi gửi byte đầu tiên ≈ 150ms trên 4G
Flow Control — Điều khiển luồng
Flow control đảm bảo sender không gửi nhanh hơn receiver có thể xử lý. Cơ chế chính là Sliding Window Protocol:
- Receiver quảng bá receive window (rwnd) — kích thước buffer còn trống
- Sender chỉ gửi tối đa rwnd bytes chưa được ACK
- Khi receiver xử lý xong data, nó mở rộng window → sender gửi thêm
Sender: [Sent+ACKed][ Sent, chờ ACK ][ Có thể gửi ][ Chưa được gửi ]
|<--- Window --->|
Receiver: [ Đã xử lý ][ Buffer chờ xử lý ][ Buffer trống = rwnd ]Ý nghĩa thực tế: Nếu receiver là mobile device có RAM hạn chế, flow control tự động giảm tốc sender — không cần application logic can thiệp.
Congestion Control — Điều khiển tắc nghẽn
Khác với flow control (bảo vệ receiver), congestion control bảo vệ network. TCP sử dụng bốn giai đoạn:
| Giai đoạn | Hành vi | Mục đích |
|---|---|---|
| Slow Start | cwnd tăng gấp đôi mỗi RTT | Thăm dò bandwidth khả dụng |
| Congestion Avoidance | cwnd tăng tuyến tính (1 MSS/RTT) | Tăng từ từ khi gần ngưỡng |
| Fast Retransmit | Gửi lại ngay khi nhận 3 duplicate ACK | Không chờ timeout (nhanh hơn) |
| Fast Recovery | Giảm cwnd xuống 1/2 (không về 1) | Tránh giảm throughput đột ngột |
Throughput
▲
│ ╱╲
│ ╱ ╲ ╱╲
│ ╱ ╲ ╱ ╲
│ ╱╱╱ ╲ ╱ ╲
│ ╱╱ ╲╱╱ ╲...
│╱╱
└──────────────────────────────► Time
Slow CA Loss Recovery
StartHead-of-Line (HOL) Blocking — Nút thắt chí mạng
Đây là vấn đề lớn nhất của TCP cho modern web:
- TCP đảm bảo in-order delivery — nếu packet #3 mất, packet #4, #5, #6 đã đến receiver nhưng phải chờ #3 được gửi lại
- Với HTTP/2 multiplexing trên 1 TCP connection: tất cả stream đều bị block bởi 1 packet loss
- Trên mạng di động (1-5% packet loss): HOL blocking xảy ra liên tục
TCP Connection States
Hiểu các trạng thái TCP quan trọng khi debug production issues (ví dụ: quá nhiều connection ở TIME_WAIT gây port exhaustion):
UDP — Sự đơn giản có chủ đích
UDP không phải "TCP thiếu tính năng" — nó là thiết kế có chủ đích cho những bài toán mà reliability không phải ưu tiên số 1.
Những gì UDP KHÔNG có (và tại sao đó là ưu điểm)
| TCP có | UDP không có | Tại sao không cần? |
|---|---|---|
| Connection setup | No connection | Giảm latency, phù hợp request-response đơn giản (DNS) |
| In-order delivery | No ordering | Real-time data: frame cũ không có giá trị, chỉ cần frame mới nhất |
| Retransmission | No retry | Video call: gửi lại frame 2s trước vô nghĩa |
| Congestion control | No congestion control | App tự control rate (có thể nguy hiểm nhưng linh hoạt) |
| 20+ bytes header | 8 bytes header | Giảm overhead, quan trọng cho IoT gửi hàng triệu packet nhỏ |
UDP Header — Minimalist by design
0 7 8 15 16 23 24 31
+--------+--------+--------+--------+
| Source Port | Dest Port | ← 4 bytes
+--------+--------+--------+--------+
| Length | Checksum | ← 4 bytes
+--------+--------+--------+--------+
| Data ... | ← Payload
+--------+--------+--------+--------+
Tổng header: 8 bytes
(TCP header: 20-60 bytes)Khi nào UDP tỏa sáng?
- 🎮 Online gaming: Vị trí nhân vật 100ms trước không quan trọng — chỉ cần vị trí MỚI NHẤT
- 📞 VoIP / Video call: Mất 1 frame audio (20ms) → không ai để ý. Delay 200ms → cuộc gọi giật
- 🌐 DNS queries: 1 question, 1 answer — không cần connection overhead
- 📡 IoT telemetry: Sensor gửi nhiệt độ mỗi giây — mất vài packet không sao, overhead thấp quan trọng hơn
- 🔴 Live streaming: Latency thấp > reliability — viewers chấp nhận glitch hơn là delay 5s
📊 Bảng so sánh quyết định
| Tiêu chí | TCP | UDP |
|---|---|---|
| Reliability | Guaranteed delivery | Best-effort |
| Ordering | In-order | No guarantee |
| Connection setup | 1–3 RTT (với TLS) | 0 RTT |
| Head-of-line blocking | Có — ảnh hưởng tất cả stream | Không |
| Congestion control | Built-in (bảo vệ mạng) | Không có (app phải tự xử lý) |
| Overhead per packet | 20–60 bytes header | 8 bytes header |
| Stateful | Có — server giữ connection state | Không — stateless |
| Use cases | Web, email, file transfer, REST API | Streaming, gaming, DNS, VoIP |
| Throughput | Tự điều chỉnh theo network | Có thể saturate network |
| NAT traversal | Khó (connection-oriented) | Dễ hơn (UDP hole punching) |
| Phù hợp khi | Data integrity > latency | Latency > completeness |
🚀 QUIC — Tại sao Google chọn UDP?
Vấn đề với TCP + TLS
Traditional HTTPS (TCP + TLS 1.2):
┌─────────────────────────────────────┐
│ TCP Handshake → 1 RTT │
│ TLS Handshake → 2 RTT │
│ HTTP Request → 1 RTT │
│ ───────────────────────────── │
│ Total trước byte đầu tiên: 4 RTT │
│ Trên 4G (100ms RTT): ~400ms chờ │
└─────────────────────────────────────┘Thêm vào đó: HTTP/2 multiplexing trên 1 TCP connection → 1 packet loss block TẤT CẢ streams.
QUIC giải quyết mọi thứ
| Vấn đề TCP | Giải pháp QUIC |
|---|---|
| 1-3 RTT connection setup | 0-RTT cho reconnection, 1-RTT cho connection mới |
| HOL blocking toàn connection | Independent streams — packet loss stream A không block stream B |
| TLS tách biệt | Encryption built-in — handshake + crypto trong cùng 1 RTT |
| IP:port thay đổi → connection reset | Connection ID — chuyển WiFi ↔ cellular liên tục, không mất connection |
| Ossified protocol (kernel space) | User space — cập nhật nhanh, không cần đợi OS update |
Connection Migration — Chuyển mạng liền mạch
Đây là killer feature cho mobile-first:
TCP: Kết nối = (src_ip, src_port, dst_ip, dst_port)
WiFi → 4G = IP thay đổi = connection CHẾT = phải reconnect
QUIC: Kết nối = Connection ID (64-bit random)
WiFi → 4G = IP thay đổi = Connection ID giữ nguyên = KHÔNG gián đoạnÝ nghĩa cho System Design: Khi thiết kế cho mobile users (>60% traffic toàn cầu), QUIC giúp giảm reconnection overhead, đặc biệt khi người dùng di chuyển liên tục (xe buýt, tàu điện ngầm).
⚠️ Trade-off Question
Khi interviewer hỏi: "Bạn sẽ chọn TCP hay UDP cho hệ thống video call?"
Câu trả lời đúng KHÔNG phải là "UDP vì nhanh hơn".
Câu trả lời thể hiện tư duy architect:
"Hệ thống video call có nhiều loại traffic khác nhau, mỗi loại cần protocol khác nhau:
Media streams (audio/video): UDP — vì real-time communication chấp nhận mất vài frame (người dùng không nhận ra mất 20ms audio), nhưng KHÔNG chấp nhận delay 200ms. Thường dùng RTP over UDP hoặc WebRTC (bản chất là UDP).
Signaling/Control plane (join room, mute, screen share request): TCP — vì những action này CẦN reliable delivery. Bạn không muốn lệnh "mute" bị mất.
Chat messages trong call: TCP hoặc WebSocket (TCP-based) — vì tin nhắn cần guaranteed delivery và ordering.
Nếu latency là ưu tiên tối thượng: Xem xét QUIC cho cả media và signaling — 0-RTT reconnection khi user chuyển WiFi/cellular."
💡 Takeaway: System design giỏi = decompose vấn đề thành sub-problems → chọn protocol phù hợp cho TỪNG sub-problem.
📺 Caselet: Netflix truyền 15% traffic toàn cầu — TCP hay UDP?
Bạn có thể nghĩ rằng video streaming = UDP, đúng không? Netflix thực tế dùng TCP.
Netflix sử dụng adaptive bitrate streaming qua HTTP (DASH protocol) — chạy trên TCP. Lý do:
- Buffered content (VOD): Netflix pre-buffer 30-60 giây video. Khi packet loss xảy ra, TCP retransmit chỉ gây delay nhỏ trong buffer — người xem KHÔNG nhận ra. Tốt hơn nhiều so với visual artifacts khi mất packet trên UDP.
- Adaptive bitrate: TCP congestion control tự nhiên phản ánh network condition. Khi mạng chậm, throughput giảm → Netflix player tự switch xuống resolution thấp hơn. Hai cơ chế bổ trợ nhau hoàn hảo.
- CDN compatibility: Toàn bộ CDN infrastructure (Akamai, CloudFront, Netflix Open Connect) được tối ưu cho TCP/HTTP. Dùng UDP nghĩa là phải xây lại toàn bộ.
Nhưng khi chuyển sang live streaming (Twitch, YouTube Live), bài toán thay đổi hoàn toàn:
- Latency budget cực kỳ tight: Viewers muốn xem "gần real-time" (2-5s delay max). TCP retransmit + buffer gây thêm seconds of delay.
- Twitch và YouTube Live sử dụng hỗn hợp: WebRTC (UDP-based) cho ultra-low-latency mode, HLS/DASH (TCP-based) cho standard latency.
- Các protocol chuyên biệt như SRT (Secure Reliable Transport) chạy trên UDP — tự implement selective retransmission thay vì dùng TCP's all-or-nothing approach.
🎯 Bài học: Protocol đúng phụ thuộc vào specific use case TRONG CÙNG MỘT DOMAIN. VOD streaming ≠ Live streaming, dù cùng gọi là "video streaming".
❌ Sai lầm điển hình
1. "TCP luôn tốt hơn vì reliable"
TCP's reliability có giá: latency. Trên mạng có 2% packet loss (phổ biến trên mobile), TCP retransmission + HOL blocking có thể thêm 200-500ms delay. Cho real-time applications, đó là unacceptable.
2. "UDP chỉ dùng cho video/game"
DNS — hệ thống nền tảng của internet — chạy trên UDP. QUIC (HTTP/3) — tương lai của web — chạy trên UDP. IoT devices gửi hàng tỷ telemetry packets mỗi ngày qua UDP. NTP (đồng bộ thời gian) dùng UDP. DHCP (cấp phát IP) dùng UDP.
3. Không hiểu Head-of-Line blocking
Nhiều engineer chọn HTTP/2 (trên TCP) mà không nhận ra: với packet loss > 2%, HTTP/2 có thể CHẬM HƠN HTTP/1.1 (vì HTTP/1.1 mở nhiều TCP connection → HOL blocking chỉ ảnh hưởng 1 connection, HTTP/2 dồn vào 1 connection → block tất cả).
4. Quên tính TLS handshake vào latency budget
Khi estimate latency cho API call, nhiều người chỉ tính network RTT + server processing. Nhưng connection đầu tiên phải trả thêm 2-3 RTT cho TCP + TLS handshake. Trên mạng có RTT 100ms, đó là 200-300ms "ẩn" — đủ để user nhận thấy.
Giải pháp: Connection pooling, HTTP keep-alive, hoặc chuyển sang QUIC (0-RTT reconnection).
✅ Checklist triển khai
Checklist ghi nhớ
Nền tảng TCP
- [ ] Giải thích được 3-way handshake: SYN → SYN-ACK → ACK và tại sao cần 3 bước (không phải 2)
- [ ] Hiểu flow control (receiver window) khác congestion control (sender cwnd)
- [ ] Biết 4 giai đoạn congestion control: slow start → congestion avoidance → fast retransmit → fast recovery
- [ ] Nhận diện được HEAD-of-line blocking và impact lên HTTP/2 multiplexing
- [ ] Hiểu TCP connection states, đặc biệt TIME_WAIT và nguyên nhân port exhaustion
Nền tảng UDP
- [ ] Liệt kê được ít nhất 5 protocol/use case dùng UDP: DNS, QUIC, WebRTC, NTP, DHCP
- [ ] Hiểu tại sao UDP header chỉ 8 bytes (vs TCP 20+ bytes) và ý nghĩa overhead
- [ ] Biết rủi ro khi UDP không có congestion control — có thể flood network
Quyết định thiết kế
- [ ] Có framework chọn TCP vs UDP: reliability cần thiết? latency budget? packet loss tolerance?
- [ ] Biết decompose hệ thống thành sub-problems với protocol khác nhau (VD: video call)
- [ ] Hiểu tại sao QUIC chọn UDP và 3 lợi ích chính: 0-RTT, no HOL blocking, connection migration
- [ ] Nhận ra VOD streaming (TCP) khác live streaming (UDP-based) dù cùng domain "video"
Production awareness
- [ ] Biết cách tính latency budget đầy đủ: network RTT + TCP handshake + TLS handshake + processing
- [ ] Hiểu connection pooling và HTTP keep-alive giảm handshake overhead
- [ ] Biết HTTP/3 (QUIC) đang được adopt bởi Cloudflare, Google, Meta — đây là hướng đi tương lai
🧠 Quiz
Câu 1: Tổng latency tối thiểu cho HTTPS request đầu tiên (TCP + TLS 1.2) trên mạng có RTT 80ms là bao nhiêu?
- [ ] 80ms (1 RTT)
- [ ] 160ms (2 RTT)
- [x] 240ms (3 RTT: 1 TCP handshake + 2 TLS handshake)
- [ ] 320ms (4 RTT)
Giải thích: TCP handshake tốn 1 RTT (SYN → SYN-ACK → ACK). TLS 1.2 thêm 2 RTT (ClientHello/ServerHello + key exchange). Tổng = 3 × 80ms = 240ms trước khi gửi byte dữ liệu đầu tiên. Với TLS 1.3, giảm xuống còn 2 RTT (160ms). Với QUIC, chỉ 1 RTT (80ms) cho connection mới, 0 RTT cho reconnection.
Câu 2: HTTP/2 multiplexing trên 1 TCP connection có thể CHẬM HƠN HTTP/1.1 (6 parallel connections) trong điều kiện nào?
- [ ] Khi server xử lý chậm
- [x] Khi packet loss rate cao (>2%), vì HOL blocking ảnh hưởng tất cả streams trên 1 TCP connection
- [ ] Khi payload quá lớn
- [ ] Khi không có CDN
Giải thích: HTTP/1.1 mở 6 TCP connections song song — packet loss trên 1 connection chỉ block 1/6 traffic. HTTP/2 dồn tất cả vào 1 TCP connection — 1 packet loss block TẤT CẢ streams do TCP in-order delivery. Trên mạng mobile có loss rate 2-5%, điều này tạo latency spike nghiêm trọng. Đây chính là lý do QUIC (HTTP/3) ra đời.
Câu 3: Netflix dùng TCP cho video streaming VOD. Lý do chính là gì?
- [ ] TCP nhanh hơn UDP
- [ ] Luật pháp yêu cầu dùng TCP
- [x] VOD có buffer 30-60s, TCP retransmit không gây delay visible cho user, và adaptive bitrate tương thích tốt với TCP congestion control
- [ ] UDP không hỗ trợ video
Giải thích: Netflix pre-buffer video, nên TCP retransmission xảy ra "trong buffer" — người xem không bao giờ thấy. Đồng thời, TCP congestion control + adaptive bitrate streaming tạo feedback loop tự nhiên: mạng chậm → TCP throughput giảm → player switch resolution thấp hơn → trải nghiệm mượt.
Câu 4: QUIC sử dụng Connection ID thay vì 4-tuple (src_ip, src_port, dst_ip, dst_port). Lợi ích thực tế lớn nhất là gì?
- [ ] Bảo mật tốt hơn
- [ ] Throughput cao hơn
- [x] Connection migration — user chuyển WiFi sang 4G mà không mất connection, không cần reconnect
- [ ] Giảm server memory
Giải thích: TCP connection được xác định bởi (src_ip, src_port, dst_ip, dst_port). Khi user chuyển từ WiFi sang 4G, IP thay đổi → TCP connection chết → phải handshake lại (thêm 2-3 RTT). QUIC dùng Connection ID (64-bit) gắn vào mỗi packet — IP thay đổi nhưng Connection ID giữ nguyên → không gián đoạn. Critical cho mobile users di chuyển liên tục.
🏗️ Kéo thả: Gán đúng protocol cho đúng use case
Hãy thử gán protocol phù hợp cho mỗi use case dưới đây:
Use cases:
| # | Use Case | Protocol? |
|---|---|---|
| 1 | REST API cho web app | ___________ |
| 2 | Video call (media stream) | ___________ |
| 3 | DNS lookup | ___________ |
| 4 | File transfer (FTP/SFTP) | ___________ |
| 5 | Online multiplayer game (state sync) | ___________ |
| 6 | IoT sensor gửi nhiệt độ mỗi giây | ___________ |
| 7 | Chat message delivery | ___________ |
| 8 | Live streaming (ultra-low latency) | ___________ |
Protocol choices: TCP, UDP, QUIC, WebRTC, gRPC over HTTP/2
🔑 Đáp án và giải thích
| # | Use Case | Protocol | Giải thích |
|---|---|---|---|
| 1 | REST API cho web app | TCP (hoặc QUIC/HTTP/3) | API cần reliable delivery — mất request/response không chấp nhận được. HTTP chạy trên TCP. Tương lai: HTTP/3 trên QUIC cho latency tốt hơn. |
| 2 | Video call (media stream) | WebRTC (UDP-based) | Real-time media cần low latency hơn reliability. WebRTC handle codec, encryption, NAT traversal, và sử dụng UDP bên dưới. |
| 3 | DNS lookup | UDP | Request nhỏ (1 question), response nhỏ (1 answer). Connection setup overhead của TCP lớn hơn cả payload. DNS dùng TCP chỉ khi response > 512 bytes (zone transfer). |
| 4 | File transfer (FTP/SFTP) | TCP | File transfer cần 100% data integrity — mất 1 byte = file corrupt. TCP guaranteed delivery là bắt buộc. |
| 5 | Online multiplayer game | UDP (custom protocol) | Game state cần low latency. Mất 1 update không sao — frame tiếp theo sẽ có state mới. Nhưng nhiều game dùng TCP cho chat/inventory (cần reliability). |
| 6 | IoT sensor | UDP | Millions of tiny packets, mất vài readings không ảnh hưởng. Overhead 8 bytes vs 20+ bytes TCP rất quan trọng khi gửi hàng triệu packet. |
| 7 | Chat message delivery | TCP (hoặc WebSocket) | Tin nhắn cần guaranteed delivery + ordering. "Xin chào" phải đến trước "Bạn khỏe không?". WebSocket (TCP-based) cho real-time push. |
| 8 | Live streaming (ultra-low latency) | WebRTC hoặc SRT (UDP-based) | Ultra-low latency (<1s) yêu cầu UDP-based. SRT thêm selective retransmission trên UDP. Standard latency live streaming có thể dùng HLS/DASH (TCP). |