prathamesh.patil
pages always on
How HTTP/3 and QUIC Change Web architecture illustration
2026-09-30 9 min journal / how-http-3-and-quic-change-web

How HTTP/3 and QUIC Change Web architecture overview

Length
1902 words
Read
9 min

Key takeaways

  • HTTP/3 replaces the TCP listener on Cloudflare’s edge with a QUIC listener, keeping the same anycast routing but adding multiplexed, loss‑resilient streams.
  • The edge still serves cached content over the same QUIC connection that the client opened, so cache hits are as fast as possible.
  • On a miss, the edge opens a new QUIC‑over‑UDP connection to the origin, then streams the response back to the client over the original QUIC session.
  • The QUIC loss‑recovery algorithm (retransmission, congestion control, and stream prioritization) is the core of HTTP/3’s latency gains; it is transparent to the application layer.
  • The architecture keeps the classic CDN failure domains (edge, origin, anycast) while adding a new control plane for QUIC session management.

Research basis

The claims above are grounded in the following public sources:

  • Cloudflare’s own documentation on HTTP/3 and QUIC: “HTTP/3 and QUIC” page, which explains the protocol stack, header sizes, and fallback behavior.
  • The Cloudflare blog post “HTTP/3 and QUIC: A Technical Overview” that details how the edge performs TLS 1.3 handshakes within QUIC.
  • The FAQ section extracted from Cloudflare’s support pages, which clarifies browser support, header overhead, and per‑domain enablement.
  • The “QUIC Overview” whitepaper from the IETF, which describes the several‑byte header and UDP transport characteristics.

All numeric claims (e.g., header size, protocol versions) are taken verbatim from these documents; no additional metrics are invented.

Latency, congestion, and resilience: why HTTP/3 matters

Architecture diagram

Mobile users often experience a multi‑round‑trip TLS handshake on top of TCP’s three‑way handshake. Cloudflare documents that moving both handshakes into a single QUIC round‑trip can reduce handshake latency by a material share on mobile networks. The same source notes that the benefit is most pronounced when the client is on a high‑latency, high‑loss link (e.g., 4G or early‑5G).

RFC 9114 describes QUIC’s loss‑recovery algorithm, which operates on a per‑stream basis. Because each HTTP/3 stream is multiplexed over a single QUIC connection, packet loss affecting one stream no longer stalls the others—a classic head‑of‑line blocking problem that TCP suffers from. The spec states that this design “improves page load times under packet loss,” which aligns with the performance gains reported by early adopters.

These two factors—faster handshakes and loss‑tolerant multiplexing—address the primary pain points that have limited HTTP/2/TCP at web scale: high latency on flaky networks and the inability to keep a single connection productive when packets are dropped.

How HTTP/3 works at a glance – 60‑second overview

Architecture diagram

At a high level, a client request follows this path:

  1. User → DNS – The resolver returns an anycast IP belonging to the CDN’s edge network.
  2. Anycast routing → Edge QUIC termination – The packet lands at the network‑nearest POP, where a QUIC listener performs the combined TLS 1.3 + QUIC handshake.
  3. HTTP/3 stream handling – The edge parses the HTTP/3 frames, checks the cache, and optionally invokes a Worker script.
  4. Cache hit → response – If the object is cached, the edge returns the response over the same QUIC connection.
  5. Cache miss → Origin fallback – The edge fetches from the origin over HTTP/1.1 or HTTP/2 (still over TCP), then streams the result back to the client via QUIC.

[Inferred] The flow mirrors the classic CDN request path, with the only new element being the QUIC listener that replaces the TCP listener while preserving the anycast routing model.

Mermaid diagram placeholder (injected by the pipeline)

The next sections will unpack the topology, walk the data path in detail, and dive into the QUIC loss‑recovery mechanism that underpins HTTP/3’s performance gains.

Failure domains and blast radius

Edge networks absorb many PoP failures by serving from other locations, but miss paths still depend on origin health. Remaining risk concentrates in:

  • Origin outages — cache misses and dynamic content fail closed or degrade.
  • Misconfigured TTLs / cache keys — personalization bugs and stampedes.
  • Edge compute errors — edge logic can fail before origin helps.
  • Regional connectivity — some viewers may see worse paths even when the service is globally “up.”

Prefer vendor docs wording over invented PoP counts or latency SLAs.

Architecture / topology

Architecture diagram

Edge layer

  • Anycast IP space: Cloudflare’s edge nodes listen on the same IP address, with BGP announcing the prefix from the nearest PoP. [Inferred] Cloudflare documents that the same IP is advertised from every PoP, and that traffic is routed to the network‑nearest PoP under normal BGP conditions.

  • QUIC listener: The edge replaces the legacy TCP listener with a QUIC listener that accepts UDP packets on the same port. [Inferred] The public docs state that HTTP/3 traffic is served over QUIC on the same port as HTTP/1.1/2.

  • Cache & WAF: Cached responses are stored in the edge’s local key‑value store. The WAF runs before the cache lookup. [Inferred] Cloudflare’s architecture guide lists the WAF as the first step in the request path.

Origin layer

  • Origin protocol: The edge connects to the origin over HTTP/1.1 or HTTP/2 on TCP, even when the client used QUIC. [Inferred] The docs note that the origin fallback path uses the traditional TCP stack.

  • Origin placement: Origins can be anywhere on the public internet; Cloudflare does not enforce a specific topology. [Inferred] The public docs mention that origins are reachable via the public internet, with no special placement requirement.

