HTTP/2 - HTTP Version 2.0

HTTP/2 ist ein Anwendungsprotokoll für das World Wide Web (WWW). Mit diesem Protokoll werden Dateien oder Datenströme von einem Webserver zur Darstellung und Wiedergabe von einem Browser geladen.
HTTP/2 soll die alten HTTP-Version 1.0 und 1.1 nicht ablösen, sondern als Alternative dienen und hauptsächlich die Datenübertragung beschleunigen.

HTTP 1.0 stammt noch aus dem Jahr 1996 und HTTP 1.1 von 1999. Das heißt, das Protokoll zur Übertragung von Daten zwischen Anwendungen hat sich nicht geändert. Mit HTTP/2 hat einen klaren Fokus auf Performance und ermöglicht den Nutzern einen effizienteren Umgang mit Netzwerkressourcen.
Die wesentlichen Bestandteile von HTTP bleiben dabei gleich. Zum Beispiel das Client-Server-Prinzip. Es ändert sich lediglich die Art und Weise, wie die Daten zwischen einem Client und Server ausgetauscht werden.

Im Vordergrund von HTTP/2 steht eine höhere Nutzerzufriedenheit durch kürzere Ladezeiten von Webseiten. Was sich letztlich auf bessere Platzierungen in den Google-Suchergebnissen und höhere Konversionsraten und Umsatz auswirkt.

SPDY (Speedy)

Der Anstoß für einen Neuentwurf von HTTP lieferte Google mit dem Protokoll SPDY, dass Google mit seinen Internet-Anwendungen weitflächig nutzte. Der erste IETF-Entwurf für HTTP/2 beruhte deshalb auf dem von Google entwickelten Protokoll SPDY.
SPDY reduziert die übertragene Datenmenge im Header und verschlüsselt alle Verbindungen. Zudem transportiert SPDY mehrere Datenströme über eine TCP-Verbindung, priorisiert diese und somit das Laden einzelner Elemente einer Webseite und kann auch Daten vom Server zum Client pushen.
Zahlreiche Eigenschaften von SPDY sind in die HTTP-Version 2 eingeflossen und verkürzen die Ladezeit und verringern die Latenz der Übertragung.

Leistungsmerkmale von HTTP/2

Bei den Leistungsmerkmalen von HTTP/2 geht es hauptsächlich darum, die Ladezeit zu optimieren bzw. zu verkürzen.

  • Kompression der Paket-Header mit HPACK (Header Compression)
  • Multiplexing
  • Priorisierung von Ressourcen (Resource Prioritization)
  • Server Push

Das Multiplexing und die Header-Kompression verkürzen die Ladezeit sofort. Um die Vorteile der Priorisierung und Server Push zu bekommen, ist ein gewisser Entwicklungsaufwand erforderlich.

Binärprotokoll

HTTP/2 ist binär, weil es von Software und nicht von Menschen lesbar sein soll. Die binäre Form optimiert den Prozess der Kommunikation zwischen Browser und Server.

Header Compression / HPACK

Mit HPACK werden die Header-Felder komprimiert, wodurch sich die Latenz verringert. Die bestehende HTTP-Semantik bleibt dabei erhalten. Zwar erhöht die Kompression den Bedarf an Rechenleistung. Allerdings geht man davon aus, dass davon genug vorhanden ist und die zeitliche Verzögerung durch Kompression und Dekompression geringer ist, als die Übertragung aller HTTP-Header.
Bei einer durchschnittlichen Webseite entsteht durch die HTTP-Requests erheblicher HTTP-Overhead, der durch die Header-Kompression wieder reduziert wird.

HTTP/2-Multiplexing

Vergleich HTTP 1.1, HTTP/2 Multiplexing und HTTP/2 Server Push

Bei HTTP Version 1.0 und 1.1 wird pro HTTP-Request/Response eine eigene TCP-Verbindung geöffnet. Über die erste TCP-Verbindung erhält der Browser eine HTML-Datei, in der weitere Dateien zum Beispiel CSS, Javascript, Bilder usw. referenziert sind. Für jede Referenz muss der Browser einen weiteren HTTP-Request/Response und damit jeweils eine eigene TCP-Verbindung initiieren. Bei beispielsweise 10 referenzierten Dateien öffnet ein Browser üblicherweise 6 parallele Verbindungen und nach abgeschlossener Übertragung noch weitere 4. Je nach aufgerufener Webseite können das aber hunderte TCP-Verbindungen sein. Das dauert und kann den Aufbau einer Website verzögern.

