Computer Networks
HTTP/2 and HTTP/3
Every website loads dozens of resources: HTML, CSS, JS, images, fonts. HTTP/1.1 loaded them sequentially, HTTP/2 - in parallel, HTTP/3 does this even on unstable connections. Understanding these protocols is the key to web performance.
- **Performance:** HTTP/2 speeds up loading by 20-50%
- **Mobile networks:** HTTP/3 + QUIC are critical for unstable LTE
- **CDN:** Cloudflare, Fastly, AWS are already on HTTP/3
Предварительные знания
HTTP/2: Streams and Multiplexing
**HTTP/2** solves the HTTP/1.1 problem - head-of-line blocking. In HTTP/1.1, requests go sequentially over one connection. In HTTP/2, one TCP connection is divided into **streams** - parallel flows for independent requests.
**Stream ID:** odd - from client (1, 3, 5...), even - from server (2, 4, 6... for server push). Stream 0 - control messages (SETTINGS, PING).
What HTTP/1.1 problem does HTTP/2 solve?
HPACK: Header Compression
**HPACK** - the header compression algorithm in HTTP/2. In HTTP/1.1, headers are sent as text and repeated in every request. HPACK uses a static table, dynamic table, and Huffman coding.
**QPACK in HTTP/3:** HPACK works on top of ordered TCP. In QUIC (UDP), order is not guaranteed. QPACK is an adaptation of HPACK for HTTP/3 that handles out-of-order delivery.
How does HPACK compress repeated headers?
Server Push
**Server Push** allows a server to send resources before the client requests them. The server knows: HTML needs CSS and JS - and sends them immediately. Saves a round-trip. In practice, rarely used due to cache management complexity.
**Why Server Push didn't take off:** 1) Hard to know what's already in the browser's cache - can push unnecessary data. 2) 103 Early Hints solves the same problem more simply. 3) Chrome removed Server Push support in 2022. Use `<link rel="preload">` instead of push.
Why is Server Push rarely used?
QUIC: Transport for HTTP/3
**QUIC** - a transport protocol from Google, running over UDP. Includes encryption (TLS 1.3), multiplexing, congestion control. Solves TCP's problem: losing one packet doesn't block all streams.
**Why UDP?** TCP is implemented in the OS kernel - updating it on billions of devices is impossible. QUIC runs in userspace on top of UDP. It can be updated with the browser/server, without touching the OS.
Why does QUIC run on UDP instead of TCP?
HTTP/3
**HTTP/3** = HTTP semantics over QUIC. Same methods, headers, status codes. The difference: QUIC is used instead of TCP+TLS. Header compression via **QPACK** (an adaptation of HPACK for unordered delivery).
**Adoption:** ~30% of web traffic is already HTTP/3 (2024). Cloudflare, Google, Facebook enabled it by default. Browsers support it. The bottleneck - servers and middleboxes that block UDP:443.
HTTP/3 is always faster than HTTP/2
HTTP/3 is faster with packet loss and on mobile networks; on stable networks the difference is minimal
The main advantage is eliminating HOL blocking and fast handshake. On stable connections without loss, TCP works great. HTTP/3 shines on unstable mobile networks with frequent losses.
How does the browser know the server supports HTTP/3?
Key Ideas
- **HTTP/2:** streams + multiplexing + HPACK (header compression)
- **QUIC:** UDP + TLS 1.3 + streams without HOL blocking
- **HTTP/3:** HTTP over QUIC; 1-RTT handshake, 0-RTT for reconnects
- **Alt-Svc:** header for announcing HTTP/3 support
Related Topics
HTTP evolution is linked to other technologies:
Вопросы для размышления
- Why does HTTP/2 over TCP still have HOL blocking?
- How does Connection Migration in QUIC help mobile apps?
- Why is a fallback to HTTP/2 needed when HTTP/3 exists?