Head-of-line blocking depends on which ordering contract applies

TCP presents one ordered byte stream in each direction. An application protocol can place frames for many logical requests into that stream, as HTTP/2 does, but the transport still cannot deliver later stream bytes before an earlier gap. A lost TCP segment can therefore delay parsing bytes associated with otherwise unrelated requests whose frames follow that gap. Multiplexing avoids some application-level request serialization and supports concurrent progress when bytes arrive, yet it cannot remove the underlying transport's in-order delivery contract. Distinguish those two improvements when explaining why HTTP/2 is useful despite this limitation.

The effect depends on where loss occurs and what bytes have already been delivered. A frame completely parsed before the gap is not retrospectively blocked merely because another request later stalls. Nor does every lost packet delay every request for an identical duration; request dependencies, framing, buffering, and scheduling matter. A packet capture that only records aggregate completion times cannot identify the exact blocked boundary. Map the lost interval to the receiver's next expected byte and the application frames behind it, then connect that timeline to the useful work the user was awaiting.

QUIC orders bytes within each stream rather than imposing one cross-stream byte sequence. If stream A has a missing range, complete bytes for independent stream B can be delivered without waiting for A's repair. Within A, later bytes still wait behind A's gap. If one lost packet carries frames for A and B, both can lose useful content together. All streams may also experience reduced sending opportunity when shared congestion control reacts. The improvement is a precise change to delivery ordering, not a guarantee that packet loss has no cross-stream performance effect.

Application protocols can introduce dependencies above the transport. HTTP/3 uses QPACK with rules designed to control header-compression blocking, but a header block referencing unavailable dynamic-table state can still wait for that state within the permitted limits. A page's script can depend on a stylesheet or an API response even when its stream is deliverable. Prioritization, CPU scheduling, storage access, and connection-level flow control can also couple requests. Place each dependency in its own layer so a transport migration is evaluated against the actual critical path instead of credited with removing delays it cannot affect.

Opening separate connections can isolate some transport ordering, but each connection brings state, handshakes, congestion behavior, and resource consumption. Multiple competing controllers may change fairness and aggregate pressure rather than create new capacity. Keeping one connection can improve reuse while retaining shared fate. Neither architecture is universally best. Evaluate short urgent requests alongside large transfers under representative RTT, loss, CPU load, and dependency patterns. Compare useful completion distributions and resource costs, and state whether a benefit comes from independent ordering, a different scheduler, extra parallelism, or simply a different initial sending budget.

Use independent queue runs to examine the shared service that remains after stream ordering is separated. Reset, explicitly set both λ=2.5 and μ=3, predict backlog four draining from t=0 to zero at t=8 seconds, then Play or Step. Reset again and re-set BOTH λ=1 and μ=3; predict zero at t=2 seconds before playback. Control edits retain t and recompute from four instead of continuing the prior backlog. Neither run contains stream order or QUIC. Use the worked timeline to compare a gap's repair with each stream's arrival, rather than treating these fluid curves as packet-level head-of-line evidence.