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:
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:
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.
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:
Und hier sind fünf entsprechende Nachteile, auf die Sie stoßen werden:
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:
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.)
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.
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.
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:
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.
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 .
Ü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:
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.
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:
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.
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.
„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."