Unter der “vielsagenden” Spezifikation rfc7540 wurde mitte letzten Jahres die Version 2 des http-Protokolls verabschiedet. Basierend auf Googles eigener Entwicklung „SPDY“ verspricht der neue Standard schnellere Webseiten. Grund genug einen Blick auf die Möglichkeiten zur Integration in unsere Java EE Landschaft zu werfen und die Frage zu stellen „Was bringt es wirklich“?
Die Änderung des Protokolls von http/1.1 auf die Version 2.0 Bedarf grundsätzlich erst einmal keinerlei Änderungen innerhalb der Anwendungen. Es geht lediglich darum wie der Browser und der Webserver miteinander kommunizieren. Bis zur Version 1.1 sah das in aller Regel so aus das für das Laden einer vollständigen Webseite eine Vielzahl an einzelnen TCP-Verbindungen zu ein und demselben Host geöffnet wurden um HTML, JavaScript, CSS und Bild-Dateien vollständig zu laden. Zum Aufbau jeder dieser Verbindungen (maximal 6-8 Verbindungen parallel pro Host) waren gewisse Header-Informationen notwendig die im Text-Format wiederholt über die Leitung transportiert werden mussten. Um dieser Probleme Herr zu werden geht http/2 in mehreren Punkten neue Wege:
- Multiplexing
- Mehrere Request über eine TCP-Verbindung
- Header Compressing
- Komprimierung der Header-Informationen
- Server-Push
- Empfangen von Ressourcen die noch nicht angefordert wurden
Ob die eigene Anwendung nun von diesen neuen Features profitiert hängt stark von der Anwendung selbst ab und in welchem Maße bereits Optimierungen für http/1.1 durchgeführt wurden. Generell kann man sagen das Anwendungen die viele kleine Requests durchführen stärker von der neuen Version profitieren als Anwendungen die wenige aber dafür große Requests verwenden.
Wildfly, ready for take off!
Ab Wildfly 9 wird http/2 im JBoss unterstützt. Leider reicht zur Nutzung ein einfaches Aktivieren über die Console nicht aus. Bis Java 9 veröffentlicht wird benötigen wir für unser JDK 8 eine Erweiterung die wir den Java-Options unseres Servers hinzufügen: ALPN. Dabei ist auf die korrekte Version zu achten die sich aus der verwendeten Java-Version ergibt, (s. „Versions“ unter: http://www.eclipse.org/jetty/documentation/current/alpn-chapter.html ). Das korrekte JAR muss dann als zusätzlicher Start-Parameter bereitgestellt werden, hier zum Beispiel über die standalone.conf.bat:
set "JAVA_OPTS=%JAVA_OPTS% -Xbootclasspath/p:%JBOSS_HOME%/bin/alpn-boot-8.1.3.v20150130.jar"
Darüber hinaus ist http/2 in den meistens Browsern nur über eine gesichterte Verbindung möglich, aus dem Grund fügen wir unserem Server eine entsprechende Konfiguration hinzu. Für die lokale Entwicklung können die Zertifikate selbst generiert werden und der Keystore im „configuration“ Ordner des Wildfly’s abgelegt werden:
keytool -genkey -alias server -keyalg RSA -keystore https.keystore
standalone.xml
<security-realm name="HTTPSRealm">
<server-identities>
<ssl>
<keystore path="https.keystore" relative-to="jboss.server.config.dir"
keystore-password="123456" alias="server" key-password="123456"/>
</ssl>
</server-identities>
</security-realm>
Zu guter Letzt fügen wir nur einen entsprechenden HTTPS-Listener mit aktiviertem http/2 hinzu:
<https-listener name="https" socket-binding="https" security-realm="HTTPSRealm" enable-http2="true"/>
Früher war alles Besser…oder?
Wie bereits angesprochen hängt der eigentliche Performance Gewinn von der eigenen Anwendung ab. Hier ein sehr einfaches Beispiel das bewusst sehr viele einzelne Requests abfeuert um auch bei der gezeigten Verbindung mit der lokalen Entwicklungsmaschine ein aussagekräftiges Ergebnis zu liefern:
Drei Dinge fallen auf: Die Übertragene Datenmenge pro Request unterscheidet sich, http/2 erreicht durch die Komprimierung von Kopf-Information eine Minimierung der Datenlast. Die Anzahl der Verbindungen zum Server selbst (Spalte 5) macht deutlich das http/2 hier wirklich nur eine einzelne Verbindung zum Server offen hält und damit nicht nur die Datenmenge reduzieren kann sondern auch den Server entlastet. Insgesamt zeigt die Zeitmessung von Chrome das die http/2 Variante auch in unserem sehr kleinen Beispiel zumindest ein wenig schneller ist. Das Beispiel lief nun auf einem lokalen Entwicklungsrecher bei dem die Antwortzeiten zwischen Browser und “localhost” Erwartungsgemäß gering sind, ein Beispiel über ein echtes Netzwerk (mit realistischen RTT) würde in diesem Fall noch deutlicher ausfallen.
Ob sich http/2 nun für die eigenen Anwendungen lohnt oder nicht kann pauschal nicht beantwortet werden, je nachdem wie die eigene Anwendung aufgebaut ist kann es aber zu spürbaren Verbesserungen führen. Die Unterstützung durch die Browser ist umfassend (IE ab Version 11), also worauf warten wir noch?
