Das HTTP/2-Modul in NGINX

Dieser Blogbeitrag basiert auf einer Präsentation 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 werde ich Ihnen einen kurzen Überblick über das neue Modul geben.

0:20 Überblick über das Protokoll

Zunächst möchte ich einige Mythen rund um das neue Protokoll entlarven.

Viele Leute halten HTTP/2 für einen glänzenden, besseren Nachfolger von HTTP/1. Ich teile diese Meinung nicht, und zwar aus folgendem Grund: HTTP/2 ist eigentlich nur eine weitere Transportschicht für HTTP/1, was nicht schlecht ist, da Sie dadurch HTTP/2 verwenden können, ohne Ihre Anwendung ändern zu müssen – es funktioniert mit denselben Headern. Sie können einfach HTTP/2 in NGINX einschalten und NGINX kümmert sich problemlos um den gesamten Protokollkram für Sie.

Aber HTTP/2 ist keine Zauberei. Es hat seine Vor- und Nachteile. Es gibt Anwendungsfälle, in denen es sich gut verhält, aber auch Szenarien, in denen es sich schlecht verhält.

1:40 Hauptfunktionen von HTTP/2

Sie können sich HTTP/2 als eine neue Version von SPDY vorstellen, da es auf SPDY basiert und ein sehr ähnliches Protokoll ist. SPDY ist ein vor einigen Jahren von Google entwickeltes Protokoll zur Beschleunigung der Bereitstellung von Webinhalten.

NGINX unterstützt SPDY bereits seit zwei Jahren, Sie können sich also mithilfe des SPDY-Moduls von den Vorteilen von HTTP/2 überzeugen. Manche würden sagen, HTTP/2 sei lediglich eine verbesserte Version von SPDY 3.1.

Wenn Sie mit SPDY nicht vertraut sind, werde ich einige wichtige Punkte durchgehen. Und diese wichtigen Punkte gelten auch für HTTP/2, da es sich im Grunde genommen um dasselbe Protokoll mit einigen Unterschieden in den Details handelt.

Der erste wichtige Punkt ist, dass das Protokoll selbst binär ist. Ich mag Binärprotokolle – sie sind einfacher zu codieren und gute Binärprotokolle haben einige Leistungsvorteile. Ich verstehe jedoch auch die Nachteile dieses Ansatzes.

3:08 HTTP/2 Inside – Binär

Hier ist eine HTTP/2-Anfrage. Es sieht ziemlich cool aus und wie Sie sehen, ist es sehr einfach zu debuggen. Nein, ich mache nur Spaß. Es ist schwer zu debuggen. Und das ist einer der Nachteile binärer Protokolle.

Möglicherweise müssen Sie zum Dekodieren der Anforderung ein Tool verwenden, oder … nun ja, manchmal müssen Sie die Binärdatei manuell debuggen, weil das Tool defekt sein kann oder Ihnen nicht alle in den Bits versteckten Details anzeigt.

Glücklicherweise können Sie HTTP/2 meistens einfach in NGINX einfügen und müssen sich nie mit seiner binären Natur befassen. Und glücklicherweise werden die meisten Anfragen von Maschinen bearbeitet. Maschinen können Binärprotokolle viel besser lesen als Menschen.

4:26 HTTP/2 Inside – Multiplexing

Der nächste wichtige Punkt von HTTP/2 ist das Multiplexing. Anstatt Antworten und Anfragen als separate Datenströme über mehrere Verbindungen zu senden und zu empfangen, multiplext HTTP/2 sie über einen Bytestrom oder einen Datenstrom. Es unterteilt die Daten in Segmente für unterschiedliche Anfragen und unterschiedliche Antworten. Jedes Segment verfügt über eine eigene Kennung und ein eigenes Größenfeld, damit der Endpunkt bestimmen kann, welche Daten zu welcher Anfrage gehören.

Der Nachteil hierbei besteht darin, dass jeder Datenblock über eine eigene Kennung und eigene Felder verfügt und daher neben den eigentlichen Daten auch Metadaten übertragen werden. Es ist also mit einem gewissen Mehraufwand verbunden. Wenn Sie also nur über einen Datenstrom verfügen, z. B. wenn Sie einen Film ansehen, ist HTTP/2 kein gutes Protokoll, da dadurch nur zusätzlicher Overhead entsteht.

