7 Tipps für eine schnellere HTTP/2-Performance

NGINX | 26. Oktober 2015

Weitere Informationen zu HTTP/2 finden Sie in der Aufzeichnung unseres beliebten Webinars „Was ist neu in HTTP/2?“

Das bewährte Hypertext Transfer Protocol, kurz HTTP, wurde nun aktualisiert. Der HTTP/2-Standard wurde im Mai 2015 verabschiedet und wird derzeit in Browsern und Webservern implementiert (darunter NGINX Plus und NGINX Open Source). HTTP/2 wird derzeit von fast zwei Dritteln aller verwendeten Webbrowser unterstützt, und dieser Anteil wächst jeden Monat um mehrere Prozentpunkte.

HTTP/2 basiert auf dem SPDY-Protokoll von Google. SPDY kann weiterhin verwendet werden, bis die Unterstützung dafür im Chrome-Browser von Google Anfang 2016 endet. NGINX gehörte zu den ersten Unterstützern von SPDY und übernimmt nun bei HTTP/2 dieselbe Vorreiterrolle. Unser umfassendes Whitepaper „HTTP/2 für Webanwendungsentwickler“ (PDF) beschreibt HTTP/2, zeigt, wie es auf SPDY aufbaut, und erläutert die Implementierung.

Die wichtigsten Funktionen von HTTP/2 entsprechen denen von SPDY:

HTTP/2 ist ein Binär- und kein Textprotokoll, wodurch es kompakter und effizienter ist.
Es verwendet eine einzige Multiplex-Verbindung pro Domain anstelle mehrerer Verbindungen, die jeweils eine Datei übertragen.
Header werden mit dem speziell dafür entwickelten HPACK-Protokoll komprimiert (anstatt wie bei SPDY mit gzip)
HTTP/2 verfügt über ein komplexes Priorisierungsschema, das Browser dabei unterstützt, die am dringendsten benötigten Dateien zuerst anzufordern. Dieses Schema wird von NGINX vollständig unterstützt (SPDY verwendete ein einfacheres Schema).

Nun müssen Sie entscheiden, ob Sie auf HTTP/2 umsteigen möchten – und dazu gehört auch, zu wissen, wie Sie das Potenzial von HTTP/2 optimal ausschöpfen. Dieser Blogbeitrag führt Sie durch die leistungsrelevanten Aspekte des Entscheidungs- und Implementierungsprozesses. Sehen Sie sich diese 7 Tipps zur Optimierung der HTTP/2-Performance an:

Entscheiden Sie, ob Sie HTTP/2 heute benötigen
HTTP/2 und TLS terminieren
Erwägen Sie, mit SPDY zu beginnen
Identifizieren Sie HTTP/1.x-Optimierungen in Ihrem Code
HTTP/2 oder SPDY implementieren
HTTP/1.x-Optimierungen überarbeiten
Intelligentes Sharding implementieren

Hinweis: Streng genommen erfordern weder SPDY noch HTTP/2 TLS, doch beide bieten vor allem in Verbindung mit SSL/TLS Vorteile, und Browser unterstützen SPDY oder HTTP/2 nur, wenn SSL/TLS verwendet wird.

Tipp 1 – Entscheiden Sie, ob Sie HTTP/2 heute benötigen

Die Implementierung von HTTP/2 ist einfach, wie wir in unserem Whitepaper erläutern: „HTTP/2 für Webanwendungsentwickler“ (PDF). HTTP/2 ist jedoch kein Allheilmittel; für manche Webanwendungen ist es nützlich, für andere weniger.

Wenn Sie SSL/TLS verwenden (im Folgenden als TLS bezeichnet), wird der Einsatz von HTTP/2 wahrscheinlich die Leistung Ihrer Website verbessern. Andernfalls müssen Sie zunächst TLS-Unterstützung hinzufügen, bevor Sie HTTP/2 verwenden können. In diesem Fall ist davon auszugehen, dass der durch TLS verursachte Leistungsverlust durch den Leistungsvorteil von HTTP/2 in etwa ausgeglichen wird. Prüfen Sie jedoch, ob dies für Ihre Website tatsächlich zutrifft, bevor Sie sich für eine Implementierung entscheiden.

