Workload & network

Assets

Name Type Size (KB) Priority Origin Remove

Playback

0 ms

What happened

How the simulation model works

This lab is a teaching model, not a packet-accurate emulator. It reproduces the behaviours that distinguish the protocols so you can build intuition.

Connection setup
HTTP/1.1 and HTTP/2 run over TCP + TLS and pay roughly two round trips before the first request. HTTP/3 runs over QUIC and needs one round trip - or zero with 0-RTT resumption. HTTP/1.1 opens up to six connections per origin (more with domain sharding); HTTP/2 and HTTP/3 multiplex everything over a single connection per origin.
Bandwidth sharing
The client link is the bottleneck. All streams downloading at a given moment split the available bandwidth; a stream finishes when its bytes have been transferred.
Head-of-line (HOL) blocking
Packet loss is turned into discrete loss events, placed deterministically from the seed so every protocol sees the same pattern. On HTTP/1.1 a stalled response blocks that connection's queue. On HTTP/2 a loss stalls the whole TCP connection for one RTT - every multiplexed stream freezes. On HTTP/3 a loss stalls only its own QUIC stream; the others keep flowing.
Priority
With prioritization on, high-priority assets get a larger share of the link on HTTP/2 and HTTP/3 and finish first. HTTP/1.1 ignores priority (first-come, first-served per connection).
Determinism
A seeded pseudo-random generator fixes the loss pattern, so the three protocols are always compared on identical conditions and every run is reproducible.

Numbers are illustrative. Real networks add congestion control, TLS false start, HPACK/QPACK, server push, connection coalescing and much more. Use this to understand the shape of the differences, not to predict exact load times.

Further reading

Deeper explanations of everything this lab demonstrates: