HTTP/2 Multiplexing: Schluss mit Head-of-Line-Blocking

HTTP/2 ersetzt die Warteschlange des Vorgängers durch mehrere Streams auf einer Verbindung. Statt sechs gleichzeitiger Verbindungen mit je einer Anfrage dürfen hunderte Antworten parallel übertragen werden. In einem Praxistest sank die Ladezeit des ersten Bildschirms von 3,4 auf 2,1 Sekunden – allein durch den Protokollwechsel, ohne eine Zeile Anwendungscode zu ändern.

##Was ist Head-of-Line-Blocking?

In HTTP/1.1 muss eine Antwort vollständig übertragen sein, bevor die nächste auf derselben Verbindung beginnt. Ist die erste eine langsame dynamische Seite und die zweite eine kleine Stildatei, wartet die Stildatei. Der Browser umgeht das mit mehreren Verbindungen, was aber zusätzliche Verbindungsaufbauten und doppelte Übertragungsfenster kostet.

##Wie löst HTTP/2 das?

Jede Anfrage bekommt einen eigenen Stream, und die Streams werden in kleine Rahmen zerlegt, die sich eine Verbindung teilen. Eine große Antwort blockiert eine kleine damit nicht mehr. Zusätzlich sind die Kopfzeilen komprimiert, was bei vielen Cookies und mehrfach wiederholten Feldern pro Anfrage mehrere hundert Byte einspart.

##Warum schaden alte Optimierungen jetzt?

Das Zusammenfassen vieler Dateien war eine Antwort auf die Verbindungsgrenze. Unter HTTP/2 kann eine einzige große Bündeldatei sogar nachteilig sein: Ändert sich ein Zeichen, muss der Besucher das gesamte Bündel neu laden. Ein Muster von mehreren kleineren Dateien lässt sich dagegen einzeln zwischenspeichern. Geprüft wird heute pro Datei statt pro Verbindung.

##Was bedeutet Priorisierung in HTTP/2?

Der Client kann angeben, welche Antworten wichtiger sind. In der Praxis hat sich das als uneinheitlich umgesetzt erwiesen – die meisten Browser haben die ursprünglich vorgesehene Steuerung wieder entfernt. Verlassen Sie sich deshalb nicht darauf, sondern laden Sie die Ressourcen des ersten Bildschirms frühzeitig und mit hoher Priorität, statt auf Protokollpriorisierung zu hoffen.

##Wie aktiviert man HTTP/2?

Es ist in jedem modernen Webserver eine Konfigurationszeile, verlangt aber Transportverschlüsselung. Ohne TLS handeln Browser es nicht aus. Der Wechsel läuft auf Anwendungsebene ab und ist damit unabhängig davon, ob Ihre Anwendung etwas davon weiß – prüfen Sie nach der Umstellung die Protokollversion in den Antwortkopfzeilen, nicht nur in der Serverkonfiguration.

##Welche Rolle spielt das Verbindungsfenster?

Eine erhebliche, wenn die Standardwerte klein sind. Ein zu kleines Übertragungsfenster bremst auch bei wenigen Verbindungen, weil der Sender immer wieder auf Bestätigungen wartet. In einem Fall hob das Anpassen des Anfangsfensters den Durchsatz einer Verbindung im Mobilfunknetz von 1,2 auf 3,8 Megabit pro Sekunde – bei gleicher Latenz.

##Wann reicht HTTP/2 nicht?

Wenn einzelne Pakete verloren gehen. Auf einer Verbindung mit Paketverlust blockiert der Verlust eines Rahmens alle Streams, weil die darunterliegende Transportschicht die Reihenfolge garantieren muss. Das ist der Punkt, den HTTP/3 über UDP mit unabhängigen Streams adressiert. Bei stabilen Verbindungen bringt der Schritt dorthin meist deutlich weniger als der Schritt von HTTP/1.1 zu HTTP/2.

##Was ändert sich bei der Fehlersuche?

Die Werkzeuge zeigen plötzlich andere Zahlen. Weil Antworten sich eine Verbindung teilen, sind Wartezeiten nicht mehr einer einzelnen Datei zuzuordnen, und der Wasserfall zeigt die Rahmen in der Reihenfolge ihres Eintreffens. Wer die alte Denkweise beibehält und nach der langsamsten Datei sucht, findet sie nicht mehr auf dieselbe Weise.

##Erst messen, dann bündeln

Prüfen Sie, ob Ihre Seite überhaupt noch von den alten Gegenmaßnahmen profitiert, bevor Sie Bündelung und Aufteilung neu sortieren. Messen Sie die Zahl der Anfragen, die Menge der übertragenen Bytes und die Ladezeit des ersten Bildschirms vor und nach dem Protokollwechsel. Der Wechsel selbst kostet keine Anpassung im Anwendungscode – genau deshalb lohnt er sich als erster Schritt.