TCP vs UDP Decision Framework

How It Works

The transport layer decision is the most consequential networking choice in any system design. Pick TCP for a real-time game and players experience rubber-banding from retransmission delays. Pick UDP for a financial trading API and missing a single message means an incorrect position. The right answer depends on understanding what each protocol actually does — and more importantly, what it does not.

TCP — The Reliable Stream

TCP (RFC 793) provides a bidirectional, ordered, reliable byte stream between two endpoints. The key properties:

Connection-oriented. A three-way handshake (SYN, SYN-ACK, ACK) establishes state on both ends before data flows. This adds one round trip of latency (TCP Fast Open can reduce this for returning clients).

Ordered delivery. TCP assigns a sequence number to every byte. The receiver reassembles bytes in order, regardless of the order packets arrive. If packet 3 arrives before packet 2, the receiver buffers packet 3 and waits.

Reliable delivery. Every data segment is acknowledged. If the sender does not receive an ACK within the retransmission timeout, it resends. Data is guaranteed to arrive or the connection is terminated.

Flow control. The receiver advertises a window size — the amount of data it can buffer. The sender never exceeds this, preventing the receiver from being overwhelmed.

Congestion control. Algorithms like Cubic and BBR adjust the sending rate based on network conditions. Packet loss or increased latency causes TCP to back off, preventing network congestion collapse.

# Watch TCP connection states
ss -tnp | head -20

# Monitor retransmissions (sign of network issues)
netstat -s | grep -i retransmit

# Measure TCP handshake time
curl -w "TCP handshake: %{time_connect}s\n" -o /dev/null -s https://example.com

UDP — The Raw Datagram

UDP (RFC 768) is the anti-TCP. It provides almost nothing: an 8-byte header with source port, destination port, length, and checksum. No connection. No ordering. No reliability. No flow control. No congestion control.

Each UDP datagram is independent. The sender fires and forgets. If the network drops a packet, neither side knows unless the application implements its own detection. If packets arrive out of order, the application sees them out of order.

This minimalism is a feature, not a limitation. UDP's lack of guarantees means:

• No head-of-line blocking. A lost packet does not stall subsequent packets.
• No connection setup latency. Data can flow immediately.
• No retransmission delay. The application decides whether to retry, skip, or send the latest version instead.
• Minimal overhead. 8-byte header vs TCP's 20+ bytes. No connection state in the kernel.

# Check UDP socket stats
ss -unp

# Monitor UDP errors
netstat -su
# Look for "packet receive errors" and "packets to unknown port received"

QUIC — The Modern Hybrid

QUIC (RFC 9000) runs over UDP but provides TCP-like reliability with critical improvements:

1-RTT handshake with built-in TLS 1.3. TCP requires one RTT for the handshake plus one more for TLS negotiation. QUIC combines both into a single round trip. Returning clients get 0-RTT.

Independent streams. QUIC multiplexes multiple streams over a single connection. A lost packet on stream 1 does not block streams 2, 3, or 4. This is the single biggest advantage over TCP, which treats the entire connection as one ordered byte stream.

Connection migration. QUIC connections are identified by a connection ID, not the IP:port tuple. When a mobile device switches from WiFi to cellular, the QUIC connection survives. TCP connections die and must be re-established.

Userspace implementation. QUIC runs in application space, not the kernel. This enables faster iteration and deployment but costs more CPU than kernel-optimized TCP.

The Decision Matrix

This is the practical framework. For each workload property, the table shows which protocol fits:

Property	TCP	UDP	QUIC
Every byte must arrive	Native	Application must implement	Native
Order matters	Native (but causes HOL blocking)	Application must implement	Per-stream ordering (no HOL blocking)
Low latency critical	1-RTT setup + retransmission delays	Zero setup, no retransmission	1-RTT setup (0-RTT for returning clients)
Multiple independent requests	One stream per connection (or HTTP/2 with HOL risk)	Natural (each datagram independent)	Native multiplexed streams
Mobile / network switching	Connection dies on IP change	No connection to lose	Connection ID survives IP change
Congestion fairness	Built-in (Cubic, BBR)	None — application must self-regulate	Built-in
Encrypted by default	No (requires TLS on top)	No	Yes (TLS 1.3 mandatory)
Kernel optimization	Decades of optimization, hardware offload	Minimal kernel overhead	Userspace — higher CPU cost

When to Use What

TCP: Web servers, REST APIs, database connections, file transfers, SSH, email. Any workload where correctness matters more than latency, and a single ordered stream is sufficient.

UDP: DNS queries, DHCP, real-time video/audio (via RTP), live game state updates, IoT telemetry. Any workload where latest-value-wins, dropped data is acceptable, or the application implements its own reliability.

QUIC: HTTP/3 web traffic, mobile applications, any workload that suffers from TCP's head-of-line blocking or needs connection migration. The sweet spot is high-latency, lossy networks (mobile, satellite) where TCP's retransmission behavior is painful.

SCTP: Telephony signaling (SIGTRAN), WebRTC data channels. Provides message boundaries (unlike TCP's byte stream), multi-homing (failover between network paths), and multi-streaming. Rarely used outside telecom because middleboxes (NAT, firewalls) often do not support it.

Building Reliability on Top of UDP

Many real-world systems use UDP as the transport but build selective reliability on top. This is not reinventing TCP — it is building exactly the guarantees needed, no more:

Game netcode: Player positions are sent unreliably (latest value always wins — an outdated position is useless). Game events (damage, item pickup, player death) are sent reliably with acknowledgments and retransmission. This split is impossible with TCP, which makes everything reliable.

Video streaming (RTP/SRTP): Video frames are sent over UDP via RTP. Lost frames cause brief visual artifacts but do not stall playback. Audio is more sensitive — codecs like Opus include forward error correction to reconstruct lost packets without retransmission.

QUIC itself: QUIC is literally reliability built on UDP. It implements congestion control, retransmission, and ordering — but per-stream, not per-connection.

TCP:    [Packet 1] [Packet 2 LOST] [Packet 3 waits] [Packet 2 retransmit] [Packet 3 delivered]
                                    ↑ head-of-line blocking

QUIC:   Stream A: [Pkt 1] [Pkt 2 LOST] [Pkt 2 retransmit → delivered]
        Stream B: [Pkt 1] [Pkt 2] [Pkt 3]  ← not blocked by Stream A's loss

Performance Comparison

Real-world measurements, not theory:

Metric	TCP	UDP	QUIC
Connection setup	1 RTT (+ 1 for TLS)	0 RTT	1 RTT (0-RTT for resumption)
Throughput (bulk)	Excellent (kernel offload)	Excellent (no overhead)	Good (userspace overhead)
Latency (0% loss)	Low	Lowest	Low
Latency (2% loss)	High (HOL blocking + retransmit)	Low (app skips lost data)	Medium (per-stream retransmit)
CPU cost	Low (kernel)	Lowest	Higher (userspace crypto + transport)
Memory per connection	~1-4 KB kernel state	None	~1-4 KB userspace state

The takeaway: on clean networks, TCP is hard to beat. On lossy networks with concurrent streams, QUIC wins. For fire-and-forget datagrams, nothing beats raw UDP. The decision is about the workload, not the protocol's reputation.