Điều gì xảy ra khi bạn gõ google.com và nhấn Enter?

Bạn gõ google.com, nhấn Enter. Khoảng 200ms sau, trang hiện ra. Cảm giác như tức thì — như thể trình duyệt "biết" Google ở đâu và gọi thẳng tới.

Thực tế giữa lúc nhấn Enter và lúc pixel đầu tiên xuất hiện, có 5 chặng riêng biệt chạy qua nhiều máy ở nhiều nơi trên thế giới. Mỗi chặng giải quyết một bài toán khác nhau: máy đó ở địa chỉ nào? làm sao mở được kênh tới nó? làm sao kênh đó an toàn? gửi yêu cầu gì? nhận về rồi vẽ ra sao?

Một backend dev không cần thuộc lòng 7 tầng OSI. Nhưng khi production ném ECONNRESET, khi trang chậm 3 giây không rõ lý do, khi cert hết hạn — bạn cần biết request đang kẹt ở chặng nào. Bài này dựng bản đồ toàn cảnh đó.

Đây là bài xương sống của cả khoá. Mỗi chặng dưới đây sẽ có một module riêng đào sâu: DNS, TCP/IP, HTTP, TLS. Giờ ta đi một vòng nhanh để thấy chúng ráp vào nhau thế nào.

1. Analogy — Gọi điện đến một tổng đài công ty

Hình dung bạn muốn gọi cho một tập đoàn lớn mà chỉ biết tên, không biết số:

1. Bạn tra danh bạ để tìm số điện thoại từ tên công ty.
2. Bạn quay số, chờ tổng đài nhấc máy, hai bên "alo, nghe rõ không?" để chắc chắn đường dây thông.
3. Vì nội dung nhạy cảm, hai bên chuyển sang đường dây mã hoá và thống nhất một bộ mật mã.
4. Bạn nói yêu cầu ("cho tôi gặp phòng kinh doanh"), nhận lại câu trả lời.
5. Bạn ghi lại và xử lý thông tin nhận được.

Một HTTP request đi đúng 5 bước đó:

2. Toàn cảnh 5 chặng

Toàn bộ câu chuyện chỉ có ba nhân vật chính: trình duyệt của bạn, hệ thống DNS, và server đích.

→

→

Đây là sequence diagram của một lần load https://google.com từ con số 0 (chưa cache gì):

sequenceDiagram
    participant B as Browser
    participant D as DNS Resolver
    participant S as Server (google.com)

    B->>D: google.com co IP nao?
    D-->>B: 142.250.x.x
    Note over B,S: Chang 1 — DNS (~20-120ms)

    B->>S: SYN
    S-->>B: SYN-ACK
    B->>S: ACK
    Note over B,S: Chang 2 — TCP handshake (1 RTT)

    B->>S: ClientHello
    S-->>B: ServerHello + cert
    B->>S: Finished
    Note over B,S: Chang 3 — TLS handshake (1 RTT, TLS 1.3)

    B->>S: GET / HTTP/2
    S-->>B: 200 OK + HTML
    Note over B,S: Chang 4 — HTTP request/response

    Note over B: Chang 5 — parse HTML, tai CSS/JS, render

Điểm mấu chốt: mỗi mũi tên qua lại là một lần đi vòng mạng — gọi là RTT (Round-Trip Time), thời gian gói tin đi tới server và quay về. RTT trong nước cỡ 10-30ms, đi quốc tế có thể 150-300ms. Càng nhiều chặng nối tiếp, độ trễ càng cộng dồn. Đây là lý do tối ưu mạng phần lớn là giảm số RTT, không phải tăng băng thông.

3. Chặng 1 — DNS: tên miền thành địa chỉ IP

Máy tính không định tuyến theo tên google.com — chúng định tuyến theo địa chỉ IP (ví dụ 142.250.190.78). DNS (Domain Name System) là hệ thống tra cứu biến tên thành IP.

Bạn tự chạy thử bằng dig:

dig google.com +short
# 142.250.190.78

