Vòng đời Request HTTP: Từ URL đến Phản hồi (Response)

Tóm tắt nhanh (TL;DR)

Một HTTP request bản chất là một phiên trao đổi request/response theo ngữ nghĩa, không nhất thiết đồng nghĩa với việc mở mới một kết nối mạng. Khi gỡ lỗi một request thực tế, hãy lần theo chuỗi các thực thể tham gia: tầng cache nào, kết nối nào được tái sử dụng, trung gian nào đã can thiệp, và máy chủ gốc có thực sự được gọi hay không.

Đừng mặc định rằng mỗi request đều phải lặp lại toàn bộ chuỗi: Phân giải DNS, bắt tay TCP, thiết lập TLS và xử lý mã nguồn tại backend. Một mục cache còn tươi mới (fresh) có thể phản hồi ngay lập tức trước khi chạm vào card mạng, một kết nối đang mở có thể gánh thêm request mới, và một CDN cache trung gian có thể trả kết quả trước khi ứng dụng backend kịp nhận tín hiệu.

HTTP/1.1, HTTP/2, và HTTP/3 chia sẻ chung ngữ nghĩa HTTP chuẩn hóa (RFC 9110). Chúng chỉ khác nhau ở cách thức truyền tải các ngữ nghĩa đó qua dây mạng.

Bốn hành trình phổ biến của một Request

🖼️ [Illustration Placeholder: 4 Hành trình phổ biến của HTTP Request]
Mô tả hình minh họa: Sơ đồ phân nhánh đối chiếu 4 luồng di chuyển thực tế của request:

1. Luồng 1 (Trúng Cache Trình duyệt): Client kiểm tra bộ nhớ cục bộ -> Phản hồi còn fresh -> Trả dữ liệu ngay (độ trễ mạng 0ms, bỏ qua hoàn toàn DNS, TCP, TLS và backend).
2. Luồng 2 (Tái sử dụng kết nối): Trượt cache cục bộ -> Client tìm thấy kết nối HTTP/2 hoặc HTTP/3 đang mở đến cùng origin -> Bắn stream HTTP qua socket có sẵn (bỏ qua phân giải DNS, bắt tay TCP 3 bước và đàm phán TLS).
3. Luồng 3 (Khởi tạo kết nối lạnh đầy đủ): Chưa có kết nối phù hợp -> Thực thi toàn bộ chuỗi: Phân giải DNS -> TCP SYN/ACK (1 RTT) -> Trao đổi khóa TLS 1.3 (1 RTT) -> Trao đổi HTTP Request/Response (1 RTT).
4. Luồng 4 (Trúng Cache Trung gian Edge CDN): Request rời máy khách qua mạng nhưng gặp trạm Edge CDN gần nhất -> CDN trả về bản ghi trong cache -> Tiết kiệm hàng trăm mili-giây và giải phóng tải tính toán cho backend gốc.

Trước khi học thuộc các tầng giao thức, hãy tự hỏi: request bạn đang gỡ lỗi thuộc về hành trình nào trong 4 trường hợp trên?

1. Trúng Cache cục bộ của Client (Fresh cache hit)

khởi tạo request
      ↓
cache của client tìm thấy bản ghi còn tươi mới (fresh)
      ↓
trả về dữ liệu đã lưu

Không có bất kỳ gói tin mạng nào cần phải rời khỏi máy khách.

2. Trượt Cache nhưng tái sử dụng kết nối sẵn có

khởi tạo request
      ↓
trượt cache (cache miss)
      ↓
tái sử dụng kết nối phù hợp đang mở
      ↓
gửi HTTP request
      ↓
nhận response

Giao dịch HTTP là mới, nhưng kết nối mạng bên dưới là kết nối cũ được tái sử dụng.

3. Chưa có kết nối phù hợp

Trình duyệt cần thực hiện phân giải địa chỉ IP (DNS), thiết lập tầng truyền tải (TCP/QUIC) và đàm phán an ninh (TLS) trước khi có thể truyền tải request HTTP.

4. Trúng Cache tại máy chủ trung gian (CDN/Proxy)

client trượt cache nội bộ
      ↓
gửi request qua mạng
      ↓
trúng cache tại máy chủ trung gian / Edge CDN
      ↓
nhận response

(bước xử lý tại backend gốc: hoàn toàn bị bỏ qua)

Chính sự đa dạng của các hành trình này giải thích vì sao không tồn tại một chuỗi bắt buộc duy nhất "DNS → TCP → TLS → App" cho mọi request HTTP.

