Latency vs throughput — vì sao 'thêm server' không luôn nhanh hơn

TL;DR: Latency (độ trễ) là thời gian để một đơn vị dữ liệu đi từ nguồn tới đích — đo bằng ms. Throughput (thông lượng) là lượng dữ liệu truyền được trong một đơn vị thời gian — đo bằng Mbps. Hai thứ độc lập: đường ống to (throughput cao) không nghĩa là nước chảy đến nhanh hơn (latency thấp). RTT (Round-Trip Time) là latency khứ hồi; handshake nối tiếp DNS+TCP+TLS cộng dồn RTT khiến request chậm dù băng thông lớn. Tối ưu sai metric là pitfall thường gặp nhất: tăng băng thông khi nút thắt là latency, hoặc thêm server khi nghẽn ở mạng.

Hình dung một câu hỏi quen thuộc từ technical interview: "App chậm, bạn làm gì?" Câu trả lời phổ biến nhất là "thêm server" hoặc "nâng bandwidth". Hai câu trả lời này đúng trong một số trường hợp — nhưng nếu nút thắt là latency mạng, cả hai đều vô dụng.

Bài này giải thích vì sao latency và throughput là hai thứ hoàn toàn khác nhau, vì sao RTT cộng dồn qua các handshake nối tiếp định hình thời gian cảm nhận của người dùng, và cách nhìn đúng metric trước khi tối ưu.

1. Analogy — Đường cao tốc vs đường làng

Hình dung bạn cần chuyển hàng từ Hà Nội vào TP.HCM. Bạn có hai lựa chọn:

Đường làng chật hẹp, 1 xe máy: Đường hẹp (throughput thấp), nhưng nếu xe máy chạy được 80 km/h và đường thẳng không tắc, thời gian tới nơi (latency) có thể chấp nhận được.

Đường cao tốc 6 làn, 100 xe tải: Throughput rất cao — hàng trăm tấn hàng mỗi chuyến. Nhưng nếu cao tốc vẫn dài 1700 km, thời gian xe tải đầu tiên tới nơi (latency) không khác xe máy là bao.

Bây giờ hỏi: muốn chiếc hàng đầu tiên tới nhanh hơn, bạn thêm xe tải hay làm đường ngắn hơn?

2. Định nghĩa chính xác

Latency

Latency là thời gian để một gói (hoặc một request) đi từ điểm A tới điểm B — đo bằng millisecond (ms). Latency có sàn vật lý không thể phá vỡ: ánh sáng trong cáp quang đi khoảng 200.000 km/s (chậm hơn ánh sáng trong chân không do hệ số khúc xạ của kính). Hà Nội — San Francisco khoảng 9.000 km → sàn latency vật lý cỡ 45ms một chiều → RTT tối thiểu cỡ 90ms, dù bạn có Gbps bandwidth.

Latency thực tế luôn cao hơn sàn vật lý vì: định tuyến không thẳng (gói phải qua nhiều hop router), xử lý tại mỗi hop, và tắc nghẽn hàng đợi (queuing delay) khi link bão hòa.

Throughput

Throughput là lượng dữ liệu thực sự truyền được qua kết nối trong một đơn vị thời gian — đo bằng Mbps hoặc Gbps. Throughput thường thấp hơn bandwidth (băng thông lý thuyết của đường truyền) vì overhead giao thức, mất gói, và cơ chế điều khiển tốc độ (congestion control TCP).

RTT — Round-Trip Time

RTT là thời gian một gói đi từ máy bạn tới đích và quay về — tức latency nhân đôi cho một vòng đi-về. Bạn đo RTT bằng ping:

ping -c 5 google.com
# PING google.com: 56 data bytes
# 64 bytes from 142.250.xxx.xxx: icmp_seq=0 ttl=117 time=18.4 ms
# 64 bytes from 142.250.xxx.xxx: icmp_seq=1 ttl=117 time=17.9 ms
# round-trip min/avg/max = 17.5/18.1/19.2 ms

RTT 18ms với Google là bình thường từ Việt Nam (server Google ở Singapore/HK). RTT sang server US có thể 150-250ms.

3. Vì sao RTT cộng dồn qua handshake

Đây là điểm quan trọng nhất bài này. Một request HTTPS không chỉ tốn 1 RTT — nó tốn tối thiểu 3 RTT nối tiếp trước khi byte dữ liệu đầu tiên tới người dùng:

