HTTP/1.1 to HTTP/3 - System Design Guide

Overview

HTTP has evolved to cut latency. HTTP/1.1 (1997) sends one request at a time per TCP connection, so browsers open about six connections per host. HTTP/2 (2015) multiplexes many requests as streams over one connection, compresses headers, and uses a binary format. HTTP/3 (2022) runs over QUIC on UDP, eliminating TCP head-of-line blocking and combining transport and TLS handshakes.

The semantics (methods, status codes, headers) stay the same across versions; only the wire format and transport change. This means you usually get the benefits by upgrading the load balancer or CDN, not your application code.

Checkout lanes

HTTP/1.1 is a single checkout lane per customer: you wait for each item to be scanned. HTTP/2 lets one cashier scan items from many baskets interleaved, but if the conveyor belt jams (packet loss), everyone waits. HTTP/3 gives each basket its own conveyor belt, so one jam affects only one basket.

When to use it

Improving page load performance with many small resources.
Mobile clients on lossy networks (HTTP/3 shines here).
Internal services that need multiplexed, streaming RPC (HTTP/2 powers gRPC).
Explaining why old optimizations like domain sharding and sprites are now harmful.

Where it shows up in interviews

Web performance

Recognize it when: a page loads hundreds of assets; reduce latency.

Optimize a media-heavy homepage
Design a CDN edge

Streaming RPC

Recognize it when: service-to-service calls with streaming.

Design an internal RPC framework
Design real-time dashboards

Where it is used in real software

CDN support

Cloudflare, Fastly, CloudFront, and Akamai serve HTTP/3 to browsers while talking HTTP/1.1 or HTTP/2 to your origin.

gRPC

gRPC relies on HTTP/2 streams and binary framing for efficient bidirectional streaming between services.

Mobile apps

Google and Meta report meaningful latency and rebuffering improvements for users on poor networks after adopting QUIC.

Key terms

Multiplexing: Many concurrent requests share one connection as interleaved streams.
HPACK / QPACK: Header compression for HTTP/2 / HTTP/3.
QUIC: UDP-based transport with streams, TLS 1.3, and connection migration.
0-RTT: Resumed connections can send data in the first packet.
Alt-Svc: Header that advertises HTTP/3 availability to clients.

What each version fixed

1
HTTP/1.0
One request per TCP connection; a new handshake for every image.
2
HTTP/1.1
Persistent connections (keep-alive), Host header, chunked transfer. Still one request at a time per connection.
3
HTTP/2
Binary framing, multiplexed streams, header compression, stream priorities. One TCP connection per origin.
4
HTTP/3
QUIC over UDP: per-stream loss recovery, 1-RTT (or 0-RTT) setup including TLS, and survives IP changes.

Loading 100 small assets at 100 ms RTT with 1% loss

Rough comparison of connection behavior

Version	Connections	Handshakes	Loss impact
HTTP/1.1	~6 per host	6 x (TCP + TLS)	Blocks one connection's queue
HTTP/2	1	1 x (TCP + TLS)	Blocks every stream on the connection
HTTP/3	1	1 combined QUIC handshake	Blocks only the affected stream

NOWVersion: HTTP/1.1 | Connections: ~6 per host | Handshakes: 6 x (TCP + TLS) | Loss impact: Blocks one connection's queue

HTTP/2 wins big on clean networks; HTTP/3 wins further on lossy mobile networks because a lost packet no longer freezes unrelated resources.

Implementation

1server {2    listen 443 ssl;3    listen 443 quic reuseport;           # HTTP/3 over UDP4    http2 on;5    server_name example.com;6 7    ssl_certificate     /etc/ssl/example.crt;8    ssl_certificate_key /etc/ssl/example.key;9    ssl_protocols TLSv1.3;10 11    # Tell browsers HTTP/3 is available on this port12    add_header Alt-Svc 'h3=":443"; ma=86400';13}

Complexity and performance

HTTP/1.1 setup2 RTT

TCP + TLS 1.3, per connection.

HTTP/3 setup1 RTT / 0-RTT

Combined transport + crypto.

Header savingsup to ~90%

Repeated headers compressed.

Trade-offs

UDP blocking

Some corporate networks block or throttle UDP; clients must fall back to HTTP/2 over TCP.

CPU cost

QUIC runs in user space and costs more CPU than kernel TCP, though this is improving.

Variants and related techniques

Server push (deprecated)

HTTP/2 push proved hard to use well; browsers removed it in favor of preload hints and 103 Early Hints.

103 Early Hints

Server sends Link headers early so the browser starts fetching CSS while the server builds the page.

Common mistakes

Domain sharding and sprite sheets under HTTP/2.
Fix: Those HTTP/1.1 workarounds now add extra connections and hurt caching; serve many small files from one origin.
Assuming app changes are required.
Fix: Upgrading usually happens at the CDN or load balancer; semantics are unchanged.

Interview questions

What problem does HTTP/2 not solve that HTTP/3 does?

TCP-level head-of-line blocking. HTTP/2 multiplexes streams, but a single lost TCP packet stalls them all; QUIC recovers loss per stream.

Why is QUIC built on UDP rather than a new protocol?

Middleboxes and operating systems across the internet only reliably pass TCP and UDP. Building on UDP allowed deployment without changing routers or kernels.

Practice problems

Problem	Difficulty	What it trains
Compare HTTP versions of 5 popular sites with curl	Easy	Adoption.
Explain why domain sharding hurts HTTP/2	Medium	Connection model.
Plan an HTTP/3 rollout with fallback and metrics	Medium	Operational trade-offs.