Head-of-line blocking

https://developer.mozilla.org/en-US/docs/Glossary/Head_of_line_blocking

“队头阻塞”（Head-of-Line Blocking, HOL Blocking）是一个形象的比喻，它指的是在按顺序处理数据时，如果队列最前面的那个数据包被卡住了，那么即使它后面的数据包已经到达并且可以被处理，也必须等待，导致整个队列都停滞不前。

你可以把它想象成一个只有一个收银台的超市：

• 所有顾客（数据包）都必须排成一队。
• 如果排在最前面的那位顾客（队头数据包）因为支付问题或其他原因被耽搁了，那么后面的所有顾客都必须停下来等待，即使他们已经准备好付款，也无法前进。

为什么 TCP 会产生队头阻塞？

---

TCP（传输控制协议）为了保证数据传输的可靠性和有序性，它有一个核心机制：数据包必须按顺序接收。

在网络传输中，数据包可能会因为各种原因（比如网络拥堵）而丢失或者乱序到达。当这种情况发生时，TCP 的接收端会做如下处理：

1. 数据包乱序到达：假设数据包 1、2、3 依次发送，但接收端先收到了数据包 2 和 3，却没收到数据包 1。
2. 等待和缓存：接收端不能直接将数据包 2 和 3 交付给上层应用。它必须先缓存起来，然后等待丢失的数据包 1 重新传输。
3. 队头阻塞：在这个等待的过程中，数据包 2 和 3 就像是“排在队头”的数据包 1 后面的顾客，即使它们已经准备就绪，也必须被“阻塞”住，等待数据包 1 到来。只有当数据包 1 重新传送到，接收端才能将整个完整有序的数据流（1、2、3）交给应用层。

队头阻塞的影响

---

队头阻塞会成为性能瓶颈，特别是在 HTTP/2 协议中。HTTP/2 允许在单个 TCP 连接上同时发送多个请求（多路复用），这本应提高效率。但由于底层的 TCP 仍然需要按顺序交付数据，一个请求的数据包丢失或延迟，就会影响到这个 TCP 连接上所有其他请求的传输，即使这些请求与丢失的数据包毫无关联。

为了解决这个问题，新一代的 HTTP/3 协议放弃了 TCP，转而使用 QUIC 协议。QUIC 基于 UDP 协议，它能够实现独立的“数据流”（streams）。每个数据流都按自己的顺序传输，一个数据流的阻塞不会影响到其他数据流，从而从根本上解决了传输层的队头阻塞问题。