Das HTTP/2-Modul in NGINX

Valentin Bartenev

Dieser Blogbeitrag basiert auf einem Vortrag von Valentin V. Bartenev auf der nginx.conf 2015, die im September in San Francisco stattfand.

Inhaltsverzeichnis

Vor ein paar Tagen haben wir das HTTP/2-Modul von NGINX veröffentlicht. In diesem Vortrag gebe ich Ihnen einen kurzen Überblick über das neue Modul.

0:20 Überblick über das Protokoll

Zunächst möchte ich mit einigen Mythen rund um das neue Protokoll aufräumen.

Viele halten HTTP/2 für einen glänzenden, überlegenen Nachfolger von HTTP/1. Ich teile diese Ansicht nicht, und zwar aus folgendem Grund: HTTP/2 ist eigentlich nur eine weitere Transportschicht für HTTP/1. Das ist keineswegs schlecht, denn dadurch können Sie HTTP/2 nutzen, ohne Ihre Anwendung ändern zu müssen – es funktioniert mit denselben Headern. Sie können HTTP/2 einfach in NGINX aktivieren, und NGINX kümmert sich zuverlässig um alle Protokolldetails.

Aber HTTP/2 ist kein Wundermittel. Es hat sowohl Vor- als auch Nachteile. Es gibt Anwendungsfälle, in denen es gut funktioniert, aber auch Szenarien, in denen es schlecht abschneidet.

1:40 Hauptmerkmale von HTTP/2

HTTP/2 kann als eine neue Version von SPDY betrachtet werden, da es auf SPDY basiert und ein sehr ähnliches Protokoll ist. SPDY ist ein vor einigen Jahren von Google entwickeltes Protokoll, das die Bereitstellung von Webinhalten beschleunigen soll.

NGINX unterstützt SPDY bereits seit zwei Jahren. Daher können Sie die Vorteile von HTTP/2 mithilfe des SPDY-Moduls ausprobieren. Manche würden sagen, HTTP/2 sei lediglich eine ausgereiftere Version von SPDY 3.1.

Falls Sie mit SPDY nicht vertraut sind, werde ich einige wichtige Punkte erläutern. Diese Punkte gelten auch für HTTP/2, da es sich im Grunde um dasselbe Protokoll handelt, das sich lediglich in einigen Details unterscheidet.

Der erste wichtige Punkt ist, dass das Protokoll selbst binär ist. Ich mag binäre Protokolle – sie lassen sich leichter programmieren, und gute binäre Protokolle bieten einige Leistungsvorteile. Allerdings verstehe ich auch die Nachteile dieses Ansatzes.

3:08 HTTP/2 von innen – Binär

Hier sehen Sie eine HTTP/2-Anfrage. Sie sieht ziemlich cool aus und lässt sich, wie Sie sehen, sehr leicht debuggen. Nein, nur ein Scherz. Sie lässt sich nur schwer debuggen. Und das ist einer der Nachteile von Binärprotokollen.

Möglicherweise müssen Sie ein Tool verwenden, um die Anfrage zu dekodieren, oder … nun ja, manchmal müssen Sie die Binärdaten manuell debuggen, weil das Tool fehlerhaft sein kann oder Ihnen möglicherweise nicht alle in den Bits verborgenen Details anzeigt.

Glücklicherweise kann man HTTP/2 meistens einfach in NGINX aktivieren und muss sich nie mit seiner binären Natur auseinandersetzen. Und zum Glück werden die meisten Anfragen von Maschinen verarbeitet. Maschinen können binäre Protokolle wesentlich besser lesen als Menschen.

4:26 HTTP/2 im Inneren – Multiplexing

Der nächste wichtige Aspekt von HTTP/2 ist das Multiplexing. Anstatt Antworten und Anfragen als separate Datenströme über mehrere Verbindungen zu senden und zu empfangen, bündelt HTTP/2 sie in einem einzigen Byte- bzw. Datenstrom. Dabei werden die Daten für verschiedene Anfragen und Antworten in einzelne Abschnitte unterteilt. Jeder Abschnitt verfügt über eine eigene Kennung und ein Größenfeld, sodass der Endpunkt bestimmen kann, welche Daten zu welcher Anfrage gehören.

Der Nachteil besteht darin, dass jeder Datenblock eine eigene Kennung und eigene Felder hat und daher zusätzlich zu den eigentlichen Daten auch Metadaten übertragen werden. Dadurch entsteht ein gewisser Overhead. Wenn Sie also nur einen einzigen Datenstrom haben, etwa beim Ansehen eines Films, ist HTTP/2 kein geeignetes Protokoll, da dadurch lediglich zusätzlicher Overhead entsteht.

