zurück zum Artikel

Wie HTTP 2.0 das Surfen beschleunigt

Praxis & Tipps | Praxis

Das Hypertext Transfer Protocol steht kurz vor einer maßgeblichen Erneuerung. Warum, so könnte man sich fragen, braucht man die überhaupt, das Surfen klappt doch prima. Dafür gibt es drei Gründe: Geschwindigkeit, Geschwindigkeit und... Geschwindigkeit.

Die Internet Engineering Task Force [1], IETF, will das Verfahren, mit dem Browser Webseiten anfordern und Server ausliefern, grundlegend renovieren. Aktuell im Einsatz ist das Hypertext Transfer Protocol 1.1. Schaut man sich die Entwürfe für die neue Version 2.0 [2] an, kann man bereits erahnen: HTTP 2.0 könnte ein großer Wurf werden. Das scheint auch dringend erforderlich, denn seit der Entstehung des WWW haben sich die Webseiten von einfachen zu komplexen Dokumenten gewandelt. Moderne Webseiten bestehen aus vielen Elementen und die muss der Browser nacheinander holen, zum Beispiel Script-Dateien, Style Sheets, Bilder, Werbeeinblendungen und anderes mehr. Nicht selten liegen diese Elemente auf unterschiedlichen Hosts eines oder sogar verschiedener Unternehmen verstreut. Der Abruf solcher Webseiten kann sich selbst bei schnellen VDSL- oder Kabelmodem-Anschlüssen spürbar hinziehen, denn die Leitungen werden nicht ausgelastet.

Es war der Suchmaschinenmarktführer Google, der mit seiner Initiative "make the web faster" neuen Schwung in die HTTP-Entwicklung [3] gebracht hat. Zusammengefasst unter dem Namen SPDY hatte das Unternehmen diverse wesentliche Verbesserungen aufgelegt [4] und zunächst im hauseigenen Browser Chrome sowie den Webservern eingebaut. Als dann weitere Verfechter aus der Industrie hinzukamen, unter anderem Mozilla mit seinem Firefox-Browser und Amazon, gab die IETF einer Arbeitsgruppe grünes Licht für die Umsetzung neuer Ideen in der Arbeitsgruppe HTTPbis. Dieser nahm sich zwar SPDY Anfang 2012 als Arbeitsgrundlage, entwickelte aber dann etliche Änderungen und Verbesserungen, die nun in den offiziellen Standard HTTP 2.0 einfließen. Die wesentlichen Eckpunkte sollen nun bis Ende April 2014 nach einer Terminverschiebung ab Juni festgeklopft werden, bevor das Verfahren später zur Standardisierung bei der IETF eingereicht wird; den Zeitplan hat die IETF hier veröffentlicht [5].

Die Autoren versprechen eine effizientere Nutzung der Netzwerk-Ressourcen und kürzere Latenzen. Verbesserungen sollen aber auch eine Kompression der Header der IP-Pakete sowie Multiplex- und Push-Techniken bringen. Browser können mittes Multiplexing mehrere Messages gleichzeitig über eine Verbindung beziehen und Server können Elemente im voraus, also ohne Anfrage des Browsers pushen.

Das klingt interessant, erklärt aber noch nicht, wie diese Neuerungen zu schnellerem Aufbau von Webseiten führen sollen. Wie das im Detail passiert, ist eine spannende Geschichte. Mehr als ein bißchen Netzwerk-Einmaleins braucht man aber nicht, um die Zusammenhänge zu verstehen.

Mit dem neuen Binary-Framing-Mechanismus ändert HTTP 2.0 die Art, wie Client und Server kommunizieren. Mittels Streams können sie mehrere Elemente verschränkt, also per Multiplexverfahren gleichzeitig übertragen. Darin setzen sich Messages aus einzelnen Frames zusammen. Die Frame-Header enthalten Stream-IDs, sodass sie der Empfänger einzelnen Streams zuordnen, also demultiplexen kann.
Mit dem neuen Binary-Framing-Mechanismus ändert HTTP 2.0 die Art, wie Client und Server kommunizieren. Mittels Streams können sie mehrere Elemente verschränkt, also per Multiplexverfahren gleichzeitig übertragen. Darin setzen sich Messages aus einzelnen Frames zusammen. Die Frame-Header enthalten Stream-IDs, sodass sie der Empfänger einzelnen Streams zuordnen, also demultiplexen kann.

