TCP vs UDP

Reliability vs speed tradeoffs, head-of-line blocking, QUIC protocol, and choosing the right transport for each use case.

Overview

Overview TCP and UDP are the two dominant Layer 4 protocols in the TCP/IP stack, and choosing between them is one of the most fundamental decisions in protocol design. They represent fundamentally different philosophies: TCP provides a reliable, ordered byte stream with built-in congestion control, while UDP is a lightweight datagram protocol that provides no guarantees beyond best-effort delivery.

TCP's reliability comes at a cost. The 3-way handshake adds at minimum one round-trip before data can flow. Retransmissions of lost packets introduce latency spikes. Head-of-line (HOL) blocking means a single lost packet stalls all subsequent data in a stream until the retransmission arrives. For bulk transfers, file downloads, API calls, and any use case where data integrity is required and latency is secondary, TCP is the right choice.

UDP trades reliability for speed. There is no connection establishment, no retransmission, no ordering. Each datagram is independent. This makes UDP ideal for real-time applications where stale data is worse than missing data — live video, voice calls, online gaming, DNS queries, and NTP synchronization. A late video frame is useless; better to skip it and render the next one.

QUIC, standardized in RFC 9000, is a modern transport protocol built on UDP that reimplements many of TCP's reliability features while solving TCP's most significant problems. QUIC multiplexes multiple streams over a single UDP connection, so a lost packet only stalls the stream it belongs to, not all concurrent streams. QUIC integrates TLS 1.3 natively, achieving 1-RTT connection establishment (and 0-RTT for resumed connections). It also handles connection migration — if a mobile client switches from WiFi to LTE, the QUIC connection persists because connection identity is a connection ID, not the 4-tuple.

For SRE and cloud engineers, the decision matrix goes beyond TCP vs UDP. It involves understanding which applications benefit from QUIC's improved multiplexing (HTTP/3, MASQUE), which require UDP's raw datagram semantics (gaming, media), and which are best served by TCP's proven reliability and broad firewall support.

Key concepts

Head-of-Line Blocking
A phenomenon where a single lost or delayed packet blocks all subsequent packets in a stream from being delivered to the application, even if those later packets have already arrived. TCP suffers from HOL blocking because it delivers data in strict order. HTTP/2 multiplexes streams over one TCP connection, so a single lost TCP segment stalls all HTTP/2 streams. QUIC eliminates TCP-level HOL blocking by multiplexing over UDP.
QUIC Protocol
A general-purpose transport protocol (RFC 9000) built over UDP, originally developed by Google. QUIC provides stream multiplexing without HOL blocking, integrated TLS 1.3 encryption, connection migration via connection IDs (survives IP/port changes), and 0-RTT connection resumption. It is the transport for HTTP/3. QUIC handles its own reliability, flow control, and congestion control in user space, enabling faster iteration than kernel TCP.
0-RTT Resumption
A QUIC (and TLS 1.3) feature that allows a client to send application data in the very first packet of a resumed connection, eliminating the round-trip required for connection establishment. The server provides a session ticket in a previous connection; the client uses it to reconstruct shared keys. Security caveat: 0-RTT data is vulnerable to replay attacks and should only be used for idempotent operations.
Datagram vs Stream
UDP is message-oriented: each send() produces exactly one datagram with defined boundaries, received as one unit by the peer. TCP is stream-oriented: boundaries between writes are not preserved; the OS may coalesce or split writes. Application protocols over TCP must implement their own framing (e.g., length-prefixed messages, newline delimiters).
UDP Receive Buffer Overflow
Unlike TCP, UDP has no flow control. If the receiving application cannot drain the socket buffer fast enough, incoming datagrams are silently dropped by the kernel. This is a common production issue with high-rate UDP metrics pipelines (StatsD, syslog) under load. Monitor with netstat -su or /proc/net/udp for RcvbufErrors.

When to use it

  • Deciding the transport protocol for a new service or protocol design
  • Diagnosing latency issues in streaming or real-time applications
  • Evaluating whether to migrate HTTP/1.1 or HTTP/2 services to HTTP/3 over QUIC
  • Understanding why VoIP or video conferencing uses UDP despite packet loss
  • Explaining head-of-line blocking in interview contexts for distributed systems roles

Interview questions

  • Why does HTTP/2 still suffer from head-of-line blocking if it multiplexes streams?
  • When would you choose UDP over TCP for a production service, and what reliability mechanisms would you implement?

Sign up free to read the full topic

More Networking topics

Start free on Cariara · Coding problems · System design studio