Seite 4: Was HTTP 2.0 verspricht

Inhaltsverzeichnis

Erst HTTP 2.0 dürfte die Situation grundlegend verbessern. Pro Server soll nur noch eine TCP-Verbindung aufgebaut werden. Das entlastet die TCP-Stacks der Server. Auf dieser einen Verbindung unterteilt HTTP 2.0 den Datenverkehr in Streams. Das wird möglich, weil HTTP 2.0 nicht mehr das Textformat verwendet, sondern ein Binarformat mit Frame-Headern. Jeder Frame enthält eine eigene Stream-ID. Dadurch kann HTTP 2.0 mehrere Resourcen auf einmal verschicken. Parallel dazu können auf einem speziellen Stream Client und Server Kontroll-Informationen und Requests austauschen.

Der Browser kann mit HTTP 2.0 also auf der einen TCP-Verbindung mehrere Resourcen laden und spart die RTTs, die mit HTTP 1.1 für den Aufbau der separaten TCP-Verbindungen erforderlich sind. Dabei entsteht aber das neue Problem, dass sich Clients die Senderichtung durch zu viele Requests selbst verstopfen können. Damit das nicht ganz so schlimm wird, können sie zusätzlich die Request-Header komprimieren.

Client und Server können beide eine Priorität für Streams festlegen und so dafür sorgen, dass wichtige Resourcen schnell und vollständig beim Client ankommen. Das lässt sich zum Beispiel dafür verwenden, um Texte umgehend anzuzeigen, damit der Benutzer schon mal mit dem Lesen beginnen kann. Bilder werden dann mit kleinerer Priorität übertragen, weil sie meistens umfangreicher sind als die Textinhalte und daher ohnehin deutlich länger für die Übertragung brauchen.

Außerdem kann der Server von sich aus Daten senden, von denen er weiß, dass sie der Browser umgehend benötigen wird (Server Push). Beispiele sind Style Sheets oder Script-Dateien. Der Client sammelt diese entweder in seinem Cache oder bricht den Transfer auf dem zugehörigen Stream ab, falls er die vom Server gepushten Daten nicht oder nicht mehr benötigt -- etwa, weil der Surfer die Seite verlassen hat.

ein Webseiten-Transfer mittels HTTP 2.0
Aktion	Dauer
Der Client baut die TCP-Verbindung zum Server auf	1 RTT für SYN/SYN-ACK
Der Client sendet den GET-Befehl, um die Datei index.html zu holen und erhält per Server Push die Dateien Script.js und Style.css ohne sie selbst anfordern zu müssen	1 RTT

Ein Browser und ein Server, die alle Möglichkeiten der neuen Technik nutzen, erledigen die Übertragung derselben Webseite weitaus schneller als Browser und Server, die nur HTTP 1.1 nutzen. Die einzelnen Komponenten wie Texte, Bilder oder Dateien sind zwar gleich lang unterwegs, aber die Anforderung und der Versand laufen umgehend ab und schöpfen Internet-Leitungen daher besser aus:

Dabei kann der Server zusätzlich gewichten, welche der beiden Dateien wichtiger sind und daher zuerst beim Client ankommen sollen, Script.js oder Style.css. Da der Browser zum Abarbeiten des Scripts zusätzliche Zeit benötigt, dürfte er Script.js auf einem höher priorisierten Stream verschicken.

Weit bessere Auslastung

Mit HTTP 2.0 lässt sich eine Verbindung also weit besser auslasten als mit HTTP 1.1; der Server sendet alle Resourcen nacheinander, ohne Verzögerungen. Wenn man heute eine größere Webseite abruft, kann das ein paar Sekunden dauern, also gemessen an den technischen Möglichkeiten sehr lange. Dabei ist die Leitung immer nur vorübergehend ausgelastet. Mit HTTP 2.0 wird die Seite aus Sicht des Surfers fast umgehend da sein.

Etliche namhafte Hersteller arbeiten inzwischen an der Umsetzung der neuen Technik in ihren Produkten, obwohl sie noch nicht vollends standardisiert ist. Immerhin steckt die Vorläufertechnik SPDY schon in den Browsern Chrome, Firefox Internet Explorer, Amazon Silk und Opera.

Es gibt auch schon einige Webserver, die SPDY nutzen, darunter Apache mittels eines von Google entwickelten Moduls, der Jetty Web Server oder auch NGINX. Unter den Webseiten-Anbietern findet die Technik ebenfalls Zuspruch. Neben Google haben zum Beispiel auch Twitter, Facebook und WordPress ihre Server mit SPDY bestückt. Ausgehend von dieser Basis kann man annehmen, dass HTTP 2.0 schnell umgesetzt wird, zumal es auch abwärtskompatibel ist. (dz)