HTTP/3 QUIC Overhead Calculator

HTTP/3 MTU & QUIC Overhead Calculator

HTTP/3 runs over QUIC, a transport protocol layered on UDP. Its big win is that it kills transport-level head-of-line blocking. Each QUIC stream keeps its own loss-recovery state, so a dropped packet stalls only the stream it belongs to instead of freezing the whole connection, which was the persistent flaw of HTTP/2 over TCP. How much payload fits in a single UDP datagram depends on the path MTU. QUIC works that out at runtime through DPLPMTUD (Datagram Packetization Layer PMTUD), defined in RFC 8899, sending progressively larger probe packets and backing off when one is lost.

QUIC encrypts nearly the whole packet, most headers included, and HTTP/3 squeezes request and response headers with QPACK (RFC 9204). QPACK is a rework of HPACK that drops the cross-stream dependency behind HOL blocking in HTTP/2. There is also connection migration: a phone that hops from Wi-Fi to 5G holds onto the same connection ID and carries on with no new handshake. HTTP/3 was standardized in RFC 9114 (June 2022), and between them Cloudflare, Google, Meta and Akamai now push most internet traffic over h3.

Applications

Reach for this calculator when you need the per-packet overhead (QUIC long/short header plus frame headers plus the AEAD tag), the goodput ceiling at a given MTU, or a starting point for UDP buffer sizing on a load balancer. It tends to come up around low-latency video and gaming, mobile-first APIs, edge CDNs, and anything where 0-RTT resumption or a clean network handover actually changes how the service feels to use.

FAQ

What MTU should I assume for QUIC? The IETF baseline is 1200 bytes, which holds on basically any path. From there DPLPMTUD probes upward toward the Ethernet maximum of 1500. Steer clear of IP fragmentation: QUIC sets the DF bit, so an oversize packet gets dropped rather than fragmented.

Why UDP if it's "unreliable"? QUIC builds its own reliability, congestion control and ordering in userspace, sitting on top of UDP. That keeps it free to evolve without waiting on OS kernels, and it slips past TCP middleboxes that would otherwise block a protocol upgrade.

Will HTTP/3 always be faster than HTTP/2? No. On a clean, low-loss wired network the gap is small. Where it really pulls ahead is lossy mobile networks, long-haul links, and any time 0-RTT resumption lets you skip a full TLS handshake.