TCP reliability — sequence, ACK, retransmission

TL;DR: TCP hứa "dữ liệu tới đủ, đúng thứ tự, không trùng" — nhưng tầng IP bên dưới không hứa gì cả (best-effort). Để giữ lời hứa đó, TCP dùng sequence number đánh số từng byte, cumulative ACK báo "đã nhận đủ tới byte N", và retransmission khi gói mất — kích hoạt bằng timeout (RTO) hoặc 3 duplicate ACK (fast retransmit). SACK mở rộng thêm để tránh truyền lại không cần thiết. Nhưng cơ chế này có cái giá: nếu một gói mất, toàn bộ dữ liệu sau nó bị chặn lại chờ — đây là head-of-line blocking, pitfall lớn nhất của TCP và là lý do HTTP/2 vẫn có giới hạn hiệu năng mà HTTP/3 QUIC giải quyết.

Ở bài 01 bạn vừa thấy handshake đồng bộ sequence number khởi đầu (ISN) cho cả hai chiều. Giờ là lúc dùng sequence number đó: mỗi byte dữ liệu gửi đi đều mang một số thứ tự, và đầu nhận dùng số đó để phát hiện thiếu, ráp lại đúng thứ tự, và xác nhận đã nhận.

Câu hỏi cốt lõi: IP layer là best-effort — nó cố gắng chuyển gói nhưng không cam kết gì. Gói có thể mất (router tràn buffer, link hỏng), đến sai thứ tự (đường đi khác nhau), hoặc trùng (gói cũ kẹt trong mạng rồi tới muộn). TCP phải phát hiện và sửa tất cả những tình huống đó — không cần sự trợ giúp từ tầng dưới.

1. Analogy — Gửi quyển sách theo từng trang riêng lẻ

Hình dung bạn cần gửi một quyển sách 500 trang cho người bạn qua bưu điện, nhưng bưu điện này đặc biệt: mỗi lần chỉ chuyển được 1 trang, có thể làm rơi, có thể giao nhầm thứ tự, và đôi khi giao trùng. Bạn giải quyết thế nào?

Bạn đánh số mỗi trang (trang 1, 2, 3...), và yêu cầu người nhận sau mỗi lô gửi xác nhận "tôi đã có đủ tới trang N". Nếu mất trang 47, người nhận nói "tôi vẫn cần từ trang 47" — bạn chỉ gửi lại từ đó. Nếu trang đến sai thứ tự, người nhận giữ lại và chờ trang thiếu. Trang trùng thì bỏ (số đã có rồi).

2. Sequence number đánh số byte, không phải gói

Sau handshake, cả hai đầu biết ISN của nhau. Mỗi byte dữ liệu gửi đi được gán một sequence number liên tục:

ISN = 1000  (ví du, sau khi handshake)

Goi 1: seq=1001, mang byte 1001-2460  (1460 byte = MSS)
Goi 2: seq=2461, mang byte 2461-3920
Goi 3: seq=3921, mang byte 3921-5380
...

Đầu nhận sau khi nhận gói 1, gửi lại:

ACK: ack=2461  -- "toi nhan du toi byte 2460, muon nhan byte 2461 tiep theo"

Đây là cumulative ACK: một số ACK xác nhận tất cả byte từ ISN tới số đó. Nếu gói 2 đến muộn (mạng định tuyến lại), đầu nhận vẫn giữ nguyên ack=2461 — không tăng lên 3921, vì có "lỗ hổng" ở giữa.

3. Mất gói và cơ chế retransmission

Khi một gói mất, đầu nhận không nhận được byte đó nên ACK không tăng lên. Đầu gửi có hai cách phát hiện:

