When UDP is the right choice, and how QUIC changes the picture

UDP (User Datagram Protocol), defined in RFC 768, has a header of exactly eight bytes: source port (2 bytes), destination port (2 bytes), length (2 bytes), and checksum (2 bytes). That is the entire protocol overhead.

UDP provides message-oriented delivery. Each UDP datagram is sent as a single unit and received as a single unit, or not at all. There is no connection establishment, no acknowledgement, no ordering, no retransmission, and no congestion control. The application gets a datagram delivery service and owns everything else.

This is not a weakness; it is a design decision. When an application needs the lowest possible per-message overhead, or when it can handle losses better than TCP's recovery mechanism, or when it needs to implement its own timing and ordering strategy, UDP provides the simplest possible foundation.

Common UDP use cases include DNS queries (short request-response, latency-sensitive, application can retry), VoIP (Voice over Internet Protocol) and video conferencing (packet loss is preferable to the delay of retransmission for real-time audio), online gaming (position updates become stale faster than retransmission can deliver them), and streaming media (the application manages buffering and playback timing).

QUIC, defined in RFC 9000, is a general-purpose transport protocol. It runs over UDP but adds the reliability, ordering, flow control, and congestion control that TCP provides. It also adds multiplexed streams and integrates TLS 1.3 cryptographic handshake behaviour directly into the transport handshake.

The multiplexed streams are the key difference from HTTP/2 over TCP. Each stream has independent flow control and recovery. A lost packet affects only the stream carrying that packet. Other streams in the same QUIC connection are unaffected. In TCP, all streams share a single byte stream, so any packet loss stalls everything waiting for the gap to be filled.

QUIC also supports 0-RTT (zero round-trip time) resumption for connections to servers the client has connected to before. In this mode, the client can send application data in the very first packet, before the handshake completes. TCP with TLS 1.3 requires at least one RTT for the handshake. QUIC 0-RTT removes that cost for repeat connections, at the cost of some replay protection limitations.

HTTP/3, defined in RFC 9114, is the version of HTTP designed to run over QUIC. Where HTTP/2 runs over TCP (and suffers head-of-line blocking when packets are lost), HTTP/3 runs over QUIC streams and gets stream-independent recovery.

From the application developer's perspective, HTTP/3 looks similar to HTTP/2. The same semantics apply: methods, headers, status codes, bodies. The transport difference is invisible at the HTTP level. The practical benefit is reduced latency on lossy paths and faster connection setup on repeat visits via 0-RTT.

Connection migration is another QUIC feature. A QUIC connection is identified by a connection ID, not by the 4-tuple of source IP, source port, destination IP, destination port. This means a mobile client can switch from WiFi to a cellular network without reconnecting. The connection ID stays constant even when the underlying IP address changes.