BLOG | NGINX

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

NGINX-Teil-von-F5-horiz-schwarz-Typ-RGB
Valentin Bartenev Miniaturbild
Valentin Bartenev
Veröffentlicht am 26. Oktober 2015

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

Der bewährte HyperText Transfer Protocol- oder HTTP -Standard wurde jetzt aktualisiert. Der HTTP/2-Standard wurde im Mai 2015 genehmigt und wird jetzt in Browsern und Webservern (einschließlich NGINX Plus und NGINX Open Source ) implementiert. HTTP/2 wird derzeit von fast zwei Dritteln aller genutzten Webbrowser unterstützt und dieser Anteil wächst jeden Monat um mehrere Prozentpunkte.

HTTP/2 basiert auf dem SPDY-Protokoll von Google und SPDY ist noch eine Option, bis der Support dafür im Chrome-Browser von Google Anfang 2016 endet. NGINX war ein Pionierunterstützer von SPDY und spielt jetzt die gleiche Rolle mit HTTP/2. Unser umfassendes Whitepaper „HTTP/2 für Web-Anwendungsentwickler“ (PDF) beschreibt HTTP/2, zeigt, wie es auf SPDY aufbaut, und erklärt, wie es implementiert wird.

Die Hauptfunktionen von HTTP/2 sind dieselben wie bei SPDY:

  • HTTP/2 ist kein Text-, sondern ein Binärprotokoll und daher kompakter und effizienter
  • Es wird eine einzige Multiplex-Verbindung pro Domäne verwendet, statt mehrerer Verbindungen, die jeweils eine Datei übertragen.
  • Header werden mit dem speziell entwickelten HPACK-Protokoll komprimiert (anstatt mit gzip wie bei SPDY).
  • HTTP/2 verfügt über ein komplexes Priorisierungsschema, das Browsern hilft, zuerst die am meisten benötigten Dateien anzufordern. Dieses Schema wird in NGINX vollständig unterstützt (SPDY hatte ein einfacheres Schema).

Jetzt müssen Sie entscheiden, ob Sie mit HTTP/2 fortfahren möchten – und dazu gehört auch, zu wissen, wie Sie die Website optimal nutzen können. Dieser Blogbeitrag führt Sie durch die leistungsbezogenen Aspekte des Entscheidungs- und Implementierungsprozesses. Schauen Sie sich diese 7 Tipps zur HTTP/2-Leistung an:

  1. Entscheiden Sie noch heute, ob Sie HTTP/2 benötigen
  2. HTTP/2 und TLS beenden
  3. Erwägen Sie den Einstieg mit SPDY
  4. Identifizieren Sie HTTP/1.x-Optimierungen in Ihrem Code
  5. Implementieren Sie HTTP/2 oder SPDY
  6. HTTP/1.x-Optimierungen überarbeiten
  7. Implementieren Sie Smart Sharding

Notiz : Streng genommen erfordern weder SPDY noch HTTP/2 TLS, aber beide sind hauptsächlich in Verbindung mit SSL/TLS von Vorteil, und Browser unterstützen SPDY oder HTTP/2 nur, wenn SSL/TLS verwendet wird.

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

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

