Four streams, one connection window

Four 60 000-byte downloads, asked for together, with the default windows. Each stream has its own 65 535-byte window, and all four share the connection's, also 65 535 bytes (RFC 9113 §6.9.1). After four DATA frames, one per stream, the connection's window is spent while every stream still holds most of its own credit: the stream windows alone would allow 262 140 bytes in flight. Flow control works at two levels, for each stream and for the connection as a whole (RFC 9113 §5.2): a receiver can hold back one stream without holding back the others, and still bound the total it must take in. From here on the server waits for each connection WINDOW_UPDATE, and spends it taking turns between the four streams (RFC 9113 §5).

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 77

Streams at this step
s0	connection SET	1 frames
s1	part-1	not open yet
s3	part-2	not open yet
s5	part-3	not open yet
s7	part-4	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), 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.

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: 65 535
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.

The client's actions, in order. Each runs when its trigger is met. Change any of them and the trace is worked out again.

part-1 GET /part/1.bin not sent yet

at start
part-2 GET /part/2.bin not sent yet

at start
part-3 GET /part/3.bin not sent yet

at start
part-4 GET /part/4.bin not sent yet

at start