W-JAX Blog von Fabian Stäber

HTTP/2: Was gibt’s Neues?

Dr. Fabian Stäber

©Shutterstock/Hayati Kayhan

HTTP/2 hat zum Ziel, das World Wide Web schneller zu machen. Dafür wurden einige interessante Features eingeführt, wie z.B. Multiplexing, Server Push Nachrichten, Stream Priorization und Flow Control. Entwickler von Web-Anwendungen müssen sich um diese Änderungen nicht kümmern: Ein Web-Server kann von HTTP/1.1 auf HTTP/2 umgestellt werden, ohne dass die Anwendungen dafür geändert werden müssen.

Die Änderungen auf HTTP-Protokollebene sind sowohl für Web-Anwendungen wie auch für Browser-Clients transparent. HTTP/2 definiert kein JavaScript API. Nutzt man HTTP/2 jedoch für REST-basierte Server-zu-Server-Schnittstellen, hat man sowohl auf Server-Seite wie auch auf Client-Seite Java-Bibliotheken, die den Zugriff auf Low-Level-Features des HTTP/2-Protokolls erlauben. Diese Features bieten interessante Möglichkeiten für neue REST-Interfaces.

Multiplexing: In HTTP/1 wirken REST-Aufrufe blockierend, d.h. während ein langlaufender Request über eine TCP-Verbindung läuft, kann die Verbindung nicht gleichzeitig für andere Requests genutzt werden. Mit HTTP/1 bleiben nur zwei Möglichkeiten, mit dieser Problematik umzugehen: Entweder sendet man sequenziell einen Request nach dem anderen und nimmt die damit verbundenen Wartezeiten in Kauf, oder man baut mehrere parallele TCP-Verbindungen auf, wobei dann darauf zu achten ist, dass es ein Limit für die maximale Zahl der parallelen Verbindungen geben sollte.

HTTP/2 Multiplexing löst dieses Problem und ermöglicht es, eine TCP-Verbindung gleichzeitig für mehrere parallele Requests zu nutzen. Dafür muss der Client jedoch ein entsprechendes asynchrones API nutzen, um mehrere parallele Requests zu starten. In meinem Vortrag auf der W-JAX wird anhand von drei Beispielen (Jetty, OkHttp und Netty) gezeigt, wie dies mit aktuellen HTTP/2-Client-Bibliotheken möglich ist.

Push-Requests: Das berühmteste Feature von HTTP/2 ist die Möglichkeit, aktiv Responses vom Server zum Client zu senden, ohne vorher auf den entsprechenden Request vom Client zu warten. Im Web-Umfeld steht dafür hauptsächlich folgende Anwendung im Vordergrund: Wenn ein Web-Browser eine Seite index.html lädt, dann ist es sehr wahrscheinlich, dass der Browser als nächstes Requests auf die eingebundenen Ressourcen wie Bilder, CSS-Dateien und JavaScript-Dateien schickt. Mit HTTP/2 braucht der Server nicht zu warten, bis er Requests auf diese Ressourcen erhält: Er kann mit Server-Push-Nachrichten direkt die Ressourcen an den Client schicken. Der Client findet die Resourcen in seinem HTTP-Cache und kann sie ohne zusätzliche Wartezeit verwenden.

Für REST-Schnittstellen kann man Push-Requests nutzen, um „effizientes Polling“ zu implementieren. Beim gewöhnlichen Pollen sendet der Client Requests in einem regelmäßigen Zeit-Intervall, um Veränderungen am Zustand einer Ressource abzufragen. Mit HTTP/2 ist es möglich, dass der Client genau dann pollt, wenn er eine Push-Nachricht vom Server erhält. Damit erreicht man, dass eine Art „Messaging-Mechanismus“ entsteht, mit dem der Server den Client über eine Zustandsänderung informieren kann. Da mit der Push-Nachricht ein gewöhnlicher GET-Request ausgelöst wird, bleibt man jedoch bei einem reinen HTTP-basierten REST Interface und ist nicht auf andere Protokolle wie „long Polling“ oder „WebSockets“ angewiesen.

Im Vortrag wird anhand einer „Push Echo Demo“ gezeigt, wie Push-Nachrichten erzeugt werden und wie sie im Client eine entsprechende Aktion auslösen können.

Stream Priorization und Flow Control: Mit Stream Priorization hat der Server die Möglichkeit, dem Client mitzuteilen, dass manche Responses bevorzugt bearbeitet werden sollen. Flow Control erlaubt es, dem Server und dem Client die verfügbare Bandbreite für einzelne Requests zu drosseln. Im Web-Umfeld wurden diese Features eingeführt, damit der Server Content-relevante Inhalte schneller ausliefern kann als z.B. eingebundene Werbung. Es ist jedoch auch möglich, diese Features für REST-Schnittstellen zu nutzen, um Business-kritischen Requests den Vorrang gegenüber Monitoring-Requests zu geben.

Im Anschluss an die Präsentation der neuen HTTP/2-Features und ihrer Anwendungen möchte ich auf praktische Aspekte bei der Implementierung von HTTP/2-basierten REST-Schnittstellen eingehen. Insbesondere soll dargestellt werden, wie die neuen Features automatisiert getestet werden können.

Aufmacherbild: Macro shot of computer screen with http:// address bar and web browser von Shutterstock / Urheberrecht: Hayati Kayhan

Verwandte Themen:

Geschrieben von
Dr. Fabian Stäber

Dr. Fabian Stäber ist Software-Entwickler, R&D-Leiter und Architekt bei der ConSol* Software GmbH. Fabian begeistert sich für JEE, Backends, Big Data Anwendungen und verteilte Architekturen.

Er ist aktiver Teil der Java Community, engagiert sich für Meetups und hält regelmäßig Vorträge auf Konferenzen. Als Mitglied der JSR 373 Expert Group arbeitet er an der Standardisierung einer REST-Schnittstelle zum Management von Java-Anwendungen.

Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: