Giao diện
🎯 Mục tiêu
🎯 Sau bài này bạn sẽ nắm được:
- Hiểu limitations của HTTP/1.1 và vì sao cần HTTP/2
- Hiểu multiplexing, HPACK, server push trong HTTP/2
- Hiểu vì sao HTTP/3 chuyển sang QUIC (UDP) và ý nghĩa cho system design
- Có framework chọn HTTP version cho từng kiến trúc
HTTP/1.1 → HTTP/2 → HTTP/3 (QUIC) — Cuộc cách mạng giao thức web
Năm 2015, khi HTTP/2 chính thức ra mắt, Google công bố page load time trên Google.com cải thiện 15–20% — chỉ bằng cách bật HTTP/2 mà không sửa một dòng code ứng dụng nào. Đến năm 2022, HTTP/3 đã chiếm hơn 25% toàn bộ web traffic toàn cầu, dẫn đầu bởi Google (YouTube, Search) và Meta (Facebook, Instagram). Con số đó vào cuối 2024 đã vượt 30%.
Mỗi phiên bản HTTP ra đời để giải quyết pain points cụ thể của phiên bản trước đó. HTTP/1.1 giải quyết vấn đề mở connection liên tục của HTTP/1.0. HTTP/2 giải quyết head-of-line blocking ở tầng HTTP. HTTP/3 giải quyết head-of-line blocking ở tầng TCP mà HTTP/2 không thể chạm tới. Hiểu chuỗi tiến hoá này dạy bạn cách tư duy về protocol trade-offs trong system design — không có silver bullet, chỉ có trade-offs phù hợp với ngữ cảnh.
Trong bài này, chúng ta sẽ đi từ gốc rễ vấn đề đến kiến trúc hiện đại, với framework ra quyết định để bạn chọn đúng HTTP version cho từng hệ thống cụ thể.
Bức tranh tư duy
Hãy tưởng tượng HTTP versions giống cách vận chuyển hàng hoá ở Việt Nam qua các thời kỳ:
HTTP/1.0 — Thuê xe ôm từng chuyến: Mỗi kiện hàng một chuyến đi riêng biệt. Gửi xong kiện A, xe ôm về garage, bạn lại gọi xe mới cho kiện B. Chi phí mở connection (thuê xe) cho mỗi request cực kỳ lãng phí.
HTTP/1.1 — Thuê xe ôm cả ngày (keep-alive): Anh xe ôm ở lại chờ bạn, không cần gọi xe mới. Nhưng vẫn chở từng kiện một — kiện B phải chờ kiện A giao xong mới được lên xe. Đây chính là head-of-line (HOL) blocking: hàng xếp hàng chờ, kiện nào chậm thì tất cả phía sau đều chậm.
HTTP/2 — Chuyển sang xe tải có nhiều ngăn (multiplexing): Một chuyến xe chở nhiều kiện cùng lúc trong các ngăn riêng biệt, bao bì được nén gọn (HPACK). Hiệu quả hơn rất nhiều — nhưng nếu xe bị thủng lốp (TCP packet loss), thì TẤT CẢ hàng trên xe đều phải dừng chờ sửa. Đây là TCP-level HOL blocking mà HTTP/2 không thể giải quyết.
HTTP/3 (QUIC) — Đội xe máy độc lập (independent UDP streams): Mỗi kiện đi một xe riêng. Xe A bị hỏng giữa đường? Xe B, C, D vẫn chạy bình thường, không bị ảnh hưởng. Thêm vào đó, 0-RTT nghĩa là xe luôn sẵn sàng — không cần thời gian khởi động engine.
Analogy này đơn giản hoá ở một điểm: trong thực tế, QUIC không phải "nhiều connection riêng biệt" mà là nhiều stream độc lập trong cùng một connection — giống đội xe máy chạy cùng tuyến nhưng không phụ thuộc nhau. Connection QUIC vẫn chỉ có một lần handshake, sau đó tất cả streams chạy song song.
Cốt lõi kỹ thuật
HTTP/1.1 — Nền tảng nhưng đầy hạn chế
HTTP/1.1 (RFC 2616, 1997) là bước tiến lớn so với HTTP/1.0 nhờ hai cải tiến chính: persistent connections (keep-alive) và pipelining. Nhưng cả hai đều mang theo những hạn chế sâu sắc.
Keep-alive connections: HTTP/1.0 mở một TCP connection cho mỗi request, rồi đóng ngay sau response. Với HTTP/1.1, connection được giữ mở (keep-alive) để tái sử dụng cho nhiều request tiếp theo — tiết kiệm chi phí TCP handshake (1 RTT) và TLS handshake (1–2 RTT).
Pipelining — ý tưởng hay, thực tế thất bại: Client có thể gửi nhiều requests liên tiếp trên cùng connection mà không cần chờ response. Nhưng responses PHẢI trả về đúng thứ tự — nếu request 1 chậm 5 giây, request 2 và 3 (dù server đã xử lý xong) phải chờ đợi. Đây là HTTP-level head-of-line blocking.
Connection limit và workarounds: Vì HOL blocking, browsers mở 6–8 TCP connections song song cho mỗi domain (Chrome: 6, Firefox: 6). Đây là lý do developers thời HTTP/1.1 sáng tạo ra hàng loạt workarounds mà ngày nay đã trở thành anti-patterns:
| Workaround | Cách hoạt động | Tại sao không cần nữa (HTTP/2+) |
|---|---|---|
| Domain sharding | Chia assets ra nhiều subdomain (img1.cdn.com, img2.cdn.com) để tăng connection limit | HTTP/2 multiplexing loại bỏ giới hạn concurrent requests |
| Sprite sheets | Gộp hàng chục icon vào 1 hình lớn | Mỗi icon là 1 stream riêng, nhẹ hơn khi cache |
| CSS/JS concatenation | Gộp tất cả CSS/JS thành 1 file | Gộp file lớn → cache invalidation kém, HTTP/2 stream cho phép tách file |
| Inlining | Embed CSS/JS/images trực tiếp vào HTML | Mất khả năng cache riêng, tăng kích thước HTML |
HTTP/2 — Multiplexing và binary framing
HTTP/2 (RFC 7540, 2015), dựa trên SPDY của Google, giải quyết triệt để HTTP-level HOL blocking bằng thiết kế hoàn toàn mới.
Binary framing layer: HTTP/1.1 là text-based protocol — mỗi request/response là chuỗi ký tự ASCII. HTTP/2 thêm một binary framing layer giữa socket và HTTP semantics. Mỗi HTTP message được chia thành các frames nhỏ, mỗi frame gắn với một stream ID.
HTTP/1.1 message (text):
GET /index.html HTTP/1.1
Host: example.com
Accept: text/html
HTTP/2 frame (binary):
┌─────────────┬──────────┬───────────┐
│ Length (24b) │ Type (8b)│ Flags (8b)│
├─────────────┼──────────┴───────────┤
│ Stream ID (31 bits) │
├─────────────────────────────────────┤
│ Frame Payload (variable) │
└─────────────────────────────────────┘Multiplexing: Nhiều streams chạy song song trên 1 TCP connection. Frames của các stream khác nhau được xen kẽ (interleaved) trên wire — server gửi frame của stream 1, rồi frame của stream 3, rồi lại stream 1 — không cần chờ nhau.
Header compression (HPACK): HTTP headers lặp lại rất nhiều giữa các requests (Cookie, User-Agent, Accept, Authorization). HPACK sử dụng:
- Static table: 61 header name-value pairs phổ biến nhất (
:method: GET,:status: 200) - Dynamic table: Headers đã gặp trong session — lần đầu gửi full, các lần sau chỉ gửi index number
- Huffman encoding: Nén giá trị header
Kết quả: Một cookie header 500 bytes gửi lần đầu, các request sau chỉ tốn 1–2 bytes (index reference). Theo nghiên cứu của Google, HPACK giảm trung bình 30% kích thước header.
Stream prioritization: Client gửi hints cho server biết stream nào quan trọng hơn. Ví dụ: CSS quan trọng hơn images → server ưu tiên gửi CSS frames trước. Tuy nhiên, implementation khác nhau giữa các server và không phải lúc nào cũng được respect.
Server push: Server có thể gửi resource trước khi client request. Client request index.html → server push luôn style.css và app.js vì biết client sẽ cần. Tuy nhiên, server push hiếm khi được dùng trong thực tế vì:
- Server không biết client đã cache resource chưa → push lãng phí bandwidth
- Khó configure đúng — push sai resource còn tệ hơn không push
- Browsers hỗ trợ không đồng đều
- Chrome đã loại bỏ hỗ trợ server push từ 2022
Hạn chế lớn nhất — TCP HOL blocking: HTTP/2 giải quyết HOL blocking ở tầng HTTP, nhưng tất cả streams chạy trên 1 TCP connection. Khi một TCP packet bị mất, TCP yêu cầu retransmit và block toàn bộ connection cho đến khi packet đó được nhận lại. Một packet loss ảnh hưởng tất cả streams, kể cả stream không liên quan đến packet bị mất.
Trên mạng tốt (datacenter, fiber), điều này hiếm khi là vấn đề. Trên mạng lossy (4G, WiFi công cộng, khu vực có coverage kém), HTTP/2 có thể chậm hơn HTTP/1.1 vì HTTP/1.1 dùng 6 connections riêng biệt — packet loss trên connection 1 không ảnh hưởng connection 2.
HTTP/3 và QUIC — Cuộc cách mạng từ Google
HTTP/3 (RFC 9114, 2022) xây dựng trên QUIC (RFC 9000) — protocol do Google phát triển từ 2012, chạy trên UDP thay vì TCP. QUIC không phải "UDP thô" — nó implement tất cả tính năng reliability của TCP (ordering, retransmission, congestion control) nhưng ở tầng application thay vì kernel.
Tại sao không sửa TCP? TCP là protocol nằm trong kernel hệ điều hành và firmware của middleboxes (firewall, NAT, load balancer). Thay đổi TCP behavior đòi hỏi cập nhật hàng tỷ thiết bị — thực tế là bất khả thi. Google chọn cách build protocol mới trên UDP vì UDP đi qua được hầu hết middleboxes.
Giải quyết triệt để HOL blocking: QUIC cung cấp independent streams — packet loss trên stream A chỉ ảnh hưởng stream A. Streams B, C, D tiếp tục nhận data bình thường. Đây là lý do cốt lõi HTTP/3 ra đời.
0-RTT connection establishment: TCP + TLS 1.3 cần 2–3 RTT trước khi gửi data. QUIC tích hợp TLS 1.3 vào protocol, chỉ cần 1 RTT cho lần kết nối đầu tiên. Cho lần kết nối tiếp theo (resumption), QUIC hỗ trợ 0-RTT — client gửi data ngay trong gói tin đầu tiên bằng cách reuse encryption keys từ session trước.
TCP + TLS 1.3:
Client ──SYN──────────────────> Server (1 RTT)
Client <──SYN-ACK───────────── Server
Client ──ACK + ClientHello────> Server (2 RTT)
Client <──ServerHello + Cert── Server
Client ──Finished + DATA──────> Server (3 RTT before data)
QUIC (first connection):
Client ──Initial + ClientHello──> Server (1 RTT)
Client <──Initial + ServerHello── Server
Client ──DATA─────────────────> Server (1 RTT before data)
QUIC (resumption — 0-RTT):
Client ──Initial + 0-RTT DATA──> Server (0 RTT before data! 🚀)Connection ID — connection survives network changes: TCP connection được xác định bởi tuple (src_IP, src_port, dst_IP, dst_port). Khi bạn chuyển từ WiFi sang 4G, IP thay đổi → TCP connection bị kill → phải reconnect + re-handshake. QUIC sử dụng Connection ID thay vì IP:port → connection vẫn sống khi đổi mạng. Đây là killer feature cho mobile.
Built-in TLS 1.3: Encryption là bắt buộc trong QUIC, không phải optional. TLS handshake được tích hợp vào QUIC handshake — tiết kiệm round trips và đảm bảo mọi QUIC traffic đều encrypted. Không có "QUIC without encryption" — loại bỏ hoàn toàn khả năng eavesdropping.
Congestion control ở userspace: TCP congestion control nằm trong kernel, rất khó cập nhật. QUIC implement congestion control ở application layer (userspace), cho phép triển khai thuật toán mới (như BBR, CUBIC variants) bằng cách update application — không cần patch kernel.
Bảng so sánh toàn diện
| Feature | HTTP/1.1 | HTTP/2 | HTTP/3 (QUIC) |
|---|---|---|---|
| Transport | TCP | TCP | UDP (QUIC) |
| Multiplexing | ❌ (workaround: multi-connection) | ✅ Single TCP connection | ✅ Independent UDP streams |
| HOL blocking | ❌ HTTP-level + TCP-level | ❌ TCP-level still exists | ✅ No HOL blocking |
| Connection setup | 2–3 RTT (TCP + TLS) | 2–3 RTT (same TCP) | 0–1 RTT (0-RTT resumption) |
| Header compression | ❌ None | ✅ HPACK | ✅ QPACK |
| Server push | ❌ | ✅ (rarely used) | ✅ (rarely used) |
| Connection migration | ❌ | ❌ | ✅ (connection ID) |
| Encryption | Optional (HTTPS) | Optional (practically required) | Mandatory (TLS 1.3 built-in) |
| Adoption (2024) | ~30% | ~40% | ~30% |
| Best for | Legacy systems, simple APIs | Most web applications | Mobile apps, lossy networks, global users |
Khi nào dùng version nào?
Không có "HTTP/3 luôn tốt hơn". Mỗi version có ngữ cảnh tối ưu riêng:
HTTP/1.1: Legacy systems không thể upgrade, internal APIs giữa services trong cùng datacenter với traffic thấp, hoặc khi cần tối đa simplicity cho debugging. Vẫn hoàn toàn phù hợp cho simple REST APIs với vài requests/second.
HTTP/2: Default choice cho hầu hết web applications. APIs với nhiều concurrent requests, single-page applications tải nhiều assets, gRPC (sử dụng HTTP/2 native). Nếu infrastructure đã hỗ trợ, không có lý do KHÔNG dùng HTTP/2.
HTTP/3: Mobile-first applications, users trên mạng không ổn định (4G, WiFi switching), global users với latency cao, real-time applications cần low latency (gaming, video streaming). Đặc biệt hữu ích khi connection migration là yêu cầu (taxi apps, delivery apps).
WARNING
⚖️ Trade-off: Tại sao chưa phải ai cũng chuyển sang HTTP/3?
Nếu HTTP/3 tốt hơn, tại sao cả thế giới không chuyển ngay? Vì có nhiều rào cản thực tế:
1. UDP bị block bởi corporate firewalls và middleboxes: Nhiều mạng doanh nghiệp, trường học, chính phủ block UDP traffic ngoại trừ DNS (port 53). QUIC chạy trên UDP port 443 — và nhiều firewall chưa cập nhật rule để cho phép. Kết quả: browser phải fallback về HTTP/2 over TCP, thêm latency do thử QUIC trước.
2. QUIC implementations chưa chín muồi: TCP đã được tối ưu trong kernel suốt 40 năm — hardware offload (NIC, FPGA), zero-copy, splice. QUIC chạy ở userspace, chưa có tối ưu kernel tương đương. Với workloads CPU-bound ở network layer, QUIC có thể tốn nhiều CPU hơn TCP.
3. Debugging và monitoring tools chưa phát triển: Wireshark chỉ mới hỗ trợ decode QUIC gần đây. Vì QUIC payload luôn encrypted, middleboxes (IDS, DPI) không thể inspect traffic — tốt cho privacy nhưng khó cho security monitoring.
4. Improvement chỉ rõ rệt trên lossy networks: Trên mạng datacenter ổn định (packet loss < 0.01%), sự khác biệt giữa HTTP/2 và HTTP/3 gần như không đo được. Lợi ích chính của HTTP/3 thể hiện rõ nhất trên mobile networks với packet loss 1–5%.
5. Service-to-service communication: Cho internal traffic giữa microservices trong cùng datacenter, HTTP/2 over TCP thường là lựa chọn tối ưu — latency thấp, ổn định, tools mature, không cần connection migration.
Kết luận: HTTP/3 là tương lai cho user-facing traffic, đặc biệt mobile. Nhưng cho internal service mesh, HTTP/2 over TCP vẫn là king.
📝 Caselet: Google Docs — Real-time collaboration qua HTTP
Google Docs là bài toán kinh điển về real-time collaboration: hàng triệu users cùng edit một document, mỗi keystroke phải xuất hiện trên màn hình collaborators trong vài trăm milliseconds.
Initial page load — HTTP/2 shines: Khi bạn mở một Google Doc, browser cần tải hàng chục resources: HTML skeleton, CSS framework, JavaScript bundles, fonts, toolbar icons, user avatars. HTTP/2 multiplexing cho phép tất cả resources tải song song trên 1 TCP connection — thay vì 6 connections song song của HTTP/1.1. Header compression (HPACK) đặc biệt hiệu quả ở đây vì Google Docs gửi rất nhiều repeated headers (auth tokens, cookies lớn).
Real-time sync — không phải HTTP request-response: Sau khi page load xong, Google Docs chuyển sang WebSocket hoặc Server-Sent Events (SSE) cho real-time synchronization. Đây là điểm quan trọng: HTTP (dù version nào) là request-response protocol — không tối ưu cho push-based, real-time communication. WebSocket cung cấp full-duplex channel cho Operational Transform (OT) hoặc CRDT updates — mỗi keystroke được gửi và nhận trong milliseconds.
Mobile experience — HTTP/3 connection migration: Google Docs trên mobile phải đối mặt với vấn đề network switching: user đi từ WiFi nhà ra đường chuyển sang 4G. Với HTTP/2 (TCP), connection bị kill khi IP thay đổi → reconnect + re-authenticate → mất vài giây, user thấy "Reconnecting...". HTTP/3 (QUIC) với Connection ID cho phép connection survive network change — user thậm chí không nhận ra mạng đã chuyển. 0-RTT resumption đảm bảo ngay cả khi connection thực sự bị ngắt, reconnect gần như instant.
Bài học cho system design: HTTP version choice ảnh hưởng đến transport layer, không phải application logic. Operational Transform/CRDT algorithms chạy giống hệt nhau bất kể HTTP/1.1, HTTP/2 hay HTTP/3. Nhưng transport layer đúng khiến application FEEL responsive — user không nhận ra độ phức tạp phía sau. Đây là nguyên tắc "right tool for each layer": HTTP/2 cho initial load, WebSocket cho real-time, HTTP/3 cho mobile resilience.
Sai lầm điển hình
⚠️ Cạm bẫy
1. "HTTP/2 nhanh hơn nên luôn tốt hơn HTTP/1.1"
Trên mạng lossy (packet loss > 2%), HTTP/2 có thể CHẬM hơn HTTP/1.1. Lý do: HTTP/1.1 mở 6 TCP connections → packet loss trên connection 1 chỉ ảnh hưởng requests trên connection đó. HTTP/2 đặt tất cả eggs vào 1 basket (1 TCP connection) → 1 packet loss block tất cả streams.
Nghiên cứu của Google (2016) cho thấy trên mạng với 2% packet loss, HTTP/2 chậm hơn HTTP/1.1 tới 10–15% cho page load time.
Bài học: Luôn test performance trên network conditions thực tế của users, không chỉ trên mạng datacenter hoàn hảo.
⚠️ Cạm bẫy
2. Enable HTTP/2 server push mà không hiểu cache behavior
Server push gửi resources trước khi client request — nghe hay nhưng server không biết client đã cache resource chưa. Nếu user đã có style.css trong browser cache, server push style.css = lãng phí bandwidth hoàn toàn.
Tệ hơn, pushed resources có thể race với browser cache check, gây confusion và wasted bytes. Đây là lý do Chrome đã chính thức loại bỏ server push support.
Giải pháp: Dùng 103 Early Hints thay vì server push — cho client biết sẽ cần resource gì để client tự quyết định fetch hay dùng cache.
⚠️ Cạm bẫy
3. Dùng HTTP/3 cho internal service mesh
HTTP/3 (QUIC) được thiết kế cho lossy, high-latency, mobile networks. Trong datacenter:
- Packet loss gần 0% → QUIC stream independence không có lợi
- Latency < 1ms → 0-RTT savings không đáng kể
- Connection migration không cần → services có fixed IPs
- QUIC userspace processing tốn CPU hơn kernel TCP
Giải pháp: Dùng HTTP/2 (hoặc gRPC over HTTP/2) cho service-to-service communication. Dành HTTP/3 cho edge — nơi traffic đi qua internet đến end users.
⚠️ Cạm bẫy
4. Không test HTTP version fallback
Browsers tự động fallback: thử QUIC (HTTP/3) → nếu bị block/timeout → fallback về HTTP/2 → fallback về HTTP/1.1. Fallback process mất thêm 300ms–3s (timeout waiting for QUIC response).
Nhiều teams enable HTTP/3 trên CDN mà không biết 10–20% users ở mạng corporate đang bị chậm hơn vì fallback timeout.
Giải pháp: Dùng Alt-Svc header hợp lý, implement QUIC discovery caching, và monitor phần trăm users thực sự dùng được HTTP/3 vs fallback. Test trên mạng có firewall block UDP.
Under the Hood
Connection setup latency — so sánh thực tế
Scenario: Client ở Hà Nội, Server ở Singapore (RTT ≈ 40ms)
HTTP/1.1 + TLS 1.2:
TCP handshake: 1 RTT = 40ms
TLS 1.2 handshake: 2 RTT = 80ms
First data: 3 RTT = 120ms trước khi nhận byte đầu tiên
HTTP/2 + TLS 1.3:
TCP handshake: 1 RTT = 40ms
TLS 1.3 handshake: 1 RTT = 40ms
First data: 2 RTT = 80ms
HTTP/3 (QUIC) — first connection:
QUIC + TLS 1.3: 1 RTT = 40ms
First data: 1 RTT = 40ms (tiết kiệm 80ms!)
HTTP/3 (QUIC) — resumption (0-RTT):
First data: 0 RTT = ~0ms (data gửi ngay trong gói đầu tiên!)Trên mạng với RTT cao (100ms+ cho cross-region), sự khác biệt 0-RTT vs 3-RTT là 200–300ms — hoàn toàn perceptible cho users.
HPACK vs QPACK — Sự khác biệt tinh tế
Tại sao HTTP/3 không dùng HPACK? Vì HPACK yêu cầu ordered delivery — encoder và decoder phải cập nhật dynamic table theo đúng thứ tự. Trên TCP (ordered), đây không phải vấn đề. Trên QUIC (independent streams, unordered delivery giữa streams), HPACK sẽ gây deadlock.
QPACK giải quyết bằng cách tách dynamic table updates thành dedicated unidirectional streams — encoder stream và decoder stream — tách biệt khỏi request/response streams. Điều này cho phép header compression mà không cần ordering giữa streams.
✅ Checklist triển khai
Checklist ghi nhớ
Kiến thức nền tảng
- [ ] Hiểu HTTP/1.1 HOL blocking: responses phải trả về đúng thứ tự trên cùng connection
- [ ] Hiểu HTTP/2 multiplexing: nhiều streams song song trên 1 TCP connection
- [ ] Hiểu TCP-level HOL blocking: packet loss trên TCP ảnh hưởng tất cả HTTP/2 streams
- [ ] Hiểu HTTP/3/QUIC independent streams: packet loss chỉ ảnh hưởng stream liên quan
Protocol details
- [ ] HPACK (HTTP/2) vs QPACK (HTTP/3): QPACK cho phép unordered delivery giữa streams
- [ ] 0-RTT: QUIC reuse encryption keys, gửi data ngay trong gói đầu tiên — nhưng có replay attack risk
- [ ] Connection ID: QUIC connection survive network changes (WiFi → 4G) — killer feature cho mobile
- [ ] Server push đã bị Chrome loại bỏ — dùng 103 Early Hints thay thế
System design decisions
- [ ] HTTP/1.1 cho legacy và simple internal APIs
- [ ] HTTP/2 là default choice cho hầu hết web applications và gRPC
- [ ] HTTP/3 cho mobile-first, lossy networks, global users, latency-sensitive apps
- [ ] Không dùng HTTP/3 cho internal service-to-service trong datacenter
- [ ] Luôn test fallback behavior: QUIC bị block → HTTP/2 → HTTP/1.1
- [ ] Monitor phần trăm users thực sự dùng được HTTP/3 vs fallback
Performance awareness
- [ ] HTTP/2 có thể chậm hơn HTTP/1.1 trên mạng lossy (>2% packet loss)
- [ ] Domain sharding, sprite sheets, CSS concatenation là anti-patterns từ HTTP/2 trở đi
- [ ] QUIC tốn nhiều CPU hơn TCP ở server side (userspace vs kernel)
Bài tập luyện tập
🧠 Quiz
Câu 1: Tại sao HTTP/2 multiplexing không hoàn toàn giải quyết head-of-line blocking?
- [ ] A. Vì HTTP/2 vẫn dùng text protocol
- [x] B. Vì tất cả streams chạy trên 1 TCP connection — packet loss ở TCP level block tất cả streams
- [ ] C. Vì HTTP/2 không hỗ trợ concurrent requests
- [ ] D. Vì browser giới hạn số streams Giải thích: HTTP/2 giải quyết HOL blocking ở tầng HTTP bằng multiplexing, nhưng vẫn dùng TCP. Khi một TCP segment bị mất, TCP yêu cầu retransmit và block toàn bộ byte stream — ảnh hưởng tất cả HTTP/2 streams trên connection đó. Đây là "TCP-level HOL blocking" — lý do cốt lõi HTTP/3 chuyển sang QUIC/UDP.
🧠 Quiz
Câu 2: Trong scenario nào HTTP/3 mang lại lợi ích lớn nhất so với HTTP/2?
- [ ] A. Internal microservice communication trong datacenter
- [ ] B. Static file serving qua CDN trên mạng fiber
- [x] C. Mobile app cho ride-hailing service, users chuyển WiFi ↔ 4G liên tục
- [ ] D. Batch processing API chạy nightly jobs Giải thích: HTTP/3 (QUIC) tỏa sáng khi: (1) connection migration — chuyển mạng không mất connection, (2) 0-RTT — reconnect nhanh, (3) independent streams — lossy mobile networks không block tất cả requests. Ride-hailing app trên mobile có tất cả 3 yếu tố này. Datacenter communication ổn định không cần HTTP/3.
🧠 Quiz
Câu 3: QUIC 0-RTT cho phép gửi data ngay trong gói tin đầu tiên. Rủi ro bảo mật chính là gì?
- [ ] A. Data không được mã hoá
- [ ] B. Server không thể verify client identity
- [x] C. Replay attack — attacker capture 0-RTT data và gửi lại
- [ ] D. Man-in-the-middle attack dễ hơn Giải thích: 0-RTT data có thể bị attacker capture và replay vì server chưa gửi fresh nonce/challenge. Vì vậy, 0-RTT chỉ nên dùng cho idempotent requests (GET, HEAD) — không bao giờ cho requests có side effects (POST transfer money). Server cần implement replay protection hoặc chỉ accept 0-RTT cho safe methods.
🧠 Quiz
Câu 4: Team bạn đang maintain legacy REST API dùng HTTP/1.1. CTO muốn upgrade lên HTTP/3 ngay. Argument nào thuyết phục nhất để upgrade lên HTTP/2 trước?
- [ ] A. HTTP/2 miễn phí, HTTP/3 phải mua license
- [x] B. HTTP/2 backward compatible, hầu hết infrastructure đã hỗ trợ, và cải thiện rõ rệt — HTTP/3 cần QUIC support ở load balancer/CDN và có thể bị firewall block
- [ ] C. HTTP/3 chưa là standard
- [ ] D. HTTP/2 nhanh hơn HTTP/3 Giải thích: HTTP/2 là incremental upgrade an toàn — enable ở reverse proxy (Nginx, Cloudflare) mà không cần thay đổi application code, hầu hết infrastructure đã hỗ trợ sẵn. HTTP/3 cần QUIC support ở edge (CDN, LB), testing fallback behavior, monitoring UDP connectivity — phức tạp hơn nhiều. Upgrade theo lộ trình: HTTP/1.1 → HTTP/2 → HTTP/3 khi infrastructure sẵn sàng.
🏗️ Architecture Drag-and-Drop: Match feature với đúng HTTP version
Hướng dẫn: Với mỗi feature bên trái, xác định nó thuộc HTTP version nào. Một số features có thể thuộc nhiều versions.
| # | Feature | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|---|
| 1 | Keep-alive connections | ? | ? | ? |
| 2 | Binary framing layer | ? | ? | ? |
| 3 | Multiplexing | ? | ? | ? |
| 4 | HPACK header compression | ? | ? | ? |
| 5 | QPACK header compression | ? | ? | ? |
| 6 | 0-RTT connection resumption | ? | ? | ? |
| 7 | Connection migration (Connection ID) | ? | ? | ? |
| 8 | Server push | ? | ? | ? |
| 9 | Stream prioritization | ? | ? | ? |
| 10 | Built-in TLS 1.3 (mandatory encryption) | ? | ? | ? |
| 11 | Text-based protocol | ? | ? | ? |
| 12 | Runs on TCP | ? | ? | ? |
| 13 | Runs on UDP | ? | ? | ? |
| 14 | Independent stream loss recovery | ? | ? | ? |
✅ Đáp án
| # | Feature | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|---|
| 1 | Keep-alive connections | ✅ | ✅ (inherited) | ✅ (QUIC connection) |
| 2 | Binary framing layer | ❌ | ✅ | ✅ |
| 3 | Multiplexing | ❌ | ✅ | ✅ |
| 4 | HPACK header compression | ❌ | ✅ | ❌ |
| 5 | QPACK header compression | ❌ | ❌ | ✅ |
| 6 | 0-RTT connection resumption | ❌ | ❌ | ✅ |
| 7 | Connection migration (Connection ID) | ❌ | ❌ | ✅ |
| 8 | Server push | ❌ | ✅ | ✅ |
| 9 | Stream prioritization | ❌ | ✅ | ✅ (extensible priorities) |
| 10 | Built-in TLS 1.3 (mandatory encryption) | ❌ | ❌ | ✅ |
| 11 | Text-based protocol | ✅ | ❌ | ❌ |
| 12 | Runs on TCP | ✅ | ✅ | ❌ |
| 13 | Runs on UDP | ❌ | ❌ | ✅ |
| 14 | Independent stream loss recovery | ❌ | ❌ | ✅ |
Giải thích các điểm hay nhầm:
- Keep-alive: HTTP/1.1 giới thiệu, HTTP/2 và HTTP/3 kế thừa concept (persistent connection)
- Server push: Có trong cả HTTP/2 và HTTP/3 spec, nhưng hiếm khi dùng trong thực tế
- Stream prioritization: HTTP/2 có priority scheme phức tạp (weight + dependency), HTTP/3 dùng RFC 9218 Extensible Priorities — đơn giản và rõ ràng hơn
- HPACK vs QPACK: HPACK cần ordered delivery (TCP), QPACK thiết kế cho unordered delivery (QUIC)
Liên kết học tiếp
Từ khóa glossary: HTTP/1.1, HTTP/2, HTTP/3, QUIC, Multiplexing, Head-of-Line Blocking, HPACK, QPACK, 0-RTT, Connection Migration, Binary Framing, Server Push, Stream Prioritization, TLS 1.3, UDP, TCP
Tìm kiếm liên quan: giao thức HTTP, so sánh HTTP versions, QUIC protocol, multiplexing, head-of-line blocking, 0-RTT handshake, connection migration, web performance optimization