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).

Those four workloads have one thing in common: each one owns its own timing, and each would rather conceal a loss than wait for a repair. The protocol described next takes the opposite decision. It puts reliability, ordering and congestion control back on top of the same eight-byte UDP header, but rebuilds them so that repairing one thing no longer stops everything else.

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.

Independent streams and 0-RTT are transport machinery. Nothing about either is specific to the web, and QUIC would work the same way carrying a file transfer or a database session. The web is simply where the machinery earns most of its keep, because a page pulls dozens of resources at once, and that is what the next protocol is for.

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.

Moving a connection's identity off the 4-tuple and into the packet is what makes that survivable for the user. It is also the moment QUIC stops being purely an endpoint concern, because every load balancer, firewall and flow record in the path was built on the assumption that the 4-tuple is the connection.

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.

The small, deliberately unstable wire image is not only a privacy decision. It is the mechanism by which QUIC keeps the right to change, and the next section is what the protocol has done with that right since it was standardised.

QUIC version 2, published as RFC 9369 in May 2023, changes almost nothing about how the protocol behaves. It uses a different version number and different salts and labels for deriving the initial keys, and that is close to the whole of it. The point is the exercise itself. A protocol that has only ever been seen in one version invites middleboxes to treat that version as the definition, and once they do, the protocol can no longer be changed without breaking them. TCP spent decades in exactly that trap. Shipping a second QUIC version early, while the installed base was still small, keeps version negotiation a thing that implementations actually exercise rather than a field nobody has ever tested.

How much of the internet has moved is a question with two honest answers, and the difference between them is the lesson. Cloudflare Radar, which measures traffic crossing Cloudflare's network, put HTTP/3 at roughly 21 to 35 percent of traffic depending on the window and the method used. W3Techs, which surveys sites rather than bytes, found about 39 percent of websites advertising HTTP/3 support. Both were read on 13 July 2026. The site survey is the higher number because a site can advertise HTTP/3 and still serve most of its bytes over TCP to clients that never take up the offer. Neither figure is wrong; a figure quoted without its source, its method and its date is.

QUIC now also carries other people's traffic. MASQUEis the IETF work that turns an HTTP connection into a proxy tunnel: RFC 9298 defines proxying UDP in HTTP, and RFC 9484 defines proxying IP the same way. Both run inside HTTP/3, so the tunnel inherits QUIC's streams, congestion control and encryption instead of reinventing them. This is the machinery under relay products such as iCloud Private Relay, where the design goal is that no single hop knows both who the user is and where the user is going. For a network team, the practical consequence is that a growing share of traffic is UDP 443 to a proxy rather than to the site the user is actually reading.

One thing is not here yet. Multipath QUIC, which would let a single connection use several network paths at once rather than migrating between them, is still an Internet-Draft (draft-ietf-quic-multipath). It has not been published as a standard, so any claim that it is standardised is a citation error, and any product claiming to implement it is implementing a document that can still change.