Die Verwendung von HTTP/2 verbessert wahrscheinlich die Website-Leistung, wenn Sie SSL/TLS (im Folgenden als TLS bezeichnet) verwenden. Wenn dies nicht der Fall ist, müssen Sie TLS-Unterstützung hinzufügen, bevor Sie HTTP/2 verwenden können. In diesem Fall können Sie davon ausgehen, dass die Leistungseinbußen durch die Verwendung von TLS in etwa durch die Leistungsvorteile bei Verwendung von HTTP/2 ausgeglichen werden. Testen Sie jedoch, ob dies für Ihre Site wirklich zutrifft, bevor Sie eine Implementierungsentscheidung treffen.

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

  1. Verwendet eine einzelne Verbindung pro Server – HTTP/2 verwendet eine Verbindung pro Server, anstatt einer Verbindung pro Dateianforderung. Dadurch ist ein deutlich geringerer, zeitaufwändiger Verbindungsaufbau nötig, was insbesondere bei TLS ein Vorteil ist, da der Aufbau von TLS-Verbindungen besonders zeitintensiv ist.
  2. Bietet eine schnellere TLS-Leistung – HTTP/2 benötigt nur einen teuren TLS-Handshake und Multiplexing holt das Beste aus der einzelnen Verbindung heraus. HTTP/2 komprimiert außerdem Header-Daten und durch das Vermeiden von HTTP/1.x-Leistungsoptimierungen wie Dateiverkettung kann das Caching effizienter arbeiten.
  3. Vereinfacht Ihre Webanwendungen – Mit HTTP/2 können Sie sich von HTTP/1.x-„Optimierungen“ verabschieden, die Ihnen als App-Entwickler und dem Client-Gerät mehr Arbeit ersparen.
  4. Ideal für gemischte Webseiten – HTTP/2 glänzt bei herkömmlichen Webseiten, die HTML, CSS, JavaScript-Code, Bilder und begrenzte Multimediainhalte mischen. Browser können Dateianforderungen priorisieren, damit wichtige Teile der Seite zuerst und schnell angezeigt werden.
  5. Unterstützt mehr Sicherheit – Durch die Reduzierung der Leistungseinbußen durch TLS kann HTTP/2 von mehr Webanwendungen verwendet werden, was den Benutzern mehr Sicherheit bietet.

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

  1. Höherer Overhead für die Einzelverbindung – Der HPACK-Datenkomprimierungsalgorithmus aktualisiert eine Nachschlagetabelle an beiden Enden. Dadurch wird die Verbindung zustandsbehaftet und die einzelne Verbindung erfordert zusätzlichen Speicher.
  2. Möglicherweise benötigen Sie keine Verschlüsselung – Wenn Ihre Daten keinen Schutz benötigen oder bereits durch DRM oder eine andere Verschlüsselung geschützt sind, hilft Ihnen die TLS-Sicherheit wahrscheinlich nicht viel.
  3. HTTP/1.x-Optimierungen schaden – HTTP/1.x-Optimierungen beeinträchtigen tatsächlich die Leistung in Browsern, die HTTP/2 unterstützen, und ihre Beseitigung bedeutet für Sie Mehrarbeit.
  4. Große Downloads bringen keinen Vorteil – Wenn Ihre Webanwendung hauptsächlich große, herunterladbare Dateien oder Medienstreams liefert, möchten Sie TLS wahrscheinlich nicht, und Multiplexing bietet keinen Vorteil, wenn nur ein Stream verwendet wird.
  5. Ihren Kunden ist das vielleicht egal – Vielleicht glauben Sie, dass es Ihren Kunden egal ist, ob die Katzenvideos, die sie auf Ihrer Site teilen, mit TLS und HTTP/2 geschützt sind – und damit könnten Sie Recht haben.

Es kommt alles auf die Leistung an – und in dieser Hinsicht haben wir gute und schlechte Nachrichten.

Die gute Nachricht ist, dass ein erster interner Test, den wir hier bei NGINX durchgeführt haben, das theoretisch vorhergesagte Ergebnis zeigt: Bei Webseiten mit gemischten Inhalten, die über Verbindungen mit typischen Internetlatenzen angefordert werden, ist die Leistung von HTTP/2 besser als die von HTTP/1.x und HTTPS. Die Ergebnisse lassen sich je nach der typischen Roundtrip-Zeit (RTT) der Verbindung in drei Gruppen einteilen:

  • Sehr niedrige RTTs (0–20 ms) – Es gibt praktisch keinen Unterschied zwischen HTTP/1.x, HTTP/2 und HTTPS.
  • Typische Internet-RTTs (30–250 ms) – HTTP/2 ist schneller als HTTP/1.x und beide sind schneller als HTTPS. Für nahe beieinander liegende US-Städte beträgt die RTT etwa 30 ms, und von Küste zu Küste (ungefähr 3000 Meilen) beträgt sie etwa 70 ms. Auf der kürzesten Strecke zwischen Tokio und London beträgt die RTT etwa 240 ms.
  • Hohe RTTs (300 ms und mehr) – HTTP/1.x ist schneller als HTTP/2, das wiederum schneller ist als HTTPS.

