HTTP/1.1, HTTP/2 and HTTP/3

HTTP/1.1

• One request at a time per connection (responses come back in order).
• To fetch many resources, browsers open about six connections per host.
• Each request repeats large text headers.
• A slow response blocks those behind it: head-of-line blocking.
• Keep-alive lets a connection be reused, saving handshakes.

HTTP/2

• Multiplexing: many requests and responses share one connection at the same time, interleaved as separate streams.
• Header compression removes the repeated cost.
• Binary framing is more efficient to parse than text.
• Server push existed but is rarely used and is being phased out.
• Still runs over TCP, so if one packet is lost, TCP holds back all streams until it is resent (head-of-line blocking at the transport layer).

HTTP/3

• Runs over QUIC, built on UDP, with encryption (TLS 1.3) included.
• Independent streams: a lost packet only delays its own stream.
• Faster connection setup: fewer round trips, and resuming a previous connection can send data immediately.
• Connection migration: a phone moving from Wi-Fi to mobile data can keep the connection, because it is identified by an ID, not an IP address.

100%

Figure SDA-CORE-04-1 · HTTP/3 · © forcsguy.com

100%

Figure SDA-CORE-04-2 · What one lost packet does in each version · © forcsguy.com

What this means for you

• Use HTTPS everywhere. Browsers only use HTTP/2 and 3 over TLS.
• Serve through a CDN or server that supports HTTP/2 and 3; clients negotiate automatically and fall back if needed.
• Do not over-optimise for HTTP/1.1 any more. Keep requests cacheable and compressed.

More on this site