Head-of-line-Blocking

In der Computernetzwerktechnik bezieht sich Head-of-line-Blocking (HOL-Blocking) auf einen Leistungsengpass, der auftritt, wenn eine Warteschlange von Paketen durch das erste Paket in der Warteschlange aufgehalten wird, obwohl andere Pakete in der Warteschlange verarbeitet werden könnten.

In HTTP/1.1 werden Anfragen auf einer einzelnen TCP-Verbindung normalerweise nacheinander gesendet – eine neue Anfrage kann nicht über die Verbindung gestellt werden, während auf eine Antwort auf die vorherige Anfrage gewartet wird. Dies kann zu HOL-Blocking-Problemen führen, selbst wenn mehrere TCP-Verbindungen zwischen dem Client und dem Server bestehen.

HTTP/1.1 definiert ein optionales Feature namens HTTP-Pipelining, das erfolglos versuchte, das HOL-Blocking zu umgehen, indem es ermöglichte, Anfragen zu senden, ohne auf frühere Antworten zu warten. Unglücklicherweise bedeutet das Design von HTTP/1.1, dass Antworten in der gleichen Reihenfolge zurückgegeben werden müssen, in der die Anfragen empfangen wurden, sodass HOL-Blocking immer noch auftreten kann, wenn das Abschließen einer Anfrage lange dauert. Netzwerkbedingungen wie Staus, Paketverlust (und die daraus resultierenden TCP-Neuübertragungen) oder TCP Slow Start können ebenfalls die Übertragung verzögern und dazu führen, dass spätere Antworten durch frühere blockiert werden.

HTTP/2 reduziert das HOL-Blocking auf Anwendungsebene durch die Einführung von Multiplexing von Anfragen und Antworten. Mit dieser Funktion können mehrere Anfragen und Antworten über eine einzige TCP-Verbindung mithilfe unabhängig nummerierter Streams ineinander verschachtelt werden, und die Stream-Priorisierung hilft dem Server zu entscheiden, welche Streams zuerst gesendet werden sollen. Paketverluste auf der Transportschicht können dennoch HOL-Blocking über Streams hinweg verursachen, da HTTP/2 über TCP läuft – ein verlorenes TCP-Segment kann alle Streams auf dieser Verbindung blockieren, bis die verlorenen Daten erneut übertragen werden.

HTTP/3 beseitigt das HOL-Blocking auf der Transportschicht, indem es QUIC über UDP verwendet, und somit existiert das HOL-Problem bei HTTP nicht mehr. QUIC bietet mehrere unabhängige Streams mit verlustspezifischer Wiederherstellung, sodass Paketverlust nur den Stream betrifft, in dem er auftritt, anstatt die gesamte Verbindung. Dies beseitigt das TCP-HOL-Problem.