Überholen erlaubt mit http/2

Eschborn, 21.04.2016
Der neue Standard http/2 wurde im Mai 2015 durch die Internet Engineering Task Force (IETF, siehe auch http://ietf.org) veröffentlicht und als Standard rfc7540 zusammen mit dem genutzten Komprimierungsverfahren HPACK (rfc7541) festgeschrieben. Fast 16 Jahre nach der Veröffentlichung von http/1.1 enthält http/2 nun wesentliche Neuerungen.

In großen Teilen basiert http/2 auf Googles http-Erweiterung spdy (sprich „speedy") und soll diese vollständig ersetzen. Google hat bereits Anfang 2015 das Ende der Unterstützung von spdy zugunsten http/2 angekündigt (http://blog.chromium.org/2015/02/hello-http2-goodbye-spdy-http-is_9.html). Intern – z.B. bei der Konfiguration des Chrome-Browsers – wird http/2 teilweise auch als spdy/4 bezeichnet.

Die Neuerungen von http/2 gegenüber dem Vorgänger http/1.1 sind im Wesentlichen

  • Multiplexing
  • Priorisierung von Requests
  • Rückruf eines Request
  • Server Push
  • Header-Daten werden mit dem neuen HPACK-Verfahren komprimiert
  • Nutzdaten werden im Binärformat übertragen.

Die Komprimierung von Headerdaten und Übertragung der Nutzdaten im Binärformat haben unmittelbare Auswirkungen auf die Größe der übermittelten Daten und reduzieren dadurch direkt die Latenzzeiten im Netzwerk.

Wir wollen hier die weiteren neuen Funktionen von http/2 betrachten:

Multiplexing

Grundsätzlich besteht die Kommunikation über http aus einer Reihe von Anfragen (Requests) eines Clients oder Browsers an einen Server, die dieser wiederum durch Responses beantwortet.

Abb. 1: Typische Response Situation über http

Wurde in http 1.0 für jede Anfrage an einen Server (Request) – und damit auch für jede einzelne Datei – noch eine TCP-Verbindung benötigt oder eine Reihe von Request innerhalb einer Verbindung sequentiell abgearbeitet Abb. 2: Sequentielle Abfolge von Requests und Reponses mit http/1.0(Abbildung 2), reduzierte http/1.1 dieses Problem durch „Request Pipelining".

Dieses Verfahren ermöglicht das Absetzen eines weiteren Requests über eine vorhandene TCP-Verbindung, während noch auf die Antwort eines vorangegangenen Requests gewartet wird (Abbildung 3). Probleme treten jedoch auch hierbei auf, wenn die Pipeline gewissermaßen „blockiert" wurde, z.B. durch lange Antwortzeit eines ausstehenden Requests oder den Transfer großer Datenmengen über das Netzwerk bei hoher Latenzzeit. Die ausstehenden Responses werden in der Reihenfolge der eingegangenen Requests nacheinander Abb. 3: Überschneidung von Requests - Responses bei http/1.1ausgegeben, ein „Überholen" ist nicht möglich. Man spricht hierbei vom „Head-of-Line Blocking". Eine langlaufende, eher unwichtige Server-Transaktion kann andere blockieren. Transaktionen, die auf dem Server inhaltlich fertig prozessiert wurden, können ihre Antworten durch die blockierte Verbindung nicht an den Client ausliefern.

Eine Lösung dieses Problems bietet http/2 durch die Funktion des Multiplexings: Bei der Kommunikation mit http/2 wird eine TCP-Connection in mehrere Streams zerlegt. Dies sind gewissermaßen Kanäle innerhalb der Verbindung, die wiederum von sogenannten Frames – das sind die atomaren Bausteine auf Bytecode-Ebene, um Request- und Response-Daten zu übermitteln – in beide Richtungen parallel „befahren" werden können. Request und Response werden stückchenweise übermittelt und am Ende der Übertragung vom Server bzw. Client wieder zusammengesetzt. Requests werden daher nicht mehr zwingend in der Reihenfolge ihres Eintreffens beantwortet. Die Requests (bzw. der gesamte Server-Roundtrip) erhalten eine numerische ID, anhand derer in den Responses der zugehörige Request referenziert wird Abb. 4: Multiplexing ermöglicht Response nach Verfügbarkeit: Überholen erlaubt (Abbildung 4). So kann der Client beim Eintreffen einer Response diese dem ursprünglichen Request zuordnen.

Ein Beispiel, das die Effizienz dieses Verfahrens eindrucksvoll veranschaulicht, finden Sie unter http://http2.golang.org/gophertiles. Hier werden 180 Bilddateien mit jeweils ca. 1 KB Dateigröße mit unterschiedlichen wählbaren Latenzzeiten mit http/1.1 und http/2  an den Browser übermittelt.

Priorisierung von Requests

Durch die Aufteilung einer TCP-Connection in Streams bietet sich noch eine weitere Möglichkeit: Webanwendungen (http-Clients wie Browsern) können Requests priorisieren und so eine vorrangige Bearbeitung durch den Server zur bewirken. Eine Priorisierung von Requests, die zu weiteren Folge-Requests führen, gegenüber unwichtigeren aber zeitraubenden Requests verspricht – bei richtiger Anwendung – deutliche Effizienzsteigerungen.

Rückruf eines Requests

Ergänzend dazu erlaubt http/2 auch den Rückruf eines Requests. Bereits vom Client abgesetzte Requests können vor der Ausführung auf dem Server abgebrochen werden. Dies entlastet bei rechenintensiven Transaktionen den Server, bei großem Datenvolumen das Netzwerk und erhöht so die Leistungsfähigkeit von Webanwendungen.

Server Push

Eine weitere Neuerung in http/2 stellt der Server Push dar. Der Server kann aktiv an den Client Daten senden, von denen er weiß, dass sie als nächstes benötigt werden Abb. 5: http/2 Push-Funktion(Abbildung 5). Der Client muss den Server nicht mehr mit einem oder mehreren Folge-Requests aufrufen („Polling"), sondern findet die Daten bereits in seinem Cache vor. Mehr Daten können so mit einem einzigen Server-Roundtrip vom Server ausgeliefert werden, was bei ungünstigen Latenzzeiten erhebliche Vorteile bringt. Auch das komplizierte Polling oder langes Offenhalten von Verbindungen ist nicht mehr nötig.

Clients und Browser

Die Browser Firefox (ab Version 34) und Chrome (ab Version 38), sowie der Internet Explorer 11 und fast alle Mobile-Browser unterstützen bereits http/2. Firefox, Chrome und der Internet Explorer unterstützen gegenwärtig http/2 jedoch nur verschlüsselt mit TLS, dem Nachfolgeprotokoll von SSL. Soll der bereitgestellte Content mit einem dieser Standardbrowser dargestellt werden, ist also die Installation eines Serverzertifikats ab TLS Version 1.2 in den Keystore des Webservers zwingend notwendig.

Grundsätzlich ist der Standard auch für eine unverschlüsselte Nutzung von http/2 definiert. Falls gewünscht müssen zur unverschlüsselten Nutzung von http/2 entsprechende http-Clients implementiert werden. Beispielweise über das Kommandozeilen-Programm curl (ab Version 7.43.0) lässt sich ein Webserver über http/2 auch unverschlüsselt aufrufen, soweit der Webserver dies unterstützt.

Die Webserver NGINX und Apache HTTP Server (httpd) unterstützen bereits http/2, ebenso Microsoft IIS ab Windows 10 bzw. Windows-Server 2016.

http/2 und Java Servlets

Unter den Application Servern bzw. Servlet-Containern ist Jetty der erste, der den neuen Standard unterstützt. Jetty bietet auch bereits eine http/2-kompatible Implementierung eines Http-Clients an. Für Android ist mit OKHttp ebenfalls ein http/2-fähiger Client verfügbar, der allerdings http/2 nur mit TLS-Verschlüsselung ermöglicht.

Obwohl die bisherigen Webanwendungen mit http/2 weiterhin lauffähig sind, darf man gespannt sein, wie die Tools und Frameworks zur Entwicklung von Webanwendungen und Webservices die zusätzlichen Möglichkeiten des neuen Standards in einsatzreife Releases umsetzen werden. Die Java Servlet API – das Rückgrat fast aller Java-basierten Webanwendungen – erfährt gerade eine entsprechenden Erweiterung. Version 4.0 befindet sich seit Oktober im Beta-Status. Die Unterstützung von http/2 steht auf der Spezifikation JSR-369, die sich zurzeit noch im Draft-Status befindet. Wenn die Servlet API damit umgehen kann, dass mit http/2 die Beziehung von Request zu Response durch eine numerische ID abgebildet wird, sowie die Priorisierung und das Canceln von Request und Response unterstützt, bieten sich neue Ansätze für Service-basierte Anwendungen. Aber vor allem der Server Push eröffnet neue Entwurfsmöglichkeiten für Webanwendungen. Mit neuen Programmier-Paradigmen bei der Entwicklung von Web-Applikation ist zu rechnen. Den Startschuss hierfür wird das finale Release der Servlet API 4.0 geben, das für das 3. Quartal 2016 geplant ist. Es werden aber auch ganz allgemein neue Kommunikationsmodelle für Client-Server-Anwendungen möglich.

Reverse Proxies bremsen noch

Eine gängige Bauweise, besteht darin, einen Webserver als Reverse Proxy zwischen Servlet-Container und Clients zu schalten, der eingehende Requests an den Servlet-Container und dessen Antwort an die Clients weiterleitet.

Abb. 6: Typisches Server-Setup mit Reverse Proxy

Die als Reverse Proxy am häufigsten verbreiteten Webserver Apache HTTP Server, NGINX und Microsoft IIS unterstützen http/2 momentan jedoch lediglich zur Kommunikation mit den Clients. Die Weiterleitung an einen Servlet-Container findet weiterhin mit http/1.1 statt. Sollen die im Servlet-Container betriebenen Web-Applikationen ebenfalls http/2 nutzen, ist es eine zwingende Voraussetzung, dass der eingesetzte Reverse Proxy die Requests auch in diesem Protokoll weiterleitet. Webtide, die Entwickler von Jetty, empfehlen hierzu die Nutzung von Jetty zusammen mit dem Open Source Produkt HAProxy als Reverse Proxy. Es ist unseres Wissens das einzige Produkt, das gegenwärtig als Reverse Proxy eine Weiterleitung an einen Servlet Container mit http/2 ermöglicht. Es ist aber damit zu rechnen, dass die anderen etablierten Reverse Proxys dies auch in kommenden Releases umsetzen.

Fazit

Durch die effizientere Ausnutzung von Netzwerk-Ressourcen erlaubt http/2 ein schnelleres Laden von Webseiten, was ohne nennenswerte Investitionen in Hard- oder Software deutliche Leistungssteigerungen ermöglicht. Aber auch im Bereich der Webservices und ihrer Nutzung durch verschiedene Client-Anwendungen wie Rich Internet Applications, Rich Clients oder Mobile Clients sind sinnvolle Verbesserungen zu erwarten.  

Autor: Storch, Matthias

Fragen Sie unseren Experten

Nicole Heyne
Marketing/Vertrieb
vertrieb@agon-solutions.de