Hier sind fünf wesentliche potenzielle Vorteile von HTTP/2:

Verwendet eine einzige Verbindung pro Server – HTTP/2 verwendet eine Verbindung pro Server statt einer Verbindung pro Dateianfrage. Dadurch müssen deutlich weniger zeitaufwendige Verbindungen aufgebaut werden. Dies ist insbesondere bei TLS von Vorteil, da der Aufbau von TLS-Verbindungen besonders zeitaufwendig ist.
Bietet eine höhere TLS-Leistung – HTTP/2 benötigt nur einen aufwendigen TLS-Handshake, und durch Multiplexing wird die einzelne Verbindung optimal genutzt. HTTP/2 komprimiert außerdem Header-Daten. Der Verzicht auf HTTP/1.x-Leistungsoptimierungen wie das Zusammenfassen von Dateien ermöglicht zudem ein effizienteres Caching.
Vereinfacht Ihre Webanwendungen – Mit HTTP/2 können Sie auf HTTP/1.x-„Optimierungen“ verzichten, die Ihnen als Anwendungsentwickler – und dem Clientgerät – mehr Arbeit abverlangen.
Ideal für gemischte Webseiten – HTTP/2 spielt seine Stärken bei herkömmlichen Webseiten aus, die HTML, CSS, JavaScript-Code, Bilder und begrenzte Multimedia-Inhalte kombinieren. Browser können Dateianfragen priorisieren, damit wichtige Teile der Seite zuerst und schnell angezeigt werden.
Unterstützt höhere Sicherheit – Durch die Verringerung der Leistungseinbußen durch TLS ermöglicht HTTP/2 mehr Webanwendungen dessen Einsatz und bietet Nutzern dadurch höhere Sicherheit.

Und hier sind fünf entsprechende Nachteile, auf die Sie stoßen werden:

Höherer Overhead für die einzelne Verbindung – Der HPACK-Datenkomprimierungsalgorithmus aktualisiert an beiden Endpunkten eine Nachschlagetabelle. Dadurch wird die Verbindung zustandsbehaftet und benötigt zusätzlichen Arbeitsspeicher.
Möglicherweise benötigen Sie keine Verschlüsselung – Wenn Ihre Daten nicht geschützt werden müssen oder bereits durch DRM oder eine andere Kodierung geschützt sind, bietet Ihnen die TLS-Sicherheit wahrscheinlich keinen großen Mehrwert.
HTTP/1.x-Optimierungen sind kontraproduktiv – HTTP/1.x-Optimierungen beeinträchtigen die Leistung in Browsern, die HTTP/2 unterstützen, und sie rückgängig zu machen, bedeutet zusätzliche Arbeit für Sie.
Große Downloads profitieren nicht – Wenn Ihre Webanwendung hauptsächlich große Dateien zum Herunterladen oder Medienstreams bereitstellt, möchten Sie wahrscheinlich kein TLS verwenden, und Multiplexing bietet keinen Vorteil, wenn nur ein einziger Stream genutzt wird.
Ihre Kunden interessiert das möglicherweise nicht – Vielleicht glauben Sie, dass es Ihren Kunden egal ist, ob die Katzenvideos, die sie auf Ihrer Website teilen, mit TLS und HTTP/2 geschützt sind – und damit könnten Sie recht haben.

Letztlich kommt es auf die Performance an – und in dieser Hinsicht haben wir eine gute und eine schlechte Nachricht.

Die gute Nachricht ist, dass ein erster interner Test, den wir hier bei NGINX durchgeführt haben, das theoretisch zu erwartende Ergebnis zeigt: Bei Webseiten mit gemischten Inhalten, die über Verbindungen mit typischen Internetlatenzen abgerufen werden, bietet HTTP/2 eine bessere Leistung als HTTP/1.x und HTTPS. Die Ergebnisse lassen sich abhängig von der typischen Paketumlaufzeit (Round-Trip Time, RTT) der Verbindung in drei Gruppen einteilen:

