HTTP/2 multiplexes streams with two levels of DATA credit

An HTTP/2 connection carries frames, many of which belong to identified streams. Request and response messages use header blocks and optional DATA, with flags and frame types determining message and stream transitions. Stream identifiers correlate exchanges; arbitrary application messages are not inferred from TCP read boundaries. A peer's stream-concurrency limit governs new-stream admission using the relevant open and half-closed streams, while maximum frame size constrains an individual frame. If the peer lowers SETTINGS_MAX_CONCURRENT_STREAMS below the existing count, it can let those streams finish; the lower limit does not require immediate closure of the excess. Neither is a byte window. An application can have many open streams and still be unable to send more body DATA because receive credit is exhausted.

Streams share one ordered TCP connection in each direction. If an earlier TCP byte range is missing, later HTTP/2 frames cannot be delivered to the parser even if they concern otherwise independent streams. This transport-level head-of-line dependency coexists with useful application multiplexing. Once bytes are available, endpoint scheduling also determines which streams receive service. An allowed concurrency of one hundred streams is therefore neither a promise of one hundred independent paths nor proof that all requests progress fairly. Inspect stream state, application scheduling, TCP recovery, and connection resources as different layers.

HTTP/2 flow control applies to DATA frames at both stream and connection scope. Sending a positive DATA payload requires enough credit in both windows. Frame payload bytes used for flow control include the Pad Length field and padding when present, not just useful application data; the nine-byte frame header is excluded. This makes padded frames consume more credit than their useful body alone. Other frame types, including WINDOW_UPDATE, are not themselves flow controlled in this way, which allows credit and control information to move even when DATA sending is blocked.

WINDOW_UPDATE adds credit at the named scope: a stream update does not automatically replenish the connection window. The receiver must process frames and manage connection credit even if one application stream reads slowly; otherwise unrelated traffic can stall. Initial stream-window settings and connection-window updates have different effects, and a decrease to initial stream windows can produce a temporarily negative stream window. A simplified positive-credit calculation is useful for a snapshot, but it is not a substitute for the specification's signed state and error handling during settings changes. Do not fix an application deadlock by sending illegal oversized DATA.

When one stream stalls, first ask whether its sender has data, whether stream credit is exhausted, whether connection credit is exhausted, and whether the transport or application is making progress. A connection-credit stall can affect many streams even when each has positive individual credit. Conversely, a stalled stream need not block unrelated streams if connection state is processed and resources remain available. Cancellation with RST_STREAM changes stream state but does not erase DATA already in flight from connection-level accounting. Keep resource release and late-frame handling consistent with the protocol instead of assuming cancellation rewinds transmission.

The queue lab isolates receive-consumption pressure without implementing those budgets. For EACH run Reset, explicitly set BOTH λ and μ, predict, then Play or Step: compare (3,2) with (1,2). Starting from four normalized units at t=0, one grows and the other empties at four seconds. Editing a rate retains t and recomputes from four rather than continuing a changed-rate trace. This aggregate fluid queue has no streams, WINDOW_UPDATE, padding, or TCP loss. Use it to explain why capacity must be bounded, and use the worked ledger to identify the exact exhausted HTTP/2 scope.