What changed between HTTP/1.1, HTTP/2 and HTTP/3?
Show the answer
Say this first
HTTP/1.1 is text over TCP with persistent connections, but one request at a time per connection, so browsers open about six connections per host. HTTP/2 keeps TCP but switches to binary frames and multiplexes many streams over one connection, with HPACK header compression; one lost TCP segment still stalls every stream. HTTP/3 runs over QUIC on UDP 443, with streams that are independent at the transport layer, TLS 1.3 built in and QPACK compression.
Go deeper
Side by side
| HTTP/1.1 | HTTP/2 | HTTP/3 | |
|---|---|---|---|
| Transport | TCP | TCP | QUIC over UDP |
| Format | Text | Binary frames | Binary frames |
| Requests per connection | One at a time (pipelining unused) | Many concurrent streams | Many concurrent streams |
| Header compression | None | HPACK | QPACK |
| Encryption | Optional (HTTPS) | Browsers require TLS | Always TLS 1.3 |
| Lost packet blocks | That connection | All streams on the connection | Only the affected stream |
| Setup round trips with TLS 1.3 | 2 (TCP + TLS) | 2 (TCP + TLS) | 1, or 0 on resumption |
How the client chooses
- HTTP/2: ALPN in the TLS handshake. The client offers
h2,http/1.1and the server picks. - HTTP/3: the server advertises it, either with an
Alt-Svc: h3=":443"response header or a DNS HTTPS record. The browser then tries QUIC and falls back to TCP if UDP 443 is blocked.
RFCs
HTTP semantics RFC 9110, HTTP/1.1 RFC 9112, HTTP/2 RFC 9113 (originally 7540), HTTP/3 RFC 9114, QUIC RFC 9000.
They will ask next
Is HTTP/2 always faster than HTTP/1.1?
Not on lossy links. Six HTTP/1.1 connections lose only one connection's progress on a drop, and six congestion windows recover separately. HTTP/2's single connection stalls every stream. HTTP/3 fixes this.
What happens when an enterprise firewall blocks UDP 443?
Browsers fall back to HTTP/2 over TCP after the QUIC attempt fails, usually with a short delay. Many enterprises block QUIC on purpose so their TLS inspection and URL filtering still see the traffic.
What was the HTTP/2 Rapid Reset attack?
A 2023 denial of service where clients opened streams and cancelled them at once with RST_STREAM, at huge rates. The server did work for every stream while the attacker stayed under the concurrent stream limit. Servers patched it by limiting resets per connection.
Traps
- Saying HTTP/2 needs TLS by specification. The spec allows cleartext h2c; browsers only use h2 over TLS.
- Saying HTTP/3 uses TCP 443.