HTTP/3 and QUIC: Transport Layer Revolution

HTTP/3 is the same HTTP semantics layered on a different transport. The interesting story is that transport: QUIC is a UDP-based, user-space protocol with TLS 1.3 bolted directly into the handshake, per-stream loss recovery so a dropped packet on one request stops only that request, and connection identifiers that survive a network change. This article walks the mechanism end-to-end: why TCP’s design forced the change, how QUIC’s encryption levels work, what 0-RTT actually costs you, how QPACK avoids re-introducing head-of-line blocking, and how browsers discover h3 in production.

Mental model

The smallest set of facts that lets the rest of the article click:

• QUIC = UDP datagrams + TLS 1.3 + per-stream byte streams. The transport runs in user space, the TLS handshake is folded into the QUIC handshake, and every stream has its own retransmission state.
• Stream independence. Loss on stream A does not stop streams B and C. This is the property HTTP/2-over-TCP cannot provide because TCP delivers a single ordered byte stream to the socket consumer.¹
• Connection IDs, not 4-tuples. A QUIC connection is identified by short opaque IDs the endpoints chose, so a client can switch from WiFi to cellular and keep the same encrypted session.²
• Encryption is the API contract. Header bits, packet numbers, and frames are all encrypted. Only the long-header version field, the connection IDs, and the packet-type bits are visible to middleboxes — and they’re designed to be unreliable so middleboxes don’t ossify on them.³
• 1-RTT new connections, 0-RTT resumption. TLS 1.3’s handshake messages travel inside QUIC’s own handshake, cutting setup to one round trip; resumption can ship request bytes alongside the ClientHello at the cost of replay risk.⁴

Why QUIC exists: TCP’s structural limits

Three constraints made QUIC inevitable. Each is fixable in isolation; together they argued for a clean transport.

TCP-level head-of-line blocking

HTTP/2 multiplexes many request streams onto one TCP connection. TCP only knows about a single ordered byte stream. When a segment carrying part of stream A is lost, the kernel will not deliver any later bytes — including bytes belonging to streams B and C — until A’s gap is filled.

The practical effect is that as packet loss climbs, HTTP/2 over a single TCP connection can fall behind HTTP/1.1 with multiple parallel connections, because in the HTTP/1.1 case loss on one connection does not stall the others. Salesforce’s measurements walk through the regimes where each one wins.¹

QUIC fixes this by giving each stream its own retransmission state and reassembly buffer. Loss on stream A is recovered by retransmitting on stream A; streams B and C continue to advance at the application layer.

TCP ossification

TCP succeeded so completely that middleboxes — firewalls, NATs, load balancers, carrier-grade NATs — make routing and policy decisions based on specific values in TCP headers. New TCP options or unfamiliar header layouts get dropped, blackholed, or rewritten.

The canonical example is TCP Fast Open (RFC 7413): it lets a client ship payload alongside the SYN, in principle saving an RTT. In practice, measurements found that a meaningful fraction of paths drop SYNs that carry data or unknown options, which forced clients to time out and retry without TFO.⁵

QUIC sidesteps this by living on UDP, which middleboxes have been forwarding since RFC 768 (1980), and by encrypting almost everything else.

Kernel-space ceiling

TCP lives in the kernel. Improving congestion control or loss detection means an OS upgrade and a slow ramp through device fleets. Kernel-space implementations also diverge across platforms, which makes uniform behavior at scale difficult.

QUIC ships in the application — typically inside the browser or the server binary — so a Cloudflare or Chrome team can roll out a new congestion controller, a new probing strategy, or a CVE patch on its own release cadence.⁶

QUIC architecture

Packet and frame structure

QUIC nests three units inside a single UDP datagram, defined in RFC 9000 §12 and §17–§19:

1. UDP datagram — the IP-level unit a middlebox sees. May carry one or more coalesced QUIC packets.
2. QUIC packet — has either a long header (Initial, 0-RTT, Handshake, Retry, Version Negotiation) or a short header (1-RTT). Long headers carry version + DCID + SCID; short headers carry only the DCID, since both peers already agreed on a CID set.
3. Frame — the unit of meaning inside the AEAD-encrypted payload. Every frame starts with a variable-length type byte; the rest depends on the type.

The frame zoo is small but load-bearing — most production behavior comes from a handful of types:

Two structural consequences flow from this layout:

• Frames are not packets. The transport never retransmits a packet; it retransmits the frames that were inside a lost packet, which is what makes per-stream loss recovery possible.⁷
• Datagram coalescing is allowed. A single UDP datagram may pack an Initial, a Handshake, and a 1-RTT packet so the OS only pays one syscall and one IP/UDP header overhead per send. RFC 9000 §12.2 constrains the order: Initial first, then 0-RTT, then Handshake, then 1-RTT.

Wire image and what middleboxes see

QUIC packets carry a small unencrypted prefix and a fully encrypted body. Per RFC 9001 §5 (Packet Protection), only a tiny invariant set is intelligible to anything between the endpoints.

The deliberate consequence: middleboxes cannot reliably read packet numbers, ACK frames, or stream IDs, so they cannot make policy decisions on them. The price is that load balancers and DDoS scrubbers need explicit support to read the connection ID for routing.³

Connection IDs and migration

A TCP connection is named by the 4-tuple (src IP, src port, dst IP, dst port). Any change — NAT rebinding, switching to cellular, IPv6 temporary address rotation — kills it. QUIC names connections by opaque connection IDs the endpoints chose, so the same logical connection can survive 4-tuple changes.²

When a peer first sees datagrams arrive from a new address, it does not blindly trust the new path. It runs a path validation:

1. Send a PATH_CHALLENGE containing 8 random bytes on the candidate path.
2. The peer echoes the same 8 bytes in a PATH_RESPONSE.
3. A matching response confirms the peer can both receive and transmit on that path; the round-trip also seeds RTT estimation for it.

Where migration works:

• NAT rebinding (port or external IP change behind the same client interface).
• WiFi → cellular hand-offs and the reverse.
• IPv6 temporary address expiration (RFC 8981).

Where it doesn’t:

• Server-initiated migration is not in RFC 9000.
• Zero-length CIDs make migration impossible (no demultiplexing key on the new path).
• Anycast or ECMP routing without QUIC-aware load balancing — the post-migration packets may land on a server that doesn’t hold the connection state.⁹

Streams and stream IDs

Every QUIC stream maintains its own flow control window, retransmission buffer, and ordering state. Per RFC 9000 §2.1, the low two bits of the 62-bit stream ID encode the stream’s category:

HTTP/3 then layers its own per-stream type byte on every unidirectional stream — 0x00 for the control stream, 0x02 for the QPACK encoder stream, 0x03 for the QPACK decoder stream — per RFC 9114 §6.2. RFC 9114 recommends (SHOULD, not MUST) that endpoints permit at least 100 concurrent client-initiated bidirectional streams to avoid throttling normal page loads.

TLS 1.3 inside the QUIC handshake

Why fusion matters

Traditional HTTPS pays for two handshakes in sequence: TCP’s three-way handshake, then TLS’s. QUIC carries TLS 1.3 records as CRYPTO frames inside its own packets, so the transport handshake and the cryptographic handshake share round trips.

Encryption levels

QUIC uses four encryption levels with distinct keys, defined in RFC 9001 §4:

1. Initial. Keys derived from the public DCID + version salt. Provides integrity for the first ClientHello / ServerHello exchange. Anyone on the path can decrypt.
2. 0-RTT. Keys derived from a Pre-Shared Key cached from a prior session. Lets the client send application data immediately on resumption — but the server cannot prove the data wasn’t replayed.
3. Handshake. Keys derived from the ECDHE shared secret established during the Initial exchange. Used to finish authenticating the server and complete the handshake.
4. 1-RTT (Application). Keys derived from the same ECDHE-rooted secret. Carries all post-handshake application data.

0-RTT: speed for replay risk

0-RTT lets a returning client ship request bytes alongside the ClientHello. The server processes them before the handshake completes. The trade-off is unavoidable and is called out plainly in RFC 9001 §9.2:

“Use of TLS early data comes with an exposure to replay attack. The use of 0-RTT in QUIC is similarly vulnerable to replay attack.”

QUIC’s own frame machinery is idempotent under replay; the replay risk is whatever the application protocol adds on top. RFC 9001 is explicit that “the responsibility for managing the risks of replay attacks with 0-RTT lies with an application protocol.” The replay attack is straightforward:

1. Client sends 0-RTT request: “transfer $100 to Alice”.
2. An on-path attacker captures the encrypted UDP datagram.
3. Attacker re-sends the same datagram to the server.
4. The server, in the absence of application-level deduplication, processes the request twice.

RFC 8470 gives HTTP a way to negotiate this: an intermediary that forwards a request received as early data adds an Early-Data: 1 header, and the origin can refuse with 425 Too Early (and a Retry-After) if the request isn’t safe to process speculatively.

Show 5 hidden lines6    if (!this.allowedMethods.includes(request.method)) {7      return { allowed: false, reason: "Non-idempotent method in 0-RTT" }8    }910    if (request.headers["early-data"] === "1") {11      // Intermediary forwarded this as early data; decide carefully.12    }1314    if (request.idempotencyKey) {15      const cached = this.replayCache.get(request.idempotencyKey)16      if (cached) return { allowed: false, reason: "Replay detected", cachedResponse: cached }17    }1819    return { allowed: true }20  }21}2223const handleEarlyData = (req, res) => {24  if (req.headers["early-data"] === "1" && !isIdempotent(req)) {Show 5 hidden lines

Production policies follow the same shape:

• Cloudflare enables 0-RTT only for GET, HEAD, and OPTIONS, and its default-on configuration restricts it further to GET requests without query parameters; everything else is forced to wait for the full handshake.^{10 11}
• Most CDNs default to disabling 0-RTT for POST/PUT/DELETE regardless of payload.
• Financial and payments APIs require an idempotency key on every state-changing request, so even if 0-RTT replays slip through they’re absorbed by the idempotency cache.

Loss detection, congestion control, and ECN

QUIC’s reliability machinery lives in RFC 9002. It borrows TCP’s vocabulary — RTT, RTO, congestion window, slow start — but the implementation is materially different in three ways.

Per-packet-number space, monotonic, encrypted ACKs

QUIC has three packet number spaces (Initial, Handshake, Application) and a single packet number is never reused inside a space. That’s a deliberate departure from TCP’s sequence-number-as-byte-offset design and it removes TCP’s classic “retransmission ambiguity”: the sender always knows whether an ACK refers to the original transmission or a retransmission, because each transmission gets a fresh, strictly increasing packet number.¹² The result is a much cleaner RTT estimator, especially under loss.

Loss detection

QUIC declares a packet lost using two complementary signals defined in RFC 9002 §6:

• Packet threshold. An unacknowledged packet is lost once a packet sent later by kPacketThreshold (3 by default) is acknowledged.
• Time threshold. An unacknowledged packet is lost once it has been outstanding longer than max(kTimeThreshold * max(SRTT, latest_rtt), kGranularity).

When the sender has nothing else to send and the loss timer has not fired, it arms a Probe Timeout (PTO) that triggers retransmission of probe packets to elicit an ACK. PTO replaces TCP’s RTO and avoids the legacy “double-on-timeout” backoff penalty for the common case.

Congestion control

QUIC does not mandate a specific algorithm; RFC 9002 §7 specifies a NewReno-style algorithm as the default, and implementations are free to swap in CUBIC, BBRv2, or research variants. Because the stack runs in user space, that swap is a library upgrade, not a kernel rebuild — Cloudflare, Google, and Meta have all shipped non-NewReno controllers in production.¹³

ECN: signalling congestion without dropping packets

Explicit Congestion Notification (RFC 3168, wired into QUIC by RFC 9000 §13.4) lets routers signal congestion by flipping two bits in the IP header instead of dropping a packet. The sender marks outgoing packets with ECT(0) or ECT(1); a congested router can rewrite those bits to CE (“Congestion Experienced”) rather than dropping; the receiver counts CE marks and feeds them back in the ECN-aware ACK frame (type 0x03).

QUIC carries three counters in every ECN-bearing ACK — ECT(0), ECT(1), and ECN-CE — per packet number space. The sender treats CE-marked acknowledgments as a congestion signal equivalent to loss, but without paying the retransmission cost.

The combination — strictly increasing packet numbers, encrypted ACKs that include CE counts, and per-path validation — is what makes ECN deployable on QUIC where it has been hard to deploy reliably on TCP for two decades.

QPACK: header compression for out-of-order delivery

Why HPACK doesn’t transplant

HTTP/2’s HPACK (RFC 7541) compresses headers by referencing a dynamic table that both peers maintain in lock-step. The dynamic table grows when an encoder inserts a new header; subsequent header blocks reference that entry by index. This works only because TCP gives the decoder a single ordered stream.

RFC 9204 §1 calls this out:

“If HPACK were used for HTTP/3, it would induce head-of-line blocking due to built-in assumptions of a total ordering across frames on all streams.”

How QPACK localizes the blocking

QPACK splits the dynamic-table updates onto two dedicated unidirectional QUIC streams:

Each header block carries a Required Insert Count — the smallest dynamic-table state the decoder needs to decode it. If the decoder hasn’t yet processed enough encoder-stream insertions to reach that count, only that one request stream blocks, not every stream sharing the connection.

Implementations tune SETTINGS_QPACK_BLOCKED_STREAMS (number of streams the decoder is willing to leave blocked) and SETTINGS_QPACK_MAX_TABLE_CAPACITY to trade compression density against blocking risk.¹⁴

Static table differences

QPACK’s larger static table reduces dynamic-table pressure for headers that are common in HTTP/3 deployments (e.g. alt-svc, early-data, content-security-policy, strict-transport-security).

Protocol discovery and negotiation

DNS HTTPS records (RFC 9460)

Discovery via DNS lets a client know an origin supports HTTP/3 before opening any connection. The HTTPS resource record (RR type 65, defined in RFC 9460) advertises ALPN, ports, IP hints, and ECH config at the apex of the zone.

1example.com. 3600 IN HTTPS 1 . alpn="h3,h2" port=4432example.com. 3600 IN HTTPS 1 . alpn="h3,h2" ipv4hint=192.0.2.1 ipv6hint=2001:db8::13example.com. 3600 IN HTTPS 1 . alpn="h3,h2" ech="..."

Why HTTPS records matter:

1. Pre-connection signal. A client knows about h3 before it spends any RTT opening TCP.
2. Apex support. Unlike CNAME, HTTPS records are valid at the zone apex.
3. ECH integration. Encrypted SNI requires the server’s ECH config to be distributed in DNS.

Alt-Svc header (fallback discovery)

When no DNS hint exists, servers advertise alternative endpoints via the Alt-Svc HTTP header (originally RFC 7838, updated by HTTP/3-aware drafts):

1HTTP/2 200 OK2Alt-Svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400

Browser protocol selection

Browsers race QUIC and TCP+TLS, prefer QUIC when both succeed within a small window, and remember failed h3 endpoints to avoid penalising the next request.

The race matters because UDP is occasionally rate-limited, blocked, or simply slow on enterprise paths. Falling back to TCP+TLS without a user-visible delay is what makes h3 deployable on the open internet.

Middlebox interference and ossification

Why UDP, not a brand-new IP protocol

QUIC runs on UDP because deploying a new IP-level protocol on today’s internet is essentially impossible.

• SCTP (RFC 4960, 2007). Designed as a better TCP, but blocked by enough middleboxes that it never reached general internet deployment.
• DCCP (RFC 4340, 2006). Same outcome.
• Unknown IP protocol numbers. Default-deny firewall behavior drops them.

UDP has been forwarded by middleboxes since 1980, so a protocol that nests inside UDP datagrams gets the deployability of UDP and supplies its own reliability, ordering, and congestion control above it.

Encryption as anti-ossification

QUIC encrypts everything that a middlebox might otherwise inspect and accidentally encode into routing or filtering rules. Header protection covers the packet number; AEAD covers the entire frame payload. The only fields that remain in the clear are the ones an endpoint needs a middlebox to read (version, CID, packet-type bits) — and even those are designed to be unreliable signals so middleboxes don’t ossify on them.³

GREASE and version negotiation

RFC 9287 — Greasing the QUIC Bit formalises a GREASE-style mechanism for the so-called “fixed bit” in the first byte of every QUIC packet. The bit was originally fixed to 1 so middleboxes could distinguish QUIC traffic from other UDP payloads; predictably, vendors started relying on the value, which is exactly the ossification QUIC was built to avoid. RFC 9287 lets endpoints negotiate the ability to send arbitrary values for that bit so middlebox vendors can no longer assume it.

RFC 9369 — QUIC Version 2 is wire-image-different from QUIC v1 only in its version number, packet-type bits, and Initial-secret salt; the protocol itself is unchanged. Its sole purpose is to keep the version-negotiation path warm, so middleboxes that ossified on v1’s exact bit patterns don’t survive into the next decade. Adoption is still small, but the existence of a second version on the wire is the deterrent that matters.

State censorship and DPI

QUIC’s wire-level encryption does not hide the SNI inside the ClientHello, and Initial-packet keys are derivable from the public DCID. A motivated censor can therefore decrypt the ClientHello and apply SNI-based filtering. The Great Firewall of China is the documented case study: SNI-based QUIC blocking has been observed since 2024-04-07, with the censor deriving Initial keys from the DCID, parsing the ClientHello, and dropping subsequent UDP packets to the same 3-tuple if the SNI matches a blocklist.¹⁶

The fix is Encrypted Client Hello (ECH), which encrypts the inner ClientHello (including the SNI) under a key distributed via the same DNS HTTPS records described above. ECH is the long-term answer; until it’s universal, “QUIC encrypts everything” overstates the privacy properties of the Initial flight.

Server support and configuration

Support matrix (2026-Q2)

nginx configuration

Show 3 hidden lines4        listen 443 quic reuseport;56        http2 on;7        http3 on;89        ssl_certificate     /etc/ssl/cert.pem;10        ssl_certificate_key /etc/ssl/key.pem;1112        add_header Alt-Svc 'h3=":443"; ma=86400';1314        ssl_early_data on;15        quic_retry on;1617        location / {18            # ... location config ...19        }20    }21}

Knobs that earn their keep:

• listen 443 quic reuseport — bind UDP/443 with SO_REUSEPORT so the kernel load-balances QUIC traffic across worker processes.
• quic_retry on — require the Retry packet address-validation token, blocking source-address spoofing that would otherwise enable amplification attacks.
• ssl_early_data on — accept 0-RTT data; only enable if the application can handle replay (see the policy section above).

CDN-fronted deployment

For most teams, fronting origin servers with a CDN that already speaks HTTP/3 is simpler than building it into the stack:

The trade-off is the usual one: the CDN absorbs the protocol surface area, but you lose visibility into origin-side connection characteristics (RTT distributions, congestion-controller behavior, migration counts).

Performance monitoring

Metrics that earn dashboard space

Sketch of an instrumentation layer

Show 8 hidden lines9  }1011  recordConnection(event) {12    const { protocol, handshakeTime, ttfb, wasResumed, usedZeroRTT } = event1314    this.increment(`protocol.${protocol}`)15    this.histogram(`handshake.${protocol}`, handshakeTime)1617    if (protocol === "h3" && wasResumed) {18      this.increment(usedZeroRTT ? "0rtt.accepted" : "0rtt.rejected")19    }2021    if (event.quicAttempted && protocol !== "h3") {22      this.increment("quic.fallback")23      this.recordFallbackReason(event.fallbackReason)24    }25  }2627  recordMigration(event) {28    this.increment(event.success ? "migration.success" : "migration.failed")29    if (!event.success) this.recordMigrationFailure(event.reason)30  }3132  getAlerts() {33    const alerts = []34    const fallbackRate = this.getRate("quic.fallback", "quic.attempted")Show 10 hidden lines

What to alert on:

• QUIC fallback rate climbing above your normal baseline → UDP/443 is being throttled or blocked somewhere on the path.
• 0-RTT rejection rate climbing → session-ticket lifetime, server clock skew, or replay-window exhaustion.
• Connection-migration failures → load balancer dropping the new path’s packets because it doesn’t know how to route the migrated CID.

When HTTP/3 actually pays off

HTTP/3 is not strictly faster than HTTP/2; it’s less likely to be slow. The handshake savings show up in TTFB everywhere, but the per-stream loss recovery only matters when you have loss, and the migration story only matters when networks change.

Implementation priorities

The order that maximises value per unit of effort:

1. Get to TLS 1.3 on every endpoint — pure latency win, no new failure modes.
2. Publish DNS HTTPS records so clients learn h3 support before opening a connection.
3. Front origin servers with a CDN that already speaks HTTP/3.
4. Instrument fallback rate, 0-RTT acceptance, and migration success so regressions are visible.
5. Write down a 0-RTT policy that says exactly which methods are allowed and how non-idempotent requests get an idempotency key.

Appendix

Prerequisites worth refreshing

• TCP three-way handshake, segments, sequence numbers, retransmission.
• TLS 1.2 vs 1.3 handshake messages and extensions (ALPN, SNI, key shares).
• HTTP/2 framing, streams, HPACK.
• DNS resolution and the difference between A/AAAA, CNAME, SVCB, and HTTPS records.

Terminology

References

Specifications:

• RFC 9000 — QUIC: A UDP-Based Multiplexed and Secure Transport
• RFC 9001 — Using TLS to Secure QUIC
• RFC 9002 — QUIC Loss Detection and Congestion Control
• RFC 9114 — HTTP/3
• RFC 9204 — QPACK
• RFC 9287 — Greasing the QUIC Bit
• RFC 9368 — Compatible Version Negotiation for QUIC
• RFC 9369 — QUIC Version 2
• RFC 9460 — Service Binding (SVCB) and HTTPS RRs
• RFC 8999 — Version-Independent Properties of QUIC
• RFC 8470 — Using Early Data in HTTP
• RFC 8446 — TLS 1.3
• RFC 7838 — HTTP Alternative Services
• RFC 3168 — The Addition of Explicit Congestion Notification (ECN) to IP

Implementation guides:

• nginx — QUIC and HTTP/3
• Cloudflare — HTTP/3
• Cloudflare — 0-RTT Connection Resumption
• Envoy — HTTP/3 overview
• HAProxy 2.6 — Experimental HTTP/3 over QUIC

Analysis and measurement:

• Salesforce Engineering — The full picture on HTTP/2 and HOL blocking
• USENIX Security 2025 — Exposing and Circumventing SNI-based QUIC Censorship of the Great Firewall of China
• arXiv 2310.02599 — Does It Spin? On the Adoption and Use of QUIC’s Spin Bit
• Paasch et al., CoNEXT 2015 — TCP Fast Open: initial measurements
• HTTP Toolkit — HTTP/3 is everywhere but nowhere