HTTP/2 ermöglicht per Multiplexing unbegrenzt viele HTTP-Requests über eine einzige TCP-Verbindung, sofern keine Fremdquellen geladen werden. Für Verbindungen zu anderen Servern wird jeweils eine eigene TCP-Verbindung aufgebaut.

Priorisierung von Ressourcen mit HTTP/2

Bei der Priorisierung von Ressourcen geht es darum, einzelne HTTP-Requests zu priorisieren, um bei knapper Bandbreite wichtige Daten zuerst und weniger wichtige Daten später zu laden. Manche Ressourcen sind für die Darstellung einer Webseite wichtiger als andere. So müssen Style-Informationen in Form von CSS-Dateien schneller geladen werden als Bilder.
Im Prinzip geht es darum, die Bestimmung der Reihenfolge der zu ladenden Daten und Dateien nicht dem Client zu überlassen, sondern serverseitig zu bestimmen.
Es ist immer noch so, dass der Browser jede Ressource mit einem Request anfordert, er beim Server aber gleichzeitig anfragt, ob die Ressource von einer anderen abhängig ist. Anhand eines Abhängigkeitsbaums kann eine Ressourcen höher oder niedriger gewichtet sein.
Dazu müssen dem Server die Abhängigkeiten bekannt sein, oder er muss über die Logik verfügen, diese herauszufinden.

Server Push mit HTTP/2

HTTP funktioniert nach dem Client-Server-Prinzip. Das heißt, eine Kommunikation mit HTTP wird immer vom Client durch einen Request initiiert und vom Server mit einem Response beantwortet. In diesem Modell ist es nicht vorgesehen, dass der Server Ressourcen von sich aus an einen Client sendet.
HTTP/2 bricht mit diesem Prinzip und ermöglicht es, dass der Server Daten zu einem Client auch ohne Request sendet. Das nennt man „Server Push“.

Server Push mit HTTP/2 setzt trotzdem eine bestehende Verbindung zum Client mit einem initiierten Request voraus. Dabei sendet der Server dem Client Ressourcen, ohne dass der Client diese mit einem Request angefragt hat. Ein Bespiel wäre, dass der Client eine HTML-Datei per Request anfragt und der Server diese HTML-Datei und alle darin referenzierten CSS- und Javascript-Dateien ungefragt mitsendet.

Damit das funktioniert müssen sowohl Browser als auch Server das Leistungsmerkmal Server Push beherrschen. Außerdem muss der Server wissen, welche Ressourcen der Browser benötigt, bevor dieser die Ressourcen tatsächlich anfragt. Der Prozess der Anzeige einer Website erfolgt durch die vorzeitige Verfügbarkeit der Daten wesentlich schneller.

Priorisierung vs. Server Push

Server Push ist im Prinzip das Gegenstück zur Priorisierung von Ressourcen. Während der Browser bei der Resource Prioritization, also der Klassifizierung der Wichtigkeit der Ressourcen, durch Requests noch beteiligt ist, kann der Server durch Server Push aktiv Ressourcen an den Client senden, um dem Browser einen expliziten Request danach zu ersparen.
Zwar werden durch Server Push die Anzahl der Kommunikationsvorgänge zwischen Server und Client reduziert, aber verbraucht in manchen Fällen auch unnötig Bandbreite. Beispielsweise, weil der Client von vorherigen Requests die Ressourcen bekommen und in seinem Cache gespeichert hat. Deshalb sollte Server Push nur in Maßen verwendet werden.

Sicherheit

Die Sicherheit bei einem Anwendungsprotokoll wie HTTP wird mit TLS realisiert, dass sich um die Authentifizierung und Verschlüsselung kümmert. Ursprünglich sollte HTTP/2 an die Verwendung von TLS gebunden sein. Das Problem dabei wäre gewesen, dass der TLS-Zwang die Migration zu HTTP/2 gehemmt hätte. Deshalb ist TLS in HTTP/2 optional. Die Unterstützung für TLS 1.2 ist vorgeschrieben, allerdings sollen auch unverschlüsselte Verbindungen möglich sein.

Kritische Stimme zu HTTP/2

