Fair Turns on One Road
Multiplexing needs a scheduler. Without fair turns, one huge stream can make tiny streams wait.
Last time: one road. Now: traffic rules.
Lesson 1 gave us one road with labels. That solves sorting, but it does not solve fairness. Imagine one elephant truck and three bicycles sharing a narrow bridge. If the elephant goes first and takes the whole bridge, bikes wait even though they are tiny.
Memorable label: “Tiny bikes need turns.” Multiplexing is useful only when the shared road is scheduled well.
Six-year-old version: If one kid dumps a giant bucket of blocks onto the toy track, no other toy train can move. Better rule: each kid puts one small train car on the track, then waits for another turn.
The new problem: head-of-line blocking
Head-of-line blocking happens when something at the front of a shared path makes everything behind it wait. In our course language: one logical channel can hog the shared connection, delaying other frames.
The fix is scheduling: deciding which channel sends next. A simple beginner rule is round-robin: file gets a turn, chat gets a turn, video gets a turn, then repeat.
HTTP/2 frames from many streams share one TCP connection (RFC 9113). That makes scheduling important, because a protocol can mix streams only if it chooses frame order carefully.
One tunnel, many lanes: Think of HTTP/2 as many logical lanes painted inside one TCP tunnel. Scheduling decides which lane gets the next car. But if the tunnel entrance is blocked, every lane waits. This is why multiplexing is not the same thing as unlimited parallelism.
Demo: greedy road vs fair road
Send frames using greedy mode, then reset and try fair mode. Same channels, same frames, different waiting time.
Shared road scheduler
Waiting table
| Channel | First delivered at step | Meaning |
|---|---|---|
| file | — | Big stream. |
| chat | — | Tiny urgent stream. |
| video | — | Steady stream. |
What to notice: multiplexing gives one road. Scheduling decides whether that road feels fast or unfair.
How to recognize this problem
- Small urgent work waits behind big slow work: chat waits behind file upload.
- One shared resource has many users: connection, CPU thread, event loop, disk, radio link.
- Average speed looks fine, but one stream feels laggy: throughput is OK, latency is bad.
When you see this shape, ask: “Do we need labels only, or labels plus fair scheduling?”
Exercise: compare two schedulers
Run:
node --test tests/fair-scheduler.test.mjsThen open src/fair-scheduler.mjs. The greedy scheduler sends all file frames first. The fair scheduler gives each non-empty channel a turn.
Knowledge check
Interview payoff
Question: “If HTTP/2 multiplexes streams, why can users still experience delays?”
Model answer: “Multiplexing lets multiple streams share one connection, but the sender still schedules frames. If one stream sends too much before others get turns, small urgent streams can wait. Multiplexing solves connection sharing; scheduling solves fairness and latency.”
Pro tip: Throughput and latency are different. A system can move lots of bytes per second and still feel slow if tiny messages wait behind big chunks.
Next challenge: We can schedule fairly inside one connection. But how does the receiver know which app should get incoming network data in the first place?