Welche Vorteile bietet Multiplexing? Der Hauptvorteil von Multiplexing besteht darin, dass durch die Verwendung nur einer einzigen Verbindung die gesamte Zeit eingespart werden kann, die bei HTTP/1.x für den Handshake beim Erstellen einer neuen Anfrage benötigt würde.

Solche Verzögerungen sind besonders problematisch, wenn TLS ins Spiel kommt. Deshalb unterstützen die meisten Clients HTTP/2 inzwischen nur über TLS. Soweit ich weiß, gibt es keine Pläne, HTTP/2 über unverschlüsseltes TCP zu unterstützen, da dies kaum Vorteile bietet. Der Grund dafür ist, dass TCP-Handshakes nicht so aufwendig sind wie TLS-Handshakes. Daher spart man hier durch das Vermeiden mehrerer Verbindungen nicht viel.

7:09 Hauptmerkmale von HTTP/2 – Header-Komprimierung

Der nächste wichtige Punkt bei HTTP/2 ist die Header-Komprimierung. Wenn Sie sehr große Cookies haben, können Sie dadurch bei jeder Anfrage oder Antwort Hunderte von Bytes einsparen. Im Allgemeinen bringt die Header-Komprimierung jedoch meist keinen großen Vorteil. Denn selbst wenn Sie einzelne Anfragen betrachten, haben Sie es im Netzwerk letztlich mit einer Paketschicht zu tun. Dabei spielt es kaum eine Rolle, ob Sie hundert oder hundertfünfzig Bytes senden, da daraus letztlich ohnehin ein einziges Paket wird.

Der Nachteil der HTTP/2-Header-Komprimierung besteht darin, dass sie zustandsbehaftet ist [Redaktion – Dies bezieht sich auf die Tabellen, in denen Informationen zur Komprimierung und Dekomprimierung gespeichert werden]. Daher müssen Server und Clients für jede Verbindung Zustandsinformationen vorhalten, was deutlich mehr Arbeitsspeicher beansprucht als bei HTTP/1-Verbindungen. Folglich benötigt jede HTTP/2-Verbindung wesentlich mehr Arbeitsspeicher.

8:40 Hauptmerkmale von HTTP/2 – Priorisierung

Der letzte wichtige Aspekt von HTTP/2 ist der Priorisierungsmechanismus. Dieser löst das durch Multiplexing entstandene Problem. Wenn nur eine Verbindung besteht, steht auch nur ein Übertragungskanal zur Verfügung. Daher muss sorgfältig entschieden werden, welche Antwort als Nächstes über diesen Kanal gesendet wird.

Die Priorisierung ist in HTTP/2 optional, doch ohne sie ergeben sich kaum Leistungsvorteile. Das HTTP/2-Modul in NGINX unterstützt die Priorisierung vollständig – sowohl anhand von Gewichtungen als auch anhand von Abhängigkeiten. Nach allem, was wir bisher gesehen haben, verfügen wir derzeit über die schnellste HTTP/2-Implementierung. Das sind die wichtigsten Punkte zu HTTP/2.

10:06 Geschichte von HTTP/2

Hier ist eine einfache Folie, die die Geschichte von HTTP/2 zusammenfasst. Ziemlich unkompliziert. Sehen wir uns nun an, wie HTTP/2 in der Praxis funktioniert.

10:16 Testseite

Um zu verstehen, wie HTTP/2 unter verschiedenen Netzwerkbedingungen funktioniert, habe ich einige Benchmark-Tests mit einer typischen Webseite durchgeführt. Dabei handelt es sich einfach um eine HTTP/2-Seite, die ich auf Github gefunden habe. Sie können sehen, wie viele Ressourcen sie enthält und wie groß die einzelnen Ressourcen sind. Ich denke, sie ist ziemlich repräsentativ für eine typische Website.

10:52 Testumgebung

Hier ist meine Testumgebung, falls Sie den Test reproduzieren möchten.

11:02 DOM-Ladevorgang

Und hier ist das Ergebnis, das ich erhalten habe. Sie sehen, dass ich auf der X‑Achse verschiedene Netzwerklatenzen als Paketumlaufzeiten (RTT) in Millisekunden simuliert und anschließend auf der Y‑Achse die Downloadzeit, ebenfalls in Millisekunden, gemessen habe. Bei diesem Test wird die Seitenladezeit bis zu dem Zeitpunkt gemessen, an dem alle Ressourcen der Seite vollständig geladen sind.