Die Surf-Geschwindigkeit hängt offenkundig zunächst von der Kapazität der Verbindungsstrecke zwischen einem Client und einem Server ab. Wenig bekannt ist aber, dass diese Kapazität gerade beim Surfen bisher nur zum Teil genutzt werden konnte. Das liegt an der Teils umständlichen Implementierung des Hypertext Transfer Protocol, das viel Raum für Verbesserungsmöglichkeiten offenlässt. Als erstes Beispiel sei der Verbindungsaufbau genannt. HTTP 1.0 benötigt für die Startphase, also noch bevor HTML-Elemente einer Webseite übertragen werden, für jede Anfrage (Request) eine separate TCP-Verbindung: Zuerst handeln der Client und der Server die TCP-Verbindung aus und dann erst sendet der Client die HTTP-Anfrage. Bei der Startphase laufen die Signale also zwei Mal zwischen den beiden Endstellen hin und her.

Die Signallaufzeit hängt von der Entfernung der beiden Endstellen ab und sie lässt sich leicht messen, etwa mittels dem Kommandozeilen-Tool Ping. Dieses ermittelt die Roundtrip-Time (RTT), also die Zeit, die verstreicht, bis ein ICMP-Paket vom Absender zum Empfänger gelangt und von diesem das Antwort-Paket beim ursprünglichen Absender eintrifft. Deshalb kann man in diesem Rahmen RTT als Zeiteinheit nutzen. Im konkreten Beispiel verstreichen bei der Startphase zwei RTTs; Pro Request ein RTT für den TCP-Aufbau und ein RTT für den HTTP-Request. HTTP 1.0 ist deshalb hinsichtlich der Startphase träge. Das merkt man um so mehr, je mehr Elemente einer Web-Seite auf unterschiedlichen Hosts verstreut sind. Für jeden Request, der an einen neuen Hosts gerichtet ist, verstreichen zwei RTTs – der Abruf zieht sich hin.

Client und Server können per HTTP 2.0 Daten bidirektional im Binärformat übermitteln. Besonders nützlich für den Client ist das neue Kompressionsverfahren, mittels dem er Frame-Header schrumpft und so den Durchsatz auf schmalen Uplinks verbessert.
Client und Server können per HTTP 2.0 Daten bidirektional im Binärformat übermitteln. Besonders nützlich für den Client ist das neue Kompressionsverfahren, mittels dem er Frame-Header schrumpft und so den Durchsatz auf schmalen Uplinks verbessert.

HTTP 1.1 hat demgegenüber eine Verbesserung mitgebracht: Damit lässt sich bei Abrufen von mehreren Elementen von einem Host immerhin die TCP-Verbindung wiederverwenden (Connection:
Keep-alive). Wenn also immer nur ein Server die Elemente einer Webseite liefert, werden nach der Startphase nur noch HTTP-Pakete übermittelt. Deshalb benötigt HTTP 1.1 pro Request nur noch eine RTT
(zum Beispiel GET + Response).

Das spart zwar Zeit, aber bei modernen Webseiten, die aus vielen Elementen aufgebaut sind, sind immer noch viele Requests erforderlich und jeder Abruf dauert mindestens eine RTT. Der Browser versucht Zeit zu sparen, indem er nicht abwartet, bis er den jeweiligen Response des Servers komplett erhalten hat. Statt dessen feuert er seine Anfragen ab, sobald er aus dem einlaufenden HTML-Code herausgelesen hat, welche erforderlich sind.