Die Abbildung zeigt die Zeit bis zum ersten Mal, also die Zeit, bis der Nutzer den Inhalt einer Webseite erstmals auf dem Bildschirm erscheinen sieht. Diese Messung wird oft als entscheidend für die Wahrnehmung der Reaktionsfähigkeit einer Website durch die Benutzer angesehen.

Einzelheiten zu unseren Tests finden Sie in meiner Präsentation „Das HTTP/2-Modul in NGINX“ auf der nginx.conf 2015.

Allerdings ist jede Webseite anders und tatsächlich ist jede Benutzersitzung anders. Wenn Sie über Streaming-Medien oder große herunterladbare Dateien verfügen oder wenn Sie Ihre HTTP/1.x-Optimierungen bis zum Äußersten ausgereizt haben (mit Entschuldigung an Der Marsianer ), können Ihre Ergebnisse anders oder sogar entgegengesetzt sein.

Unterm Strich lässt sich sagen: Das Kosten-Nutzen-Verhältnis ist für Sie möglicherweise unklar. Wenn ja, lernen Sie so viel wie möglich, führen Sie Leistungstests für Ihre eigenen Inhalte durch und treffen Sie dann eine Entscheidung. (Zur Anleitung sehen Sie sich unser Webinar „ Was ist neu in HTTP/2? “ an.)

Tipp 2: HTTP/2 und TLS beenden

Das Beenden eines Protokolls bedeutet, dass Clients eine Verbindung zu einem Proxyserver unter Verwendung eines gewünschten Protokolls wie TLS oder HTTP/2 herstellen. Der Proxyserver stellt dann eine Verbindung zu Anwendungsservern, Datenbankservern usw. her, ohne notwendigerweise dasselbe Protokoll zu verwenden, wie in der Abbildung gezeigt.

Die Verwendung eines separaten Servers zur Terminierung bedeutet den Wechsel zu einer Multiserverarchitektur. Bei den Servern kann es sich um separate physische Server, virtuelle Server oder virtuelle Serverinstanzen in einer Cloudumgebung wie AWS handeln. Dies stellt im Vergleich zu einem einzelnen Server oder sogar einer Kombination aus Anwendungsserver und Datenbankserver eine Steigerung der Komplexität dar. Aber es bietet viele Vorteile und ist für stark frequentierte Websites praktisch (kein Wortspiel beabsichtigt) eine Notwendigkeit.

Sobald ein Server oder virtueller Server vor ein bestehendes Setup gestellt wird, ist vieles möglich. Der neue Server entlastet die anderen Server von der Aufgabe der Client-Kommunikation und kann zum Lastenausgleich, zur Zwischenspeicherung statischer Dateien und für andere Zwecke verwendet werden. Anwendungsserver und andere Server können je nach Bedarf problemlos hinzugefügt und ersetzt werden.

NGINX und NGINX Plus werden häufig für all diese Zwecke verwendet – zum Beenden von TLS und HTTP/2, zum Lastenausgleich und mehr. An der bestehenden Umgebung müssen keinerlei Änderungen vorgenommen werden, außer dass ein „Frontend“ mit dem NGINX-Server bereitgestellt wird.

Tipp 3 – Erwägen Sie den Einstieg mit SPDY

Herausgeber – Seit der Veröffentlichung dieses Blogbeitrags wird SPDY von den wichtigsten Browsern nicht mehr unterstützt. Für eine großflächige Bereitstellung ist der Einstieg mit SPDY keine Option mehr.

