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.

RFC 9312 is the operator's guide to QUIC manageability. The central change is the wire image: what a network device can infer by looking at packets. TCP exposes sequence numbers, acknowledgements, and many control behaviours. QUIC encrypts most transport control information, leaving a much smaller stable surface visible to the network.

That is intentional. It improves privacy and prevents middleboxes from freezing the protocol by depending on internal fields. The tradeoff is that traditional devices can no longer inspect the same transport details they used for troubleshooting, traffic optimisation, or policy. Operators must rely more on endpoint telemetry, flow metadata, server logs, explicit load-balancer support for QUIC connection IDs, and synthetic tests.

Connection migration also changes load-balancing assumptions. A TCP connection is tied to the 4-tuple. QUIC uses connection IDs so a client can move networks while preserving the connection. That is powerful for mobile users, but any load balancer or DDoS control that assumes the 4-tuple is the connection identity needs a QUIC-aware design.