Blog - gnuheidix

Motivation

Seitdem HTTP/2 nun auch in den beiden großen Webservern Apache und nginx implementiert ist, habe ich es nun auch für mein Blog aktiviert, um zu sehen, inwieweit die bisher schon sehr guten Performancewerte übertroffen werden.

Mir ist bekannt, dass die Dokumentation beider Webserver zum Zeitpunkt der Erstellung dieses Beitrags die HTTP/2-Funktionalität als experimentell ausweist.

Mir geht es in diesem speziellen Beitrag primär um die Testung der Frontendperformance ohne Browsercache. Dies ist dem geschuldet, dass ich die Cachingkonfiguration dieser Website bereits als praktisch optimal erachte. Weiter will ich hier die Datenübertragungsperformance beleuchten und Daten werden schließlich nur übertragen, wenn sie noch nicht im Browsercache liegen.

HTTP/1.1

Am 09.10.2016 habe ich eine Performanceanalyse mittels WebPagetest ausgeführt, um den allgemeinen TLS-Overhead von einem externen System zu prüfen.

Es ist zu sehen, dass der Chrome-Browser für die neun einzelnen Ressourcen der Startseite dieses Blogs nacheinander insgesamt drei TLS-Verbindungen aufgebaut hat. Dabei wird nach der DNS-Auflösung bereits eine zweite Verbindung aufgebaut, weil er sich wohl auf weitere Ressourcendownloads vorbereitet. Er versucht, sobald er eine bisher nicht geladene Ressource erkennt, eine der aktuell nicht benutzten Verbindungen zu benutzen. Falls alle ausgelastet sind, wird direkt eine neue Verbindung aufgebaut.

Dieses Verhalten ist dem geschuldet, dass HTTP/1.1 pro Verbindung keine Ressourcen gleichzeitig übertragen kann. Dabei wird aber pro Verbindung in Kauf genommen, dass trotz geringer Datenmengen bei optimierten Websites die unter dem TLS liegende TCP-Verbindung bezüglich Slow-Start noch nicht warm ist. Die maximal mögliche Datenrate des Clients von 5 Mbps wird dabei gerade mal zur Hälfte ausgenutzt.

Es ist außerdem zu sehen, dass abhängig von den verfügbaren Verbindungen alle Ressourcen nacheinander geladen werden.

Der vollständige Ladevorgang der Seite benötigt in diesem Test etwa 1,4 Sekunden.

HTTP/2

Heute habe ich eine weitere Performanceanalyse mit identischer Konfiguration durchgeführt, um die Änderungen durch die Aktivierung von HTTP/2 von einem externen System zu prüfen.

Es fällt direkt auf, dass der Browser lediglich eine einzige TLS-Verbindung aufbaut. Sämtliche im HTML referenzierten Ressourcen werden durch die selbe Verbindung gleichzeitig übertragen und dabei wird sogar kurzzeitig die maximal mögliche Datenrate des Clients erreicht.

Der vollständige Ladevorgang der Seite benötigt hier 0,9 Sekunden, das ist eine halbe Sekunde weniger als mit HTTP/1.1 auf den ersten Blick.

Man darf nicht übersehen, dass es, bis die initiale TLS-Verbindung steht, länger im HTTP/1.1-Test dauerte als im Test mit HTTP/2. Diese Unterschiede kommen in der Regel von unterschiedlichen Lastzuständen der Netzwerkinfrastruktur zwischen dem WebPagetest-Client und meinem Server.

Wenn man diesen Nachteil berücksichtigt, dann ist HTTP/2 etwa 0,4 Sekunden performanter.

Webserveranpassung

Ich nutze die größte Version von nginx, die in den Ubuntupaketen verfügbar ist. Diese Version hat bereits das notwendige Modul hineincompiliert. Man aktiviert es in der listen-Direktive. Es ist nur eine Zeile, die man anpassen muss.

Man darf nicht vergessen, dass dieses Modul experimentell ist und man sich gut überlegen sollte, ob man es aktiviert. HTTP/2 ist im Vergleich zu HTTP/1.1 erheblich komplexer. Mangels Alter bzw. Reife des Codes ist es im Prinzip nur eine Frage der Zeit, bis kritische Bugs bekannt werden.

Im schlimmsten Fall übernimmt mir jemand den Webserver. Bei diesem Blog finde ich das Risiko akzeptabel. Wenn niemand sowas benutzt und keiner Bugs meldet, wird der Code schließlich auch nicht reifer. Man sieht aber an existierenden Sicherheitsanalysen, dass sich nginx ganz gut schlägt.

Fazit

Mit der breiten Unterstützung von HTTP/2 auf Client- und Serverseite ist ein Grundstein gelegt, Anforderungen von Nutzern moderner Webapplikationen mit endlichem Aufwand gerecht werden zu können.

Ich muss noch weitere Tests fahren, um weitere Aussagen treffen zu können. Als nächstes sehe ich Lasttestvergleiche, um zu prüfen, wie viel "Strom" die HTTP/2-Komplexität auf dem Server in Abwärme umwandelt.

Nachtrag

26.10.2016: Man muss beachten, dass die HTTP/2-Verbindung fehlschlagen kann, wenn man zu unsichere TLS-Ciphers konfiguriert hat. Ich habe das gemerkt, weil mein SailfishOS Mobiltelefon diese Site nicht mehr erreichen konnte. Zum Glück hat nginx die debug_connection-Direktive.