Trình duyệt không hỏi thẳng "tổng đài gốc" mỗi lần. Nó tra qua một chuỗi cache:

flowchart LR
    A[Browser cache] --> B[OS cache]
    B --> C[Router]
    C --> D[ISP resolver]
    D --> E[Root / TLD / Authoritative]

Hỏi tới đâu thấy kết quả còn hạn (TTL chưa hết) thì dừng. Lần đầu vào một domain lạ có thể mất 100ms+ vì phải đi tới cuối chuỗi; lần sau gần như 0ms vì đã cache. Đây là chặng đầu tiên có thể làm trang "đơ" vài giây nếu resolver chậm — và là thủ phạm hay bị bỏ qua khi debug.

4. Chặng 2 — TCP handshake: bắt tay 3 bước

Có IP rồi, nhưng chưa thể gửi dữ liệu ngay. Hai đầu — client và server — phải bắt tay mở kết nối trước.

⇄

TCP cần thiết lập kết nối trước qua 3 gói tin — gọi là 3-way handshake:

sequenceDiagram
    participant B as Client
    participant S as Server
    B->>S: SYN (toi muon ket noi, seq=x)
    S-->>B: SYN-ACK (ok, seq=y, ack=x+1)
    B->>S: ACK (xac nhan, ack=y+1)
    Note over B,S: Ket noi mo — san sang truyen du lieu

Ba bước này để cả hai phía đồng ý mở kết nối và đồng bộ số thứ tự gói (sequence number) dùng cho việc đảm bảo dữ liệu tới đủ và đúng thứ tự sau này. Tốn đúng 1 RTT trước khi byte dữ liệu đầu tiên được gửi.

Vì sao một backend dev phải quan tâm? Vì handshake này tốn tài nguyên ở server, và khi đóng kết nối lại sinh ra trạng thái TIME_WAIT — nguồn cơn của lỗi "hết port" kinh điển trên server tải cao (sẽ có hẳn một bài ở module TCP). Bạn xem trạng thái các kết nối bằng:

ss -tan | head
# State    Recv-Q  Send-Q   Local Address:Port   Peer Address:Port
# ESTAB    0       0        10.0.0.5:443         203.0.113.7:51324
# TIME-WAIT 0      0        10.0.0.5:443         203.0.113.7:51210

5. Chặng 3 — TLS: thiết lập kênh mã hoá

URL bắt đầu bằng https nghĩa là dữ liệu phải được mã hoá. Sau khi TCP mở kết nối, hai bên chạy thêm TLS handshake: trao đổi để (1) xác thực server đúng là google.com qua certificate, và (2) thống nhất một khoá mã hoá chung cho phiên này.

Với TLS 1.3, handshake tốn thêm 1 RTT (TLS 1.2 tốn 2 RTT — đây là một lý do nâng cấp TLS giúp web nhanh hơn). Bạn quan sát toàn bộ chặng 1→3→4 chỉ bằng một lệnh curl:

curl -v https://google.com -o /dev/null
# * Connected to google.com (142.250.190.78) port 443    <- DNS + TCP xong
# * TLS handshake, Done                                  <- TLS xong
# > GET / HTTP/2                                          <- chang 4 bat dau
# < HTTP/2 200

Cờ -v (verbose) in từng chặng. Khi gặp lỗi cert hết hạn hay "Not Secure", chặng dừng ngay ở dòng TLS — và curl -v cho bạn thấy chính xác nó hỏng ở đâu.

6. Chặng 4 — HTTP: request và response

Đến đây kênh đã mở và an toàn. Trình duyệt mới gửi HTTP request thật sự — yêu cầu nội dung. Một request tối giản:

GET / HTTP/2
Host: google.com
User-Agent: Mozilla/5.0 ...
Accept: text/html

Server trả về response:

HTTP/2 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: private, max-age=0

<!DOCTYPE html>...

