TCP Handshake và Tối ưu hóa độ trễ

Trong lập trình mạng, TCP (Transmission Control Protocol) là "xương sống" của hầu hết các ứng dụng. Tuy nhiên, cái giá của sự tin cậy là độ trễ (latency).

Nếu không hiểu rõ cách TCP hoạt động, bạn rất dễ đánh giá sai nguyên nhân khiến hệ thống chậm: đôi khi vấn đề không nằm ở code backend mà nằm ở số lượng round-trip mà bạn bắt client phải thực hiện.

1. Quá trình bắt tay 3 bước (3-way Handshake)

Trước khi dữ liệu đầu tiên được gửi đi, Client và Server phải thực hiện:

SYN: Client gửi một yêu cầu kết nối.
SYN-ACK: Server phản hồi xác nhận.
ACK: Client xác nhận lại một lần nữa.

Quá trình này tốn mất 1.5 RTT (Round Trip Time). Nếu RTT của bạn là 100ms, bạn đã mất 150ms chỉ để "chào hỏi".

2. TCP Slow Start

TCP không gửi toàn bộ dữ liệu ngay lập tức. Nó bắt đầu với một lượng nhỏ (Congestion Window) và tăng dần nếu không thấy mất gói tin. Đây là lý do tại sao các file lớn ban đầu tải chậm và sau đó nhanh dần.

Điều này cực kỳ quan trọng khi bạn thiết kế hệ thống phân phối file, CDN hoặc streaming: kích thước gói đầu tiên, pattern truyền dữ liệu và độ ổn định của đường truyền đều ảnh hưởng đến trải nghiệm người dùng.

3. Cách tối ưu hóa trong thực tế

TCP Fast Open (TFO): Cho phép gửi dữ liệu ngay trong gói SYN đầu tiên.
Keep-Alive: Giữ kết nối mở để tránh phải bắt tay lại cho mỗi request.
QUIC / HTTP/3: Sử dụng UDP thay vì TCP để giảm số bước bắt tay và giải quyết vấn đề Head-of-line blocking.

Ngoài ra, các hệ thống phân tán hiện đại còn tối ưu:

Nagle's Algorithm: Gom nhiều gói nhỏ thành một gói lớn để giảm overhead.
Window Scaling: Cho phép cửa sổ trượt lớn hơn trên các đường truyền có băng thông cao.

4. Tại sao lập trình viên cần biết điều này?

Khi bạn viết một API, nếu client phải thực hiện quá nhiều kết nối ngắn hạn, độ trễ sẽ tăng vọt. Hiểu về tầng Transport giúp bạn thiết kế kiến trúc hệ thống hiệu quả hơn, biết khi nào dùng gRPC qua HTTP/2 thay vì REST truyền thống.

4.1 Ví dụ kiến trúc

Giả sử bạn có một frontend gọi 5 API khác nhau để render một dashboard. Nếu mỗi request tạo một kết nối TCP mới, tổng thời gian RTT sẽ đội lên rất nhiều.

Giải pháp:

Gộp nhiều request thành một API tổng hợp (backend for frontend).
Tận dụng HTTP/2 multiplexing để chia sẻ kết nối.
Dùng connection pool ở backend để giữ kết nối tới database/downstream service.

5. Những sai lầm hay gặp

Đặt timeout quá ngắn mà không hiểu latency tối thiểu của đường truyền.
Không bật keep-alive trên load balancer / reverse proxy.
Để mặc default kernel config mà không tinh chỉnh cho workload cụ thể (web realtime, batch, streaming,...).

Mạng máy tính không phải là "ma thuật", nó là một chuỗi các giao thức được tính toán kỹ lưỡng. Hiểu rõ TCP giúp bạn nói chuyện với team infra, SRE ở "cùng ngôn ngữ", và thiết kế hệ thống từ code tới hạ tầng một cách nhất quán.