© Fotograf, 123RF.com

HTTP 1.1 ist in die Jahre gekommen und bremst das Surfen im Web. Abhilfe verspricht die Nachfolgeversion HTTP 2.0. Was wird sich für Admins und Nutzer ändern?

HTTP 2.0 – so heißt offiziell die neue Version des bekannten Netzwerkprotokolls. Die erfolgreiche Vorgängerversion standardisierte der RFC 2616 [1] bereits 1999. Seit dieser Zeit hat sich das Web allerdings stark gewandelt. Moderne Webseiten bestehen aus vielen Elementen, die Browser nacheinander laden müssen: Skripte, CSS-Dateien, Bilder, Werbe-Elemente und vieles mehr gehört zu einer einzelnen Webseite.

Die Top-1000-Websites bestanden 1999 nur aus etwa zehn Objekten, doch allein in den Jahren 2009 bis 2012 verdoppelte sich die Anzahl der Objekte von 50 auf 100. Dadurch stieg von 2010 bis 2012 trotz höherer Bandbreiten die durchschnittliche Ladezeit um 48 Prozent [2]. Um Netzwerkressourcen effizienter nutzen zu können und um die Latenz zu verringern, war eine Anpassung des Webstandards überfällig.

Die neue Version ist zu HTTP 1.1 weitgehend abwärtskompatibel, weil Methoden, Statuscodes, URIs und Header gleich bleiben [3]. Bereits existierende Webapplikationen brauchen keine Änderung. Neue Applikationen können jedoch von den neuen Funktionen profitieren. Gängige HTTP-Anwendungsfälle, etwa Desktop-Webbrowser, mobile Webbrowser, Web-APIs, Webserver, Proxyserver, Firewalls und Content Delivery Networks, unterstützt die neue Version, die das Surfen beschleunigen soll.

Zu den wichtigen Änderungen gehören daher die Komprimierung der Header, eine Server-Push-Funktion, die Behebung des Head-of-Line-Blocking und paralleles Laden mehrerer Ressourcen über eine einzige TCP-Verbindung. Wer den Effekt dieser neuen Funktionen richtig einordnen will, muss einen Blick auf den bisherigen Stand von HTTP 1.1 werfen, der in Kombination mit TCP das Surfen im Web bremst.

Das Laden einer Website beginnt bei HTTP 1.x mit einer Zwangspause, weil zunächst eine TCP-Verbindung aufzubauen ist. Der Verbindungsaufbau mit Drei-Wege-Handschlag erzeugt einen Overhead, den verbindungslose Transportprotokolle wie UDP bewusst vermeiden. TCP aber braucht Verbindungen, weil es nur so eine höhere Zuverlässigkeit gewährleisten kann. HTTP 1 benötigt für jede einzelne HTTP-Anfrage eine separate TCP-Verbindung, weil es die nach der Antwort des Servers schließt.

Keep-Alive und Pipelining

Um Roundtrips beim Verbindungsaufbau zu vermeiden, führte HTTP 1.1 persistente Verbindungen ein. Eine zwischen HTTP-Client und -Server aufgebaute Verbindung gilt als persistent, wenn sie nach der Übertragung einer Ressource nicht gleich abgebaut wird, sondern die Möglichkeit besteht, weitere HTTP-Abfragen zu senden. Persistente Verbindungen sind gekennzeichnet durch den Header »Connection: Keep-Alive« .

Wenn ein Browser beispielsweise eine Webseite mit zwei Bildern per HTTP 1.1 lädt, reicht schon eine persistente Verbindung aus. Jedoch ist das Laden relativ langsam, weil ein Client erst die empfangenen Daten verarbeitet, bevor er weitere anfordert. Dieses Problem erkannte man frühzeitig und versuchte es durch Pipelining in HTTP 1.1 zu lösen.

HTTP-Pipelining zahlt sich besonders bei Verbindungen mit hoher Latenz aus, die so innerhalb einer TCP-Verbindung mehrere HTTP-Anfragen senden, ohne auf die zugehörigen Antworten warten zu müssen. Pipelining ist prinzipiell bei idempotenten HTTP-Operationen wie »GET« , »HEAD« , »PUT« und »DELETE« nutzbar. Leider ist es kaum verbreitet: Nur wenige Server und Browser unterstützen es.