SPDY ist das Vorgängerprotokoll von HTTP/2 und seine Gesamtleistung ist ungefähr gleich. Da es bereits seit mehreren Jahren existiert, unterstützen mehr Webbrowser SPDY als HTTP/2 . Zum Zeitpunkt des Schreibens dieses Artikels schließt sich die Lücke jedoch; etwa zwei Drittel der Webbrowser unterstützen HTTP/2, während etwa vier von fünf SPDY unterstützen.

Wenn Sie es mit der Implementierung des neuen Web-Transportprotokolls eilig haben und schon heute die größtmögliche Anzahl von Benutzern unterstützen möchten, können Sie mit dem Anbieten von SPDY beginnen. Wenn dann Anfang 2016 die SPDY-Unterstützung allmählich eingestellt wird, können Sie auf HTTP/2 umsteigen – eine schnelle Umstellung, zumindest mit NGINX. Zu diesem Zeitpunkt verwenden bereits mehr Benutzer Browser, die HTTP/2 unterstützen. Sie haben also während dieser Umstellung das Beste für die größte Zahl Ihrer Benutzer getan.

Tipp 4: Ermitteln Sie Ihren Einsatz von HTTP/1.x-Optimierungen

Bevor Sie sich für die Implementierung von HTTP/2 entscheiden, müssen Sie ermitteln, wie viel Ihrer Codebasis für HTTP/1.x optimiert ist. Es gibt vier Arten von Optimierungen, auf die Sie achten sollten:

  1. Domänen-Sharding – Möglicherweise haben Sie Dateien bereits in verschiedenen Domänen abgelegt, um die Parallelität bei der Dateiübertragung zum Webbrowser zu erhöhen; Content Domain Networks (CDNs) tun dies automatisch. Aber es verbessert die Leistung unter HTTP/2 nicht – und kann sogar schaden. Sie können HTTP/2-versiertes Domänen-Sharding (siehe Tipp 7 ) verwenden, um nur für HTTP/1.x-Benutzer zu sharden.
  2. Bild-Sprites – Bild-Sprites sind Ansammlungen von Bildern, die in einer einzigen Datei heruntergeladen werden. Ein separater Code ruft die Bilder dann bei Bedarf ab. Die Vorteile von Sprite-Bildern sind unter HTTP/2 geringer, Sie finden sie jedoch möglicherweise immer noch nützlich.
  3. Verketten von Codedateien – Ähnlich wie bei Bild-Sprites werden Codeblöcke, die normalerweise als separate Dateien verwaltet und übertragen würden, zu einer einzigen Datei kombiniert. Der Browser findet und führt dann nach Bedarf den benötigten Code innerhalb der verketteten Datei aus.
  4. Inlining-Dateien – CSS-Code, JavaScript-Code und sogar Bilder werden direkt in die HTML-Datei eingefügt. Dies bedeutet weniger Dateiübertragungen, auf Kosten einer aufgeblähten HTML-Datei beim ersten Herunterladen.

Bei den letzten drei Optimierungsarten werden kleine Dateien zu größeren zusammengefasst, um die Anzahl neuer Verbindungen und den Initialisierungs-Handshake zu verringern, der bei TLS besonders kostspielig ist.

Die erste Optimierung, das Domain-Sharding, bewirkt das Gegenteil: Sie erzwingt das Öffnen weiterer Verbindungen, indem sie zusätzliche Domänen in die Situation einbezieht. Zusammen können diese scheinbar widersprüchlichen Techniken die Leistung von HTTP/1.x-Sites recht effektiv steigern. Für die Konzeption, Implementierung, Verwaltung und Ausführung aller dieser Lösungen sind jedoch Zeit, Aufwand und Ressourcen erforderlich.

Ermitteln Sie vor der Implementierung von HTTP/2, wo diese Optimierungen vorhanden sind und wie sie sich derzeit auf das Anwendungsdesign und den Workflow in Ihrem Unternehmen auswirken, damit Sie sie nach der Umstellung auf HTTP/2 ändern oder rückgängig machen können.

