HTTP/2

To appreciate what HTTP/2 fixes, you need to see what was broken.

HTTP/1.1 delivers responses sequentially on each connection. If a client sends two requests on the same connection, the server must finish sending the first response before it can begin the second. This is called head-of-line blocking. While the server is busy with a slow database query for request one, request two—​which might be a tiny icon file ready to go—​waits in line.

Browsers compensated by opening up to six parallel connections per origin. A page with sixty resources across two origins could use twelve simultaneous connections. But each connection requires a TCP handshake (one round-trip) and, over HTTPS, a TLS handshake (another round-trip or two). On a transatlantic link with 80ms round-trip time, those handshakes alone cost hundreds of milliseconds before a single byte of content arrives.

HTTP/1.1 pipelining was supposed to help: the client could send several requests without waiting for responses. In practice it was fragile, poorly supported by intermediaries, and never widely deployed. The problem needed a deeper solution.

Google began experimenting with an alternative in 2009 under the name SPDY (pronounced "speedy"). The goals were ambitious: cut page load times in half without requiring website authors to change their content. Lab tests on the top 25 websites showed pages loading up to 55% faster.

By 2012, SPDY was supported in Chrome, Firefox, and Opera, and major sites like Google, Twitter, and Facebook were serving traffic over it. Seeing this momentum, the IETF HTTP Working Group adopted SPDY as the starting point for an official successor to HTTP/1.1. Over the next three years, SPDY and the emerging HTTP/2 standard coevolved: SPDY served as the experimental branch where proposals were tested in production before being folded into the specification.

In May 2015, RFC 7540 (HTTP/2) and RFC 7541 (HPACK header compression) were published. Google retired SPDY shortly after. By the time the standard was approved, dozens of production-ready client and server implementations already existed—​an unusually smooth launch for a major protocol revision.

The single most important change in HTTP/2 is invisible to applications: the replacement of HTTP/1.1’s newline-delimited text format with a binary framing layer.

In HTTP/1.1, a request looks like this on the wire:

Parsing this requires scanning for line endings, handling optional whitespace, and dealing with varying termination sequences—​a process that is error-prone and surprisingly expensive at scale.

HTTP/2 replaces this with fixed-length binary frames. Each frame begins with a nine-byte header:

Binary framing is more compact, faster to parse, and unambiguous. The client and server handle the encoding transparently—​applications continue to work with the same HTTP methods, headers, and status codes they always have.

HTTP/2 introduces three layers of abstraction within a single TCP connection:

All communication happens over a single TCP connection. The connection carries many concurrent streams. Each stream carries one message exchange. Each message is broken into frames that can be interleaved with frames from other streams. On the receiving end, frames are reassembled into messages using the stream identifier.

This layering is the foundation of everything else HTTP/2 offers.

Multiplexing is the headline feature. It solves head-of-line blocking at the HTTP layer in a single stroke.

In HTTP/1.1, loading a page with a stylesheet, a script, and three images from the same origin requires the browser to either queue requests behind each other on one connection or open multiple connections. With HTTP/2, all five requests can be sent immediately on a single connection, and the server can interleave the responses:

The server does not have to finish sending the CSS before it starts on the JavaScript. It can send a chunk of the image, then a chunk of the HTML, then more of the image—​whatever order is optimal. Frames from different streams are interleaved freely and reassembled by the receiver.

The practical consequences are significant:

When dozens of streams are in flight at once, not all of them are equally urgent. The CSS that unblocks page rendering matters more than a background image below the fold. HTTP/2 lets the client express these priorities so the server can allocate bandwidth and processing time intelligently.

Each stream can be assigned a weight (an integer from 1 to 256) and a dependency on another stream. Together, these form a prioritization tree:

For example, if stream A (weight 12) and stream B (weight 4) are siblings, stream A should receive three-quarters of the available bandwidth and stream B one-quarter. If stream C depends on stream D, then D should be fully served before C begins receiving data.

The client can update priorities at any time—​when the user scrolls, for instance, images that have moved on-screen can be reprioritized above those that have scrolled off.

Priorities are hints, not mandates. The server should respect them, but it is free to adapt. A good HTTP/2 server interleaves frames from multiple priority levels so that a slow high-priority stream does not starve everything else.

HTTP/1.1 headers are verbose and repetitive. Every request to the same origin sends the same Host, User-Agent, Accept, and cookie headers—​often 500 to 800 bytes of identical text, request after request. On pages that generate dozens of requests, the header overhead alone can fill the initial TCP congestion window and add an entire round-trip of latency.

HTTP/2 addresses this with HPACK (RFC 7541), a compression scheme designed specifically for HTTP headers. HPACK uses two techniques:

Static table. A predefined table of 61 common header field/value pairs (:method: GET, :status: 200, content-type: text/html, and so on). These can be referenced by index instead of transmitted in full.

Dynamic table. A per-connection table that both sides maintain. When a header field is sent for the first time, it is added to the dynamic table. Subsequent requests that use the same field can reference the table entry instead of retransmitting the value.

