A narrow window starves a fast pipe

One 200 000-byte download, and a client that announces INITIAL_WINDOW_SIZE 16 384 in its SETTINGS (RFC 9113 §6.5.2). The server may send that much on the stream, then it must wait: a DATA frame spends credit from the stream's window and from the connection's (RFC 9113 §6.9.1), and only a WINDOW_UPDATE from the client gives it back (RFC 9113 §6.9). The client sends one when a frame has landed, and it takes 21 ms to reach the server. So each 16 KB frame costs about 58 ms: 17 ms to put it on the wire, 20 ms in flight, 21 ms for the credit to come back. The link is busy less than a third of the time: 16 384 bytes every 58 ms, a round trip plus the 17 ms it takes to put the frame on the wire, is about 280 bytes per ms, on a link that carries 1 000. To keep a link busy, the window must cover its bandwidth times its round trip, which is why real clients widen the window, with a larger INITIAL_WINDOW_SIZE or a WINDOW_UPDATE (RFC 9113 §6.9.2). Compare wide-window: the same download with the window out of the way.

Connection · one pipe, many streams

DATA: a block as wide as its time on the wire, in its stream's colour
HEADERS: hatched
SETTINGS, ACK, PING, WINDOW_UPDATE, GOAWAY: a tick with a glyph
RST_STREAM: a cut; NO_ERROR is not a failure
END_STREAM: a thick trailing edge
a window: the filled part is the credit left, in bytes, not in time
a gauge for a stream with no window yet: dashed, not the same as empty
bytes ready with no credit
current frame
in flight: from its last byte to its landing at the other end
why: the frame whose landing set the current one off
faded: not sent yet
close ticks step to a second line so two close glyphs don't overlap

The pipe

client windows

server windows

Step 0 of 73

Streams at this step
s0	connection SET	1 frames
s1	big	not open yet

Frame

Reset

Step 0 · SETTINGS · stream 0 · leaves client → server

The client sends its SETTINGS

Before any frame, the client sends the 24-octet connection preface, PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n. RFC 9113 §3.4 chose it so that a large proportion of HTTP/1.x servers and intermediaries do not process further frames. It is not a frame, so it is not drawn. Then SETTINGS states what the client will accept: frames of up to 16 384 bytes (MAX_FRAME_SIZE), 16 384 bytes per stream before the server must wait for more window (INITIAL_WINDOW_SIZE). It also turns server push off (ENABLE_PUSH 0); the hub does not model it anyway.

moment: leaves the client
sent at: 0 ms
received at: 21 ms
length: 18 bytes
flags: none

Settings

SETTINGS_ENABLE_PUSH: 0
SETTINGS_INITIAL_WINDOW_SIZE: 16 384
SETTINGS_MAX_FRAME_SIZE: 16 384

RFC 9113 §3.4 · RFC 9113 §6.5.2

Lifecycle

RFC 9113 §5.1

ES is END_STREAM. Select a state to read about it. RFC 9113 §5.1 also has two reserved states for server push; they are left out because push is not modelled.