What is head-of-line blocking in TCP, and when does it hurt?

Head-of-line blocking is a consequence of TCP's in-order delivery guarantee: if one segment is lost, TCP must retransmit and successfully deliver it before it will hand any later, already-received bytes up to the application, because delivering them out of order would violate the stream's ordering. So a single lost packet stalls the entire stream behind it until the retransmission completes, even though the later data is sitting in the receive buffer ready to go. This hurts most for real-time and latency-sensitive data: in live audio or video, stalling the whole stream to recover one old packet causes a freeze or glitch that's worse than simply dropping that packet and continuing, which is precisely why such applications use UDP (or QUIC, which avoids it) and tolerate or conceal loss rather than wait. It also hurts when you multiplex independent messages over one TCP connection, a loss affecting one message delays all the others sharing the connection. For bulk transfer where you only care about the final correct result (a file, a config blob), head-of-line blocking is harmless and the reliability is exactly what you want. So it's a tradeoff that makes TCP ideal for correctness-critical bulk data and poor for real-time or multiplexed independent streams.