HTTP 1.1 sieht sogar Pipelining vor, das heisst, der Client dürfte zeitsparenderweise über dieselbe TCP-Verbindung weitere Requests zum selben Host abfeuern, während ein aktueller noch in Arbeit ist. Doch das gilt als unzuverlässig und ist standardmäßig deaktiviert. Deshalb bauen die Browser mit HTTP 1.1 sicherheitshalber für jeden weiteren Request zum selben Host eine separate TCP-Verbindung auf. Das tun sie auch schon während die Daten des aktuellen Requests auf der ersten TCP-Verbindung eingehen, warten also nicht dessen Ende ab. Um die Server nicht zu stark zu belasten, dürfen Clients mit HTTP 1.1 nicht mehr als 6 bis 8 TCP-Verbindungen öffnen; für jeden Verbindungsaufbau vergeht wieder eine RTT.

Die Konzeptionierung von HTTP 1.1 hat aber noch weiteren Raum für Verbesserungen gelassen. Das Verfahren ist nach dem Vorbild von RFC 822 als Textprotokoll aufgebaut, sodass Requests und deren Parameter im Klartext übertragen werden. Pro Request benötigt man mehrere 100 Bytes an Zusatzinformationen (HTTP Header). Schickt ein Client mehrere Requests gleichzeitig, summiert sich das und verstopft den Uplink. Das wird besonders bei schmalbandingen DSL-Anschlüssen spürbar und führt um so mehr zu Problemen, je mehr HTTP-Verbindungen gleichzeitig zum Server aufgebaut werden.

Und eine weitere Schwäche des Protokolls offenbart sich, wenn man das Verfahren analysiert, mit dem Browser ermitteln, ob sich Teile einer bereits zuvor abgerufenen Webseite in der Zwischenzeit geändert haben. Das passiert beispielsweise bei Nachrichten-Seiten ganz häufig am Tag, bei anderen vielleicht nur selten, aber mit HTTP 1.1 auf jeden Fall für den Client nicht vorhersehbar.

Um zu erfahren, ob sich eine Resource auf dem Server geändert hat, muss der Client zum Beispiel bei einem Reload-Befehl des Benutzers einen Request an den Server senden und eine RTT abwarten. Dann bekommt er entweder die Antwort "304 Not modified" oder "200 OK" und die aktualisierte Resource. Das ist schon mal besser als das Minimalverfahren, bei dem er eine RTT zum Abfragen von Änderungen braucht und dann eine weitere RTT zum Abruf der Resource mittels des GET-Befehls.

Beispiel für einen optimierten Webseitenabruf per HTTP 1.1
Aktion Dauer
Der Client baut die TCP-Verbindung zum Server auf 1 RTT für SYN/SYN-ACK
Der Client sendet GET für die Datei Index.html 1 RTT
Parsing: Der Client liest die Datei Index.html und stellt fest, dass er Script.js und Style.css noch laden muss 10 ms
Der Client sendet GET für Script.js auf der bestehenden Verbindung 1 RTT
Der Client baut eine zweite TCP-Verbindung auf 1 RTT
Der Client sendet GET für Style.css 1 RTT

Aktuelle Browser schöpfen fast alle Möglichkeiten von HTTP 1.1 aus. Ein Beispiel für dieses hoch optimierte Verfahren, sieht so aus:

Obwohl er script.js und style.css gleichzeitig über zwei TCP-Verbindungen holen kann, benötigt der Client für den Seitenaufbau mindestens vier RTTs plus die parse time für index.html. Mit HTTP 1.1 sind aber keine weiteren Verbesserungen möglich.

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.

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.


URL dieses Artikels:
http://www.heise.de/-2164146

Links in diesem Artikel:
[1] http://www.ietf.org/
[2] http://tools.ietf.org/html/draft-ietf-httpbis-http2-11
[3] https://www.heise.de/meldung/Google-will-das-Internet-beschleunigen-1250991.html
[4] http://googlecode.blogspot.de/2012/01/making-web-speedier-and-safer-with-spdy.html
[5] http://datatracker.ietf.org/wg/httpbis/charter/