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

Предварительные знания

  • HTTPS and TLS

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:

  • TLS — HTTP/2 requires TLS; HTTP/3 includes TLS 1.3
  • TCP — TCP limitations led to the creation of QUIC
  • WebSocket — Alternative for bidirectional; works over HTTP/1.1

Вопросы для размышления

  • 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?

Связанные уроки

  • bt-07-http2-http3
HTTP/2 and HTTP/3

0

1

Sign In