The result is dramatic. On the second request to the same origin, most headers are transmitted as single-byte index references. If nothing has changed between requests—​common for polling—​the header overhead drops to nearly zero.

Consider two successive requests:

In HTTP/1.1, both requests transmit every header in full. In HTTP/2, the second request transmits only the changed :path value; everything else is implied by the dynamic table. Where HTTP/1.1 might send 400 bytes of headers on the second request, HTTP/2 sends perhaps 20.

HPACK was designed to resist the CRIME attack that compromised earlier compression approaches (SPDY originally used zlib). By using index-based referencing and Huffman coding instead of general-purpose compression, HPACK avoids leaking secrets through compression side channels.

Multiplexing many streams on one connection creates a resource allocation problem: a large download should not starve smaller, time-sensitive requests. HTTP/2 solves this with a flow control mechanism modeled on TCP’s own window-based approach, but applied at the stream level.

Each side of the connection advertises a flow control window--the number of bytes it is willing to receive—​for each stream and for the connection as a whole. The default window is 65,535 bytes. As data is received, the window shrinks; the receiver sends WINDOW_UPDATE frames to replenish it.

Key properties of HTTP/2 flow control:

Flow control applies only to DATA frames. Control frames like HEADERS and SETTINGS are always delivered without flow control, ensuring that the connection can always be managed even when data windows are exhausted.

HTTP/2 introduced server push: the ability for a server to send resources to the client before the client requests them. When the server knows that an HTML page will need a particular stylesheet and script, it can push those resources alongside the initial response, eliminating the round-trip the client would spend discovering and requesting them.

The mechanism works through PUSH_PROMISE frames. The server sends a PUSH_PROMISE containing the headers of the resource it intends to push. The client can accept the push (letting it populate the cache) or reject it with a RST_STREAM if the resource is already cached.

In theory, server push was elegant. In practice, it proved difficult to use effectively. Servers had to guess what clients already had cached, and incorrect guesses wasted bandwidth. The overhead of implementing push correctly on both sides outweighed the latency savings in many deployments.

RFC 9113, the 2022 revision of the HTTP/2 specification, formally deprecated server push. Browsers have largely removed support for it. The same goal—​hinting to the client about needed resources before the page HTML is fully parsed—​is now better served by 103 Early Hints responses, which tell the client what to preload without the complexity of push streams.

HTTP/2 runs over TCP, and in practice almost exclusively over TLS. All major browsers require HTTPS for HTTP/2 connections, even though the specification technically allows cleartext HTTP/2.

For HTTPS connections, the client and server negotiate HTTP/2 during the TLS handshake using ALPN (Application-Layer Protocol Negotiation). The client includes h2 in its list of supported protocols in the TLS ClientHello message. If the server also supports HTTP/2, it selects h2 in the ServerHello, and both sides begin speaking HTTP/2 immediately after the handshake completes. No extra round-trips are needed.

Once the TLS handshake finishes, both sides send a connection preface: a SETTINGS frame declaring their configuration (maximum concurrent streams, initial window size, maximum header list size, and so on). The client also sends a well-known 24-byte magic string as a sanity check:

This string is designed to fail clearly if an HTTP/1.1 server accidentally receives it, preventing silent protocol mismatches.

For the rare case of cleartext HTTP/2, the client can use the HTTP/1.1 Upgrade mechanism:

If the server supports HTTP/2, it responds with 101 Switching Protocols and both sides switch to binary framing. If not, the exchange continues as normal HTTP/1.1.

HTTP/2 is designed around a single connection per origin. Where HTTP/1.1 browsers opened six connections to achieve parallelism, HTTP/2 multiplexes everything onto one. This has several benefits:

There is a trade-off. Because all streams share one TCP connection, a single lost packet forces TCP to retransmit and stalls every stream on that connection—​head-of-line blocking returns, but at the transport layer rather than the application layer. On lossy networks (mobile, satellite), this can hurt performance.

In practice, the benefits of compression, prioritization, and reduced overhead outweigh the TCP-level blocking penalty for most deployments. The transport-layer limitation is the primary motivation for HTTP/3, which replaces TCP with QUIC to give each stream independent loss recovery.

HTTP/2 defines ten frame types. Understanding them gives you a complete picture of what the protocol can express:

The GOAWAY frame deserves special mention. It allows a server to drain gracefully: the server tells the client which streams were processed and which were not, so the client can safely retry unprocessed requests on a new connection. This is essential for zero-downtime deployments.

Because HTTP/2 preserves HTTP semantics, existing applications work without modification. But understanding the protocol lets you stop fighting it:

HTTP/2 adoption crossed 35% of all websites by early 2026, and virtually all modern browsers support it. It remains the workhorse protocol for the majority of encrypted web traffic, even as HTTP/3 gains ground with its QUIC-based transport. Understanding HTTP/2 is not just historical context—​it is the protocol most of your requests travel over today.