HTTP/2: Hintergrund, Leistungsvorteile und Implementierungen

http/2: Netzwerkprotokoll, das die Ladegeschwindigkeit der Webseite erheblich verbessert

Kernpunkte:

• http/2 (2015 veröffentlicht) löst das Latenzproblem seines Vorgängers HTTP/1.1 durch Komprimieren von HTTP -Headern, implementieren Server -Pushes und Multiplexing -Anforderungen für eine einzelne Verbindung. Es wurde auch so konzipiert, dass es das Problem der Blockierung des Teams des Teams löst und standardmäßig Verschlüsselung erfordert.
• Der Übergang von HTTP/1.1 zu HTTP/2 ist nicht ohne Herausforderungen, da die Kompatibilität für die Rückwärtsbekämpfung mit vorhandenen Websites erforderlich ist. Jede Verbesserung des Protokolls muss so implementiert werden, dass das Internet nicht unterbricht.
• Alle Mainstream -Browser unterstützen derzeit HTTP/2. Sie müssen jedoch alle HTTP/2 -Anforderungen verschlüsselt werden, was keine Voraussetzung für die HTTP/2 -Spezifikation selbst ist.
• Implementieren von HTTP/2 auf einem Server beinhaltet normalerweise die Aktualisierung der Serversoftware oder der Hosting -Umgebung auf eine Version, die HTTP/2 unterstützt und den Server so konfiguriert, dass die HTTP/2 -Funktionalität aktiviert wird. Es ist zu beachten, dass HTTP/2 ein SSL -Zertifikat benötigt, sodass die Website Dienste über HTTPS bereitstellen muss.

Evolution des HTTP -Protokolls:

Die Infrastruktur des Internets - oder der physischen Netzwerkschicht - ist ein Internetprotokoll (als Teil der TCP/IP- oder Transportschicht). Es ist die Infrastruktur für den größten Teil unserer Internetkommunikation.

oben befindet sich die Anwendungsschicht, und verschiedene Anwendungen verwenden verschiedene Protokolle, um Informationen zu verbinden und zu übertragen. Zum Beispiel haben wir SMTP, POP3 und IMAP zum Senden und Empfangen von E -Mails.

Das berühmteste Protokoll, das auch gleichbedeutend mit dem Internet ist, ist HTTP (Hypertext -Transferprotokoll). Wir nutzen es jeden Tag, um die Website zu besuchen. Es wurde bereits 1989 von Tim Berners Lee in Cern entworfen. Die Spezifikation für Version 1.0 wurde 1996 (RFC 1945) und Version 1.1 1999 veröffentlicht.

HTTP -Spezifikation wird von der World Wide Web Alliance beibehalten und finden Sie unter https://www.w3.org/standards/techs/http.

Die erste Generation von HTTP -Protokollen (Versionen 1.0 und 1.1) dominierte das Internet bis 2015, nachdem HTTP/2 die Branche (Webserver und Browser -Anbieter) angenommen hatte.

Einschränkungen von http/1.1:

http ist ein auf ein staatenloses Protokoll basierend auf einer Anfrage-Wirkungsstruktur, was bedeutet, dass der Client Anfragen an den Server stellt. (Aus diesem Grund verwenden wir Cookies - zum Beispiel, um mehrere Anforderungen in einer Benutzersitzung zu verbinden, um dem angemeldeten Benutzer eine authentifizierte Version der Website bereitzustellen.)

Transfers werden normalerweise vom Client (Browser des Benutzers) initiiert, und der Server reagiert normalerweise nur auf diese Anfragen.

Es kann gesagt werden, dass der aktuelle HTTP-Status ziemlich "ungeschickt" oder eher niedrig ist und viel "Hilfe" für den Browser und Server erfordert, um zu veranschaulichen, wie man effektiv kommuniziert. Es ist nicht einfach, Änderungen in diesem Bereich vorzunehmen, da viele vorhandene Websites mit Rückwärtskompatibilität mit allen eingeführten Änderungen angewiesen sind. Jeder Vorgang zur Verbesserung des Protokolls muss nahtlos durchgeführt werden, ohne das Internet zu unterbrechen.

In vielerlei Hinsicht ist dieses strenge Antrags-Response-, Atomic-, Synchronisationsmodell zu einem Engpass geworden, und der Fortschritt hat in der Form des Hackings, die normalerweise von Branchenführern wie Google und Facebook geleitet werden, in die Form von Hacking erfolgt. Die übliche Situation (die auf verschiedene Weise verbessert wird) ist, wenn Besucher eine Webseite anfordern und wenn ihr Browser sie vom Server empfängt, analysiert sie die HTML und findet andere Ressourcen, die zur Rendite der Seite erforderlich sind, wie z. und JavaScript. Wenn es auf diese Ressourcenlinks stößt, wird das Laden aller anderen Inhalte eingestellt und die angegebene Ressource vom Server angefordert. Es wird sich erst bewegt, wenn es empfangen wird. Anschließend fordert es eine weitere Ressource und so weiter.

Die Anzahl der Anforderungen, die zum Laden der weltweit besten Websites erforderlich sind, beträgt normalerweise Hunderte.

Dies beinhaltet eine Menge Wartezeit sowie eine Menge Hin- und Rückfahrt, während der Besucher nur weiße Bildschirm oder halbgerenderte Websites sehen können. Dies sind alles ein paar Sekunden verschwendet. Während dieser Antragszyklen ist eine große Menge an verfügbarer Bandbreite einfach untätig und ungenutzt.

cDN kann viele dieser Probleme lindern, sind aber auch nur eine vorübergehende Lösung.

Wie Daniel Stenberg von Mozilla (einer der an der HTTP/2 -Standardisierung beteiligten Personen) betonte, hat die erste Version des Protokolls Schwierigkeiten, die Kapazität der zugrunde liegenden Transportschicht TCP voll auszunutzen. Benutzer, die daran gearbeitet haben, die Ladegeschwindigkeiten der Website zu optimieren, wissen, dass dies normalerweise eine gewisse Kreativität erfordert, um es euphemistisch auszudrücken.

im Laufe der Zeit hat die Internetbandbreitengeschwindigkeit erheblich zugenommen, aber die Infrastruktur in der HTTP/1.1 -ERA hat dies nicht voll ausgenutzt. Es hat immer noch Schwierigkeiten, Probleme wie HTTP -Pipelines zu behandeln, die mehr Ressourcen über dieselbe TCP -Verbindung übernehmen - und so weiter. Clients im Browser unterstützen die meisten Drags, Firefox und Chrome deaktivieren ihn standardmäßig, oder es wird überhaupt nicht unterstützt, wie z. B. IE, Firefox 54 -Versionen usw. Dies bedeutet, dass selbst eine kleine Ressource eine neue TCP -Verbindung und das folgende Aufblähern öffnen muss - TCP -Handshake, DNS -Lookup, Verzögerung ... Aufgrund des Blockierens des Teams wird das Laden einer Ressource alles blockieren Laden anderer Ressourcen.

synchronisiert den Vergleich von Nichtpipeline-Verbindungen mit Pipeline-Verbindungen und zeigt mögliche Ladezeiteinsparungen an.

Unter dem HTTP/1 -Modell müssen einige Optimierungstechniken, mit denen Webentwickler ihre Websites optimieren müssen, Bildassistenten, CSS und JavaScript -Verbindungen, Sharding (verteilt die Ressourcenanfragen des Besuchers an mehrere Domänen oder Subdomains) usw.

Verbesserung ist erforderlich. Es muss diese Probleme auf nahtlose, rückwärtskompatible Weise behandelt, um zu vermeiden, dass die Arbeit an vorhandenen Netze unterbrochen wird.

spdy und http/2:

im Jahr 2009 kündigte Google ein Projekt an, das ein Entwurf für den Protokoll der nächsten Generation (ausgesprochen schnelles ), um Chrome zu unterstützen und es in den nächsten Jahren aufzunehmen Dienstleistungen. Anschließend bieten Twitter- und Serverhersteller wie Apache und Nginx auch Support, Node.js sowie später Facebook, WordPress.com und die meisten CDN -Anbieter.

SPDY führt Multiplexing ein und beendete mehrere Ressourcen parallel über eine einzelne TCP -Verbindung. Die Verbindung wird standardmäßig verschlüsselt und die Daten werden komprimiert. Erstens zeigten vorläufige Tests der ersten 25 Websites im SPDY -Whitepapier, dass die Geschwindigkeit um mehr als 27% auf mehr als 60% stieg.

Nachdem SPDY Version 3 seine Effektivität in einer Produktionsumgebung nachgewiesen hatte, wurde er zur Grundlage für den ersten Entwurf von HTTP/2, der von HTTPBIS, der Arbeitsgruppe für Hypertext -Transferprotokolle im Jahr 2015, entwickelt wurde.

http/2 soll das Verzögerungsproblem beheben, das die erste Version des Protokolls plagt, um:

• HTTP -Header
komprimieren
• implementieren Server Push
• Multiplexing -Anforderung für eine einzelne Verbindung

Es wurde auch entwickelt, um das Problem der Frontalblockierung zu lösen. Die Daten, die sie im binären Format übertragen, verbessert die Effizienz und erfordert standardmäßig Verschlüsselung (oder zumindest ist dies eine Anforderung, die von Mainstream -Browsern auferlegt wird).

Kopfkomprimierung wird mit dem HPack -Algorithmus durchgeführt, der Schwachstellen in SPDY auflöst und die Größe der Webanforderungen in zwei Hälften verringert.

Server Push ist eine der Funktionen, mit denen die Wartezeit verschwendet werden soll und Ressourcen für den Server des Browsers bereitstellen, bevor der Browser anfordert. Dies verkürzt die Rundreisezeit, was ein großer Engpass bei der Website -Optimierung ist.

