TCP vs. UDP: Mô hình tư duy 'Thư bảo đảm'

Đi phỏng vấn mà hỏi Networking thì kiểu gì cũng có câu: “Mày phân biệt TCP và UDP xem nào?”

Câu trả lời sách giáo khoa: “TCP tin cậy; UDP không tin cậy.”

Câu trả lời Senior: “TCP lịch sự nhưng lề mề; UDP thô lỗ nhưng nhanh gọn. Và trớ trêu thay, cả thế giới web đang quay về dùng UDP (HTTP/3) để sửa chữa sự lịch sự thái quá của TCP.”

Đây là Hướng dẫn chuyên sâu về Giao thức vận chuyển.

Phần 1: Nền tảng (Mô hình tư duy)

TCP = Thư Bảo Đảm (Chuyển phát nhanh có ký nhận)

Hãy nghĩ về TCP (Transmission Control Protocol) như việc gửi hợp đồng quan trọng qua FedEx (yêu cầu chữ ký).

Hướng kết nối (Connection Oriented): Bạn phải gọi điện trước xem người ta có nhà không.
Tin cậy: Nếu xe tải gặp tai nạn, FedEx gửi xe khác. Bạn chắc chắn sẽ nhận được thư, dù sớm hay muộn.
Thứ tự (Ordered): Trang 1 luôn luôn đến trước Trang 2.
Nặng nề: Mấy thủ tục ký nhận này tốn thời gian.

UDP = Hét to giữa đám đông

Hãy nghĩ về UDP (User Datagram Protocol) như việc bạn Hét vào mặt bạn mình trong quán bar ồn ào.

Phi kết nối (Connectionless): Cứ thế là hét lên thôi. Chẳng biết nó có đang nghe không.
Không tin cậy: Nếu ai đó đi ngang qua che mất tiếng, bạn mình sẽ nghe lọt từ. Bạn không lặp lại câu nói đó.
Không thứ tự: Có thể nó nghe thấy chữ “Bia!” trước chữ “Uống không?”.
Nhanh: Ngay lập tức. Không thủ tục lằng nhằng.

Phần 2: Điều tra (Debug như chuyên gia)

1. Bắt tay 3 bước (3-Way Handshake) của TCP

Trước khi TCP gửi dù chỉ 1 byte dữ liệu (ví dụ trang web), nó tốn thời gian để bắt tay xã giao.

SYN (Client): “Alo? Mày có đó không?”
SYN-ACK (Server): “Có, tao đây. Mày có đó không?”
ACK (Client): “Có, tao đây. Vào việc nhé.”

Cái giá: 1 RTT (Round Trip Time). Nếu server ở Mỹ, bạn ở Việt Nam, bạn vừa lãng phí 300ms cuộc đời chỉ để “Alo”.
UDP: Zero handshake. 0ms. Bụp cái gửi luôn.

2. Sự cố “Mất gói tin” (Packet Loss)

Tải file (TCP): Nếu Gói tin số 50 bị rơi dọc đường, máy tính sẽ DỪNG việc tải lại và bảo server “Gửi lại gói 50 đi!”. Cả dòng chảy bị ngưng trệ. Đây là lý do tải file thì bị Pause (đứng hình) chứ không bao giờ bị sai nội dung.
Gọi Video (UDP): Nếu gói tin chứa cái mặt bạn bị rơi, UDP kệ xác nó. Nó hiển thị luôn khung hình tiếp theo. Đây là lý do gọi Zalo/Zoom thỉnh thoảng hình bị vỡ xanh lè hoặc tiếng bị robot. Thà hiển thị hình vỡ ngay bây giờ còn hơn hiển thị hình nét căng nhưng trễ 3 giây.

Phần 3: Chẩn đoán (Head-of-Line Blocking)

Đây là điểm yếu chí mạng của TCP dẫn đến sự ra đời của HTTP/3.

Tưởng tượng một đường cao tốc 1 làn xe (Kết nối TCP). Bạn đang lái 5 cái xe chở hàng (Web request: HTML, CSS, JS, Ảnh 1, Ảnh 2).

Nếu Xe #1 (HTML) bị nổ lốp (Mất gói tin):

TCP: Tất cả xe đằng sau PHẢI DỪNG LẠI. Mặc dù xe CSS không bị sao cả, nó vẫn không được phép vượt. Đường bị tắc.
Hậu quả: Trang web quay đều quay đều.

Giải pháp: HTTP/3 (QUIC) Google nhận ra điều này quá dở. Nên họ xây dựng QUIC chạy trên nền UDP.

Nó xử lý độ tin cậy ở tầng ứng dụng (application layer), không phải tầng kernel.
Nó cho phép Xe #2 lách qua Xe #1 đang hỏng để đi tiếp.
Kết quả: UDP lại trở thành tương lai của web tin cậy.

Phần 4: Giải pháp (Dùng cái nào?)

Đừng nghĩ nhiều. Dùng cây quyết định này:

Dùng TCP Nếu:

Độ chính xác là sống còn. Mất 1 bit là file hỏng luôn.
Ví dụ: Lướt web (HTTP/1, HTTP/2), Tải file (FTP), Email (SMTP), Gọi API (REST/JSON).

Dùng UDP Nếu:

Tốc độ là sống còn. Dữ liệu đến muộn là rác rưởi.
Ví dụ: Livestream, VOIP (Skype/Zoom/Zalo), Game Online (Bắn súng CS:GO).
Tại sao: Nếu tôi bảo bạn “Địch đang ở tọa độ X:50, Y:50” mà gói tin đó bị lạc, thì việc gửi lại nó sau 200ms là vô nghĩa. Địch chạy mất rồi. Tôi cần tọa độ mới, không phải tọa độ cũ.

Mô hình tư duy chốt hạ

1
2
3
4
TCP (HTTP/REST) -> Ông Kế toán. Chậm, tỉ mỉ, đảm bảo từng xu một.
UDP (Game/Zoom) -> Bình luận viên bóng đá. Nhanh, mồm to, lỡ lời thì nói tiếp câu khác.

HTTP/3 (QUIC)   -> Thuê một ông Bình luận viên làm việc Kế toán. (Nhanh mà vẫn chuẩn).

Nếu cần từng byte chính xác: TCP. Nếu cần tương tác thời gian thực: UDP.