Der Grund für die geringe Verbreitung dieses Feature ist eine in der Praxis schwer umzusetzende Anforderung: Die Antworten des Servers müssen die Reihenfolge der Anfragen einhalten. Einige Server-Implementierungen bearbeiten jedoch Anfragen parallel und antworten, sobald Ergebnisse vorliegen. Falls der Client mehrere Abfragen abgeschickt hat und die Bearbeitung der ersten länger dauert als die der zweiten, erhält der Client die Antworten in der falschen Reihenfolge, und das widerspricht der HTTP-Spezifikation.

Für statische Inhalte mag die Reihenfolge keine Rolle spielen, aber für dynamisch berechnete ist die Reihenfolge wichtig, weil sonst eventuell ein verfälschtes Ergebnis entsteht. Um die korrekte Reihenfolge sicherzustellen, muss der Server die Anfragen aufreihen und dann nacheinander abarbeiten, sodass sich die Performance-Vorteile relativieren.

Head-of-Line-Blocking

Weil Pipelining sich nicht durchsetzte, stellt HTTP 1.1 seine Anfragen nacheinander. Ein Client muss die Antwort der ersten Anfrage also abwarten, bevor er mit der zweiten fortfahren kann. Falls für die erste Anfrage eine große Datenmenge zu übertragen ist, wird die zweite entsprechend lange blockiert, auch wenn bei ihr nur wenige Daten zu übertragen wären.

In der Praxis wäre das Laden einer kompletten Webseite damit zu langsam, wenn Webbrowser nicht gleichzeitig mehrere TCP-Verbindungen öffnen könnten. Firefox beispielsweise setzt standardmäßig sechs persistente Verbindungen pro Host ein.

Weil auch das zu wenig ist, um die vielen einzelnen Ressourcen einer Webseite schnell zu laden, greifen manche Websites zu Domain Sharding. Sie verteilen die Ressourcen der Website auf mehrere Hosts, sodass der Webbrowser noch mehr Verbindungen öffnen kann. Die zusätzlichen Sockets der Verbindungen kosten jedoch auf Client- und Server-Seite Speicherplatz und CPU-Zeit.

Um dem Problem zu begegnen, entwickelte Google das experimentelle Netzwerkprotokoll SPDY [4]. Teile dieses Protokolls übernahm HTTP 2.0. Head-of-Line-Blocking vermeidet es durch Multiplexing, weil es gleichzeitig mehrere Ressourcen überträgt (Abbildung 1). Mit dieser Technik ist es möglich, die Übertragung einer kleinen Ressource abzuschließen, während die Datenübertragung einer großen Ressource noch andauert.

Abbildung 1: Parallele Streams ermöglichen die gleichzeitige Datenübertragung in beide Richtungen.

HTTP-2.0-Verbindungen

Mit HTTP 2.0 muss theoretisch nur eine TCP-Verbindung zwischen Client und Server existieren. Der Datenverkehr in dieser Verbindung wird fortan in mehrere Streams eingeteilt, die eine oder mehrere Nachrichten bidirektional austauschen können. Eine Nachricht realisiert entweder eine Clientanfrage oder eine Serverantwort. Die Nachrichten bestehen ihrerseits aus Frames, den kleinsten Kommunikationseinheiten von HTTP 2.0. Jeder Frame hat einen Header, mit dem er eindeutig einem Stream zugeordnet ist. Statt Text verwendet HTTP 2.0 ein Binärformat für die Frames.

Zwischen Client und Server lassen sich innerhalb einer Verbindung praktisch beliebig viele Streams öffnen, um mehrere Nachrichten gleichzeitig zu senden. Mit der eindeutigen Nummerierung der Streams halten beide Seiten die ausgetauschten Nachrichten auf beiden Seiten auseinander. Das Multiplexing der neuen HTTP-Verbindung revolutioniert die Kommunikation zwischen Browser und Server im Web. Durch den Mechanismus dürfte ein Browser bereits neue Anfragen abschicken, während der Server noch Datenpakete überträgt.

Zudem lassen sich die Header komprimieren, um zusätzliche Performancevorteile zu erzielen. Hpack [5] ist das Komprimierungsformat zur effizienten Repräsentation der Headerfelder in HTTP 2.0. Ursprünglich wollte man für diesen Zweck Gzip einsetzen, doch wegen des CRIME-Exploit wurde entschieden, eine weniger effiziente, dafür aber sicherere Methode zu benutzen [6].

Push-Optionen