Aufgrund all dieser Verbesserungen kann der Ladezeitunterschied von HTTP/2 auf der Beispielseite von ImageKit.io angezeigt werden.

Je mehr Einsparungen in der Ladezeit sind, desto offensichtlicher sind die Website -Ressourcen.

So sehen Sie, ob eine Website Ressourcen über http/2 bereitstellt:

In Mainstream-Browsern wie Firefox oder Chrome können wir die Unterstützung der Website für das HTTP/2-Protokoll im Inspektor-Tool überprüfen, indem wir die Registerkarte "Netzwerk" öffnen und mit der rechten Maustaste auf den Streifen über der Ressourcenliste klicken. Hier können wir das "Protokoll" -Punkt aktivieren.

Server -Seiten -Implementierung:

Nach diesem Schreiben unterstützen alle Mainstream -Browser HTTP/2, obwohl alle HTTP/2 -Anforderungen erforderlich sind und die HTTP/2 -Spezifikation selbst keine Verschlüsselung erfordert.

Server

Apache 2.4 unterstützt es durch sein Modul mod_http2, das jetzt zur Produktion bereit sein sollte. Apache muss es erstellen, indem der Parameter-Enable-Http2 zum Befehl ./Configure hinzugefügt wird. Wir müssen auch sicherstellen, dass mindestens Version 1.2.1 der Bibliothek libnghttp2 installiert ist. Wenn das System Schwierigkeiten hat, es zu finden, können wir einen Weg zu ./Configure bieten, indem wir-with-nghttp2 = hinzufügen.

Der nächste Schritt besteht darin, das Modul zu laden, indem die Anweisung zur Konfiguration von Apache hinzugefügt wird:

<code>LoadModule http2_module modules/mod_http2.so</code>

Dann fügen wir Protokollen H2 H2C HTTP/1.1 zu unserem virtuellen Host -Block hinzu und laden Sie den Server neu. Die Dokumentation von Apache warnt uns vor Vorsichtsmaßnahmen, wenn sie HTTP/2:

aktivieren

Aktivieren von HTTP/2 auf Ihrem Apache -Server wirkt sich auf den Ressourcenverbrauch aus. Wenn Sie über eine geschäftige Website verfügen, möchten Sie möglicherweise die Auswirkungen sorgfältig prüfen.

Wenn HTTP/2 aktiviert ist, ist das erste, was zu beachten ist, dass Ihr Serverprozess zusätzliche Threads startet. Der Grund dafür ist, dass HTTP/2 alle Anfragen für die Bearbeitung an einen eigenen Worker -Thread erhält, die Ergebnisse sammelt und an den Kunden streamen.

Sie können hier mehr über die Apache -Konfiguration lesen.

nginx hat http/2 unterstützt, da Version 1.9.5 dies aktivieren kann, indem wir einfach den Parameter http2 zu unserer virtuellen Host -Spezifikation hinzufügen:

<code>server {
    listen 443 ssl http2 default_server;

    ssl_certificate    server.crt;
    ssl_certificate_key server.key;</code>

Dann laden Sie Nginx neu.

Der Server -Push wurde leider nicht offiziell implementiert, wurde jedoch in die Entwicklungs -Roadmap hinzugefügt und soll nächstes Jahr veröffentlicht werden. Für abenteuerlustige Menschen gibt es ein inoffizielles Nginx -Modul, das den HTTP/2 -Server -Druck unterstützt.

Leenspeed und OpenLiteSpeed ​​haben auch die Unterstützung von HTTP/2.

Eine Notiz vor der Aktivierung von HTTP/2 auf der Serverseite besteht darin, sicherzustellen, dass wir SSL -Unterstützung haben. Dies bedeutet, dass alle oben erwähnten virtuellen Host -Code -Snippets - für Apache und Nginx - die SSL -Version des virtuellen Host -Blocks eingeben und Port 443 anhören. Sobald wir Apache oder Nginx installiert haben und den regulären virtuellen Host konfiguriert haben, sollte das Erhalten des LetSencrypt -SSL -Zertifikats und die Installation auf einer Diga -Linux -Verteilung nur wenige Codezeilen sein. Certbot ist ein Befehlszeilen -Tool, das den gesamten Vorgang automatisiert.

Zusammenfassung:

In diesem Artikel skizziere ich kurz HTTP/2, eine aufstrebende Webprotokollspezifikation der zweiten Generation.

Die vollständige Liste der Implementierungen der neuen Generation von HTTP finden Sie hier.

Für diejenigen, die nicht viel über Technologie wissen, kann die Abkürzung zum Übergang zu diesem neuen Protokoll darin bestehen, CDN einfach im Webstapel zu implementieren, da CDN einer der ersten Anbieter war, die HTTP/2 übernehmen.

http/2 faq:

(Der FAQ -Teil wird hier weggelassen, da es stark mit der vorherigen Ausgabe dupliziert wird)

Das obige ist der detaillierte Inhalt vonHTTP/2: Hintergrund, Leistungsvorteile und Implementierungen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!