Was sind die Vorteile des Multiplexing? Der Hauptvorteil des Multiplexing besteht darin, dass Sie durch die Verwendung nur einer einzigen Verbindung die gesamte Zeit sparen, die Sie mit HTTP/1.x für das Handshake aufwenden würden, wenn Sie eine neue Anforderung erstellen müssen.

Solche Verzögerungen sind besonders schmerzhaft, wenn Sie mit TLS arbeiten. Aus diesem Grund unterstützen die meisten Clients jetzt nur HTTP/2 über TLS. Soweit mir bekannt ist, gibt es keine Pläne, HTTP/2 über einfaches TCP zu unterstützen, da dies keinen großen Nutzen bringt. Dies liegt daran, dass TCP-Handshakes nicht so teuer sind wie TLS-Handshakes, sodass Sie hier durch die Vermeidung mehrerer Verbindungen nicht viel sparen.

7:09 Wichtige Funktionen 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 Hunderte von Bytes pro Anfrage oder Antwort sparen, aber im Allgemeinen profitieren Sie in den meisten Fällen nicht sehr von der Header-Komprimierung. Denn selbst wenn Sie über separate Anfragen nachdenken, haben Sie es letztlich mit einer Paketschicht im Netzwerk zu tun. Dabei spielt es keine große Rolle, ob Sie hundert oder hunderteinhalb Bytes senden, da das Ergebnis letztlich immer noch ein Paket ist.

Der Nachteil der HTTP/2-Headerkomprimierung besteht darin, dass sie zustandsbehaftet ist [ Editor – Für die Tabellen, die zum Speichern von Komprimierungs-/Dekomprimierungsinformationen verwendet werden]. Daher müssen Server und Clients für jede Verbindung einen bestimmten Status beibehalten, was wesentlich mehr Speicher beansprucht als die Beibehaltung des Status für HTTP/1-Verbindungen. Daher verbraucht jede HTTP/2-Verbindung wesentlich mehr Speicher.

8:40 Wichtige Funktionen von HTTP/2 – Priorisierung

Der letzte wichtige Punkt zu HTTP/2 ist seine Priorisierungsmechanik. Dadurch wird das durch das Multiplexing entstandene Problem gelöst. Wenn Sie nur eine Verbindung haben, haben Sie nur eine Pipe und sollten sorgfältig entscheiden, welche Antwort Sie als Nächstes in diese Pipe einfügen.

Die Priorisierung ist in HTTP/2 optional, ohne sie ergibt sich jedoch kein großer Leistungsvorteil. Das HTTP/2-Modul in NGINX unterstützt die Priorisierung vollständig und unterstützt Priorität basierend auf Gewichtungen und Priorität basierend auf Abhängigkeiten. Nach allem, was wir bisher gesehen haben, verfügen wir derzeit über die schnellste Implementierung von HTTP/2. Dies sind die wichtigsten Punkte zu HTTP/2.

10:06 Geschichte von HTTP/2

Hier ist eine einfache Folie, die durch die Geschichte von HTTP/2 führt. 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 Benchmarks auf einer typischen Webseite durchgeführt. Dies ist nur eine HTTP/2-Seite, die ich auf Github gefunden habe. Sie können sehen, über wie viele Ressourcen es verfügt und wie groß jede Ressource ist. Ich denke, es ist ziemlich repräsentativ für eine typische Site.

10:52 Testumgebung

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

11:02 DOM laden

Und hier ist das Ergebnis, das ich erhalten habe. Sie können sehen, dass ich auf der X-Achse unterschiedliche Netzwerklatenzen als Round-Trip-Zeiten (RTT) in Millisekunden simuliert habe und anschließend auf der Y-Achse die Downloadzeit, ebenfalls in Millisekunden, gemessen habe. Und dieser Test misst die Seitenladezeit, wenn alle Ressourcen der Seite vollständig geladen sind.

