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

TL;DR

Hộp Trả Lời Nhanh (Google Search Featured Snippet):

TCP và UDP khác nhau như thế nào? TCP (Transmission Control Protocol) là giao thức hướng kết nối, đảm bảo gửi dữ liệu toàn vẹn, đúng thứ tự thông qua quy trình bắt tay 3 bước (SYN $\rightarrow$ SYN-ACK $\rightarrow$ ACK). UDP (User Datagram Protocol) là giao thức phi kết nối, bắn gói tin đi ngay lập tức với độ trễ cực thấp mà không cần bắt tay hay gửi lại gói tin bị mất.

Khi nào nên dùng TCP và UDP? Dùng TCP khi mọi byte dữ liệu đều quan trọng (REST API, tải file, giao dịch ngân hàng). Dùng UDP khi tốc độ thời gian thực quan trọng hơn việc mất mát vài gói tin nhỏ (livestream video, game online nhiều người chơi, truy vấn DNS, và chuẩn HTTP/3 QUIC).

Tại sao HTTP/3 lại dùng UDP thay vì TCP? Nhằm triệt tiêu hoàn toàn vấn đề tắc nghẽn đầu hàng (Head-of-Line Blocking) của TCP, nơi một gói tin bị rơi sẽ làm đóng băng toàn bộ các luồng request khác trên cùng kết nối.

Bản Đồ Cho Người Mới Bắt Đầu: So Sánh TCP & UDP

Tiêu chí	TCP (Transmission Control Protocol)	UDP (User Datagram Protocol)
Cơ chế kết nối	Hướng kết nối (Bắt tay 3 bước SYN-ACK)	Phi kết nối (Gửi trực tiếp không chờ)
Độ tin cậy	Đảm bảo 100% (Có xác nhận ACK & gửi lại)	Không đảm bảo (Best-effort delivery)
Thứ tự gói tin	Đảm bảo tuần tự theo Sequence Number	Gói tin có thể đến lộn xộn
Tắc nghẽn đầu hàng (HoL)	Bị ảnh hưởng (Mất 1 gói là nghẽn cả luồng)	Không bị (Xử lý độc lập từng gói)
Ứng dụng tiêu biểu	HTTP/1.1, HTTP/2, SSH, FTP, REST API	DNS, DHCP, WebRTC, VoIP, HTTP/3 (QUIC)

Đ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é.”

Markdy animation

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ạ

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.

Câu Hỏi Thường Gặp Về TCP và UDP (FAQ)

1. Quá trình bắt tay 3 bước (3-Way Handshake) của TCP diễn ra như thế nào?

Bắt tay 3 bước thiết lập một kết nối song công toàn phần (full-duplex) tin cậy trước khi dữ liệu ứng dụng được phép truyền:

SYN: Client gửi gói tin đồng bộ hóa kèm số thứ tự ban đầu (ISN).
SYN-ACK: Server phản hồi xác nhận số thứ tự của client (ACK) đồng thời gửi số thứ tự của chính mình (SYN).
ACK: Client gửi gói tin xác nhận số thứ tự của server. Sau khi hoàn thành 1 vòng RTT này, luồng dữ liệu chính thức bắt đầu truyền tải.

2. Tại sao chuẩn HTTP/3 lại được xây dựng trên nền UDP (QUIC) thay vì TCP?

HTTP/2 cho phép ghép nhiều luồng request (multiplexing) trên một kết nối TCP duy nhất. Tuy nhiên, nếu chỉ 1 gói tin TCP bị mất trên đường truyền mạng, cơ chế kernel của TCP sẽ chặn đứng toàn bộ các luồng còn lại cho đến khi gói tin đó được truyền lại thành công (hiện tượng TCP Head-of-Line Blocking). HTTP/3 thay thế TCP bằng giao thức QUIC chạy trên UDP, quản lý đa luồng và khôi phục gói tin độc lập ở tầng ứng dụng, giúp việc mất một gói tin ảnh không bao giờ làm đơ quá trình dựng HTML/CSS.

3. Một ứng dụng chạy trên giao thức UDP có thể đạt độ tin cậy 100% không?

Hoàn toàn có thể. Bản thân UDP không có cơ chế tin cậy, nhưng tầng ứng dụng xây dựng trên UDP (như QUIC của Google, giao thức SCTP trong WebRTC, hoặc các game engine nhiều người chơi) có thể tự cài đặt thuật toán xác nhận chọn lọc, sửa lỗi chuyển tiếp (FEC) và sắp xếp lại thứ tự gói tin theo nhu cầu mà không phải chịu chi phí trễ của kernel OS.

4. Tại sao hệ thống phân giải tên miền (DNS) lại mặc định dùng UDP?

Một truy vấn DNS thông thường chỉ gồm một gói tin hỏi và một gói tin trả lời. Dùng UDP giúp loại bỏ hoàn toàn chi phí bắt tay 3 bước (tiết kiệm 1 RTT độ trễ). Nếu gói tin bị rớt, DNS resolver sẽ tự động gửi lại sau một khoảng thời gian chờ ngắn. Chỉ khi dữ liệu phản hồi vượt quá 512 bytes (hoặc bản ghi DNSSEC), DNS mới chuyển sang dùng TCP.

Bài Viết Kiến Trúc Hệ Thống & Mạng Liên Quan

So Sánh REST vs. GraphQL vs. gRPC: Khám phá cách gRPC tận dụng HTTP/2 binary framing và multiplexing để tối ưu hiệu năng microservices.
Load Balancer, Reverse Proxy & API Gateway: Tìm hiểu cách thức các proxy tầng L4 (TCP/UDP) và L7 (HTTP/gRPC) phân phối tải quy mô lớn.
OmniRoute: Gateway Định Tuyến AI Thông Minh: Tìm hiểu tầng middleware gateway xử lý fallback và chống nghẽn kết nối khi gọi các API AI.