HTTP/1.1 → HTTP/2 → HTTP/3 (QUIC)

Multiplexing, head-of-line blocking, QUIC over UDP, compression, and flattening request waterfalls — the three-generation story of what changed and why it matters on the platform's mobile traffic.

1The one model: one bottleneck fixed per generation

Every HTTP version runs the same bargain — client sends requests, server returns responses — over a transport layer. What changed across three generations is which bottleneck each version fixed, and at which layer.

Version	Year	Transport	Key fix	Remaining problem
HTTP/1.1	1997	TCP	Persistent connections, pipelining (broken in practice)	One request in flight per connection → 6 connections per origin as workaround
HTTP/2	2015	TCP	Binary framing + multiplexing → many streams on one connection	TCP head-of-line blocking: one dropped packet freezes ALL streams
HTTP/3	2022	QUIC/UDP	Per-stream reliability → lost packet only affects that stream	QUIC CPU cost; UDP firewalls; observability harder

2HTTP/1.1 — one request at a time & the workarounds

HTTP/1.1 is a text protocol over TCP. The core constraint: each connection handles one request at a time. HTTP pipelining (send multiple requests without waiting for responses) exists in the spec but is broken in practice — responses must arrive in order, so one slow response blocks everything behind it.

How browsers worked around it

Browsers open ~6 TCP connections per origin. More connections = more parallel slots. This spawned the anti-pattern of domain sharding: splitting assets across static1.cdn.com, static2.cdn.com to get 12–18 parallel connection slots. It works, but costs one DNS lookup + TCP handshake + TLS handshake per shard domain.

3HTTP/2 — binary, multiplexed, still on TCP

HTTP/2 replaced the text protocol with a binary framing layer. Requests and responses are split into frames that interleave on a single TCP connection via independent streams. This is multiplexing: one connection, many parallel in-flight requests, no HTTP-layer head-of-line blocking.

What HTTP/2 delivers

The problem HTTP/2 didn't solve: TCP head-of-line blocking

TCP guarantees ordered, reliable byte delivery. If one packet is lost, TCP waits for retransmission before delivering any subsequent bytes — even bytes from completely unrelated streams. Because HTTP/2 puts all streams on one TCP connection, a single dropped packet blocks every stream simultaneously. On a lossy mobile network (1% packet loss is common across SEA), this can make H2 worse than H1.1's parallel connections.

4HTTP/3 & QUIC — transport layer redesign

HTTP/3 (RFC 9114, 2022) solves TCP head-of-line blocking by replacing TCP entirely with QUIC — a multiplexed, encrypted transport protocol built on UDP. Each stream is tracked independently: a lost packet triggers retransmission only for that stream, while other streams keep flowing.

QPACK — header compression for out-of-order delivery

HTTP/2's HPACK required headers to be decoded in order (another form of HoL blocking at the header layer). HTTP/3 uses QPACK: the same static + dynamic table approach, but adapted so headers referencing the dynamic table can be decoded even if earlier stream frames haven't arrived yet.

5Compression: gzip vs Brotli

HTTP compression is negotiated via Accept-Encoding (client lists what it accepts) and Content-Encoding (server declares what it applied). Two algorithms dominate in 2024:

Algorithm	Ratio vs gzip	Compress speed	Decompress	Requires
gzip (level 6)	Baseline	Fast — viable for dynamic	Fast	Nothing; universal support
Brotli (level 11)	~20–26% smaller for text	~100× slower than gzip	Similar to gzip	HTTPS; all modern browsers
Brotli (level 4–5)	~10–15% smaller for text	~2–3× slower than gzip	Fast	HTTPS; viable for dynamic

The strategy

Static assets (JS, CSS, HTML): pre-compress with Brotli level 11 at build/deploy. Store the .br file alongside the original on the CDN. Serve with Content-Encoding: br to browsers that send Accept-Encoding: br. Dynamic SSR responses: gzip level 6 (good ratio, fast enough CPU); offer Brotli level 4–5 only if you have headroom. Never compress already-compressed formats — JPEG, WebP, AVIF, woff2, zip will grow, not shrink.

6Request waterfalls — and how to flatten them

A waterfall is a cascade of requests where each step must complete before the next begins. The classic LCP waterfall on a client-rendered app:

// ❌ Classic useEffect waterfall — each step adds 1+ round trips
HTML arrives
  → browser discovers JS bundle → downloads + executes
      → useEffect fires → fetch("/api/hotels")
          → response arrives → React renders hotel cards
              → hero image discovered → starts downloading
                  → LCP fires  ← 800–1200ms later on a slow link

Each arrow is a minimum of one round trip — on a 100ms RTT link (Bangkok → Singapore), that's 400ms of purely sequential waiting. The fix is not faster HTTP — it's making the steps parallel or eliminating them.

7Platform whiteboard — the Lead answer

If asked "what's your network/HTTP strategy for a global travel platform?", structure the answer in three layers:

1. Protocol: HTTP/2 is table stakes — CDN support is universal, enable it. Layer HTTP/3 at the CDN edge (Cloudflare, Akamai support it) with automatic H2 fallback via Alt-Svc. No code change on the app. H3 matters most for SEA mobile users — high packet loss + connection migration during booking flows.
2. Compression: Pre-compressed Brotli (level 11) for all static assets in the CDN deploy pipeline. gzip level 6 for dynamic SSR. Never compress images or fonts — already binary-compressed.
3. Waterfalls: Hotel search results and hotel detail data colocated with SSR — no client fetch waterfall for critical content. 103 Early Hints for CSS/fonts from the CDN layer. Parallel queries with Promise.all / RSC parallel routes. Preconnect to API and CDN origins in <head>. Edge-cached ISR pages for hotel static content (description, photos). Speculation Rules for anticipated navigations (search results → hotel detail).

8Check yourself — scenario quiz