In der Computernetzwerktechnik bezieht sichHead-of-line-Blocking (HOL-Blocking) auf einen Leistungsengpass, der auftritt, wenn eine Warteschlange vonPaketen 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 einzelnenTCP-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 namensHTTP-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) oderTCP 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 vonMultiplexing 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 esQUIC überUDP 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.

Siehe auch

• Verwandte Glossarbegriffe
  • HTTP,HTTP/2,HTTP/3
  • TCP,QUIC,UDP
• Das Befüllen der Seite: wie Browser funktionieren
• Head-of-line blocking auf Wikipedia