Tipp 5: HTTP/2 oder SPDY einsetzen

Tatsächlich ist die Bereitstellung von HTTP/2 oder SPDY nicht so schwer. Wenn Sie ein NGINX-Benutzer sind, „aktivieren“ Sie einfach das Protokoll in Ihrer NGINX-Konfiguration, wie wir es für HTTP/2 in unserem Whitepaper „HTTP/2 für Web-Anwendungsentwickler“ (PDF) ausführlich beschreiben. Der Browser und der Server verhandeln dann über die Auswahl eines Protokolls und entscheiden sich für HTTP/2, wenn der Browser dies auch unterstützt (und TLS verwendet wird).

Sobald Sie HTTP/2 auf Serverebene implementiert haben, werden die Sitzungen der Benutzer von Browserversionen, die HTTP/2 unterstützen, mit Ihrer Web-App über HTTP/2 ausgeführt. Bei Benutzern älterer Browserversionen werden die Sitzungen über HTTP/1.x ausgeführt, wie in der Abbildung dargestellt. Wenn Sie HTTP/2 oder SPDY für eine stark frequentierte Site implementieren, sollten Sie über Prozesse verfügen, um die Leistung vor und nach der Implementierung zu messen und die Änderung rückgängig zu machen, wenn sie erhebliche negative Auswirkungen hat.

Notiz : Mit HTTP/2 und der Verwendung einer einzigen Verbindung werden einige Details Ihrer NGINX-Konfiguration wichtiger. Überprüfen Sie Ihre NGINX-Konfiguration und achten Sie dabei besonders auf die Feinabstimmung und das Testen der Einstellungen von Anweisungen wie output_buffers , proxy_buffers und ssl_buffer_size . Allgemeine Konfigurationsanweisungen finden Sie unter „NGINX SSL/TLS-Terminierung“ im NGINX Plus-Administratorhandbuch. Spezifischere Tipps erhalten Sie in unseren Blogs SSL-Offloading, Verschlüsselung und Zertifikate mit NGINX und So verbessern Sie SEO mit HTTPS und NGINX . Unser Whitepaper NGINX SSL-Leistung untersucht, wie sich die Wahl der Serverschlüsselgröße, der Serververeinbarung und der Massenchiffre auf die Leistung auswirkt.

