HTTP/2 & HTTP/3 Flow Control, Stream Multiplexing & Prioritization Studio

Flow control in HTTP/2 and HTTP/3 is a directional, credit-based mechanism that prevents a fast sender from overwhelming a slow receiver buffer or saturating intermediary proxies. It operates at two independent hierarchical levels: (1) Stream-level window: Limits the number of DATA payload bytes a sender can transmit on an individual stream (initial default: 65,535 bytes in HTTP/2). (2) Connection-level window: Limits the total aggregate bytes a sender can transmit across all active multiplexed streams combined (initial default: 65,535 bytes). A sender must possess available credit in BOTH windows to transmit DATA frames. When the receiver consumes data from its buffer, it sends WINDOW_UPDATE frames (specifying the stream ID and a 31-bit positive window credit increment). Setting flow control windows too small throttles bandwidth on high Bandwidth-Delay Product (BDP) networks, while setting them too large risks out-of-memory crashes on memory-constrained devices.

A flow control deadlock occurs when a large transfer on one stream exhausts the shared connection-level flow control window, freezing all other streams on the connection. For example, if a client requests a 10 MB image on Stream 1 and critical CSS on Stream 3 with an initial connection window of 64 KB, the server transmits 64 KB of the image and exhausts the connection window. Even if the client has plenty of stream credit on Stream 3, the server cannot transmit a single byte of CSS because the connection credit is zero. If the client pauses reading Stream 1 (or if client JavaScript is waiting for the CSS before consuming the image), neither side makes progress: the server waits for connection credit, and the client waits for CSS. Modern CDNs avoid this by dynamically tuning connection windows up to 16-32 MB and auto-emitting WINDOW_UPDATE frames ahead of time.

In HTTP/2, multiple independent application requests are interleaved into binary frames over a single underlying TCP connection. However, the Linux kernel TCP stack only understands a contiguous stream of ordered bytes, with zero awareness of HTTP/2 stream boundaries. If an IP packet carrying a chunk of Stream 3 is dropped by network congestion, the receiving OS TCP buffer must hold all subsequently received packets (including packets containing Stream 1, 5, and 7 data) in the socket receive buffer until the lost packet is retransmitted and acknowledged. In contrast, HTTP/3 runs over QUIC on top of UDP. QUIC natively understands stream IDs at the transport layer: each stream has its own independent offset and receive buffer. If a packet containing Stream 3 data is dropped, only Stream 3 is delayed; Streams 1 and 5 are delivered to user space immediately with zero latency penalty.

HTTP/2 (RFC 7540) originally specified a complex prioritization scheme based on dependency trees, where streams depended on parent streams with fractional integer weights (1–256) and exclusive flags. In practice, this design was a failure: (1) It required servers and intermediate CDNs to maintain state for closed streams, causing memory leaks; (2) Browsers (Chrome, Firefox, Safari) used radically different, conflicting tree generation heuristics; (3) Intermediate proxies frequently scrambled tree dependencies. RFC 9218 replaced this with Extensible Prioritization Scheme, a lightweight scheme transmitted via HTTP headers or PRIORITY_UPDATE frames: Priority: u=urgency, i. Urgency is an integer from 0 (highest, e.g. HTML/CSS) to 7 (lowest, e.g. background analytics), and "i" is a boolean flag indicating whether concurrent streams should be multiplexed incrementally (i=?1, e.g. progressive images) or delivered strictly sequentially (i=?0).

To achieve 100% link utilization without artificial idle pauses, the flow control window must be at least equal to the Bandwidth-Delay Product (BDP) of the network: BDP (bytes) = Bandwidth (bits/sec) * Round-Trip Time (seconds) / 8. For a 100 Mbps fiber link with a 40 ms RTT to the server, BDP = (100 * 10^6 * 0.040) / 8 = 500,000 bytes (~500 KB). If the HTTP/2 connection window is left at the default 65,535 bytes, the server can only transmit for 5.2 ms before the window shuts, leaving the line idle for the remaining 34.8 ms while waiting for WINDOW_UPDATE frames. This caps throughput at only 13.1 Mbps (an 87% performance penalty!). Production servers set the connection window to at least 2x to 4x the expected worst-case BDP (typically 4 MB to 16 MB).

When an HTTP client aborts a request (e.g. user navigates away or cancels an image download), it must immediately halt wasted upstream transmission. In HTTP/2, this is done via a single RST_STREAM frame. In HTTP/3, QUIC provides bidirectional signaling: (1) RESET_STREAM: Sent by the sender to abruptly terminate its sending half of the stream, indicating the final byte offset so the receiver can verify flow control accounting; (2) STOP_SENDING: Sent by the receiver to inform the sender to immediately cease transmitting on that stream, carrying an application error code (e.g. H3_REQUEST_CANCELLED = 0x010c). The sender acknowledges and immediately releases its transmit buffers and flow control reservations, preventing multi-megabyte pipeline waste.