HTTP/2 Multiplexing, Flow Control, HPACK & Stream Priority Studio

In HTTP/1.1, requests and responses are serialized as ASCII text over a TCP connection. Because there are no frame delimiters or stream identifiers, a connection can only process one request-response exchange at a time. If the server takes 500ms to generate response A, response B cannot be sent even if it is ready immediately—this is HTTP/1.1 application-layer Head-of-Line (HoL) blocking. HTTP/2 eliminates this by breaking messages into small, independent binary frames (such as HEADERS and DATA). Every frame includes a 31-bit Stream Identifier in its 9-byte header. Frames from hundreds of concurrent streams (e.g. Stream 1, Stream 3, Stream 5) are interleaved onto a single TCP connection simultaneously. The client and server reassemble the independent byte streams using their stream IDs, allowing high-priority assets like CSS and JS to bypass slow database-bound HTML requests.

HTTP/1.1 headers are uncompressed, frequently wasting 500 to 2,000 bytes per request in cookies, user-agents, and authorization tokens. HTTP/2 introduced HPACK (RFC 7541) specifically to compress headers safely. Standard gzip (DEFLATE) was banned because of the CRIME and BREACH attacks, where an attacker injects plaintext into a request and observes changes in the ciphertext length to recover secret session cookies. HPACK prevents this by maintaining two tables: (1) A Static Table of 61 pre-defined, immutable common header name/value pairs (e.g. Index 2 is ":method: GET", Index 14 is ":status: 200"); (2) A Dynamic Table that stores newly seen header pairs in a FIFO ring buffer shared between client and server across the connection lifetime. Subsequent requests only transmit small integer table indices (often 1 or 2 bytes) instead of repeating strings. String literals are optionally compressed using a static Canonical Huffman Code table.

HTTP/2 enforces flow control via WINDOW_UPDATE frames at two distinct hierarchical levels: (1) Connection-level Flow Control: Governs the total aggregate byte volume that may be transmitted across all streams combined on that TCP socket. (2) Stream-level Flow Control: Governs the byte volume that may be transmitted on a specific individual stream. Both windows start at an initial default of 65,535 bytes (64 KB). The receiver periodically transmits WINDOW_UPDATE frames as it reads data from its application buffers, granting the sender permission to transmit additional DATA frames. Flow control prevents a fast sender from overwhelming a memory-constrained receiver (e.g. a mobile phone) or saturating local socket buffers.

Throughput on a flow-controlled protocol is bounded by the Bandwidth-Delay Product (BDP = Bandwidth * Round-Trip Time). If a client is connected over a high-latency link (e.g. 100ms cross-oceanic RTT) and the HTTP/2 stream flow control window is left at the default 65,535 bytes (64 KB), the sender will exhaust its entire credit window after transmitting 64 KB and must stop transmitting until the receiver's WINDOW_UPDATE packet travels back over the 100ms path. The maximum achievable throughput is capped at Window_Size / RTT = 65,536 bytes / 0.1s = 655 KB/s (~5.24 Mbps), regardless of whether the physical link has 1 Gbps capacity! Production servers and proxies must tune SETTINGS_INITIAL_WINDOW_SIZE and issue WINDOW_UPDATE frames to expand windows to 1MB–16MB on high-BDP links.

RFC 7540 defined a complex stream prioritization scheme using 31-bit stream dependency trees, weight allocations (1 to 256), and exclusive dependency flags (E). In practice, this proved to be a catastrophic failure: browser implementations (Chrome, Firefox, Safari) built wildly divergent, incompatible priority trees that servers could not interpret consistently. Server implementations consumed significant CPU memory maintaining dynamic dependency graphs, and complex trees frequently caused starvation or misallocated bandwidth. In 2022, the IETF published RFC 9218 (Extensible Priorities), replacing the tree model with two simple HTTP header parameters: Urgency (u=0 highest to u=7 lowest, default 3) and Incremental (i=true for concurrent round-robin streaming, i=false for strict serial delivery). RFC 9218 is supported across modern browsers, CDNs, and HTTP/3.

Although HTTP/2 multiplexes multiple application streams over a single TCP connection, the underlying TCP layer is entirely unaware of stream boundaries. TCP guarantees strict in-order byte delivery. If a single IP packet belonging to Stream 1 is dropped on a congested Wi-Fi network, the receiving OS kernel halts delivery of ALL subsequent received packets—including packets belonging to completely unrelated streams like Stream 3 and Stream 5—until the lost packet is retransmitted and acknowledged. On networks with 2% packet loss, HTTP/2 can perform slower than HTTP/1.1 with multiple independent TCP connections. HTTP/3 solves this by replacing TCP with QUIC over UDP, providing independent stream packet accounting where a dropped packet on Stream 1 has zero impact on Stream 3.