Notiz : Die Verwendung von Chiffren, die Sie mit HTTP/2 verwenden, erfordert möglicherweise besondere Aufmerksamkeit. Das RFC für HTTP/2 enthält eine lange Liste zu vermeidender Verschlüsselungssammlungen und Sie möchten die Verschlüsselungsliste möglicherweise lieber selbst konfigurieren. Erwägen Sie in NGINX und NGINX Plus die Anpassung der Direktive „ssl_ciphers“ , die Aktivierung von „ssl_prefer_server_ciphers“ und testen Sie die Konfiguration mit gängigen Browserversionen. Der Qualys SSL-Servertest analysiert die Konfiguration von SSL-Webservern, ist aber (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 müssen zahlreiche Aspekte berücksichtigt werden und es besteht hinsichtlich der Vorgehensweise ein großer Handlungsspielraum.

Bevor Sie mit den Änderungen beginnen, überlegen Sie, ob diese für Benutzer älterer Browser problematisch sein könnten. Vor diesem Hintergrund gibt es drei allgemeine Strategien zum Rückgängigmachen oder Überarbeiten von HTTP/1.x-Optimierungen:

  • Hier gibt es nichts zu sehen, Leute – Wenn Sie Ihre Anwendung(en) nicht für HTTP/1.x optimiert haben oder moderate Änderungen vorgenommen haben, die Sie gerne beibehalten, müssen Sie nichts tun, um HTTP/2 in Ihrer App zu unterstützen.
  • Gemischter Ansatz – Sie möchten die Datei- und Datenverkettung möglicherweise reduzieren, aber nicht vollständig vermeiden. Beispielsweise könnten einige Bild-Spritings für zusammenhängende Gruppen kleiner Bilder erhalten bleiben, wohingegen das Aufblähen der ursprünglichen HTML-Datei mit Inline-Daten wegfallen könnte.
  • Vollständige Umkehrung der HTTP/1.x-Optimierungen (siehe jedoch den Hinweis zur Domänen-Sharding in Tipp 7 ) – Möglicherweise möchten Sie diese Optimierungen ganz loswerden.

Beim Caching handelt es sich um eine Art Platzhalter. Theoretisch funktioniert das Caching optimal, wenn eine Vielzahl kleiner Dateien vorhanden ist. Das ist jedoch eine Menge Datei-E/A. Eine gewisse Verkettung eng verwandter Dateien kann sowohl für den Arbeitsablauf als auch für die Anwendungsleistung sinnvoll sein. Berücksichtigen Sie bei der Implementierung von HTTP/2 sorgfältig Ihre eigenen Erfahrungen und die Beiträge anderer Entwickler.

Tipp 7 – Implementieren Sie Smart Sharding

Domain-Sharding ist vielleicht die extremste und möglicherweise auch erfolgreichste HTTP/1.x-Optimierungsstrategie. Sie können eine Version des Domänen-Shardings verwenden, die die Leistung für HTTP/1.x immer noch verbessert, für HTTP/2 jedoch grundsätzlich ignoriert wird, was von Vorteil ist. (Was aufgrund der Verwendung einer einzelnen Verbindung im Allgemeinen nicht von der Domänen-Sharding profitiert.)

Sorgen Sie für HTTP/2-freundliches Sharding für die folgenden beiden Dinge:

  • Sorgen Sie dafür, dass die Domänennamen für Shard-Ressourcen in dieselbe IP-Adresse aufgelöst werden.
  • Stellen Sie sicher, dass Ihr Zertifikat über ein Platzhalterzeichen verfügt, das es für alle zum Sharding verwendeten Domänennamen gültig macht, oder dass Sie über ein entsprechendes Multidomänenzertifikat verfügen.

Einzelheiten finden Sie unter RFC 7540 , Hypertext Transfer Protocol Version 2 (HTTP/2) .

Wenn diese Bedingungen erfüllt sind, erfolgt Sharding für HTTP/1.x – die Domänen sind unterschiedlich genug, um Browser zum Erstellen zusätzlicher Verbindungssätze zu veranlassen – und nicht für HTTP/2. Die einzelnen Domänen werden als eine Domäne behandelt und eine einzelne Verbindung kann auf alle zugreifen.

Abschluss

HTTP/2 und TLS verbessern wahrscheinlich die Leistung Ihrer Site und vermitteln den Benutzern die Gewissheit, dass ihre Interaktion mit Ihrer Site sicher ist. Unabhängig davon, ob Sie in Ihrem Block als Erster HTTP/2 implementieren oder gegenüber Ihren Mitbewerbern aufholen, können Sie HTTP/2-Unterstützung schnell und gut hinzufügen.

Nutzen Sie diese Tipps, um mit minimalem Aufwand die höchste HTTP/2-Leistung zu erzielen, sodass Sie sich auf die Erstellung schneller, effektiver und sicherer Anwendungen konzentrieren können, die einfach zu warten und auszuführen sind.

Ressourcen

Weitere Blogbeiträge zu F5 NGINX lesen ›

„Dieser Blogbeitrag kann auf Produkte verweisen, die nicht mehr verfügbar und/oder nicht mehr unterstützt werden. Die aktuellsten Informationen zu verfügbaren F5 NGINX-Produkten und -Lösungen finden Sie in unserer NGINX-Produktfamilie . NGINX ist jetzt Teil von F5. Alle vorherigen NGINX.com-Links werden auf ähnliche NGINX-Inhalte auf F5.com umgeleitet."