The server's SETTINGS says it will handle at most two streams at a time (RFC 9113 §6.5.2). The client wants five icons. It opens two streams and holds the other three back, because a client must not open more streams than the server's limit allows (RFC 9113 §5.1.2). Only open and half-closed streams count toward it. Each time a stream closes, the next waiting request takes its place, in the order the script lists them.
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
a band: its width is time on the wire, its tilt is latency
HEADERS: hatched
SETTINGS, ACK, PING, WINDOW_UPDATE, GOAWAY: a tick with a glyph
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), 65 535 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.
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.
Stream 0 carries the connection's own frames: SETTINGS, PING, GOAWAY, and WINDOW_UPDATE
for the whole connection. The connection is ready once each side has acknowledged the
other's SETTINGS (RFC 9113 §6.5.3).