Tách bạch Ngữ nghĩa HTTP và Thiết lập Mạng

Ngữ nghĩa HTTP (HTTP Semantics)
Phương thức (Method) + Mục tiêu (Target) + Tiêu đề (Headers) + Body tùy chọn
                              ↓
Mã trạng thái (Status) + Tiêu đề (Headers) + Body phản hồi tùy chọn

Bao bọc xung quanh phiên trao đổi ngữ nghĩa đó là các tầng cache, tái sử dụng socket, máy chủ ủy quyền và máy chủ gốc. DNS, TCP và TLS ảnh hưởng lớn đến độ trễ, nhưng chúng không định nghĩa ngữ nghĩa của GET, 404 Not Found hay Cache-Control.

Bộ nhớ Cache trước khi ra Mạng

🖼️ [Illustration Placeholder: Lưu đồ Caching & Xác thực có điều kiện (Revalidation)]
Mô tả hình minh họa: Sơ đồ cây quyết định trong bộ nhớ cache trình duyệt:

• Bắt đầu request -> Kiểm tra Local Cache:
  • Trượt Cache (Miss): -> Gửi request qua mạng ra Internet.
  • Trúng Cache (Hit):
    • Nếu còn hạn theo max-age (Fresh): Trả ngay dữ liệu lưu trữ -> 200 OK (from disk cache).
    • Nếu hết hạn (Stale):
      • Kiểm tra bản ghi có token xác thực (ETag hoặc Last-Modified) không?
      • Nếu CÓ: Gửi Request có điều kiện mang theo If-None-Match: "xyz".
        • Server xác nhận dữ liệu chưa đổi -> Trả về 304 Not Modified (chỉ có headers, body rỗng) -> Trình duyệt đọc body từ cache máy.
        • Server xác nhận dữ liệu đã đổi -> Trả về 200 OK + Body mới đầy đủ -> Trình duyệt ghi đè cache.

Tái sử dụng Kết nối và Các thế hệ HTTP

🖼️ [Illustration Placeholder: Kiến trúc kết nối: HTTP/1.1 vs HTTP/2 vs HTTP/3]
Mô tả hình minh họa: So sánh trực quan cơ chế truyền tải mạng qua 3 thế hệ HTTP:

1. HTTP/1.1 (Tắc nghẽn đầu hàng trên TCP - Head-of-Line Blocking): Mỗi request phải đợi response trước đó hoàn thành trên một kết nối TCP. Trình duyệt mở tối đa 6 kết nối TCP song song đến mỗi domain.
2. HTTP/2 (Ghép kênh Multiplexing trên 1 kết nối TCP): Chia nhỏ request/response thành các khung nhị phân (Binary Frames) đan xen nhau trên các stream logic qua 1 đường ống TCP duy nhất. Giải quyết tắc nghẽn ở tầng ứng dụng, nhưng 1 gói tin TCP bị rơi rớt sẽ làm nghẽn toàn bộ các stream (TCP HoL Blocking).
3. HTTP/3 (QUIC trên nền UDP): Sử dụng giao thức QUIC chạy trên UDP. Các stream hoàn toàn độc lập ở tầng truyền tải; mất gói tin ở stream ảnh A không hề làm chậm dữ liệu của stream API B và C.

HTTP/1.1, HTTP/2, và HTTP/3

• HTTP/1.1: Dạng văn bản thuần, hỗ trợ kết nối giữ lâu (Keep-Alive) nhưng bị giới hạn bởi hiện tượng nghẽn đầu hàng (Head-of-Line Blocking).
• HTTP/2: Giữ nguyên ngữ nghĩa, bổ sung đóng khung nhị phân (Binary Framing), nén tiêu đề (HPACK), và ghép nhiều stream đồng thời trên một kết nối TCP duy nhất.
• HTTP/3: Ánh xạ ngữ nghĩa HTTP lên giao thức truyền tải bảo mật QUIC chạy trên nền UDP, tích hợp sẵn bắt tay TLS 1.3 và loại bỏ hoàn toàn hiện tượng nghẽn đầu hàng ở tầng truyền tải.

Khám phá thực tế: Request Path Explorer

Hãy sử dụng công cụ mô phỏng dưới đây để đối chiếu từng chặng trong các kịch bản request phổ biến:

Tình huống thực tế trên Production

Tình huống: Hiện tượng "Mã 200 ma" và sự biến mất của log máy chủ