Dòng đầu response chứa status code — 200 là OK, 404 không tìm thấy, 500 server lỗi, 301 chuyển hướng. Phần lớn công việc đọc lỗi production của backend dev nằm ở việc hiểu đúng status code và header. Đây là tầng bạn "sống cùng" mỗi ngày, nên cả một module sẽ dành riêng cho nó.

7. Chặng 5 — Browser render (tóm tắt)

Nhận được HTML, trình duyệt parse ra cây DOM, phát hiện cần thêm CSS, JS, ảnh — và lặp lại chặng 1-4 cho từng tài nguyên đó. Một trang thường kéo hàng chục request con. Đây là lý do HTTP/2 (multiplexing nhiều request trên một kết nối) tạo khác biệt lớn về tốc độ so với HTTP/1.1.

Chặng render thuộc về frontend nhiều hơn, nên khoá này chỉ điểm qua — trọng tâm của ta là 4 chặng mạng phía trước.

8. Vì sao lần đầu chậm, lần sau nhanh

Ghép lại, ngân sách độ trễ một lần load "nguội" (chưa cache) trông như sau:

Gần như mọi tầng đều có cache riêng. Đây là insight quan trọng nhất bài này: tối ưu hiệu năng mạng phần lớn là tránh làm lại chặng đã làm — tái dùng kết nối TCP, resume phiên TLS, cache DNS, cache HTTP. Mỗi cache bạn bỏ lỡ là một RTT cộng thêm vào độ trễ người dùng cảm nhận.

9. Pitfall — hiểu nhầm thường gặp

❌ Nhầm 1: "Trang chậm chắc do server yếu / cần thêm CPU." ✅ Server có thể trả byte đầu tiên trong 5ms, nhưng nếu DNS resolver chậm 2 giây hoặc TLS handshake đi vòng quốc tế, người dùng vẫn chờ 2 giây. Luôn xác định chặng nào chậm trước khi tối ưu — curl -w in được thời gian từng chặng.

❌ Nhầm 2: "HTTPS chỉ làm chậm vì phải mã hoá." ✅ Chi phí mã hoá dữ liệu là không đáng kể trên CPU hiện đại. Chi phí thật của HTTPS là handshake (thêm RTT) — và nó được loại bỏ gần hết nhờ keep-alive và session resumption. Đổi lại, HTTP/2 (chỉ chạy trên HTTPS) thường làm trang nhanh hơn HTTP thuần.

❌ Nhầm 3: "ping được thì mạng ổn, lỗi phải do code." ✅ ping chỉ kiểm tra chặng định tuyến IP (ICMP), không đụng tới TCP/TLS/HTTP. Ping thông mà app vẫn timeout là chuyện thường — vì lỗi nằm ở port bị firewall chặn, TLS sai cert, hay server không listen. Mỗi chặng phải debug bằng công cụ của chặng đó.

10. 📚 Deep Dive — tài liệu gốc

11. Tóm tắt

• Một HTTP request đi qua 5 chặng nối tiếp: DNS → TCP → TLS → HTTP → render. Lỗi ở chặng sớm chặn mọi chặng sau.
• DNS biến tên miền thành IP, tra qua một chuỗi cache; TTL quyết định bao lâu kết quả còn được dùng lại.
• TCP 3-way handshake (SYN / SYN-ACK / ACK) mở kết nối và đồng bộ sequence number, tốn 1 RTT.
• TLS handshake thiết lập kênh mã hoá + xác thực server; TLS 1.3 chỉ tốn 1 RTT.
• HTTP là tầng request/response thật — status code và header là nơi backend dev đọc lỗi nhiều nhất.
• Mỗi RTT là một lần đi-về mạng; tối ưu hiệu năng chủ yếu là giảm số RTT chứ không phải tăng băng thông.
• Gần như mọi tầng đều có cache — lần load "ấm" bỏ qua phần lớn handshake nhờ keep-alive và session resumption.
• Khi debug, xác định chặng nào hỏng trước (curl -v, dig, ss), rồi mới dùng công cụ của đúng chặng đó.

12. Tự kiểm tra

Bài tiếp theo: DNS — phân giải tên miền hoạt động thế nào