Why architecture matters here
HTTP/3 architecture matters because it solves problems TCP couldn't. Head-of-line blocking on TCP means a single lost packet stalls every HTTP/2 stream on that connection; QUIC's per-stream flow control eliminates it. Mobile networks changing IPs kill TCP connections; QUIC migrates seamlessly.
Cost is modest but real. QUIC uses more CPU than TCP (userspace TLS, no kernel offload for most stacks). Deployment complexity is higher.
Reliability under lossy networks is where HTTP/3 shines. Mobile users on flaky links see materially better tail latency.
The architecture: every feature explained
Walk the diagram top to bottom.
Client. Browser or SDK with HTTP/3 support. Falls back to HTTP/2 over TCP if not supported.
QUIC Transport. UDP-based transport implementing everything TCP did (reliability, ordering, flow control, congestion control) plus multiple independent streams.
Server. HTTP/3-capable endpoint. Often nginx (with quic module), Cloudflare edge, or purpose-built.
Streams. Each request/response pair on its own QUIC stream. Packet loss on one stream doesn't stall others.
TLS 1.3 in QUIC. Encryption is part of QUIC, not a layer above. Handshake integrates transport + crypto.
0-RTT resumption. If the client has seen this server before, it can send request data immediately, without waiting for handshake completion.
Connection migration. Client's IP changes (WiFi → cellular). QUIC connection continues via connection ID; no re-handshake.
Congestion control. Pluggable. BBR (Google) or CUBIC (traditional). Application-level runs in userspace so easier to iterate.
Middlebox challenges. Firewalls, NATs, and other middleboxes often confused by QUIC (looks like generic UDP). Adoption navigating this.
Adoption. Cloudflare, Google, Meta serve significant traffic over QUIC. Support in Chrome, Firefox, Safari; nginx, quiche, msquic servers.
End-to-end HTTP/3 request flow
Trace a request. Client resolves example.com; Cloudflare edge returns Alt-Svc header advertising HTTP/3 support on UDP port 443.
Client initiates QUIC connection: sends UDP packet with Initial CRYPTO frame + TLS 1.3 ClientHello. Server responds. Handshake completes in one round-trip.
Client sends 5 parallel HTTP/3 requests, each on its own stream. Each stream carries HEADERS + DATA frames.
Server processes concurrently, streams responses back. Client renders as they arrive.
Network packet loss: one response stream's packet drops. Other 4 streams continue unaffected. Lost packet retransmitted; that one stream stalls briefly.
User walks from WiFi to cellular. Client's IP changes. Instead of TCP RST, QUIC connection continues with new IP thanks to connection ID. First packet from new path re-validates path.
Next visit, minutes later. Client has QUIC session ticket. Sends 0-RTT request with data included. Response starts before handshake fully completes.