HTTP/2 defines its own flow-control windows on top of TCP. Explain how the per-stream and per-connection windows work, and what symptom appears when the window is left at the default 65,535 bytes on a high-bandwidth, high-latency link.

## Why HTTP/2 needs its own flow control TCP already has a receive window, but it applies to the whole byte stream. On a multiplexed connection that is too coarse: if an application reads a video stream slowly, TCP backpressure would freeze *every* stream on the connection, including the small JSON call you need immediately. HTTP/2 therefore adds a second, per-stream credit scheme so a receiver can say "stop sending on stream 7" while stream 9 keeps flowing. ## The mechanics Flow control covers **DATA frames only**. Control frames — HEADERS, SETTINGS, PING, RST_STREAM, WINDOW_UPDATE, GOAWAY — are never blocked, which is what keeps a stalled connection controllable. Every sender tracks two windows for every stream it sends on: - the **stream window**, initialized to `SETTINGS_INITIAL_WINDOW_SIZE` (default 65,535 bytes); - the **connection window** for stream 0, initialized to 65,535 bytes. Sending a DATA frame with N payload bytes subtracts N from both. When either window reaches zero the sender must stop sending DATA on the affected scope, even if the other window has room. Windows are signed 31-bit values; a receiver that lowers `SETTINGS_INITIAL_WINDOW_SIZE` mid-connection can push an already-consumed window negative, and the sender must handle that rather than treat it as an error. The receiver replenishes credit with **WINDOW_UPDATE**, which carries an increment (1 .. 2^31-1) and is sent either on a specific stream or on stream 0 for the connection. Typically a stack sends WINDOW_UPDATE once the application has actually consumed buffered bytes — that is what makes the backpressure real rather than a formality. Exceeding a window is a `FLOW_CONTROL_ERROR`. Crucially, `SETTINGS_INITIAL_WINDOW_SIZE` affects only **stream** windows; the connection window is never changed by SETTINGS, only by WINDOW_UPDATE. Many stacks default the connection window to 65,535 too, so a deployment that raises the stream window to 16 MB but never raises the connection window still tops out at 65,535 bytes in flight across *all* streams combined. This is one of the most common HTTP/2 performance bugs in proxies and gRPC deployments. ## The long-fat-network symptom With credit-based flow control the achievable rate per scope is bounded by window / RTT (the same bandwidth-delay product argument as TCP's receive window): - 65,535 bytes over 100 ms RTT ≈ 655 KB/s ≈ 5.2 Mbit/s. - Over a 30 ms intra-region RTT ≈ 17 Mbit/s. So on a 1 Gbit/s transcontinental path, a large download over HTTP/2 crawls at a few megabits while `iperf` on the same path is fast, and the packet capture shows a sawtooth: a burst of DATA, then idle, then a WINDOW_UPDATE, then another burst. People often misdiagnose this as a server or disk problem. The fix is to raise both windows — gRPC and proxies commonly use 1–16 MB, or enable dynamic window auto-tuning (gRPC's BDP estimator, nginx's `http2_body_preread_size` and buffer settings, Go's `http2.Transport` window options) — and to make sure the TCP receive buffer is not the narrower constraint. ## The other direction: too large is also wrong A huge window disables the backpressure that flow control exists to provide. If a receiver grants 64 MB per stream on 100 concurrent streams, a fast sender can force gigabytes of buffering — memory exhaustion, and "bufferbloat" where a high-priority response sits behind megabytes of already-committed low-priority data. Sizing is therefore a real tradeoff: roughly bandwidth × RTT for the paths you serve, multiplied by expected concurrent bulk streams, capped by memory you are willing to commit per connection. ## Diagnosing it Look for a stalled sender with a non-empty application queue. Concretely: capture with Wireshark's HTTP/2 dissector or enable the stack's frame log (`GODEBUG=http2debug=2` for Go, `nghttp -v`, Chrome net-export) and watch for DATA bursts of exactly window size followed by WINDOW_UPDATE arrivals one RTT later. Server metrics that help: time blocked on flow control, current window per stream, and bytes buffered but unwritten. ## Where it does not apply HTTP/3 keeps the same idea but moves it into QUIC, which has per-stream and connection-level flow control plus limits on the number of streams. And on the receiving side of a *proxy*, remember each hop has its own windows: the edge-to-client and proxy-to-origin connections are tuned independently, so a stall can live on either leg.