Wenn man HTTP/2 aktiviert, dann kann man Vorteile aus der Header-Kompression, dem Multiplexing und TLS 1.2 ziehen. Aber, dafür würde es ausreichen weiterhin HTTP 1.1 zu verwenden und Pipelining, Content-Kompression und TLS 1.2 vorzuschreiben. Dabei könnte man auf die Nachteile von HTTP/2 verzichten.

Was sind die Nachteile von HTTP/2?

Multiplexing: Beim Multiplexing mit HTTP/2 werden alle Requests/Responses über eine TCP-Verbindung übertragen. Dazu muss man wissen, dass innerhalb des Internets alle TCP/IP-Verbindungen gleich behandelt werden. Das bedeutet, wenn man für mehrere HTTP-Verbindung nur eine TCP-Verbindung aufbaut, dann bekommt man auch nur die Bandbreite für eine TCP-Verbindung. Dagegen würde man für mehrere TCP-Verbindungen insgesamt mehr Bandbreite bekommen.
Eine TCP-Verbindung bedeutet auch, dass man sich einen Single-Point-of-Failure einhandelt. Wenn Paketverluste auftreten, dann wirkt sich das auf diese eine TCP-Verbindung mit allen HTTP-Verbindungen aus. Die gesamte Verbindung bleibt stehen oder wird langsamer. Bei HTTP 1.1 mit mehreren TCP-Verbindungen wäre nur eine TCP-Verbindung und nicht alle betroffen.
Desweiteren muss der Server entscheiden, was er mit welcher Priorität über diese eine TCP-Verbindung überträgt. Beispielsweise beim Streaming und der parallelen Übertragung von Status-Informationen. Hierfür muss im Server eine Logik implementiert sein. Faires Scheduling reicht hier aber nicht aus. Das muss schon intelligent sein. Es muss in die Inhalte hineinschauen. Dazu muss der Server die Inhalte parsen oder besser gleich rendern. Aber, woher will der Server wissen, was der Client mit den Ressourcen macht?

Ressourcen-Priorisierung: Das heißt, der Browser gibt dem Server vor, welche Ressourcen mit welcher Priorität gesendet werden sollen. Die Frage ist, warum schickt der Server die Ressourcen nicht gleich in der Reihenfolge, wie sie angefragt werden? Warum der ganze Aufwand?

Header-Kompression: Die Idee mit der Header-Kompression kommt daher, weil der HTTP-Header ziemlich umfangreich sein kann und je nach HTTP-Verbindung mehrfach redundant übertragen wird. Anstatt den Header zu komprimieren hätte man die einzelnen Bestandteile hinterfragen und auszumisten können.

Fazit: Es gibt gute Gründe, warum sich HTTP mit der Version 1.1 seit 1999 hat halten können. Und es gibt noch mehr gute Gründe, warum man beide Versionen parallel benutzen kann. Richtige Probleme mit HTTP 1.1 haben wir keine. Wenn Webseiten-Betreiber ihre Webseiten mit hunderten Ressourcen, die alle einzeln angefordert werden müssen, überfrachten, dann ist das nicht das Problem von HTTP, sondern des Betreibers. Dann will der das so.
Stattdessen wird mit HTTP/2 viel Aufwand für einen geringfügigen Geschwindigkeitsvorteil betrieben.

Aufgaben und Übungen mit dem Raspberry Pi

Für den Raspberry Pi gibt es verschiedene Webserver. Am einfachsten ist es mit dem "lighttpd". Hier muss man am wenigsten konfigurieren und die Installation ist effektiv mit einem Befehl auf der Kommandozeile erledigt.

Übersicht: HTTP

Weitere verwandte Themen:

Teilen

Produktempfehlungen

Alles was Sie über Netzwerke wissen müssen.

Netzwerktechnik-Fibel

Die Netzwerktechnik-Fibel ist ein Buch über die Grundlagen der Netzwerktechnik, Übertragungstechnik, TCP/IP, Dienste, Anwendungen und Netzwerk-Sicherheit.

Das will ich haben!

Alles was Sie über Netzwerke wissen müssen.

Netzwerktechnik-Fibel

Die Netzwerktechnik-Fibel ist ein Buch über die Grundlagen der Netzwerktechnik, Übertragungstechnik, TCP/IP, Dienste, Anwendungen und Netzwerk-Sicherheit.

Das will ich haben!