TCP and UDP are both transport layer protocols — they move data between applications. The key difference: TCP guarantees delivery (reliable but slower). UDP doesn’t guarantee anything (fast but lossy). Choosing between them is all about the tradeoff.
Side-by-Side Comparison
TCP Three-Way Handshake
Before any data flows over TCP, the client and server do a handshake to establish the connection. Think of it as a “are you there?” check.
Client → Server: SYN "Hey, I want to connect"
Server → Client: SYN-ACK "Got it, I'm ready too"
Client → Server: ACK "Great, let's go"
After these 3 packets, the connection is open and data starts flowing. This is why TCP has more latency than UDP — we pay an upfront cost before any real data moves.
To close the connection, there’s a four-way teardown (FIN → ACK → FIN → ACK).
How TCP Ensures Reliability
TCP does a lot of work behind the scenes:
- Sequence numbers — every byte gets a number so the receiver can reorder packets
- Acknowledgments (ACK) — the receiver confirms what it got
- Retransmission — if an ACK doesn’t come back in time, TCP resends the data
- Flow control — the receiver tells the sender “slow down, I’m full” using a window size
- Congestion control — TCP detects network congestion and backs off automatically
UDP — The “Fire and Forget” Protocol
UDP just wraps data in a thin header and sends it. No handshake, no acknowledgment, no ordering.
The UDP header is only 8 bytes (vs TCP’s 20+ bytes). That’s why it’s faster — less overhead per packet.
Source Port | Destination Port | Length | Checksum | Data
That’s it. No sequence numbers, no flow control, no nothing.
When to Use Which
| Use Case | Protocol | Why |
|---|---|---|
| Web browsing (HTTP/HTTPS) | TCP | Need reliable, ordered delivery |
| Database connections | TCP | Can’t afford to lose queries |
| Email (SMTP) | TCP | Messages must arrive complete |
| SSH | TCP | Every keystroke must arrive |
| Video streaming | UDP | A dropped frame is fine, lag is not |
| Online gaming | UDP | Speed > perfect delivery |
| DNS queries | UDP | Small, fast, one-shot queries |
| Voice calls (VoIP) | UDP | Real-time, slight loss is OK |
| IoT sensors | UDP | Lightweight, frequent updates |
The rule of thumb: if losing a packet would break things (web, email, files), use TCP. If speed matters more than perfection (video, gaming, real-time), use UDP.
Ports
Both TCP and UDP use ports to route traffic to the right application. A port is just a number from 0 to 65535.
# Common well-known ports
22 → SSH (TCP)
53 → DNS (UDP/TCP)
80 → HTTP (TCP)
443 → HTTPS (TCP)
3306 → MySQL (TCP)
5432 → PostgreSQL (TCP)
6379 → Redis (TCP)
Ports 0-1023 are well-known ports (need root to bind). Ports 1024-49151 are registered ports. Ports 49152-65535 are ephemeral (assigned dynamically to clients).
# Check what's listening on which ports
ss -tlnp # TCP listeners with process names
ss -ulnp # UDP listeners with process names
HTTP/3 and QUIC
Here’s a fun fact: HTTP/3 runs over QUIC, which is built on UDP (not TCP). QUIC adds its own reliability and encryption on top of UDP, getting the speed benefits of UDP while still being reliable. It’s like building a better TCP from scratch using UDP as the foundation.
In simple language, TCP is the careful, reliable friend who double-checks everything. UDP is the fast friend who sends stuff and hopes for the best. We pick based on whether we need reliability or speed.