The HTTP/2 protocol

I suggest reading the HTTP tutorial first.

HTTP/2 is one of the HTTP protocol versions used on the web.

It was first standardized in 2015 as RFC 7540. That document was replaced in 2022 by RFC 9113, which contains the current HTTP/2 specification.

HTTP/3 is also standardized and deployed, while HTTP/1.1 is still in use. These versions coexist. A client and server use a version they both support.

HTTP/2 keeps the same HTTP semantics: methods, status codes, URLs, header fields, and message content still mean the same things. What changes is how those messages are framed and transported.

Its main features are:

• streams and request/response multiplexing
• binary framing
• HPACK header compression
• per-stream and connection-level flow control
• stream prioritization
• optional server push

How HTTP/2 is negotiated

For HTTPS connections, the client and server normally select HTTP/2 during the TLS handshake using ALPN. The protocol identifier is h2.

If HTTP/2 is not available, they can negotiate another supported protocol, such as HTTP/1.1. This fallback is why enabling HTTP/2 on a server can be transparent to application code, but HTTP/2 is not simply “100% backwards compatible” at the wire-protocol level.

The specification also defines cleartext HTTP/2, commonly called h2c, but browsers normally use HTTP/2 over TLS for public websites.

Streams and multiplexing

An HTTP/2 connection contains multiple independent streams. Each request and response exchange uses its own stream, and frames from several streams can be interleaved on the same TCP connection.

With HTTP/1.1, browsers commonly opened several TCP connections because a slow response could delay other work on the same connection. HTTP/2 multiplexing allows many requests to make progress concurrently without needing one connection per request.

This made old workarounds such as domain sharding counterproductive in many HTTP/2 deployments. Combining files only to reduce the number of requests is also less important than it was with HTTP/1.1, although bundle size, caching, compression, and processing cost still matter.

Multiplexing does not make every site automatically faster. All HTTP/2 streams share one TCP connection, so packet loss can still stall data for every stream while TCP recovers the missing bytes. This is transport-level head-of-line blocking.

Binary framing

HTTP/2 divides messages into binary frames.

For example, HEADERS frames carry compressed header fields and DATA frames carry message content. Frames include a stream identifier so the receiver can put interleaved data back into the correct request or response.

“Binary framing” does not mean that HTML, JSON, or other message content changes format. It also does not provide encryption by itself. TLS provides encryption for HTTPS.

Header compression with HPACK

HTTP requests and responses often repeat the same field names and values. Cookies can make those fields especially large.

HTTP/2 uses HPACK, defined by RFC 7541, to compress header fields. It can reuse entries from a table shared by the encoder and decoder instead of sending the same text with every request.

Flow control and prioritization

Flow control prevents a sender from overwhelming the receiver. HTTP/2 applies it both to individual streams and to the connection as a whole.

Prioritization lets an endpoint communicate which streams are more important. The original priority scheme from RFC 7540 was deprecated by RFC 9113, and newer extensible priorities are defined separately in RFC 9218.

What happened to server push?

HTTP/2 server push lets a server send a response that it predicts the client will need before the client makes that request.

It remains an optional part of the specification, but it is difficult to use efficiently. The server can waste bandwidth by pushing something already cached or something the page never uses.

Chrome removed HTTP/2 server push support in version 106 after finding little use and no clear net performance gain. For browser performance work, preload links and 103 Early Hints are more practical options.

HTTP/2 and HTTP/3

HTTP/3 is no longer experimental. It was standardized in 2022 as RFC 9114.

HTTP/2 runs over TCP. HTTP/3 maps HTTP semantics onto QUIC, which runs over UDP and includes transport security.

QUIC provides independent streams at the transport layer. Packet loss affecting one HTTP/3 stream does not block unrelated streams in the same way it can on a shared HTTP/2 TCP connection.

HTTP/3 uses QPACK instead of HPACK because QUIC streams can deliver data independently.

HTTP/2 remains useful and widely deployed. HTTP/3 improves the transport, but it does not make HTTP/2 obsolete overnight.

Related posts about network: