Der Unterschied zwischen http2.0 und http1.1

Was ist HTTP 2.0?

HTTP/2 (Hypertext Transfer Protocol Version 2, ursprünglich HTTP 2.0 genannt) ist die zweite Hauptversion des weltweit verwendeten HTTP-Protokolls Breites Web. HTTP/2 ist das erste Update des HTTP-Protokolls seit der Veröffentlichung von HTTP 1.1 im Jahr 1999. Es basiert hauptsächlich auf dem SPDY-Protokoll (einem TCP-basierten Anwendungsschichtprotokoll, das von Google entwickelt wurde, um Netzwerkverzögerungen zu minimieren, die Netzwerkgeschwindigkeit zu erhöhen und zu optimieren die Netzwerknutzungserfahrung der Benutzer).

Im Vergleich zu HTTP 1.1 sind die Hauptunterschiede:

HTTP/2 verwendet Binärformat anstelle von Textformat

HTTP/2 ist vollständig gemultiplext, nicht geordnet und blockierend – für die Parallelität ist nur eine Verbindung erforderlich

Mithilfe der Header-Komprimierung reduziert HTTP/2 den Overhead

HTTP/2 ermöglicht dem Server Antworten aktiv an den Client-Cache „pushen“

Empfohlener Kurs: PHP-Tutorial.

Warum ist HTTP/2 binär?

Im Vergleich zu Textprotokollen wie HTTP/1.x sind Binärprotokolle effizienter zu analysieren, kompakter „online“ und, was noch wichtiger ist, sie weisen weniger Fehler auf.

Warum erfordert HTTP/2 Multiplexing?

HTTP/1.x hat ein Problem namens Head-of-Line-Blockierung, was bedeutet, dass dies der Fall ist Es ist effizienter, wenn eine Verbindung jeweils nur eine Anfrage sendet, und sie wird langsamer, wenn mehr Anfragen eingehen. HTTP/1.1 hat versucht, dieses Problem mit Pipelining zu lösen, aber der Effekt war nicht ideal (große Datenmengen oder langsame Antworten behindern die dahinter stehenden Anforderungen. Darüber hinaus kann der Server dies aufgrund der Netzwerkmedien (Vermittler) nicht unterstützen Pipeline gut, was die Bereitstellung schwierig macht. Multiplexing kann diese Probleme sehr gut lösen, da es mehrere Nachrichtenanforderungen und -antworten gleichzeitig verarbeiten kann und während des Übertragungsprozesses sogar eine Nachricht mit einer anderen mischen kann. Der Client benötigt also nur eine Verbindung, um eine Seite zu laden.

Warum müssen Nachrichtenkopfzeilen komprimiert werden?

Angenommen, eine Seite hat 80 Ressourcen zum Laden (diese Zahl ist für das heutige Web recht konservativ), und jede Anfrage hat einen 1400-Byte-Nachrichtenkopf (was aufgrund der Existenz von Cookies und Referenzen auch nicht ungewöhnlich ist), und es dauert mindestens 7 bis 8 „online“ hin und her, um diese Nachrichtenkopfzeilen zu erhalten. Darin ist die Reaktionszeit nicht enthalten – das ist nur die Zeit, die benötigt wird, um sie vom Kunden zurückzubekommen. Dies ist alles auf den Slow-Start-Mechanismus von TCP zurückzuführen, der anhand der Anzahl bekannter Pakete bestimmt, welche Pakete hin- und hergeholt werden sollen – was offensichtlich die Anzahl der Pakete begrenzt, die in den ersten paar Roundtrips gesendet werden können. Im Gegensatz dazu kann selbst eine leichte Komprimierung der Header die Verarbeitung dieser Anfragen in nur einem Roundtrip – manchmal sogar in einem Paket – ermöglichen. Dieser Overhead kann eingespart werden, insbesondere wenn man mobile Clientanwendungen berücksichtigt, bei denen selbst unter guten Bedingungen typischerweise Roundtrip-Latenzen von mehreren hundert Millisekunden auftreten.

Was sind die Vorteile von Server Push?

Wenn der Browser eine Webseite anfordert, sendet der Server HTML zurück. Der Server muss warten, bis der Browser den HTML-Code analysiert und den gesamten Inline-Inhalt sendet, bevor der Server mit dem Senden von JavaScript beginnt , Bilder und CSS-Ressourcenanfragen. Der Server-Push-Dienst vermeidet Roundtrip-Verzögerungen, indem er Inhalte, von denen er glaubt, dass sie der Client benötigt, in den Cache des Clients „pusht“.

Das obige ist der detaillierte Inhalt vonDer Unterschied zwischen http2.0 und http1.1. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!