TCP là gì? Vai trò của TCP trong truyền tải dữ liệu tin cậy

TCP hay Transmission Control Protocol là giao thức hướng kết nối nằm ở tầng Transport, chịu trách nhiệm đảm bảo dữ liệu được truyền tải đầy đủ, đúng thứ tự và không bị lỗi giữa hai thiết bị đầu cuối.

Trong DevOps và SRE, TCP là nền tảng của hầu hết các ứng dụng quan trọng như Web Server, Database và SSH. Hiểu sâu về TCP stack giúp kỹ sư tối ưu hóa throughput, giảm latency cho các kết nối HTTP và khắc phục các sự cố mạng phức tạp như packet loss hay connection timeout.

Ví dụ: Khi bạn tải một file lớn từ S3, TCP đảm bảo các gói tin dù đi qua nhiều đường khác nhau vẫn được ghép lại đúng thứ tự và yêu cầu gửi lại các gói bị mất.

Khác với các giao thức đơn giản, TCP sử dụng cơ chế bắt tay và xác nhận nhận gói tin liên tục để duy trì độ tin cậy.

TCP cho biết điều gì?

Trạng thái của các kết nối TCP cung cấp cái nhìn sâu sắc về sức khỏe hệ thống:

Connection State: Số lượng kết nối đang ở trạng thái ESTABLISHED, TIME_WAIT hay CLOSE_WAIT phản ánh tải của server.
Network Quality: Tỷ lệ Retransmission cao cho biết mạng đang chập chờn hoặc bị nghẽn.
Throughput Capacity: Kích thước Window Size và Buffer Size quyết định tốc độ truyền tải tối đa.

Nếu monitoring cho thấy số lượng kết nối ở trạng thái SYN_RECV tăng đột biến, đó có thể là dấu hiệu của cuộc tấn công SYN Flood.

TCP khác UDP ra sao?

Hai giao thức này phục vụ các mục đích đối lập nhau:

TCP: Ưu tiên độ tin cậy. Dùng cho ứng dụng cần toàn vẹn dữ liệu như Web, Email, File Transfer, Database. Chấp nhận hy sinh tốc độ để sửa lỗi.
UDP: Ưu tiên tốc độ. Dùng cho ứng dụng chấp nhận mất gói tin nhưng cần real-time như Streaming, VoIP, DNS, Gaming.

Trong thực tế, HTTP/3 đang chuyển sang dùng QUIC trên nền UDP để khắc phục nhược điểm head-of-line blocking của TCP.

TCP 3-way Handshake và Latency

Trước khi truyền dữ liệu, TCP bắt buộc phải thiết lập kết nối qua quy trình 3 bước:

Client gửi SYN.
Server phản hồi SYN-ACK.
Client gửi ACK.

Quy trình này tốn 1 RTT hay Round Trip Time. Với các server nằm xa nhau về địa lý, việc thiết lập kết nối này tạo ra độ trễ đáng kể.

Ví dụ:

Nếu Ping giữa Client và Server là 200ms, riêng việc bắt tay TCP đã tốn 200ms trước khi byte dữ liệu đầu tiên được gửi đi.

Vấn đề TIME_WAIT và Ephemeral Ports

Khi một kết nối TCP đóng lại, nó không biến mất ngay mà chuyển sang trạng thái TIME_WAIT trong một khoảng thời gian thường là 60s để đảm bảo mọi gói tin lạc đường đều được xử lý.

Trên các hệ thống High Load có lượng request ngắn hạn lớn, server có thể bị cạn kiệt ephemeral ports do quá nhiều kết nối nằm ở TIME_WAIT.

Giải pháp thường dùng là tuning các tham số kernel như net.ipv4.tcp_tw_reuse để cho phép tái sử dụng socket an toàn.

TCP Retransmission là gì?

Đây là cơ chế tự sửa lỗi của TCP. Nếu bên gửi không nhận được ACK xác nhận từ bên nhận trong khoảng RTO, nó sẽ gửi lại gói tin đó.

Retransmission là kẻ thù của performance vì nó làm tăng latency và giảm throughput thực tế. Nguyên nhân thường do nghẽn mạng, thiết bị mạng lỗi hoặc buffer trên server bị đầy.

TCP Keepalive

Keepalive hoạt động bằng cách trao đổi các gói tin nhỏ nhằm kiểm tra trạng thái sống của kết nối. Nó giúp:

Ngăn chặn tường lửa hoặc Load Balancer cắt kết nối do idle quá lâu.
Phát hiện dead connection khi bên kia bị mất điện hoặc crash mà không kịp gửi gói tin FIN.

Checklist TCP Optimization cho Production

Đã tuning kích thước buffer tcp_rmem và tcp_wmem để phù hợp với băng thông mạng chưa?
Đã bật tcp_fastopen để giảm RTT cho các kết nối lặp lại chưa?
Đã cấu hình tcp_keepalive_time hợp lý cho các kết nối database long-lived chưa?
Có monitoring số lượng kết nối theo từng trạng thái TCP không?
Đã kiểm tra limit nf_conntrack_max để tránh drop gói tin khi connection table bị đầy chưa?

Kết luận

TCP là xương sống của internet hiện đại, đảm bảo sự tin cậy cho luồng dữ liệu.

Để vận hành hệ thống hiệu suất cao, bạn cần theo dõi sát sao chỉ số Retransmission, quản lý trạng thái TIME_WAIT để tránh cạn kiệt tài nguyên và tuning các tham số TCP stack phù hợp với đặc thù workload của ứng dụng.