隊頭阻塞

在計算機網路中，隊頭阻塞（HOL blocking）是指當資料包佇列中的第一個資料包受阻時，即使佇列中其他資料包可以被處理，也會導致效能瓶頸。

在 HTTP/1.1 中，單個 TCP 連線上的請求通常是按順序傳送的——當等待對上一個請求的響應時，不能在該連線上發出新請求。這可能會導致 HOL 阻塞問題，即使客戶端和伺服器之間有多個 TCP 連線也是如此。

HTTP/1.1 定義了一個可選功能，稱為 HTTP 流水線，它試圖透過允許在不等待早期響應的情況下發送請求來解決 HOL 阻塞，但未能成功。不幸的是，HTTP/1.1 的設計意味著響應必須以與收到請求相同的順序返回，因此如果請求需要很長時間才能完成，仍然可能發生 HOL 阻塞。網路狀況，如擁塞、資料包丟失（以及由此導致的 TCP 重傳）或 TCP 慢啟動，也可能延遲傳輸並導致後續響應被早期響應阻塞。

HTTP/2 透過引入請求和響應的多路複用來減少應用層面的 HOL 阻塞。透過此功能，多個請求和響應可以透過單個 TCP 連線交錯進行，使用獨立的編號流，並且流優先順序有助於伺服器決定首先發送哪些流。傳輸層的資料包丟失仍然可能導致跨流的 HOL 阻塞，因為 HTTP/2 執行在 TCP 之上——丟失的 TCP 段會阻塞該連線上承載的所有流，直到丟失的資料被重傳。

HTTP/3 透過在 UDP 上使用 QUIC 消除了傳輸層隊頭阻塞，因此 HTTP 上的 HOL 問題不再存在。QUIC 提供了多個獨立流，每個流都有自己的丟失恢復機制，因此資料包丟失只會影響發生丟失的流，而不是整個連線。這消除了 TCP 級別的 HOL 問題。