© Excellent backgrounds/Shutterstock.com
Java Magazin
Kolumne: EnterpriseTales

Servlet 4.0 mit HTTP/2

von Lars Röwekamp und Arne Limburg

Arne Limburg, Lars Röwekamp


Mit jeder neuen Java-EE-Version gibt es auch eine neue Servlet-Version. Diese Regel gilt schon seit J2EE 1.2, und sie wird auch mit Java EE 8 Bestand haben. Der Plan lautet, dass mit Java EE 8 Servlet 4.0 ausgeliefert wird. Neu ist allerdings, dass die neue Servlet-Spezifikation auf einer neuen HTTP-Version basiert. Alle bisherigen Servlet-Versionen seit 2.3 basieren auf HTTP/1.1, das es seit 1999 gibt. Video: Fünfzehn Jahre Enterprise-Java: Aus diesen Fehlern können wir lernen Der Auslöser für das Starten eines neuen Major-Releases der Servlet Spec war das sich abzeichnende Release eines neuen HTTP-Standards. Im August 2014 wurde die Arbeit an HTTP/2 gestartet. Dies sahen die Macher der Servlet Spec als so bedeutend an, dass auf dieser Basis Servlet 4.0 begonnen wurde. Man ging mit Servlet 4.0 also gewissermaßen in Vorleistung, wobei ein gewisses Risiko bestand, dass HTTP/2 nicht rechtzeitig zum geplanten Erscheinungsdatum von Servlet 4.0 fertig werden würde. Mittlerweile hat sich dieses Risiko aber erledigt. Im Mai dieses Jahres wurde der RFC 7540 veröffentlicht, der HTTP/2 spezifiziert [1]. Aber was ist HTTP/2 genau? Was bringt es für Neuerungen, dass es sich lohnt, eine eigene Servlet-Spezifikation darauf basieren zu lassen?Schwächen von HTTP/1Ein großer Teil der Ladezeit vergeht damit, dass Client-Server-Verbindungen auf- und wieder abgebaut werden. Daher ist es eine logische Folge, dass versucht wird, die Anzahl der auf- und abgebauten Verbindungen zu minimieren. Dies ist bereits in HTTP/1.1 mit dem Pipelining geschehen. Dabei wird eine Client-Server-(TCP-)Verbindung für mehrere HTTP-Requests wiederverwendet. Das funktioniert zwar zunächst gut, allerdings stößt man hier auf das Head-of-Line-Blocking-Problem. Dieses Problem tritt auf, weil der HTTP-Standard garantiert, dass HTTP-Requests der Reihe nach abgearbeitet werden. Geht z. B. der zweite von drei Requests verloren, kann auch der dritte nicht ausgeliefert werden, bis der zweite erneut angefragt ist. Auch alle weiteren Requests an denselben Server sind blockiert.HTTP-Ergänzungen wie z. B. WebSocket sind weitere Versuche, dem Problem des Auf- und Abbaus von Verbindungen zu begegnen. Parallel dazu wurde von Goo­gle das Protokoll SPDY (sprich: speedy) entwickelt [2], das auch zum Ziel hatte, die beschriebenen Schwachstellen von HTTP/1 zu beheben. SPDY wurde seither von Chrome unterstützt, bevor Firefox und der Internet Explorer ab ihren Versionen 11 nachzogen.The Rise of HTTP/2Ziele von HTT...

Java Magazin
Kolumne: EnterpriseTales

Servlet 4.0 mit HTTP/2

von Lars Röwekamp und Arne Limburg

Arne Limburg, Lars Röwekamp


Mit jeder neuen Java-EE-Version gibt es auch eine neue Servlet-Version. Diese Regel gilt schon seit J2EE 1.2, und sie wird auch mit Java EE 8 Bestand haben. Der Plan lautet, dass mit Java EE 8 Servlet 4.0 ausgeliefert wird. Neu ist allerdings, dass die neue Servlet-Spezifikation auf einer neuen HTTP-Version basiert. Alle bisherigen Servlet-Versionen seit 2.3 basieren auf HTTP/1.1, das es seit 1999 gibt. Video: Fünfzehn Jahre Enterprise-Java: Aus diesen Fehlern können wir lernen Der Auslöser für das Starten eines neuen Major-Releases der Servlet Spec war das sich abzeichnende Release eines neuen HTTP-Standards. Im August 2014 wurde die Arbeit an HTTP/2 gestartet. Dies sahen die Macher der Servlet Spec als so bedeutend an, dass auf dieser Basis Servlet 4.0 begonnen wurde. Man ging mit Servlet 4.0 also gewissermaßen in Vorleistung, wobei ein gewisses Risiko bestand, dass HTTP/2 nicht rechtzeitig zum geplanten Erscheinungsdatum von Servlet 4.0 fertig werden würde. Mittlerweile hat sich dieses Risiko aber erledigt. Im Mai dieses Jahres wurde der RFC 7540 veröffentlicht, der HTTP/2 spezifiziert [1]. Aber was ist HTTP/2 genau? Was bringt es für Neuerungen, dass es sich lohnt, eine eigene Servlet-Spezifikation darauf basieren zu lassen?Schwächen von HTTP/1Ein großer Teil der Ladezeit vergeht damit, dass Client-Server-Verbindungen auf- und wieder abgebaut werden. Daher ist es eine logische Folge, dass versucht wird, die Anzahl der auf- und abgebauten Verbindungen zu minimieren. Dies ist bereits in HTTP/1.1 mit dem Pipelining geschehen. Dabei wird eine Client-Server-(TCP-)Verbindung für mehrere HTTP-Requests wiederverwendet. Das funktioniert zwar zunächst gut, allerdings stößt man hier auf das Head-of-Line-Blocking-Problem. Dieses Problem tritt auf, weil der HTTP-Standard garantiert, dass HTTP-Requests der Reihe nach abgearbeitet werden. Geht z. B. der zweite von drei Requests verloren, kann auch der dritte nicht ausgeliefert werden, bis der zweite erneut angefragt ist. Auch alle weiteren Requests an denselben Server sind blockiert.HTTP-Ergänzungen wie z. B. WebSocket sind weitere Versuche, dem Problem des Auf- und Abbaus von Verbindungen zu begegnen. Parallel dazu wurde von Goo­gle das Protokoll SPDY (sprich: speedy) entwickelt [2], das auch zum Ziel hatte, die beschriebenen Schwachstellen von HTTP/1 zu beheben. SPDY wurde seither von Chrome unterstützt, bevor Firefox und der Internet Explorer ab ihren Versionen 11 nachzogen.The Rise of HTTP/2Ziele von HTT...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang