WEBMACHA

WebMacha HTTP/2

app.js is asked for first, so it gets stream 1, but the server needs 60 ms to produce it. The stylesheet and the logo are ready at once, so the server sends them on their own streams, and both have landed before app.js's first frame leaves. On one HTTP/1.1 connection, responses come back in the order they were asked for (RFC 9112 §9.3.2), so both would have waited behind app.js. HTTP/2 puts no order between streams (RFC 9113 §5).

The pipe

client windows
server windows

Step 0 of 29

Streams at this step
s0 connection SET 1 frames
s1 app not open yet
s3 style not open yet
s5 logo not open yet
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
from the client's side send HEADERS send HEADERS + ES send ES recv ES RST_STREAM recv ES · RST send ES · RST idle open half-closed (local) half-closed (remote) closed

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.

Step 0 of 29: The client sends its SETTINGS