sequenceDiagram
    participant S as Sender
    participant R as Receiver
    S->>R: seq=1001 (byte 1001-2460)
    R-->>S: ack=2461
    S->>R: seq=2461 (byte 2461-3920) -- MAT GOI
    S->>R: seq=3921 (byte 3921-5380)
    S->>R: seq=5381 (byte 5381-6840)
    Note over R: nhan 3921 va 5381<br/>nhung thieu 2461
    R-->>S: ack=2461 (duplicate ACK #1)
    R-->>S: ack=2461 (duplicate ACK #2)
    R-->>S: ack=2461 (duplicate ACK #3)
    Note over S: 3 duplicate ACK -> fast retransmit
    S->>R: seq=2461 (truyen lai)
    R-->>S: ack=6841 (xac nhan ca lo du lieu da buffer)

Cách 1 — RTO (Retransmission Timeout)

Khi gửi một segment, đầu gửi khởi động một bộ đếm RTO (Retransmission Timeout). Nếu hết thời gian mà chưa nhận ACK, segment được truyền lại. RTO không phải số cố định — nó được đo động dựa trên RTT (Round-Trip Time) thực tế của kết nối:

• SRTT (Smoothed RTT) — RTT trung bình có trọng số (exponential moving average).
• RTTVAR — variance của RTT.
• RTO = SRTT + 4 × RTTVAR (công thức Jacobson/Karels, RFC 6298).

Khi RTO xảy ra, đầu gửi truyền lại và tăng gấp đôi RTO (exponential backoff) để tránh spam mạng đang nghẽn.

Cách 2 — Fast retransmit (3 duplicate ACK)

RTO chậm: phải đợi timer hết. Nếu đầu nhận tiếp tục nhận các gói sau gói mất, nó gửi lại ACK cũ (duplicate ACK) mỗi lần — vì ACK cumulative, nó không thể tăng ACK khi còn lỗ hổng.

Khi đầu gửi thấy 3 duplicate ACK liên tiếp, nó kết luận gói đó đã mất và truyền lại ngay lập tức, không đợi RTO. Đây là fast retransmit — nhanh hơn đáng kể vì không tốn cả RTT đợi timer.

4. SACK — Selective Acknowledgment

Cumulative ACK có một hạn chế: đầu gửi chỉ biết "đầu nhận thiếu từ byte N trở đi", không biết đầu nhận đã có gì ở phía sau lỗ hổng. Kết quả: sau khi truyền lại gói mất, đầu gửi không chắc có cần truyền lại các gói sau đó không.

SACK (Selective ACK, RFC 2018) giải quyết bằng cách cho phép đầu nhận báo cáo chính xác những block byte nào đã nhận được, dù còn lỗ hổng:

ACK: ack=2461, SACK=[3921-6841]
-- "toi muon byte 2461, nhung toi DA CO byte 3921 toi 6841"

Đầu gửi biết chính xác cần truyền lại mỗi mình 2461-3920 — không phải toàn bộ từ 2461 trở đi. SACK là TCP option thương lượng trong handshake; hầu hết OS hiện đại bật mặc định.

# Kiem tra SACK co bat khong (Linux):
sysctl net.ipv4.tcp_sack
# Output: net.ipv4.tcp_sack = 1  (da bat)

5. Head-of-line blocking — khi đảm bảo tin cậy trở thành gánh nặng

Đây là pitfall quan trọng nhất của TCP và là thứ bạn sẽ gặp ngay khi học HTTP/2.

Giả sử bạn tải đồng thời 3 resource qua một kết nối TCP (đây chính xác là cách HTTP/2 multiplexing hoạt động — nhiều stream trong 1 kết nối):

Stream A: byte 1-5000   (CSS file)
Stream B: byte 5001-10000 (JS file)
Stream C: byte 10001-15000 (image)

Nếu gói ở byte 3001-4460 (giữa Stream A) bị mất:

• Đầu nhận nhận được Stream B và C hoàn chỉnh — nhưng không thể deliver chúng lên application.
• Tại sao? Vì TCP deliver dữ liệu theo thứ tự byte liên tục. Có lỗ hổng ở byte 3001 → toàn bộ dữ liệu sau đó bị giữ trong receive buffer, chờ retransmit.
• Stream B và C, dù đã có đủ, cũng bị chặn bởi một gói mất trong Stream A. Đây là head-of-line (HOL) blocking.

HTTP/2 multiplexing cải thiện nhiều vấn đề của HTTP/1.1 nhưng không giải quyết được HOL blocking ở tầng TCP — vì đó là cơ chế của giao thức vận chuyển, không phải tầng ứng dụng. HTTP/3 giải quyết bằng cách chạy trên QUIC (UDP-based), nơi mỗi stream độc lập và mất gói ở stream này không chặn stream khác. Bạn sẽ gặp lại HOL blocking ở module 2 khi học HTTP/2 và HTTP/3.

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

❌ Nhầm 1: "ACK xác nhận từng gói riêng lẻ." ✅ ACK là cumulative — một số ACK xác nhận tất cả byte từ đầu đến số đó. ack=5000 nghĩa là "tôi đã nhận đủ mọi thứ tới byte 4999, muốn byte 5000 tiếp theo". Nếu gói 2 mất nhưng gói 3 và 4 đến, ACK vẫn là số cũ cho tới khi gói 2 được truyền lại và lấp đầy lỗ hổng.

❌ Nhầm 2: "Mất gói là do đường truyền chất lượng kém." ✅ Ở mạng hiện đại, mất gói thường là do router tràn buffer (congestion), không phải lỗi vật lý. Đây là tín hiệu để TCP giảm tốc — và là nền tảng của congestion control mà bài 03 sẽ giải thích.

❌ Nhầm 3: "SACK thay thế hoàn toàn cumulative ACK." ✅ SACK là phần bổ sung, không phải thay thế. Trường ack vẫn dùng cumulative ACK báo "tôi muốn byte N tiếp theo". SACK blocks trong TCP option thêm thông tin về các vùng đã có — giúp đầu gửi tối ưu retransmit, nhưng không thay đổi nghĩa của trường ack.

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

• Bài 01 — 3-way handshake: handshake đồng bộ ISN cho cả hai chiều — sequence number trong bài này bắt đầu từ đó. HOL blocking là lý do trực tiếp khiến connection pool quan trọng.
• Bài 03 — Flow & congestion control: sau khi biết TCP retransmit khi mất gói, bài tiếp giải thích TCP phản ứng thế nào để không làm nghẽn mạng — slow start, congestion avoidance, và thuật toán hiện đại BBR.
• Bài 06 — Connection pooling & keep-alive: HOL blocking là một lý do HTTP/2 dùng nhiều connection TCP song song thay vì một — pool giúp quản lý điều này.
• Module 2 — HTTP/2 & HTTP/3: HOL blocking ở tầng TCP là chính xác lý do HTTP/3 chuyển sang QUIC (UDP). Bài này đặt nền khái niệm cho bài đó.

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

9. Tóm tắt

• Tầng IP là best-effort — gói có thể mất, đảo thứ tự, hoặc trùng. TCP xây đảm bảo tin cậy lên trên bằng cơ chế riêng.
• Sequence number đánh số từng byte liên tục (không phải gói). Mỗi gói TCP mang seq = số byte đầu tiên nó chứa.
• Cumulative ACK: ack=N nghĩa là "đã nhận đủ mọi byte trước N, muốn byte N tiếp theo". Có lỗ hổng → ACK không tăng.
• RTO kích hoạt retransmit sau timeout (tính từ RTT đo được); fast retransmit kích hoạt ngay sau 3 duplicate ACK, nhanh hơn nhiều.
• SACK (RFC 2018) cho phép báo cáo chính xác các block đã nhận, giúp đầu gửi chỉ truyền lại đúng phần thiếu.
• Head-of-line blocking: một gói mất chặn toàn bộ dữ liệu sau nó trong receive buffer — kể cả dữ liệu của stream khác đã nhận đủ.
• HOL blocking là giới hạn cơ bản của TCP; HTTP/3 QUIC giải quyết bằng cách xử lý từng stream độc lập ở tầng transport.

10. Tự kiểm tra

Bài tiếp theo: Flow control & congestion control — vì sao download tăng tốc dần