Why HTTP/2 Matters: From Head‑of‑Line Blocking to Server Push

Why HTTP/2 Matters for Interviews and Real‑World Projects

Interview questions on HTTP/2 are few, but many modern frameworks—most notably Google’s gRPC—rely on it to boost efficiency. Understanding HTTP/2 helps you stand out in interviews and grasp the inner workings of such frameworks.

Problems with HTTP/1.x

TCP connection limits cause browsers to cap the number of simultaneous connections.

Head‑of‑Line (HoL) blocking: a single TCP stream can handle only one request at a time, so later requests wait for earlier ones to finish.

Pipelining was introduced but still suffered from slow first responses, server buffering overhead, retry complexities, and the need for full client‑proxy‑server support.

Headers are sent repeatedly without compression, wasting bandwidth.

To reduce request count, developers merge files, which can increase latency for individual resources.

Plaintext transmission is insecure.

Enter HTTP/2

RFC 7540 defines HTTP/2, built on the experimental SPDY protocol. It adds binary framing, header compression, multiplexing, request priority, and server push to address the issues above.

What Is SPDY?

SPDY, created by Google, optimizes HTTP by compressing headers, multiplexing streams, and assigning priorities, aiming to reduce the number of TCP connections. It was later standardized as HTTP/2, and Google deprecated SPDY in favor of HTTP/2.

Binary Framing Layer

HTTP/2 inserts a binary framing layer between the application (HTTP) and transport (TCP) layers. All communication is broken into frames, which are binary‑encoded, preserving HTTP semantics while enabling efficient multiplexing.

Key concepts:

Frame : Smallest unit; contains an 8‑byte header (length, type, flags, reserved bits) and a stream identifier.

Message : Logical HTTP request or response composed of one or more frames (e.g., HEADERS + DATA).

Stream : Virtual bidirectional channel within a single TCP connection, identified by an integer. Client‑initiated streams use odd IDs, server‑initiated use even IDs.

+-----------------------------------------------+
|               Length (24 bits)               |
+---------------+---------------+---------------+
|   Type (8)    |   Flags (8)   |
+-+-------------+---------------+-------------------------------+
|R|            Stream Identifier (31)            |
+=+=============================================================+
|                Frame Payload (0…)                ...
+---------------------------------------------------------------+

Frames replace the plaintext transmission of HTTP/1.x, allowing multiple streams to coexist on a single connection.

Multiplexing

Multiple request‑response pairs share one TCP connection. Each frame carries a Stream ID, enabling the receiver to reassemble frames belonging to the same stream, even when frames from different streams interleave. This eliminates HoL blocking and reduces the number of TCP connections.

Server Push

When a client requests a resource, the server can proactively send additional related resources (e.g., CSS, JavaScript) without waiting for separate requests. This reduces round‑trips and improves page load speed.

Example: Client requests /page.html (Stream 1). The server responds with Stream 1 and simultaneously pushes /script.js (Stream 2) and /style.css (Stream 4).

Header Compression (HPACK)

HTTP/1.x repeats full header fields for every request, consuming bandwidth. HTTP/2 introduces HPACK, which compresses headers using a static and dynamic table. Repeated header fields are sent as indexes into the table, dramatically reducing overhead.

Request Priority

Each stream can declare a dependency and weight, forming a priority tree. The scheduler can favor critical streams, preventing important resources from being blocked.

Application‑Level Stream Reset

Instead of closing the whole TCP connection (as in HTTP/1.x), HTTP/2 provides a RST_STREAM frame to cancel a single stream while keeping the connection alive.

Flow Control

HTTP/2 implements per‑stream flow control similar to TCP’s sliding window. The receiver advertises a window size for each stream, limiting how much data the sender may transmit before receiving a WINDOW_UPDATE.

Conclusion

HTTP/2 adds a binary framing layer, multiplexing, server push, header compression, request priority, stream reset, and flow control on top of HTTP/1.x semantics. These enhancements reduce latency, improve throughput, and are increasingly adopted by browsers and servers, making them essential knowledge for modern web developers.