TCP vs UDP — Reliability, Ordering & the Handshake

The Split

Both TCP and UDP sit on top of IP, which by itself is unreliable: packets can be dropped, duplicated, delayed, or reordered. TCP and UDP make opposite bets about what to do with that.

TCP gives you a reliable, ordered byte stream and hides packet loss from you — at the cost of latency and head-of-line blocking. UDP gives you raw datagrams with no guarantees — and hands you the steering wheel.

Property	TCP	UDP
Connection	Yes — handshake first	No — just send
Reliability	Retransmits lost data	None — app's problem
Ordering	In-order delivery	May arrive reordered
Boundaries	Byte stream (no message frames)	Preserves datagram boundaries
Flow / congestion control	Built in	None
Header size	20+ bytes	8 bytes
Head-of-line blocking	Yes	No

The 3-Way Handshake

TCP is connection-oriented: before any data moves, both sides synchronize sequence numbers so they can detect loss and reordering. That costs one round trip before the first byte.

sequenceDiagram participant C as Client participant S as Server C->>S: SYN (seq=x) S->>C: SYN-ACK (seq=y, ack=x+1) C->>S: ACK (ack=y+1) Note over C,S: Connection established — 1 RTT spent C->>S: data (application bytes)

SYN: client proposes its initial sequence number.
SYN-ACK: server acknowledges and proposes its own.
ACK: client acknowledges the server's. Now both sides agree on where the stream starts.

Why it matters: that RTT is pure setup latency. Over TLS it gets worse — see TLS, where the crypto handshake stacks on top. Collapsing these round trips is exactly what HTTP/3 over QUIC is built to do.

UDP has no equivalent. You call sendto() and the datagram leaves immediately — zero setup RTT.

Reliability, in Pieces

TCP's "reliability" is really four mechanisms working together:

Sequence numbers — every byte is numbered, so the receiver can reorder and dedupe.
ACKs — the receiver confirms the highest contiguous byte it has.
Retransmission — unacknowledged data is resent after a timeout (RTO) or on duplicate ACKs (fast retransmit).
Checksums — corrupt segments are discarded and retransmitted.

The cost of ordering: if segment #2 is lost, TCP will hold back #3, #4, #5 that already arrived — the application can't read them until the gap is filled. That's head-of-line blocking, and it's unavoidable in a single TCP stream. It's the core reason HTTP/2 still stalls under packet loss despite multiplexing.

Flow Control vs Congestion Control

Two different problems, often confused:

	Flow control	Congestion control
Protects	The receiver from being overrun	The network from being overrun
Mechanism	Advertised receive window (`rwnd`)	Congestion window (`cwnd`)
Signal	Receiver's buffer space	Packet loss / delay (Reno, CUBIC, BBR)

The effective send rate is bounded by min(rwnd, cwnd). Congestion control starts in slow start (exponential ramp) then switches to congestion avoidance (linear), backing off hard on loss. This is why a fresh connection is slow — cwnd has to warm up.

Sending a Datagram (UDP)

UDP's API is almost nothing — no connect, no accept, no stream. You get message boundaries for free.

import socket

# UDP: connectionless, boundary-preserving, no delivery guarantee
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.sendto(b"PING", ("10.0.0.5", 9999))   # fire and forget — may never arrive

data, addr = sock.recvfrom(1500)           # one recv == one datagram
print(data, "from", addr)

Compare TCP, where you connect first and read an undelimited stream:

import socket

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect(("10.0.0.5", 9999))    # triggers the 3-way handshake
sock.sendall(b"hello world")        # bytes, not messages
chunk = sock.recv(4096)             # may return a partial "message" — you frame it yourself

No message framing in TCP: recv() can return half a message or two messages glued together. Every TCP protocol invents its own framing — length prefixes, delimiters, or a self-describing format like protobuf on the wire.

When Each Wins

Use TCP when…	Use UDP when…
Every byte must arrive, in order (HTTP, DBs, file transfer)	Fresh data beats late data (voice, video, game state)
You want the OS to handle loss & ordering	You'll build your own reliability (QUIC, DNS, custom protocols)
Long-lived, high-throughput streams	Tiny request/response or multicast

The twist: QUIC is built on UDP precisely to escape TCP's kernel-level head-of-line blocking — then rebuilds reliability, ordering, and congestion control in user space, per-stream. UDP wasn't chosen for speed; it was chosen for a blank slate.

Key Takeaways

TCP = reliable ordered byte stream, with a setup RTT and head-of-line blocking baked in.
UDP = unreliable datagrams, message boundaries preserved, zero guarantees.
Reliability is sequence numbers + ACKs + retransmission + checksums — you either get it from TCP or build it yourself.
Flow control protects the receiver; congestion control protects the network. Both throttle you.
Modern protocols (QUIC) pick UDP to rebuild transport semantics they can control.