TCP vs UDP

beginner tcp udp networking protocols

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 (Transmission Control Protocol)
✓ Connection-oriented (handshake first)
✓ Guaranteed delivery
✓ Ordered packets
✓ Error checking + retransmission
✓ Flow control (won't overwhelm receiver)
Think: registered mail with tracking
UDP (User Datagram Protocol)
✗ Connectionless (just send it)
✗ No delivery guarantee
✗ No ordering
✗ No retransmission
✓ Much less overhead → faster
Think: dropping postcards in a mailbox

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 CaseProtocolWhy
Web browsing (HTTP/HTTPS)TCPNeed reliable, ordered delivery
Database connectionsTCPCan’t afford to lose queries
Email (SMTP)TCPMessages must arrive complete
SSHTCPEvery keystroke must arrive
Video streamingUDPA dropped frame is fine, lag is not
Online gamingUDPSpeed > perfect delivery
DNS queriesUDPSmall, fast, one-shot queries
Voice calls (VoIP)UDPReal-time, slight loss is OK
IoT sensorsUDPLightweight, 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.