Network: So sánh, Interview và End-to-End Flow
12. So sánh tổng quan
HTTP Versions
| HTTP/1.1 | HTTP/2 | HTTP/3 | |
|---|---|---|---|
| Năm | 1997 | 2015 | 2022 |
| Transport | TCP | TCP | UDP (QUIC) |
| Format | Text | Binary frames | Binary frames |
| Multiplexing | ❌ (1 req/conn) | ✅ streams | ✅ streams |
| HOL Blocking | Application+TCP | TCP only | ❌ Không còn |
| Header compression | ❌ | HPACK | QPACK |
| Server Push | ❌ | ✅ (deprecated) | ✅ |
| TLS | Optional | Optional (thực tế bắt buộc) | Bắt buộc |
| Handshake | 2-3 RTT | 2-3 RTT | 1 RTT / 0-RTT |
| Connection migration | ❌ | ❌ | ✅ Connection ID |
| Adoption (2024) | ~25% | ~65% | ~30% |
Protocols cho API
| REST | GraphQL | gRPC | WebSocket | |
|---|---|---|---|---|
| Transport | HTTP | HTTP | HTTP/2 | WS (TCP) |
| Format | JSON | JSON | Protobuf | Binary/Text |
| Schema | Optional | Required | Required | Không |
| Streaming | ❌ | Subscriptions | 4 loại | Full duplex |
| Browser | ✅ | ✅ | Cần proxy | ✅ |
| Type safety | Không | Có | Tốt nhất | Không |
| Use case | Public API | Flexible query | Microservices | Real-time |
13. Câu hỏi phỏng vấn Senior hay gặp
Q: HTTP/2 có giải quyết hoàn toàn HOL blocking không?
Không. HTTP/2 giải quyết HOL blocking ở application layer — không còn phải đợi response trước mới gửi request tiếp. Nhưng TCP-level HOL blocking vẫn còn: nếu 1 TCP segment bị mất, tất cả streams phải đợi retransmission. HTTP/3 (QUIC) mới giải quyết triệt để vì mỗi QUIC stream có sequence number riêng, mất packet của stream này không ảnh hưởng stream khác.
Q: Tại sao HTTPS cần 2 RTT (TLS 1.2) nhưng TLS 1.3 chỉ 1 RTT?
TLS 1.2 dùng RSA key exchange: client phải nhận server certificate trước, encrypt pre-master secret gửi lên, server decrypt — đây là 2 round trips. TLS 1.3 bắt buộc dùng ECDH: cả hai bên gửi public key ngay trong ClientHello/ServerHello của lần đi đầu tiên, derive session key mà không cần thêm round trip — chỉ 1 RTT.
Q: WebSocket có dùng được với HTTP/2 không?
Khó. HTTP/2 không có upgrade mechanism như HTTP/1.1. RFC 8441 định nghĩa "WebSocket over HTTP/2" dùng CONNECT method nhưng support còn hạn chế. Trong thực tế, WebSocket thường vẫn chạy trên HTTP/1.1 TCP connection riêng — không được hưởng lợi từ HTTP/2 multiplexing.
Q: Tại sao gRPC không dùng được trực tiếp trên browser?
gRPC yêu cầu kiểm soát HTTP/2 framing ở tầng thấp — đặc biệt là trailers (headers gửi sau body). Nhưng browser không expose HTTP/2 framing API cho JavaScript. Cần grpc-web proxy (Envoy) ở giữa để convert. Giải pháp mới hơn là Connect protocol — compatible với gRPC nhưng fallback được về HTTP/1.1 + JSON.
Q: CDN cache được HTTPS không? TLS không phải mã hóa end-to-end?
CDN terminate TLS tại edge server: decrypt, đọc và cache content, rồi tạo kết nối TLS mới đến origin. Bạn đang tin tưởng CDN provider trong chain. Nếu muốn truly end-to-end encryption: dùng "TLS passthrough" ở Layer 4 LB — nhưng khi đó CDN không đọc được content nên không cache được.
Q: DNS TTL thấp ảnh hưởng gì?
TTL thấp (ví dụ 60s): DNS changes propagate nhanh → tốt cho blue-green deployment, failover nhanh. Nhưng nhiều DNS queries hơn → tăng latency mỗi khi cache hết hạn. TTL cao → nhanh hơn nhưng changes lan chậm. Best practice: hạ TTL xuống thấp trước khi planned changes, giữ TTL cao trong điều kiện bình thường.
Q: Tại sao HTTP/3 dùng UDP thay vì cải tiến TCP?
TCP đã bị "ossified" — ăn sâu vào OS kernel và mọi middlebox (firewall, NAT, router) trên internet. Thay đổi TCP protocol mà không break infrastructure hiện có là bất khả thi. QUIC trên UDP tránh được vấn đề này: chạy ở user space, update được như bất kỳ thư viện nào. QUIC tự implement reliability và congestion control — tốt hơn TCP vì không bị ràng buộc bởi backward compatibility.
Q: Consistent Hashing là gì và dùng ở đâu?
Traditional hashing: server = hash(key) % N. Khi N thay đổi (thêm/bớt server), gần như toàn bộ keys bị remap → cache miss hàng loạt.
Consistent hashing: servers và keys đều được map lên một "ring" (0 đến 2^32). Key được serve bởi server đầu tiên theo chiều kim đồng hồ. Khi thêm/bớt server, chỉ ~1/N keys bị remap. Dùng trong Redis Cluster, Cassandra, DynamoDB, CDN routing.
🗺️ Bức tranh tổng thể: bạn gõ URL và chuyện gì xảy ra
1. DNS Resolution
Browser → OS cache → Recursive resolver → Root → TLD → Authoritative
Kết quả: IP của CDN PoP gần nhất (Anycast routing)
2. TCP + TLS
TCP 3-way handshake (1 RTT)
TLS 1.3 handshake (1 RTT, hoặc 0-RTT nếu resumed session)
ALPN negotiate: "h2" (HTTP/2)
3. HTTP/2 Request
HEADERS frame (HPACK compressed)
Có thể multiplex nhiều resources đồng thời trên 1 connection
4. CDN Edge
Cache HIT → trả về ngay (0 RTT đến origin)
Cache MISS → fetch từ Origin, cache lại
5. Load Balancer (nếu cache miss)
Layer 7 LB đọc Host header, route đến đúng service
Health check đảm bảo chỉ route đến healthy instances
6. Application Server
Xử lý request, query DB, trả về response
7. Response về browser
CDN cache response (nếu cacheable)
HTTP/2 frames về browser → render
Tổng thời gian lý tưởng (user gần CDN PoP):
DNS: ~5ms (cached)
TCP+TLS: ~20ms (1 PoP RTT × 2 handshakes)
HTTP request: ~10ms
→ Tổng: ~35ms đến first byte (TTFB)Covers: OSI/TCP · HTTP/1.1/2/3 · TLS · WebSocket · gRPC · DNS · CDN · Load Balancer