Aus dem Diagramm lässt sich ein klarer Trend ablesen: Bei niedrigen Latenzen gibt es keinen nennenswerten Unterschied zwischen HTTP, HTTPS und HTTP/2. Bei höheren Latenzen ist unverschlüsseltes HTTP/1.x die schnellste Option. HTTP/2 liegt an zweiter Stelle, während HTTPS am langsamsten ist.

11:48 Erstes Rendering

Wie sieht es mit der Zeit bis zum „First Paint“ aus? In vielen Fällen ist dies aus Sicht der Nutzer die wichtigste Kennzahl, denn zu diesem Zeitpunkt sehen sie tatsächlich etwas auf ihrem Bildschirm. Oft ist es weniger entscheidend, wie lange es dauert, bis die Seite vollständig geladen ist. Viel wichtiger ist, wie lange die Nutzer warten müssen, bis sie etwas sehen.

Hier zeigt sich derselbe Trend. Interessant ist bei unserem Test jedoch, dass HTTP/2 bei Latenzen im mittleren Bereich von 30 ms bis 250 ms etwas schneller ist als herkömmliches HTTP, auch wenn der Unterschied sehr gering ist.

12:45 Konfiguration

Das waren also unsere Benchmarks. Sehen wir uns nun an, wie HTTP/2 und NGINX konfiguriert werden.

Eigentlich ist es ganz einfach. Sie müssen lediglich den Parameter http2 zur Direktive listen hinzufügen. Der wahrscheinlich komplizierteste Schritt besteht darin, die neueste Version von OpenSSL zu installieren, da HTTP/2 die ALPN-Erweiterung [Application-Layer Protocol Negotiation] benötigt und diese erst ab OpenSSL 1.0.2 unterstützt wird.

Wir haben außerdem NPN [Next Protocol Negotiation] für HTTP/2 implementiert, das derzeit mit den meisten Clients funktioniert. Da SPDY jedoch Anfang 2016 eingestellt wird, werden diese die Unterstützung für NPN entfernen. Das bedeutet, dass Sie HTTP/2 derzeit mit der OpenSSL-Version verwenden können, die in vielen Linux-Distributionen enthalten ist. Sie sollten jedoch bedenken, dass dies in naher Zukunft nicht mehr funktionieren wird.

Damit ist alles zur Konfiguration von NGINX für HTTP/2 gesagt, und ich bin am Ende meiner Präsentation angelangt. Vielen Dank.

[Referenzdokumentation für das HTTP/2-Modul]

Fragen und Antworten

F: Werden Sie HTTP/2 auch auf der Upstream-Seite unterstützen oder nur auf der Client-Seite?

A: Derzeit unterstützen wir HTTP/2 nur auf der Clientseite. HTTP/2 kann nicht mit proxy_pass konfiguriert werden. [Redaktion – In der ursprünglichen Version dieses Beitrags wurde dieser Satz fälschlicherweise wie folgt wiedergegeben: „HTTP/2 kann mit proxy_pass konfiguriert werden.“ Wir bitten um Entschuldigung für etwaige dadurch entstandene Unklarheiten.]

Aber welchen Sinn hat HTTP/2 auf der Backend-Seite? Wie Sie den Benchmarks entnehmen können, bietet HTTP/2 in Netzwerken mit geringer Latenz, etwa bei Upstream-Verbindungen, kaum Vorteile.

Außerdem steht Ihnen in NGINX das Keepalive-Modul zur Verfügung, und Sie können einen Keepalive-Cache konfigurieren. Der wichtigste Leistungsvorteil von HTTP/2 besteht darin, zusätzliche Handshakes zu vermeiden. Wenn Sie dies jedoch bereits mit einem Keepalive-Cache erreichen, benötigen Sie auf der Upstream-Seite kein HTTP/2.

Weitere Ressourcen zu HTTP/2

• HTTP/2 für Webanwendungsentwickler – Whitepaper (PDF) mit allem Wissenswerten über HTTP/2
• High Performance Browser Networking – Sonderausgabe des E-Books von Ilya Grigorik von Google
• Was ist neu in HTTP/2? – NGINX-Webinar, das die wichtigsten Funktionen beschreibt und Hinweise zur Implementierung gibt
• 7 Tipps zur Verbesserung der HTTP/2-Performance – Blogbeitrag
• Liste der Browser, die HTTP/2 unterstützen – Website „Can I Use?“

Möchten Sie HTTP/2 mit NGINX Plus in Ihrer Umgebung ausprobieren? Starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen.

Über den Autor

Valentin Bartenev

Weitere Blogbeiträge von Valentin Bartenev