© Excellent backgrounds/Shutterstock.com
Kolumne: EnterpriseTales

Servlet 4.0 mit HTTP/2


von Lars Röwekamp und Arne Limburg

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

Die Servlet-Spezifikation gibt es seit 1997. Servlet 2.x hatte dabei eine Gültigkeit von über zehn Jahren, bis es dann 2009 von Servlet 3.0 ersetzt wurde. Servlet 3.0 brachte Dependency Injection und Asynchronität. Welchen Sinn ergibt es da, nun erneut ein Major-Release herauszubringen? Was ist von Servlet 4.0 zu erwarten? Die Antwort darauf wird diese Kolumne liefern.

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/1

Ladezeiten für Webseiten spielen trotz immer schneller werdender Internetverbindungen nach wie vor eine große Rolle bei der Webentwicklung. Und so verwundert es nicht, dass Neuentwicklungen des Kommunikationsprotokolls auch immer das Thema Performance im Auge haben.

Ein 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-Reque...

Neugierig geworden?

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