27. Juli 2015 | 3 min lesezeit

JSR 369 – Servlet 4.0

Mit Java EE 8 wird es auch dieses mal eine neue Servlet-Version geben. Nach der „Minor-Version“ 3.1 in Java EE 7 folgt nun mit Servlet 4.0 das nächste Major-Release welches auf HTTP/2 basieren wird.

Auslöser für die Arbeit an der Servlet 4.0 Spec war das sich abzeichnende Release des neuen HTTP/2-Standards. Dieser wurde im Mai 2015 im RFC 7540 veröffentlicht und wird Neuerungen wie Request/Response MultiplexingBinary FramingStream Prioritization und Server Push enthalten.

Probleme in HTTP/1.x
Ein wesentlicher Grund für die Entwicklung eines neuen Standards waren die anhaltenden Probleme mit Ladezeiten für umfangreiche Webseiten bei immer schnelleren Breitbandanschlüssen und Internetzugängen. Die Ursache hierfür ist im TCP-Protokoll begründet. Der TCP-Handshake ist beim Verbindungsauf- und abbau ist vergleichsweise kostenintensiv, was bei einer steigenden Anzahl von Verbindungen beim Laden einer Webseite (Content, CSS, JavaScript, Bilder, Werbung, etc.) zwangsläufig zu Problemen führen muss. Dem wurde in HTTP/1.1 mit dem Pipelining-Mechanismus entgegengewirkt, der die Wiederverwendung einer bestehenden TCP-Verbindung für mehrere HTTP-Requests ermöglicht. Ein weiteres Problem stellt das Head-of-Line-Blocking (kurz HOL) dar. Da der HTTP-Standard die Abarbeitung von Requests in der verschickten Reihenfolge garantiert, führt ein verlorener Request dazu, dass auch alle weiteren Requests an denselben Server blockiert werden. Die beschriebenen Schwachstellen führten in den letzten Jahren zur Entwicklung von HTTP-Ergänzungen wie z.B. WebSocket und dem Protokoll SPDY (sprich: speedy), welches zuerst von Chrome mittlerweile auch von Firefox und dem Internet Explorer (ab Version 11) unterstützt wird.

Ziele von HTTP/2
Das primäre Ziel bei der Spezifikation von HTTP/2 war eine deutliche Verringerung der Latenz. Das Head-of-Line-Problem wird durch Zuweisung einer eindeutigen Stream-ID zu jeder Aktion (Binary_Framing) gelöst. Anhand der Stream-ID können mehrere Requests und Responses in einer TCP-Verbindung unterschieden werden (Request/Response Multiplexing), so dass mehrere Responses parallel geladen werden können. Ergänzt werden die Features durch Server Push, welches dem Server die Möglichkeit gibt, auf eine Anfrage zusätzliche Informationen an den Client zu senden und das heute gängige Resource Inlining überflüssig machen wird. Der Server könnte dem Client beim Laden einer Webseiten selbstständig zusätzlich benötige Resourcen wie CSS- und JavaScript Dateien übermitteln und die Zahl zusätzlicher Anfragen somit zu reduzieren.
Ein weiterer Punkt war eine möglichst weitgehende Kompatibilität zu HTTP/1 zu gewährleisten. Das führte dazu, dass zentrale Eckpfeiler des Standards wie Methods (GET, POST …), Statuscodes und URIs beibehalten wurden. Neu hingegen ist die Option für Client und Server das Kommunikationsprotokoll (HTTP 1.1, 2.0 oder alternative Protokolle wie SPDY) auszuhandeln.

Servlet 4.0
Die Herausforderungen bei der Realisierung von Servlet 4.0 liegen darin die HTTP/2 Features in der API bereitzustellen. Die bestehende API wurde mit dem Grundsatz eine Anfrage – eine Antwort entwickelt. Dieses ändert sich nun mit HTTP/2. Die Herausforderung wird sein in Zukunft für einen Anfrage eine oder mehrere Antworten zu verarbeiten. Gleichzeitig muss die Abwärtskompatibilität zu Servlet 3.x und HTTP/1 gewährleistet sein.
Die Klassen HttpServletRequest und HttpServletResponse werden um die Methode get­StreamId() erweitert, die natürlich auch bei einem HTTP/1.x-Client einen sinnvollen Wert liefern muss. Zusätzlich werden die Methoden getPriority() und setPriority(Priority p) hinzugefügt, um Streams zu priorisieren. Interessant werden sicherlich die Methoden für den Push-Support werden. Einen ersten interessanten Einblick bietet hier eine Präsentation von Ed Burns (Folie 68 ff).

Wichtiger als die Servlet 4.0 API wird aber die HTTP/2 Integration in die JSRs, die auf der Servlet Spec aufbauen. Der Erfolg von MVC und die weitere Nutzung von JSF wird sicherlich maßgeblich durch die Verfügbarkeit von Server Push und der Möglichkeit zum automatisierten Pushen von Resource-URLs beeinflußt werden. Voraussetzung dafür ist, dass die Servlet 4.0 API möglichst früh einen stabilen Stand erreicht, damit darauf aufsetzende Spezifikationen wie JAX-RS, MVC und JSF die neuen Features nutzen können. In diesem Fall ist in Java EE 8 mit einer signifikanten Performancesteigerung von Webanwendungen zu rechnen, ohne dass Anwendungsentwickler eine Zeile Code dafür schreiben müssen.

Die offizielle Informationen zum JSR 369 lassen sich unter https://jcp.org/en/jsr/detail?id=369 nachlesen. Weitere Informationen finden sich auf der Projektseite.


Keine Kommentare

Kontakt

OPEN KNOWLEDGE GmbH

Standort Oldenburg:
Poststraße 1, 26122 Oldenburg

Standort Essen:
II. Hagen 7, 45127 Essen