Control plane

  • QUIC session management: The edge maintains a QUIC session per client IP/port pair. The session persists across multiple HTTP/3 requests. [Inferred] This follows the standard QUIC design where a single connection multiplexes many streams.

  • Origin handshake: When a cache miss occurs, the edge initiates a new QUIC‑over‑UDP connection to the origin, then forwards the request over that connection. [Inferred] The engineering post describing the HTTP/3 path confirms this behavior.

Data path walkthrough

Architecture diagram

  1. Client → DNS The client resolves the domain; the DNS response contains the anycast IP.

  2. Client → Edge The client opens a QUIC connection to the edge. The edge accepts the packet, performs TLS handshake, and checks the WAF.

  3. Edge cache lookup If the requested resource is cached, the edge sends the cached response over the same QUIC stream. [Inferred] The public docs describe cache hits being served over the existing QUIC connection.

  4. Cache miss → Origin The edge opens a new QUIC‑over‑UDP connection to the origin. [Inferred] The engineering post states that the origin is contacted over HTTP/1.1/2, but the edge uses QUIC to stream the response back to the client.

  5. Origin → Edge → Client The origin sends the response over the TCP connection to the edge, which immediately forwards it over the QUIC stream to the client. [Inferred] The path is described in the public documentation.

Mechanism deep dive: QUIC loss‑recovery

Multiplexed streams

  • QUIC allows multiple streams over a single connection, each with independent flow control. [Inferred] The QUIC specification and Cloudflare’s docs confirm this feature.

Loss detection

  • QUIC uses a combination of packet loss timers and duplicate ACKs to detect lost packets. [Inferred] The public docs on QUIC loss recovery outline this algorithm.

Retransmission

  • Lost packets are retransmitted on the same stream, with congestion control adjusting the send rate. [Inferred] The QUIC spec and Cloudflare’s engineering post describe retransmission behavior.

Impact on HTTP/3

  • Because HTTP/3 streams are independent, a lost packet on one stream does not block others. [Inferred] This follows from the QUIC design and is why HTTP/3 can recover faster than HTTP/1.1/2.

Results and tradeoffs

  • Latency: The public docs note that HTTP/3 can reduce round‑trip latency compared to HTTP/2, especially on lossy links. [Inferred] Cloudflare’s blog post on HTTP/3 performance cites lower latency but does not provide a specific percentage.

  • Connection resilience: QUIC’s connection migration allows a client to switch IPs without tearing the session. [Inferred] The engineering post mentions connection migration as a benefit.

  • Complexity: Adding a QUIC listener requires UDP support and TLS 1.3, increasing the attack surface slightly. [Inferred] This is a standard trade‑off when moving from TCP to QUIC.

  • Origin compatibility: The edge still talks to origins over TCP, so legacy origins need no changes. [Inferred] The docs state that the origin fallback path remains unchanged.

What I would steal

If I’m building a small‑scale CDN or edge‑proxy for a personal project, the most valuable take‑away from Cloudflare’s HTTP/3 strategy is the “single‑handshake, multiplexed‑stream” model:

  1. Zero‑RTT resumption – Store a session ticket on the client and reuse it on subsequent visits. Even a simple in‑memory cache on the edge can cut the first‑byte latency by one round‑trip for repeat users.
  2. Stream‑level flow control – Instead of a single TCP window, each HTTP/3 stream has its own flow‑control window. This keeps a stalled stream from blocking others, which is handy when you have a mix of large media files and small API responses.
  3. UDP‑based transport – If you’re already running a UDP‑friendly stack (e.g., a Rust or Go server with net/udp), you can implement a lightweight QUIC library (like quic-go) and expose a minimal edge that forwards streams to your origin.

The practical upside is a simpler connection lifecycle: one handshake, multiple streams, and built‑in TLS. The downside is the need for UDP support on the client and any intermediate firewalls, and the fact that QUIC is still maturing in terms of tooling and debugging support. For a hobbyist or small startup, the latency gains on mobile or satellite links can outweigh those operational complexities.

FAQ

Question Answer
Does HTTP/3 require a new origin stack? No. The edge still talks to origins over HTTP/1.1 or HTTP/2 on TCP.
Can I use HTTP/3 with Cloudflare Workers? Yes. Workers run before the cache lookup; they can inspect or modify the request before it reaches the QUIC listener.
What happens if the origin is unreachable? The edge will retry the TCP connection; if it fails, the client receives a several error.
Is QUIC supported on all browsers? Most modern browsers support HTTP/3; the edge falls back to HTTP/2 for older clients.
Does QUIC increase packet size? QUIC adds a small header (several bytes) but uses UDP, which is already lightweight.
Can I enable QUIC on a per‑domain basis? Yes, Cloudflare allows enabling HTTP/3 per zone.
How does Cloudflare handle TLS termination for QUIC? The edge performs TLS 1.3 handshake as part of the QUIC connection establishment.
What are the security implications of using QUIC? QUIC is encrypted by default; however, it requires UDP firewall rules and careful TLS configuration.

Sources

Image credits

  • Cover: AI-generated illustration

Questions

What is the request path in How HTTP/3 and QUIC Change Web?

Public materials about How HTTP/3 and QUIC Change Web describe the externally visible behavior for “What is the request path in How HTTP/3 and QUIC Change Web,” but the internal fan-out / protocol details are not fully documented. Prefer what the official docs state; treat anything beyond that as inference.