Wenn erst einmal eine Verbindung zwischen Client und Server aufgebaut ist, kann der Server auch selbstständig weitere Ressourcen zum Browser übertragen. Fordert beispielsweise ein Webbrowser mit »GET« eine HTML-Seite an, dann kann der Webserver antizipieren, dass der Browser als Nächstes die in der HTML-Seite referenzierten Bilder, Skripte und Stylesheets haben will. Der Server kann diese Ressourcen selbstständig zum Browser pushen. Die Push-Option optimiert dabei nicht nur das erstmalige Laden von Webseiten, sondern auch deren Aktualisierung (Abbildung 2).

Abbildung 2: Mit Push-Operationen überträgt HTTP 2.0 vorausschauend Seitenelemente.

Websockets, die die HTML-Version 5 eingeführt hatte, werden durch die Push-Option trotzdem nicht überflüssig. Es ist sogar das Gegenteil der Fall: Mit den Server-Sent-Events und den Websockets von HTML 5 lässt sich nämlich eine gewöhnliche HTTP-Verbindung zur Übertragung von Push-Notifications vom Server zum Client nutzen. HTTP ist an eine strengere Anfrage-Antwort-Semantik gebunden. Im Vergleich dazu erlauben die Server-Sent-Events und die Websockets Vollduplex-Kommunikation.

HTTP 2.0 kann die Streams zudem priorisieren und so beispielsweise Text mit höherer Priorität als Bilder übertragen, um die auf Client-Seite wahrnehmbare Latenz auf diese Weise zusätzlich zu verringern. Prinzipiell sollte ein Server einem Browser zuerst die Daten zur Verfügung stellen, die der Browser zum Aufbauen der Webseite benötigt. Im Anschluss daran folgen alle weiteren Inhalte.

Umstieg auf HTTP 2.0

Der Umstieg auf HTTP 2.0 wird aller Voraussicht nach etliche Jahre in Anspruch nehmen. Auch lässt sich die neue Protokollversion nur verwenden, wenn sowohl Client als auch Server sie unterstützten. Aus diesem Grund werden also in Zukunft beide Protokolle parallel im Web koexistieren. Praktisch bedeutet das, dass der Webbrowser einen Server zunächst mit der alten Version 1.1 kontaktiert und anschließend den Upgrade-Mechanismus nutzt, falls auch der Server HTTP 2.0 unterstützt.

Gegenwärtig verwenden Browser für diese Upgrade-Anfrage eine verschlüsselte HTTP-Anfrage. Falls ein Server die Anfrage akzeptiert, wechselt er automatisch zu HTTP 2.0. Der Einsatz von TLS ist allerdings nicht zwingend für HTTP 2.0 erforderlich. Laut Spezifikation lässt sich HTTP 2.0 auch unverschlüsselt über TCP einsetzen.

Trotzdem unterstützen die großen Browserhersteller Mozilla und Google HTTP 2.0 gegenwärtig nur in Kombination mit TLS. Auf diese Weise wollen sie die Verschlüsselung im Web stärken. In der Spezifikation ist vorgeschrieben, dass – wenn TLS zum Einsatz kommt – mindestens TLS 1.2 zu verwenden ist. Außerdem ist es nicht erlaubt, die Datenkomprimierung in Kombination mit TLS zu benutzen.

Möchte ein Anwender wissen, ob sein Webbrowser bereits HTTP 2.0 unterstützt, dann kann er zum Beispiel die Webseite von Akamai [7] besuchen. Schaut er dort mit einem passenden Webbrowser vorbei, kann er auch gleich eine Demo betrachten, die ihm eindrucksvoll zeigt, wie schnell sich Bilder mit HTTP 2.0 im Vergleich zu HTTP 1.1 laden lassen.

Ausblick

Die neue Protokollversion bietet nicht nur für Benutzer, sondern auch für die Webserver Vorteile, denn beide Seiten sparen beträchtlich Speicherplatz und CPU-Zeit ein. Nicht ohne Grund jedenfalls forscht Google bereits seit fünf Jahren an effizienteren Alternativen zu HTTP 1.1. Weil durch die Push-Option schon eine Verbindung zwischen Client und Server ausreicht, werden sich die komplexen Infrastrukturen für Domain Sharding ändern.

Auch Techniken zur Verringerung der Ressourcenanzahl, zum Beispiel CSS-Sprites und Ressourcen Inlining, dürften bald überflüssig sein. Welche Auswirkungen die neuen Funktionen auf das Design von Web-APIs haben werden, bleibt abzuwarten.