Einfach ausgedrückt, ermöglicht Multiplexing Ihrem Browser, mehrere Anforderungen gleichzeitig über dieselbe Verbindung auszulösen und die Anforderungen in beliebiger Reihenfolge zurück zu erhalten.
Und nun zur viel komplizierteren Antwort ...
Wenn Sie eine Webseite laden, wird die HTML-Seite heruntergeladen, es wird CSS, JavaScript, eine Menge Bilder usw. benötigt.
Unter HTTP / 1.1 können Sie jeweils nur eines davon über Ihre HTTP / 1.1-Verbindung herunterladen. Ihr Browser lädt also den HTML-Code herunter und fragt nach der CSS-Datei. Wenn das zurückgegeben wird, fragt es nach der JavaScript-Datei. Wenn das zurückgegeben wird, werden Sie nach der ersten Bilddatei gefragt ... usw. HTTP / 1.1 ist im Grunde genommen synchron - sobald Sie eine Anfrage senden, bleiben Sie stecken, bis Sie eine Antwort erhalten. Dies bedeutet, dass der Browser die meiste Zeit nicht viel tut, da er eine Anfrage ausgelöst hat, auf eine Antwort wartet, dann eine andere Anfrage auslöst und dann auf eine Antwort wartet ... usw. Natürlich komplexe Websites mit Für viel JavaScript muss der Browser viel verarbeiten, dies hängt jedoch vom heruntergeladenen JavaScript ab, sodass die Verzögerungen, die HTTP / 1.1 erbt, zumindest zu Beginn Probleme verursachen. Normalerweise ist der Server nicht
Eines der Hauptprobleme im heutigen Web ist die Netzwerklatenz beim Senden der Anforderungen zwischen Browser und Server. Es kann nur zehn oder vielleicht Hunderte von Millisekunden dauern, was nicht viel zu sein scheint, aber sie summieren sich und sind oft der langsamste Teil des Webbrowsings - insbesondere, wenn Websites komplexer werden und zusätzliche Ressourcen (wie sie werden) und Internetzugang erfordern erfolgt zunehmend über Mobilgeräte (mit langsamerer Latenz als Breitband).
Nehmen wir als Beispiel an, es gibt 10 Ressourcen, die Ihre Webseite laden muss, nachdem der HTML-Code selbst geladen wurde (was nach heutigen Maßstäben eine sehr kleine Site ist, da mehr als 100 Ressourcen üblich sind, aber wir werden es einfach halten und damit fortfahren Beispiel). Nehmen wir an, jede Anforderung benötigt 100 ms, um über das Internet zum Webserver und zurück zu gelangen, und die Verarbeitungszeit an beiden Enden ist vernachlässigbar (der Einfachheit halber für dieses Beispiel 0). Da Sie jede Ressource senden und einzeln auf eine Antwort warten müssen, dauert das Herunterladen der gesamten Site 10 * 100 ms = 1.000 ms oder 1 Sekunde.
Um dies zu umgehen, öffnen Browser normalerweise mehrere Verbindungen zum Webserver (normalerweise 6). Dies bedeutet, dass ein Browser mehrere Anforderungen gleichzeitig auslösen kann, was viel besser ist, jedoch auf Kosten der Komplexität des Einrichtens und Verwaltens mehrerer Verbindungen (was sich sowohl auf den Browser als auch auf den Server auswirkt). Fahren wir mit dem vorherigen Beispiel fort und sagen wir auch, dass es 4 Verbindungen gibt. Nehmen wir zur Vereinfachung an, dass alle Anforderungen gleich sind. In diesem Fall können Sie die Anforderungen auf alle vier Verbindungen aufteilen, sodass zwei über 3 Ressourcen verfügen und zwei über 2 Ressourcen, um die zehn Ressourcen vollständig abzurufen (3 + 3 + 2 + 2 = 10). In diesem Fall beträgt der schlechteste Fall 3 Rundenzeiten oder 300 ms = 0,3 Sekunden - eine gute Verbesserung. In diesem einfachen Beispiel sind jedoch die Kosten für die Einrichtung dieser Mehrfachverbindungen nicht enthalten.
Mit HTTP / 2 können Sie mehrere Anforderungen gleichzeitig sendenVerbindung - Sie müssen also nicht mehrere Verbindungen wie oben beschrieben öffnen. Ihr Browser kann also sagen: "Gib mir diese CSS-Datei. Gib mir die JavaScript-Datei. Gib mir image1.jpg. Gib mir image2.jpg ... usw." um die eine einzige Verbindung voll auszunutzen. Dies hat den offensichtlichen Leistungsvorteil, dass das Senden dieser Anforderungen, die auf eine kostenlose Verbindung warten, nicht verzögert wird. Alle diese Anfragen gelangen (fast) parallel über das Internet zum Server. Der Server antwortet auf jeden einzelnen und beginnt dann den Rückweg. Tatsächlich ist es sogar noch leistungsfähiger, da der Webserver in beliebiger Reihenfolge darauf reagieren und Dateien in unterschiedlicher Reihenfolge zurücksenden oder sogar jede angeforderte Datei in Teile zerlegen und die Dateien miteinander vermischen kann.Problem mit der Blockierung des Leitungsleiters ). Der Webbrowser hat dann die Aufgabe, alle Teile wieder zusammenzusetzen. Im besten Fall (unter der Annahme, dass keine Bandbreitenbeschränkungen vorliegen - siehe unten), wenn alle 10 Anforderungen ziemlich gleichzeitig parallel ausgelöst und vom Server sofort beantwortet werden, bedeutet dies, dass Sie im Grunde eine Hin- und Rückfahrt oder 100 ms oder 0,1 Sekunden haben Laden Sie alle 10 Ressourcen herunter. Und dies hat keinen der Nachteile, die mehrere Verbindungen für HTTP / 1.1 hatten! Dies ist auch viel skalierbarer, wenn die Ressourcen auf jeder Website zunehmen (derzeit öffnen Browser unter HTTP / 1.1 bis zu 6 parallele Verbindungen. Sollte dies jedoch zunehmen, wenn Websites komplexer werden?).
Hinweis: HTTP / 1.1 verfügt über das Konzept des Pipelining, mit dem auch mehrere Anforderungen gleichzeitig gesendet werden können. Sie mussten jedoch noch zurückgegeben werden, damit sie in ihrer Gesamtheit angefordert wurden, also bei weitem nicht so gut wie HTTP / 2, auch wenn es konzeptionell ähnlich ist. Ganz zu schweigen von der Tatsache, dass dies sowohl von Browsern als auch von Servern so schlecht unterstützt wird, dass es selten verwendet wird.
In den folgenden Kommentaren wird hervorgehoben, wie sich die Bandbreite hier auf uns auswirkt. Natürlich ist Ihre Internetverbindung dadurch begrenzt, wie viel Sie herunterladen können, und HTTP / 2 behebt dies nicht. Wenn es sich bei diesen 10 in den obigen Beispielen beschriebenen Ressourcen um massive Bilder in Druckqualität handelt, können sie nur langsam heruntergeladen werden. Für die meisten Webbrowser ist die Bandbreite jedoch weniger ein Problem als die Latenz. Wenn es sich bei diesen zehn Ressourcen also um kleine Elemente handelt (insbesondere um Textressourcen wie CSS und JavaScript, die als winzig eingestuft werden können), wie dies auf Websites sehr häufig vorkommt, ist die Bandbreite kein wirkliches Problem - es ist häufig das schiere Ressourcenvolumen, das häufig auftritt Problem und HTTP / 2 versucht, das zu beheben. Aus diesem Grund wird die Verkettung in HTTP / 1.1 als weitere Problemumgehung verwendet, sodass beispielsweise häufig alle CSS-Dateien zu einer Datei zusammengefasst werden:Anti-Pattern unter HTTP / 2 - obwohl es Argumente dafür gibt, es auch komplett abzuschaffen).
Um es als Beispiel aus der Praxis zu nennen: Angenommen, Sie müssen 10 Artikel in einem Geschäft bestellen, um nach Hause geliefert zu werden:
HTTP / 1.1 mit einer Verbindung bedeutet, dass Sie sie einzeln bestellen müssen und den nächsten Artikel erst bestellen können, wenn der letzte eintrifft. Sie können verstehen, dass es Wochen dauern würde, um alles durchzuhalten.
HTTP / 1.1 mit mehreren Verbindungen bedeutet, dass Sie eine (begrenzte) Anzahl unabhängiger Bestellungen gleichzeitig ausführen können.
HTTP / 1.1 mit Pipelining bedeutet, dass Sie alle 10 Artikel nacheinander anfordern können, ohne zu warten, aber dann kommen sie alle in der von Ihnen gewünschten Reihenfolge an. Und wenn ein Artikel nicht vorrätig ist, müssen Sie darauf warten, bevor Sie die Artikel erhalten, die Sie danach bestellt haben - auch wenn diese späteren Artikel tatsächlich auf Lager sind! Dies ist etwas besser, unterliegt jedoch immer noch Verzögerungen. Nehmen wir an, die meisten Geschäfte unterstützen diese Art der Bestellung ohnehin nicht.
HTTP / 2 bedeutet, dass Sie Ihre Artikel in einer bestimmten Reihenfolge bestellen können - ohne Verzögerungen (ähnlich wie oben). Der Shop versendet sie, sobald sie fertig sind, sodass sie möglicherweise in einer anderen Reihenfolge ankommen, als Sie es gewünscht haben, und sie können sogar Artikel aufteilen, sodass einige Teile dieser Bestellung zuerst eintreffen (also besser als oben). Letztendlich sollte dies bedeuten, dass Sie 1) alles insgesamt schneller bekommen und 2) mit der Arbeit an jedem Artikel beginnen können, sobald er eintrifft ("Oh, das ist nicht so schön, wie ich es mir vorgestellt habe, also möchte ich vielleicht auch etwas anderes bestellen oder stattdessen"). ).
Natürlich sind Sie immer noch durch die Größe Ihres Postboten (die Bandbreite) begrenzt, sodass diese möglicherweise einige Pakete bis zum nächsten Tag im Sortierbüro zurücklassen müssen, wenn sie für diesen Tag voll sind, aber das ist im Vergleich selten ein Problem auf die Verzögerung beim tatsächlichen Senden der Bestellung hin und her. Beim Surfen im Internet werden meistens kleine Briefe hin und her gesendet, anstatt sperrige Pakete.
Tolle Erklärung. Beispiel ist, was ich brauchte, um dies zu bekommen. In HTTP / 1.1 wird also Zeit zwischen dem Warten auf die Antwort und dem Versenden der nächsten Anforderung verschwendet. HTTP / 2 behebt dies. Danke dir.
user3448600
1
Aber hart denke ich. Hätte mich einfach bitten können, einen Beitrag zur Bandbreite hinzuzufügen - was ich gerne mache und tun werde, nachdem wir diese Diskussion beendet haben. IMHO Bandbreite ist jedoch kein so großes Problem für das Surfen im Internet (zumindest in der westlichen Welt) - Latenz ist. Und HTTP / 2 verbessert die Latenz. Die meisten Websites bestehen aus vielen kleinen Ressourcen, und selbst wenn Sie über die Bandbreite verfügen, um sie herunterzuladen (wie dies häufig der Fall ist), ist dies aufgrund der Netzwerklatenz langsam. Die Bandbreite wird für große Ressourcen zu einem größeren Problem. Ich bin damit einverstanden, dass diese Websites mit massiven Bildern und anderen Ressourcen möglicherweise noch eine Bandbreitenbeschränkung erreichen.
Barry Pollard
1
HTTP sollte nicht zur Durchsetzung der Bestellung verwendet werden, da es keine solchen Garantien bietet. Mit HTTP / 2 können Sie eine Priorität für die Lieferung vorschlagen, jedoch keine Bestellung. Auch wenn eines Ihrer JavaScript-Assets zwischengespeichert ist, das andere jedoch nicht, kann HTTP nicht einmal die Priorität beeinflussen. Verwenden Sie stattdessen die Reihenfolge im HTML- Code in Verbindung mit der entsprechenden Verwendung von Async oder Defer ( Wachstum mit theweb.com/2014/02/async-vs-defer-attributes.html ) oder eine Bibliothek wie require.js.
Barry Pollard
1
Tolle Erklärung. Vielen Dank!
Hmacias
2
Dies liegt daran, dass HTTP / 1.1 ein Textstrom ist und HTTP / 2 paketbasiert ist. Nun, sie werden in HTTP / 2 eher als Frames als als Pakete bezeichnet. In HTTP / 2 kann also jeder Frame einem Stream zugeordnet werden, der das Verschachteln der Frames ermöglicht. In HTTP / 1.1 gibt es kein solches Konzept, da es sich nur um eine Reihe von Textzeilen für den Header und dann für den Body handelt. Weitere Details hier: stackoverflow.com/questions/58498116/…
Barry Pollard
5
Multiplexing anfordern
HTTP / 2 kann mehrere Datenanforderungen parallel über eine einzige TCP-Verbindung senden. Dies ist die fortschrittlichste Funktion des HTTP / 2-Protokolls, da Sie damit Webdateien asynchron von einem Server herunterladen können. Die meisten modernen Browser beschränken TCP-Verbindungen auf einen Server. Dies reduziert die zusätzliche Roundtrip-Zeit (RTT), beschleunigt das Laden Ihrer Website ohne Optimierung und macht Domain-Sharding unnötig.
Multiplexing bedeutet, dass Ihr Browser mehrere Anforderungen senden und mehrere Antworten "gebündelt" in einer einzigen TCP-Verbindung empfangen kann. Daher wird die mit DNS-Lookups und Handshakes verbundene Arbeitslast für Dateien gespeichert, die vom selben Server stammen.
Dies kann durch Pipelining auch in http 1.1 erreicht werden. Der Hauptzweck des Multiplexens in HTTP2 besteht darin, nicht in geordneter Weise auf die Antworten zu warten
Dhairya Lakhera,
3
Multiplexing in HTTP 2.0 ist die Art der Beziehung zwischen dem Browser und dem Server, die über eine einzige Verbindung mehrere Anforderungen und Antworten parallel übermittelt und dabei viele einzelne Frames erstellt.
Multiplexing löst sich von der strengen Anforderungs-Antwort-Semantik und ermöglicht Eins-zu-Viele- oder Viele-zu-Viele-Beziehungen.
Ihr HTTP / 2-Multiplexing-Beispiel zeigt nicht wirklich Multiplexing. Das Szenario in Ihrem Diagramm zeigt das in HTTP / 1.1 eingeführte HTTP-Pipelining.
ich5003
@ ich5003 Es ist Multiplexing, weil es eine einzige Verbindung verwendet. Es ist aber auch wahr, dass die Fälle des Sendens mehrerer Antworten pro nur einer Anfrage dort nicht dargestellt sind.
Juanma Menendez
1
Was ich versuche zu sagen, dass das oben gezeigte Szenario auch nur mit HTTP-Pipelining erreichbar ist.
ich5003
Ich glaube, die Quelle der Verwirrung ist hier die Reihenfolge der Anforderung / Antwort im Diagramm rechts - sie zeigen einen speziellen Fall des Multiplexens in HTTP / 2, der auch durch Pipelining in HTTP / 1.1 erreicht werden kann. Sollte sich die Antwortreihenfolge im Diagramm von der Anforderungsreihenfolge unterscheiden, würde keine Verwirrung entstehen.
Raiks
1
Da die Antwort von @Juanma Menendez korrekt ist, während sein Diagramm verwirrend ist, habe ich beschlossen, sie zu verbessern und den Unterschied zwischen Multiplexing und Pipelining zu verdeutlichen, die häufig miteinander verschmolzen sind.
Pipelining (HTTP / 1.1)
Über dieselbe HTTP-Verbindung werden mehrere Anforderungen gesendet . Die Antworten gehen in derselben Reihenfolge ein. Wenn die erste Antwort viel Zeit in Anspruch nimmt, müssen andere Antworten in der Schlange stehen. Ähnlich wie beim CPU-Pipeling, bei dem ein Befehl abgerufen wird, während ein anderer dekodiert wird. Es sind mehrere Anweisungen gleichzeitig im Flug, aber ihre Reihenfolge bleibt erhalten.
Multiplexing (HTTP / 2)
Über dieselbe HTTP-Verbindung werden mehrere Anforderungen gesendet . Die Antworten gehen in beliebiger Reihenfolge ein. Sie müssen nicht auf eine langsame Antwort warten, die andere blockiert. Ähnlich wie bei der Ausführung von Befehlen außerhalb der Reihenfolge in modernen CPUs.
Hoffentlich verdeutlicht das verbesserte Bild den Unterschied:
Antworten:
Einfach ausgedrückt, ermöglicht Multiplexing Ihrem Browser, mehrere Anforderungen gleichzeitig über dieselbe Verbindung auszulösen und die Anforderungen in beliebiger Reihenfolge zurück zu erhalten.
Und nun zur viel komplizierteren Antwort ...
Wenn Sie eine Webseite laden, wird die HTML-Seite heruntergeladen, es wird CSS, JavaScript, eine Menge Bilder usw. benötigt.
Unter HTTP / 1.1 können Sie jeweils nur eines davon über Ihre HTTP / 1.1-Verbindung herunterladen. Ihr Browser lädt also den HTML-Code herunter und fragt nach der CSS-Datei. Wenn das zurückgegeben wird, fragt es nach der JavaScript-Datei. Wenn das zurückgegeben wird, werden Sie nach der ersten Bilddatei gefragt ... usw. HTTP / 1.1 ist im Grunde genommen synchron - sobald Sie eine Anfrage senden, bleiben Sie stecken, bis Sie eine Antwort erhalten. Dies bedeutet, dass der Browser die meiste Zeit nicht viel tut, da er eine Anfrage ausgelöst hat, auf eine Antwort wartet, dann eine andere Anfrage auslöst und dann auf eine Antwort wartet ... usw. Natürlich komplexe Websites mit Für viel JavaScript muss der Browser viel verarbeiten, dies hängt jedoch vom heruntergeladenen JavaScript ab, sodass die Verzögerungen, die HTTP / 1.1 erbt, zumindest zu Beginn Probleme verursachen. Normalerweise ist der Server nicht
Eines der Hauptprobleme im heutigen Web ist die Netzwerklatenz beim Senden der Anforderungen zwischen Browser und Server. Es kann nur zehn oder vielleicht Hunderte von Millisekunden dauern, was nicht viel zu sein scheint, aber sie summieren sich und sind oft der langsamste Teil des Webbrowsings - insbesondere, wenn Websites komplexer werden und zusätzliche Ressourcen (wie sie werden) und Internetzugang erfordern erfolgt zunehmend über Mobilgeräte (mit langsamerer Latenz als Breitband).
Nehmen wir als Beispiel an, es gibt 10 Ressourcen, die Ihre Webseite laden muss, nachdem der HTML-Code selbst geladen wurde (was nach heutigen Maßstäben eine sehr kleine Site ist, da mehr als 100 Ressourcen üblich sind, aber wir werden es einfach halten und damit fortfahren Beispiel). Nehmen wir an, jede Anforderung benötigt 100 ms, um über das Internet zum Webserver und zurück zu gelangen, und die Verarbeitungszeit an beiden Enden ist vernachlässigbar (der Einfachheit halber für dieses Beispiel 0). Da Sie jede Ressource senden und einzeln auf eine Antwort warten müssen, dauert das Herunterladen der gesamten Site 10 * 100 ms = 1.000 ms oder 1 Sekunde.
Um dies zu umgehen, öffnen Browser normalerweise mehrere Verbindungen zum Webserver (normalerweise 6). Dies bedeutet, dass ein Browser mehrere Anforderungen gleichzeitig auslösen kann, was viel besser ist, jedoch auf Kosten der Komplexität des Einrichtens und Verwaltens mehrerer Verbindungen (was sich sowohl auf den Browser als auch auf den Server auswirkt). Fahren wir mit dem vorherigen Beispiel fort und sagen wir auch, dass es 4 Verbindungen gibt. Nehmen wir zur Vereinfachung an, dass alle Anforderungen gleich sind. In diesem Fall können Sie die Anforderungen auf alle vier Verbindungen aufteilen, sodass zwei über 3 Ressourcen verfügen und zwei über 2 Ressourcen, um die zehn Ressourcen vollständig abzurufen (3 + 3 + 2 + 2 = 10). In diesem Fall beträgt der schlechteste Fall 3 Rundenzeiten oder 300 ms = 0,3 Sekunden - eine gute Verbesserung. In diesem einfachen Beispiel sind jedoch die Kosten für die Einrichtung dieser Mehrfachverbindungen nicht enthalten.
Mit HTTP / 2 können Sie mehrere Anforderungen gleichzeitig sendenVerbindung - Sie müssen also nicht mehrere Verbindungen wie oben beschrieben öffnen. Ihr Browser kann also sagen: "Gib mir diese CSS-Datei. Gib mir die JavaScript-Datei. Gib mir image1.jpg. Gib mir image2.jpg ... usw." um die eine einzige Verbindung voll auszunutzen. Dies hat den offensichtlichen Leistungsvorteil, dass das Senden dieser Anforderungen, die auf eine kostenlose Verbindung warten, nicht verzögert wird. Alle diese Anfragen gelangen (fast) parallel über das Internet zum Server. Der Server antwortet auf jeden einzelnen und beginnt dann den Rückweg. Tatsächlich ist es sogar noch leistungsfähiger, da der Webserver in beliebiger Reihenfolge darauf reagieren und Dateien in unterschiedlicher Reihenfolge zurücksenden oder sogar jede angeforderte Datei in Teile zerlegen und die Dateien miteinander vermischen kann.Problem mit der Blockierung des Leitungsleiters ). Der Webbrowser hat dann die Aufgabe, alle Teile wieder zusammenzusetzen. Im besten Fall (unter der Annahme, dass keine Bandbreitenbeschränkungen vorliegen - siehe unten), wenn alle 10 Anforderungen ziemlich gleichzeitig parallel ausgelöst und vom Server sofort beantwortet werden, bedeutet dies, dass Sie im Grunde eine Hin- und Rückfahrt oder 100 ms oder 0,1 Sekunden haben Laden Sie alle 10 Ressourcen herunter. Und dies hat keinen der Nachteile, die mehrere Verbindungen für HTTP / 1.1 hatten! Dies ist auch viel skalierbarer, wenn die Ressourcen auf jeder Website zunehmen (derzeit öffnen Browser unter HTTP / 1.1 bis zu 6 parallele Verbindungen. Sollte dies jedoch zunehmen, wenn Websites komplexer werden?).
Dieses Diagramm zeigt die Unterschiede, und es gibt auch eine animierte Version .
Hinweis: HTTP / 1.1 verfügt über das Konzept des Pipelining, mit dem auch mehrere Anforderungen gleichzeitig gesendet werden können. Sie mussten jedoch noch zurückgegeben werden, damit sie in ihrer Gesamtheit angefordert wurden, also bei weitem nicht so gut wie HTTP / 2, auch wenn es konzeptionell ähnlich ist. Ganz zu schweigen von der Tatsache, dass dies sowohl von Browsern als auch von Servern so schlecht unterstützt wird, dass es selten verwendet wird.
In den folgenden Kommentaren wird hervorgehoben, wie sich die Bandbreite hier auf uns auswirkt. Natürlich ist Ihre Internetverbindung dadurch begrenzt, wie viel Sie herunterladen können, und HTTP / 2 behebt dies nicht. Wenn es sich bei diesen 10 in den obigen Beispielen beschriebenen Ressourcen um massive Bilder in Druckqualität handelt, können sie nur langsam heruntergeladen werden. Für die meisten Webbrowser ist die Bandbreite jedoch weniger ein Problem als die Latenz. Wenn es sich bei diesen zehn Ressourcen also um kleine Elemente handelt (insbesondere um Textressourcen wie CSS und JavaScript, die als winzig eingestuft werden können), wie dies auf Websites sehr häufig vorkommt, ist die Bandbreite kein wirkliches Problem - es ist häufig das schiere Ressourcenvolumen, das häufig auftritt Problem und HTTP / 2 versucht, das zu beheben. Aus diesem Grund wird die Verkettung in HTTP / 1.1 als weitere Problemumgehung verwendet, sodass beispielsweise häufig alle CSS-Dateien zu einer Datei zusammengefasst werden:Anti-Pattern unter HTTP / 2 - obwohl es Argumente dafür gibt, es auch komplett abzuschaffen).
Um es als Beispiel aus der Praxis zu nennen: Angenommen, Sie müssen 10 Artikel in einem Geschäft bestellen, um nach Hause geliefert zu werden:
HTTP / 1.1 mit einer Verbindung bedeutet, dass Sie sie einzeln bestellen müssen und den nächsten Artikel erst bestellen können, wenn der letzte eintrifft. Sie können verstehen, dass es Wochen dauern würde, um alles durchzuhalten.
HTTP / 1.1 mit mehreren Verbindungen bedeutet, dass Sie eine (begrenzte) Anzahl unabhängiger Bestellungen gleichzeitig ausführen können.
HTTP / 1.1 mit Pipelining bedeutet, dass Sie alle 10 Artikel nacheinander anfordern können, ohne zu warten, aber dann kommen sie alle in der von Ihnen gewünschten Reihenfolge an. Und wenn ein Artikel nicht vorrätig ist, müssen Sie darauf warten, bevor Sie die Artikel erhalten, die Sie danach bestellt haben - auch wenn diese späteren Artikel tatsächlich auf Lager sind! Dies ist etwas besser, unterliegt jedoch immer noch Verzögerungen. Nehmen wir an, die meisten Geschäfte unterstützen diese Art der Bestellung ohnehin nicht.
HTTP / 2 bedeutet, dass Sie Ihre Artikel in einer bestimmten Reihenfolge bestellen können - ohne Verzögerungen (ähnlich wie oben). Der Shop versendet sie, sobald sie fertig sind, sodass sie möglicherweise in einer anderen Reihenfolge ankommen, als Sie es gewünscht haben, und sie können sogar Artikel aufteilen, sodass einige Teile dieser Bestellung zuerst eintreffen (also besser als oben). Letztendlich sollte dies bedeuten, dass Sie 1) alles insgesamt schneller bekommen und 2) mit der Arbeit an jedem Artikel beginnen können, sobald er eintrifft ("Oh, das ist nicht so schön, wie ich es mir vorgestellt habe, also möchte ich vielleicht auch etwas anderes bestellen oder stattdessen"). ).
Natürlich sind Sie immer noch durch die Größe Ihres Postboten (die Bandbreite) begrenzt, sodass diese möglicherweise einige Pakete bis zum nächsten Tag im Sortierbüro zurücklassen müssen, wenn sie für diesen Tag voll sind, aber das ist im Vergleich selten ein Problem auf die Verzögerung beim tatsächlichen Senden der Bestellung hin und her. Beim Surfen im Internet werden meistens kleine Briefe hin und her gesendet, anstatt sperrige Pakete.
Hoffentlich hilft das.
quelle
Multiplexing anfordern
HTTP / 2 kann mehrere Datenanforderungen parallel über eine einzige TCP-Verbindung senden. Dies ist die fortschrittlichste Funktion des HTTP / 2-Protokolls, da Sie damit Webdateien asynchron von einem Server herunterladen können. Die meisten modernen Browser beschränken TCP-Verbindungen auf einen Server. Dies reduziert die zusätzliche Roundtrip-Zeit (RTT), beschleunigt das Laden Ihrer Website ohne Optimierung und macht Domain-Sharding unnötig.
quelle
Einfache Antwort ( Quelle ):
Multiplexing bedeutet, dass Ihr Browser mehrere Anforderungen senden und mehrere Antworten "gebündelt" in einer einzigen TCP-Verbindung empfangen kann. Daher wird die mit DNS-Lookups und Handshakes verbundene Arbeitslast für Dateien gespeichert, die vom selben Server stammen.
Komplexe / detaillierte Ans:
Schauen Sie sich die Antwort von @BazzaDP an.
quelle
Multiplexing in HTTP 2.0 ist die Art der Beziehung zwischen dem Browser und dem Server, die über eine einzige Verbindung mehrere Anforderungen und Antworten parallel übermittelt und dabei viele einzelne Frames erstellt.
Multiplexing löst sich von der strengen Anforderungs-Antwort-Semantik und ermöglicht Eins-zu-Viele- oder Viele-zu-Viele-Beziehungen.
quelle
Da die Antwort von @Juanma Menendez korrekt ist, während sein Diagramm verwirrend ist, habe ich beschlossen, sie zu verbessern und den Unterschied zwischen Multiplexing und Pipelining zu verdeutlichen, die häufig miteinander verschmolzen sind.
Pipelining (HTTP / 1.1)
Über dieselbe HTTP-Verbindung werden mehrere Anforderungen gesendet . Die Antworten gehen in derselben Reihenfolge ein. Wenn die erste Antwort viel Zeit in Anspruch nimmt, müssen andere Antworten in der Schlange stehen. Ähnlich wie beim CPU-Pipeling, bei dem ein Befehl abgerufen wird, während ein anderer dekodiert wird. Es sind mehrere Anweisungen gleichzeitig im Flug, aber ihre Reihenfolge bleibt erhalten.
Multiplexing (HTTP / 2)
Über dieselbe HTTP-Verbindung werden mehrere Anforderungen gesendet . Die Antworten gehen in beliebiger Reihenfolge ein. Sie müssen nicht auf eine langsame Antwort warten, die andere blockiert. Ähnlich wie bei der Ausführung von Befehlen außerhalb der Reihenfolge in modernen CPUs.
Hoffentlich verdeutlicht das verbesserte Bild den Unterschied:
quelle