head-of-line blocking

Picture a single-file checkout line where the person at the front is fumbling for exact change. Everyone behind them is stuck — not because they aren't ready, but because the rules say the line must be served strictly in order. Head-of-line blocking is that frustration in network form: one stuck item at the front holds up everything queued behind it, even items that are perfectly ready to go.

In TCP it arises directly from the in-order byte stream. TCP must deliver bytes to the application strictly in sequence, so if one segment is lost, every segment that arrived after it has to wait in the receiver's buffer — undelivered — until the missing one is retransmitted and the gap is filled. The data behind the gap is sitting right there, correct and complete, but the in-order promise forbids handing it up. This is especially painful when one TCP connection carries several independent things at once: a single lost packet stalls all of them, even the ones that didn't lose anything.

Why it matters: head-of-line blocking is a built-in cost of TCP's reliability-plus-ordering guarantee, and it shows up wherever independent streams are forced to share one ordered channel. HTTP/2 multiplexed many requests over one TCP connection and ran straight into it: one lost packet stalled every request on that connection. The fix motivated QUIC, which runs over UDP and gives each stream its own ordering, so a loss in one stream doesn't block the others — and HTTP/3 is HTTP over QUIC. Note this is the transport-stream flavor of the problem; the same name also describes an analogous switch-buffering issue at lower layers.