Sehr niedrige RTTs (0–20 ms) – Zwischen HTTP/1.x, HTTP/2 und HTTPS besteht praktisch kein Unterschied.
Typische Internet-RTTs (30–250 ms) – HTTP/2 ist schneller als HTTP/1.x, und beide sind schneller als HTTPS. Zwischen nahe beieinanderliegenden US-Städten beträgt die RTT etwa 30 ms, von Küste zu Küste (etwa 3000 Meilen) sind es rund 70 ms. Auf der kürzesten Route zwischen Tokio und London beträgt die RTT etwa 240 ms.
Hohe RTTs (ab 300 ms) – HTTP/1.x ist schneller als HTTP/2, das wiederum schneller als HTTPS ist.

Die Abbildung zeigt die Zeit bis zur ersten Darstellung – also die Zeit, bis der Benutzer erstmals Inhalte der Webseite auf dem Bildschirm sieht. Dieser Messwert gilt häufig als entscheidend dafür, wie Benutzer die Reaktionsgeschwindigkeit einer Website wahrnehmen.

Weitere Einzelheiten zu unseren Tests finden Sie in meinem Vortrag von der nginx.conf 2015: „Das HTTP/2-Modul in NGINX“.

Allerdings ist jede Webseite anders, und tatsächlich ist auch jede Benutzersitzung anders. Wenn Sie Streaming-Medien oder große Dateien zum Herunterladen anbieten oder wenn Sie aus Ihren HTTP/1.x-Optimierungen auch noch das, äh, letzte Quäntchen herausgekitzelt haben (mit Verlaub an „Der Marsianer“), können Ihre Ergebnisse anders oder sogar gegenteilig ausfallen.

Unterm Strich könnte die Kosten-Nutzen-Abwägung für Sie nicht eindeutig ausfallen. Informieren Sie sich in diesem Fall so umfassend wie möglich, führen Sie Leistungstests mit Ihren eigenen Inhalten durch und treffen Sie anschließend eine Entscheidung. (Hilfestellung bietet unser Webinar „Was ist neu bei HTTP/2?“.)

Tipp 2 – HTTP/2 und TLS terminieren

Das Terminieren eines Protokolls bedeutet, dass Clients über ein gewünschtes Protokoll wie TLS oder HTTP/2 eine Verbindung zu einem Proxyserver herstellen. Der Proxyserver stellt anschließend Verbindungen zu Anwendungsservern, Datenbankservern usw. her, ohne dabei zwingend dasselbe Protokoll zu verwenden, wie in der Abbildung dargestellt.

Die Verwendung eines separaten Servers für die Terminierung bedeutet den Umstieg auf eine Architektur mit mehreren Servern. Dabei kann es sich um separate physische Server, virtuelle Server oder virtuelle Serverinstanzen in einer Cloud-Umgebung wie AWS handeln. Dies erhöht die Komplexität gegenüber einem einzelnen Server oder sogar einer Kombination aus Anwendungs- und Datenbankserver. Dafür bietet eine solche Architektur viele Vorteile und ist für stark frequentierte Websites praktisch – im wahrsten Sinne des Wortes – unverzichtbar.

Sobald einer bestehenden Konfiguration ein Server oder virtueller Server vorgeschaltet wird, eröffnen sich zahlreiche Möglichkeiten. Der neue Server entlastet die anderen Server von der Kommunikation mit den Clients und kann für den Lastenausgleich, das Caching statischer Dateien und andere Zwecke eingesetzt werden. Anwendungsserver und andere Server lassen sich dann bei Bedarf problemlos hinzufügen und austauschen.

NGINX und NGINX Plus werden häufig für all diese Zwecke eingesetzt – zur TLS- und HTTP/2-Terminierung, zur Lastverteilung und für vieles mehr. Die bestehende Umgebung muss überhaupt nicht geändert werden; ihr muss lediglich der NGINX-Server vorgeschaltet werden.

Tipp 3 – Erwägen Sie, mit SPDY zu beginnen

Anmerkung der Redaktion – Seit der Veröffentlichung dieses Blogbeitrags wird SPDY von den wichtigsten Browsern nicht mehr unterstützt. Für eine breit angelegte Bereitstellung kommt SPDY daher nicht mehr als Ausgangspunkt infrage.

SPDY ist das Vorgängerprotokoll von HTTP/2 und bietet insgesamt eine vergleichbare Leistung. Da es bereits seit mehreren Jahren existiert, unterstützen mehr Webbrowser SPDY als HTTP/2. Zum Zeitpunkt der Erstellung dieses Beitrags schließt sich diese Lücke jedoch: Etwa zwei Drittel der Webbrowser unterstützen HTTP/2, während rund vier von fünf SPDY unterstützen.

Wenn Sie den neuen Webtransportprotokoll-Ansatz möglichst schnell implementieren und schon heute die größtmögliche Anzahl von Benutzern unterstützen möchten, können Sie zunächst SPDY anbieten. Anfang 2016, wenn die Unterstützung für SPDY allmählich eingestellt wird, können Sie dann auf HTTP/2 umsteigen – zumindest mit NGINX ist diese Umstellung schnell erledigt. Bis dahin werden mehr Benutzer Browser verwenden, die HTTP/2 unterstützen. So haben Sie während dieser Übergangsphase stets die bestmögliche Lösung für die größtmögliche Anzahl Ihrer Benutzer bereitgestellt.

Tipp 4 – Ermitteln Sie, welche HTTP/1.x-Optimierungen Sie verwenden

Bevor Sie sich für die Implementierung von HTTP/2 entscheiden, müssen Sie ermitteln, in welchem Umfang Ihre Codebasis für HTTP/1.x optimiert ist. Dabei sollten Sie auf vier Arten von Optimierungen achten:

Domain-Sharding – Möglicherweise haben Sie Dateien bereits auf verschiedene Domains verteilt, um die Parallelität bei der Dateiübertragung an den Webbrowser zu erhöhen; Content Delivery Networks (CDNs) tun dies automatisch. Unter HTTP/2 bringt das jedoch keine Vorteile – und kann die Leistung sogar beeinträchtigen. Mit HTTP/2-kompatiblem Domain-Sharding (siehe Tipp 7) können Sie das Sharding auf HTTP/1.x-Nutzer beschränken.
Bild-Sprites – Bild-Sprites fassen mehrere Bilder zusammen, die in einer einzigen Datei heruntergeladen werden. Anschließend ruft separater Code die Bilder bei Bedarf ab. Die Vorteile von Bild-Sprites fallen unter HTTP/2 geringer aus, dennoch können sie weiterhin nützlich sein.
Zusammenfassen von Codedateien – Ähnlich wie bei Bild-Sprites werden Codeabschnitte, die normalerweise als separate Dateien verwaltet und übertragen würden, in einer einzigen Datei zusammengefasst. Der Browser findet den benötigten Code dann in der zusammengefassten Datei und führt ihn bei Bedarf aus.
Einbetten von Dateien – CSS-Code, JavaScript-Code und sogar Bilder werden direkt in die HTML-Datei eingebettet. Dadurch müssen weniger Dateien übertragen werden, allerdings ist die HTML-Datei beim ersten Herunterladen entsprechend größer.

Bei den letzten drei Optimierungsarten werden jeweils kleine Dateien zu größeren zusammengefasst, um die Anzahl neuer Verbindungen und der anfänglichen Handshakes zu reduzieren, die insbesondere bei TLS aufwendig sind.

Die erste Optimierung, das Domain-Sharding, bewirkt das Gegenteil: Durch die Einbeziehung zusätzlicher Domains wird das Öffnen weiterer Verbindungen erzwungen. Zusammen können diese scheinbar widersprüchlichen Techniken die Leistung von HTTP/1.x-Websites recht effektiv steigern. Ihre Konzeption, Implementierung, Verwaltung und ihr Betrieb erfordern jedoch allesamt Zeit, Aufwand und Ressourcen.

Ermitteln Sie vor der Implementierung von HTTP/2, wo diese Optimierungen zum Einsatz kommen und wie sie sich derzeit auf das Anwendungsdesign und die Arbeitsabläufe in Ihrem Unternehmen auswirken. So können Sie sie nach der Umstellung auf HTTP/2 anpassen oder rückgängig machen.

Tipp 5 – HTTP/2 oder SPDY bereitstellen

Die Bereitstellung von HTTP/2 oder SPDY ist eigentlich gar nicht so schwierig. Wenn Sie NGINX verwenden, müssen Sie das Protokoll lediglich in Ihrer NGINX-Konfiguration „aktivieren“. Wie das für HTTP/2 funktioniert, erläutern wir in unserem Whitepaper „HTTP/2 für Webanwendungsentwickler“ (PDF). Browser und Server handeln anschließend aus, welches Protokoll verwendet wird. Unterstützt der Browser ebenfalls HTTP/2 (und wird TLS verwendet), fällt die Wahl auf HTTP/2.

Sobald Sie HTTP/2 auf Serverebene implementiert haben, werden die Sitzungen von Benutzern mit Browser-Versionen, die HTTP/2 unterstützen, über HTTP/2 mit Ihrer Webanwendung ausgeführt. Die Sitzungen von Benutzern mit älteren Browser-Versionen werden dagegen über HTTP/1.x ausgeführt, wie in der Abbildung dargestellt. Wenn Sie HTTP/2 oder SPDY für eine stark frequentierte Website implementieren, sollten Sie Prozesse einrichten, um die Leistung vor und nach der Umstellung zu messen und die Änderung rückgängig zu machen, falls sie erhebliche negative Auswirkungen hat.

Hinweis: Da HTTP/2 nur eine einzige Verbindung verwendet, gewinnen einige Details Ihrer NGINX-Konfiguration an Bedeutung. Überprüfen Sie Ihre NGINX-Konfiguration und achten Sie dabei besonders auf die Optimierung und das Testen der Einstellungen von Direktiven wie output_buffers, proxy_buffers und ssl_buffer_size. Allgemeine Konfigurationsanweisungen finden Sie unter NGINX SSL/TLS-Terminierung im NGINX Plus-Administratorhandbuch. Konkretere Tipps finden Sie in unseren Blogbeiträgen SSL-Auslagerung, Verschlüsselung und Zertifikate mit NGINX und So verbessern Sie die SEO mit HTTPS und NGINX. Unser Whitepaper NGINX SSL-Performance erläutert, wie sich die Wahl der Serverschlüsselgröße, der Schlüsselvereinbarung und der Blockchiffre auf die Leistung auswirkt.

Hinweis: Die Verwendung von Verschlüsselungsverfahren mit HTTP/2 erfordert möglicherweise besondere Aufmerksamkeit. Der RFC für HTTP/2 enthält eine lange Liste von zu vermeidenden Verschlüsselungssammlungen, und möglicherweise möchten Sie die Liste der Verschlüsselungsverfahren selbst konfigurieren. Bei NGINX und NGINX Plus sollten Sie die Direktive ssl_ciphers optimieren, ssl_prefer_server_ciphers aktivieren und die Konfiguration mit gängigen Browserversionen testen. Der Qualys SSL Server Test analysiert die Konfiguration von SSL-Webservern, ist jedoch (Stand November 2015) für HTTP/2-Handshakes nicht zuverlässig.

Tipp 6 – HTTP/1.x-Optimierungen überarbeiten

Überraschenderweise ist das Rückgängigmachen oder Überarbeiten Ihrer HTTP/1.x-Optimierungen tatsächlich der kreativste Teil einer HTTP/2-Implementierung. Dabei sind mehrere Aspekte zu berücksichtigen, und es gibt viele Möglichkeiten, wie Sie vorgehen können.

Bevor Sie Änderungen vornehmen, sollten Sie überlegen, ob Nutzer älterer Browser dadurch Nachteile haben. Vor diesem Hintergrund gibt es drei grundlegende Strategien, um HTTP/1.x-Optimierungen rückgängig zu machen oder zu überarbeiten:

Hier gibt es nichts zu tun – Wenn Sie Ihre Anwendung(en) nicht für HTTP/1.x optimiert oder nur moderate Änderungen vorgenommen haben, die Sie beibehalten möchten, müssen Sie nichts weiter tun, damit Ihre App HTTP/2 unterstützt.
Gemischter Ansatz – Sie können sich dafür entscheiden, die Zusammenfassung von Dateien und Daten zu reduzieren, aber nicht vollständig darauf zu verzichten. So kann beispielsweise die Zusammenfassung zusammengehöriger kleiner Bilder in Sprites beibehalten werden, während auf das Aufblähen der ursprünglichen HTML-Datei durch eingebettete Daten verzichtet wird.
Vollständige Rücknahme der HTTP/1.x-Optimierungen (beachten Sie jedoch den Hinweis zum Domain-Sharding in Tipp 7) – Möglicherweise möchten Sie ganz auf diese Optimierungen verzichten.

Caching ist ein wenig unberechenbar. Theoretisch funktioniert Caching optimal, wenn eine Vielzahl kleiner Dateien vorhanden ist. Dies führt jedoch zu zahlreichen Datei-E/A-Vorgängen. Es kann sinnvoll sein, eng zusammengehörige Dateien teilweise zusammenzufassen – sowohl im Hinblick auf den Workflow als auch auf die Anwendungsleistung. Berücksichtigen Sie sorgfältig Ihre eigenen Erfahrungen sowie die Erkenntnisse, die andere Entwickler bei der Implementierung von HTTP/2 teilen.

Tipp 7 – Intelligentes Sharding implementieren

Domain-Sharding ist vielleicht die radikalste und möglicherweise auch erfolgreichste Optimierungsstrategie für HTTP/1.x. Sie können eine Variante des Domain-Shardings verwenden, die die Leistung von HTTP/1.x weiterhin verbessert, von HTTP/2 jedoch im Wesentlichen ignoriert wird – was von Vorteil ist. (HTTP/2 profitiert aufgrund der Verwendung einer einzigen Verbindung im Allgemeinen nicht von Domain-Sharding.)

Für ein HTTP/2‑freundliches Sharding müssen diese beiden Voraussetzungen erfüllt sein:

Sorgen Sie dafür, dass die Domainnamen für aufgeteilte Ressourcen auf dieselbe IP-Adresse verweisen.
Stellen Sie sicher, dass Ihr Zertifikat einen Platzhalter enthält, durch den es für alle beim Sharding verwendeten Domainnamen gültig ist, oder dass Sie über ein geeignetes Multidomain-Zertifikat verfügen.

Weitere Informationen finden Sie in RFC 7540, Hypertext Transfer Protocol Version 2 (HTTP/2).

Wenn diese Bedingungen erfüllt sind, erfolgt das Sharding bei HTTP/1.x – die Domains unterscheiden sich ausreichend, sodass Browser zusätzliche Verbindungsgruppen erstellen –, nicht jedoch bei HTTP/2. Hier werden die separaten Domains als eine einzige Domain behandelt, und über eine einzige Verbindung kann auf alle zugegriffen werden.

Fazit

HTTP/2 und TLS verbessern voraussichtlich die Leistung Ihrer Website und vermitteln den Nutzern, dass ihre Interaktion mit Ihrer Website sicher ist. Ganz gleich, ob Sie in Ihrem Umfeld als Erster HTTP/2 implementieren oder mit Ihren Mitbewerbern gleichziehen möchten: Die Unterstützung für HTTP/2 lässt sich schnell und zuverlässig hinzufügen.

Mit diesen Tipps erzielen Sie bei minimalem laufendem Aufwand die bestmögliche HTTP/2-Performance. So können Sie sich darauf konzentrieren, schnelle, leistungsfähige und sichere Anwendungen zu entwickeln, die sich einfach warten und betreiben lassen.

Ressourcen

Ausführliche Informationen zu HTTP/2 finden Sie im Whitepaper von NGINX (PDF).
Die Website „Can I use“ zeigt die Browserunterstützung für eine Vielzahl von Frontend-Webtechnologien, darunter SPDY und HTTP/2.
Im Januar 2016 nutzten mehr als 6 % der Websites HTTP/2.

Einzelheiten zu unseren Tests finden Sie in der HTTP/2-Präsentation von der nginx.conf 2015.
NGINX bietet ein Webinar mit dem Titel „Was ist neu in HTTP/2?“ an, in dem die wichtigsten Funktionen beschrieben und Empfehlungen zur Implementierung gegeben werden.
Einen Überblick über Tipps zur Leistungsoptimierung von NGINX finden Sie in unserem Blogbeitrag „10 Tipps für eine 10-fache Anwendungsleistung“.