In der Grafik können Sie deutlich erkennen, dass bei niedrigen Latenzen kein signifikanter Unterschied zwischen HTTP, HTTPS und HTTP/2 besteht. Bei höheren Latenzen ist einfaches HTTP/1.x die schnellste Wahl. HTTP/2 kommt an zweiter Stelle und HTTPS ist am langsamsten.

11:48 Erstes Gemälde

Was ist mit der Zeit für das „erste Gemälde“? In vielen Fällen ist dies aus Sicht des Benutzers die aussagekräftigste Kennzahl, da dies der Fall ist, wenn er tatsächlich etwas auf seinem Bildschirm sieht. In vielen Fällen ist es nicht so wichtig, wie lange es dauert, bis die Seite vollständig geladen ist, sondern wie lange es dauert, bis der Benutzer etwas sieht.

Hier sehen wir denselben Trend, aber das Interessante an unserem Test ist, dass HTTP/2 bei Latenzen im mittleren Bereich, von 30 ms bis 250 ms, etwas schneller ist als einfaches HTTP, obwohl der Unterschied sehr gering ist.

12:45 Konfiguration

Das waren also unsere Benchmarks. Jetzt sprechen wir darüber, wie HTTP/2 und NGINX konfiguriert werden.

Eigentlich ist es ganz einfach. Sie müssen lediglich den Parameter http2 zur Listen -Direktive hinzufügen. Der wahrscheinlich komplizierteste Schritt besteht hier darin, die neueste Version von OpenSSL zu erhalten, da HTTP/2 die ALPN-Erweiterung [ Application‑Layer Protocol Negotiation ] erfordert und die ALPN-Erweiterung nur von OpenSSL 1.0.2 unterstützt wird.

Wir haben auch NPN [ Next Protocol Negotiation ] für HTTP/2 implementiert, was derzeit mit den meisten Clients funktioniert, aber die Unterstützung für NPN wird eingestellt, da SPDY Anfang 2016 veraltet ist. Das bedeutet, dass Sie HTTP/2 mit der OpenSSL-Version verwenden können, die derzeit Teil vieler Linux-Distributionen ist, aber Sie müssen bedenken, dass sie in naher Zukunft nicht mehr funktionieren wird.

Das ist alles zur Konfiguration von NGINX für HTTP/2, und damit ist meine Präsentation abgeschlossen. Danke schön.

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

Fragen und Antworten

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

A: Derzeit unterstützen wir nur HTTP/2 auf der Clientseite. Sie können HTTP/2 nicht mit proxy_pass konfigurieren. [ Herausgeber – In der Originalversion dieses Beitrags wurde dieser Satz fälschlicherweise als „Sie können HTTP/2 mit proxy_pass konfigurieren.“ transkribiert. Wir entschuldigen uns für etwaige Verwirrungen, die dadurch entstanden sein könnten. ]

Aber was ist der Sinn von HTTP/2 auf der Backend-Seite? Denn wie Sie den Benchmarks entnehmen können, bietet HTTP/2 für Netzwerke mit geringer Latenz, wie etwa Upstream-Verbindungen, keine großen Vorteile.

Darüber hinaus verfügen Sie in NGINX über das Keepalive -Modul und können einen Keepalive-Cache konfigurieren. Der wichtigste Leistungsvorteil von HTTP/2 besteht darin, dass zusätzliche Handshakes entfallen. Wenn Sie dies jedoch bereits mit einem Keepalive-Cache tun, benötigen Sie HTTP/2 auf der Upstream-Seite nicht.

Weitere HTTP/2-Ressourcen

• HTTP/2 für Web-Anwendungsentwickler – Whitepaper (PDF) mit allem, was Sie über HTTP/2 wissen müssen
• High Performance Browser Networking – Sonderausgabe des E-Books von Ilya Grigorik von Google
• Was ist neu in HTTP/2? – NGINX-Webinar beschreibt die wichtigsten Funktionen und gibt Implementierungstipps
• 7 Tipps zur Verbesserung der HTTP/2-Leistung – Blogbeitrag
• Liste der Browser, die HTTP/2 unterstützen – Kann ich diese Website verwenden?

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