Một nhóm kỹ sư nhận được phản hồi khẩn từ người dùng: sau khi cập nhật thông tin cá nhân trên trang cá nhân, giao diện vẫn hiển thị thông tin cũ kỹ. Kỹ sư mở tab Network trên DevTools và thấy:

• Mã trạng thái: 200 OK
• Dữ liệu trả về: Vẫn là thông tin cũ
• Thời gian: 3ms

Nghi ngờ backend bị lỗi cache Redis hoặc cơ sở dữ liệu chưa ghi kịp, kỹ sư mất hơn hai giờ rà soát toàn bộ access log của hệ thống backend, nhưng kỳ lạ thay: hoàn toàn không có bất kỳ request nào từ user đó được ghi nhận tại server.

• Hậu quả: Tiêu tốn hàng giờ làm việc căng thẳng của đội ngũ frontend và backend do chẩn đoán sai ranh giới lỗi.
• Nguyên nhân cốt lõi: Kỹ sư đã bỏ qua cột Size/Transferred trong DevTools: nó hiển thị rõ ràng (from disk cache)! Request chưa từng rời khỏi máy của người dùng. Một response trước đó đã trả về Cache-Control: public, max-age=3600, ra lệnh cho trình duyệt tự phục vụ dữ liệu từ ổ cứng suốt 1 giờ mà không được hỏi lại server.
• Cách khắc phục chuẩn:
  1. Luôn nhìn cột Size/Transferred trước tiên: (from disk cache) hay (from memory cache) xác nhận request đã được giải quyết hoàn toàn tại client.
  2. Bổ sung Cache-Control: private, no-cache hoặc no-store đối với các API trả về dữ liệu định danh người dùng nhạy cảm để ép buộc trình duyệt luôn kiểm tra mạng.

Bảng phân vùng ranh giới lỗi (Failure Boundaries)

Câu hỏi củng cố tư duy

Một lập trình viên ghi nhận thông tin request API trong DevTools như sau:

• Giao thức hiển thị là HTTP/2;
• Kết nối hiển thị tái sử dụng ID kết nối cũ;
• Trả về mã 304 Not Modified;
• Dịch vụ backend không có log xử lý dữ liệu body;
• Giao diện web cập nhật hiển thị dữ liệu đầy đủ.

Nguyên tắc cốt lõi dành cho Kỹ sư

Khi gỡ lỗi hoặc viết mã tương tác qua HTTP, không bao giờ giả định một chuỗi tuần tự cứng nhắc DNS -> TCP -> TLS -> Backend. Hãy xác định xem request có bị chặn bởi cache không, có tái sử dụng kết nối không, phiên bản HTTP nào đang phục vụ, thành phần nào thực sự sinh ra mã trạng thái, và lỗi gặp phải thuộc tầng mạng, tầng giao thức hay tầng nghiệp vụ.

Checklist kiểm tra khi rà soát luồng HTTP:

• Kiểm tra tầng cache: Request có thực sự đi ra mạng hay được giải quyết ngay bởi disk cache / memory cache?
• Trạng thái tái sử dụng kết nối: Request này có tái sử dụng socket/TLS session cũ hay phải chịu chi phí bắt tay mới từ đầu?
• Nhận diện thế hệ giao thức: Giao dịch đang chạy trên HTTP/1.1 (tuần tự), HTTP/2 (ghép kênh TCP) hay HTTP/3 (QUIC UDP)?
• Xác định ranh giới phản hồi: Mã trạng thái và headers được sinh ra từ Edge CDN, API Gateway, WAF hay chính mã nguồn backend?
• Cấu hình xác thực lại (Revalidation): Các tiêu đề ETag, Last-Modified, và Cache-Control đã được thiết lập chuẩn để tận dụng mã phản hồi nhẹ 304 Not Modified chưa?
• Phân tách tầng lỗi: Sự cố đang gặp phải là đứt kết nối mạng vật lý, lỗi giao thức cổng trung gian (502/504), hay lỗi nghiệp vụ được bọc trong mã 200?
• Quy chuẩn Retry an toàn: Cơ chế gửi lại (retry) có được giới hạn nghiêm ngặt cho các thao tác an toàn (idempotent) hoặc được bảo vệ bằng Idempotency Key không?

Nguồn tham khảo chuẩn mực

• RFC 9110 — HTTP Semantics
• RFC 9111 — HTTP Caching
• RFC 9113 — HTTP/2
• RFC 9114 — HTTP/3
• RFC 9001 — Using TLS to Secure QUIC
• WHATWG Fetch Living Standard