sequenceDiagram
    participant B as Browser
    participant D as DNS Resolver
    participant S as Server

    B->>D: DNS query (ten mien -> IP)
    D-->>B: DNS response (RTT #1 ~ 10-50ms)

    B->>S: TCP SYN
    S-->>B: TCP SYN-ACK (RTT #2 ~ 18ms)
    B->>S: TCP ACK

    B->>S: TLS ClientHello
    S-->>B: TLS ServerHello + Cert + Finished (RTT #3 ~ 18ms voi TLS 1.3)
    B->>S: HTTP GET /
    S-->>B: HTTP 200 OK (RTT #4 ~ 18ms)
    Note over B,S: Tong: DNS + TCP + TLS + HTTP ~ 4 RTT

Với RTT 18ms (server gần, ví dụ Singapore) và DNS cache miss:

• DNS: cỡ 20-50ms (phụ thuộc DNS resolver và TTL cache)
• TCP handshake: 1 RTT = 18ms
• TLS 1.3 handshake: 1 RTT = 18ms
• HTTP request: 1 RTT = 18ms

Tổng: cỡ 70-120ms trước khi byte đầu tiên của response tới — dù server có Gbps bandwidth.

Nếu server ở US (RTT 200ms), con số này trở thành: DNS + 200ms + 200ms + 200ms = 600ms+ chỉ để nhận byte đầu tiên. Đây là lý do CDN tồn tại.

4. Bandwidth-delay product — "data đang bay" trong đường ống

Bandwidth-Delay Product (BDP) = Bandwidth × RTT. Đây là lượng dữ liệu "đang bay" trên đường truyền tại một thời điểm — tức lượng dữ liệu sender đã gửi nhưng chưa được ACK.

Ví dụ: link 100 Mbps, RTT 200ms: BDP = 100 Mbps × 0.2s = 20 Mb = 2.5 MB

Nghĩa là sender cần có thể có 2.5 MB dữ liệu "trên không" cùng lúc mới tận dụng hết băng thông. Nếu TCP receive window (giới hạn lượng dữ liệu chưa được ACK) nhỏ hơn BDP, băng thông thực sự bị giới hạn bởi window, không phải bởi link capacity.

Throughput thực te = min(Bandwidth, WindowSize / RTT)

Đây là lý do TCP slow start và congestion window tồn tại: TCP dần mở rộng window cho tới khi lấp đầy đường ống (BDP) mà không gây mất gói. Bài module 1 bài 03 — TCP congestion control giải thích cơ chế này chi tiết.

5. Vì sao latency cao giết hiệu năng dù bandwidth lớn

Đây là insight phản trực giác: tăng bandwidth giúp ích rất ít khi latency cao với các request nhỏ.

Lấy ví dụ cụ thể: bạn load một trang web gồm 100 resource nhỏ (mỗi file 10 KB), server ở US (RTT 200ms). Mỗi resource cần ít nhất 1 RTT để fetch:

• Với HTTP/1.1 (6 kết nối song song tối đa): 100 / 6 × 200ms ≈ 3.3 giây chỉ cho latency
• Bandwidth 1 Gbps? 100 × 10 KB = 1 MB — gửi xong trong 8ms. Nhưng page vẫn mất 3.3 giây

Tăng bandwidth từ 100 Mbps lên 1 Gbps không thay đổi gì đáng kể — vì nút thắt là RTT 200ms, không phải bandwidth. Đây là lý do "mua thêm bandwidth" không giải quyết được page load time chậm với server xa.

Senariot ngược: download file 1 GB (throughput-bound). Ở đây latency chỉ ảnh hưởng lần đầu kết nối — một khi TCP đã warm up và window đủ lớn, throughput mới là yếu tố quyết định. Tăng bandwidth từ 100 Mbps lên 1 Gbps: download time giảm từ 80s xuống 8s.

6. Tối ưu: giảm RTT là đòn bẩy lớn nhất

Vì latency/RTT định hình trải nghiệm người dùng với web request, các kỹ thuật tối ưu hiệu năng đều hướng về giảm số RTT:

HTTP keep-alive & connection pooling: Tái dùng kết nối TCP đã thiết lập — trả chi phí handshake 1 lần rồi dùng lại nhiều request. Không tạo kết nối mới cho từng request → tiết kiệm 1-2 RTT mỗi request. Xem bài HTTP keep-alive.

TLS session resumption & 0-RTT: TLS 1.3 hỗ trợ 0-RTT resumption: client gửi kèm dữ liệu ứng dụng ngay trong gói đầu tiên khi kết nối lại (không cần handshake đầy đủ). Tiết kiệm 1 RTT TLS cho subsequent connections.

HTTP/2 multiplexing: Gửi nhiều request song song qua một kết nối TCP/TLS duy nhất — tránh tạo nhiều kết nối mới (mỗi kết nối mới = 2-3 RTT setup). Xem bài HTTP/2 và HTTP/3.

CDN (Content Delivery Network): Đặt content gần người dùng hơn về mặt địa lý → RTT từ 200ms xuống còn 10-20ms. Giảm RTT vật lý là cách duy nhất vượt qua sàn tốc độ ánh sáng. CDN không tăng bandwidth của bạn — nó giảm khoảng cách.

flowchart LR
    subgraph Before["Khong co CDN — RTT 200ms"]
      U1["User VN"] -->|"200ms RTT"| S1["Server US"]
    end
    subgraph After["Co CDN — RTT 15ms"]
      U2["User VN"] -->|"15ms RTT"| C["CDN Edge SG"]
      C -->|"200ms (cached)"| S2["Origin US"]
    end

DNS prefetch & preconnect: Thực hiện DNS lookup và TCP/TLS handshake trước khi cần — "trả phí" RTT trong lúc idle thay vì trên critical path.

7. Pitfall — tối ưu sai metric

❌ Nhầm 1: Tăng bandwidth khi nút thắt là latency ✅ Nếu người dùng phàn nàn trang chậm, trước tiên đo curl -w "%{time_total}\n" và break down từng chặng (DNS, TCP connect, TLS, TTFB). Nếu TTFB lớn (Time To First Byte = latency), tăng bandwidth không giúp gì. Cần CDN, giảm số request, hoặc tối ưu phía server trả response.

❌ Nhầm 2: Thêm server xử lý khi nghẽn ở mạng ✅ Thêm server app giúp khi CPU/memory của server là bottleneck (throughput xử lý thấp). Nhưng nếu vấn đề là người dùng ở xa server (latency cao) — thêm bao nhiêu server ở cùng một data center cũng không giúp. Cần CDN hoặc multi-region deployment.

❌ Nhầm 3: Nhầm lẫn bandwidth với throughput ✅ Nhà mạng quảng cáo "100 Mbps" là bandwidth tối đa lý thuyết (capacity của đường truyền). Throughput thực tế thường thấp hơn do overhead protocol (header TCP/IP ~5%), mất gói buộc TCP giảm tốc (congestion control), và chia sẻ với traffic khác. Speedtest đo throughput thực tế — con số luôn thấp hơn bandwidth danh nghĩa.

❌ Nhầm 4: Ping thấp = app sẽ nhanh ✅ ping đo RTT của ICMP packet cỡ 64 byte — không chịu TCP slow start, không có TLS overhead, không có HTTP parsing. App thực có HTTP/1.1 với nhiều request nhỏ sẽ chậm hơn ping nhiều lần do RTT nhân lên qua mỗi round-trip. Metric thực tế cần đo: TTFB (Time To First Byte) và page load time.

8. Liên hệ các bài khác

• Foundations bài 01 — Điều gì xảy ra khi gõ URL: chuỗi DNS → TCP → TLS → HTTP là chuỗi RTT cộng dồn bài này mô tả — mỗi chặng thêm ít nhất 1 RTT.
• Module 1 bài 01 — TCP 3-way handshake: handshake tốn 1 RTT là lý do keep-alive và connection pool quan trọng — cơ chế bài này nhắc đến trong tối ưu.
• Module 1 bài 03 — TCP congestion control: BDP và congestion window bài này đề cập — bài 03 giải thích cơ chế slow start và CWND chi tiết.
• Module 2 bài 04 — HTTP/2 và HTTP/3: multiplexing HTTP/2 giải quyết head-of-line blocking và giảm số RTT — đây là ứng dụng trực tiếp của insight "giảm RTT" bài này.
• Bài 01 — TLS/HTTPS handshake: TLS 1.3 giảm handshake xuống 1 RTT (so với 2 RTT của TLS 1.2) — trực tiếp áp dụng nguyên tắc "giảm RTT" để tối ưu.

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

10. Tóm tắt

• Latency = thời gian 1 đơn vị đi từ A → B (ms). Throughput = lượng data/giây (Mbps). Hai thứ độc lập — đường ống to không nghĩa là nước đến nhanh hơn.
• RTT = latency khứ hồi; sàn vật lý do tốc độ ánh sáng trong cáp quang (~200.000 km/s).
• Một request HTTPS tốn 3-4 RTT nối tiếp trước byte đầu tiên: DNS + TCP handshake + TLS handshake + HTTP. Với server xa (RTT 200ms), tổng có thể vượt 600ms dù bandwidth Gbps.
• Bandwidth-Delay Product (BDP) = Bandwidth × RTT = lượng data "đang bay". TCP window phải lớn hơn BDP mới tận dụng hết băng thông — quan trọng với link xa bandwidth cao.
• Với web page (nhiều request nhỏ): nút thắt là RTT, không phải bandwidth. Tối ưu = giảm số RTT (keep-alive, multiplexing, CDN, TLS 1.3).
• Với download file lớn: nút thắt là throughput. Tối ưu = tăng bandwidth, window lớn hơn.
• CDN giảm RTT vật lý bằng cách đưa content gần người dùng — đây là đòn bẩy latency mạnh nhất.
• Pitfall thường gặp nhất: tăng bandwidth hoặc thêm server khi nút thắt thực sự là latency — đo metric đúng trước khi tối ưu.

11. Tự kiểm tra

Bài tiếp theo: Mini-challenge — dựng reverse proxy + HTTPS, debug bằng curl