Prerequisite: the TCP and QUIC visual tour. Outcome: explain independent stream delivery, byte offsets, flow control, and the end of one sending direction. Allow: 20 minutes. The lab runs entirely in your browser and needs no server or credentials.

Operate the stream lab

Use the four tabs to change one condition at a time. The examples illustrate protocol behavior. They do not measure network performance.
Open the stream lab in a separate page. On narrow screens, scroll inside the lab to reach the lower controls.

Experiment 1: four streams, then eight

  1. Select 4 or 8 streams and keep Packet loss selected.
  2. Drop the selected packet and observe the missing and buffered byte ranges.
  3. Recover the bytes and compare the recovery packet number with the lost packet number.
  4. Select 8 streams and Two streams for the packet contents.
  5. Drop that packet and count the streams with gaps.
  6. Select Packet reordering and repeat the experiment.
A packet can carry frames from several streams. Losing the selected packet creates a gap in each affected stream. Each affected stream buffers its later bytes. Unaffected streams can deliver contiguous received bytes. Recovery sends the missing ranges in a new packet with a new number. Their stream offsets remain the same. In the reordering example, the original delayed packet fills the gap without a retransmission. All streams still share congestion control. The application can introduce further dependencies.

Experiment 2: reassemble a byte stream

  1. Select Offsets and FIN.
  2. Receive offsets 4–7 before offsets 0–3.
  3. Receive FIN at offset 8 while the earlier bytes are still missing.
  4. Receive offsets 0–3, then receive that range again.
The first four received bytes wait behind a gap. They are buffered but not yet available in order. FIN declares a final size of eight bytes. It does not supply the missing data. After the earlier range arrives, all eight bytes become readable and the receiving direction can finish. The duplicate does not create four additional application bytes.
QUIC streams carry bytes. An application must define how those bytes form messages, such as through a length prefix. One application write does not imply one STREAM frame or one network packet.

Experiment 3: exhaust two different allowances

  1. Select Limits and reset.
  2. Send four bytes on A twice. Observe A’s exhausted stream allowance.
  3. Send four bytes on B. Observe the exhausted connection allowance.
  4. Add four bytes of A credit. Observe that A still cannot send.
  5. Add eight bytes of connection credit, then send on A.
  6. Reset A’s sending direction and check B’s state.
A starts with eight bytes of stream credit. B can still send after A reaches that limit. Once their combined use reaches twelve bytes, the connection allowance blocks additional stream bytes. Increasing A’s stream limit alone does not increase the connection limit. Resetting A ends that sending direction. Its final size remains part of connection accounting, and B remains open. The experiment assumes that congestion control permits each illustrated send.

Experiment 4: decode a stream ID

Select Stream IDs and compare the four combinations of initiator and direction. A bidirectional stream has separate offsets and flow-control state for each sending direction. FIN finishes one direction normally. RESET_STREAM abandons one sending direction; STOP_SENDING asks the peer to stop its sending direction. These actions do not require the entire connection to close. Completion check: explain why a blocked stream, an exhausted connection allowance, and a lost packet require different observations.

Sources and inspiration

Read RFC 9000 on streams, termination, flow control, and STREAM frames. The multiple-lane presentation takes inspiration from PosTQuic. The academy diagrams, explanations, and code are original. Continue to the 15-card QUIC carousel.