Was sind die Unterschiede zwischen http1.x, http2.0 und http3.0?

Erfahren Sie mehr über die Unterschiede zwischen den verschiedenen Versionen von http

Was ist das http-Protokoll? Warum ist es in http1.x, http2.0,http3.0Was sind die Unterschiede zwischen diesen drei? Im Folgenden finden Sie eine detaillierte Einführung in die Unterschiede zwischen den einzelnen Versionen des HTTP-Protokolls, damit Sie das HTTP-Protokoll besser verstehen können.

Was ist HTTP?

Hypertext Transfer ProtocolHyperText Transfer Protocol (HTTP) ist das am weitesten verbreitete Netzwerkprotokoll im Internet. Der ursprüngliche Zweck von HTTP bestand darin, eine Methode zum Veröffentlichen und Empfangen von HTML-Seiten bereitzustellen. Über HTTP oder HTTPS angeforderte Ressourcen werden durch Uniform Resource Identifiers (URIs) identifiziert.

HTTP ist ein Protokoll der Anwendungsschicht, das aus Anfragen und Antworten besteht und ein standardmäßiges Client-Server-Modell darstellt. HTTP ist ein verbindungs- und zustandsloses Protokoll, das auf TCP/IP basiert (jede HTTP-Nachricht ist unabhängig vom Status der vorherigen Nachricht). HTTP setzt voraus, dass sein unteres Protokoll eine zuverlässige Übertragung gewährleistet. Daher verwendet es TCP als Transportschicht in der TCP/IP-Protokollsuite.

Die Hauptmerkmale des HTTP-Protokolls lassen sich wie folgt zusammenfassen:

Einfach: Wenn ein Client einen Dienst von einem Server anfordert, muss er lediglich die Anforderungsmethode und den Pfad senden. Gängige Anforderungsmethoden sind GET, HEAD und POST. Jede Methode spezifiziert eine andere Art der Kommunikation zwischen Client und Server.
Flexibel: HTTP ermöglicht die Übertragung beliebiger Datenobjekttypen. Der übertragene Typ wird durch den Content-Type gekennzeichnet.
Anforderungs-Antwort-Modus: Jedes Mal, wenn der Client eine Anforderung an den Server sendet, wird eine Verbindung hergestellt und der Server trennt die Verbindung, nachdem er die Anforderung des Clients verarbeitet hat.
Zustandslos: HTTP ist ein zustandsloses Protokoll. Zustandslos bedeutet, dass das Protokoll keinen Speicher für die Transaktionsverarbeitung hat. Der fehlende Zustand bedeutet, dass, wenn die nachfolgende Verarbeitung vorherige Informationen benötigt, diese erneut übertragen werden müssen.

HTTP-Arbeitsprozess

HTTP besteht aus Anfragen und Antworten und ist ein Standard-Client-Server-Modell (B/S). Das HTTP-Protokoll beginnt immer damit, dass der Client die Anfrage initiiert und der Server die Antwort zurücksendet.

1. Der Client (Browser) sendet aktiv eine Verbindungsanforderung an den Server (Webserver) (für diesen Schritt ist möglicherweise das DNS-Auflösungsprotokoll erforderlich, um die IP-Adresse des Servers zu erhalten).

2. Der Server akzeptiert die Verbindungsanforderung und stellt eine Verbindung her. (Schritt 1 und 2 sind der uns bekannte TCP-Drei-Wege-Handshake.)

3. Über diese Verbindung sendet der Client HTTP-Befehle wie GET an den Server („HTTP-Anforderungsnachricht“).

4. Der Server empfängt den Befehl und überträgt die entsprechenden Daten gemäß dem Befehl an den Client („HTTP-Antwortnachricht“).

5. Der Client empfängt die vom Server gesendeten Daten.

6. Nach dem Senden der Daten schließt der Server die Verbindung aktiv („TCP-Vierwege-Trennung“).

Zusammenfassend lässt sich der Client/Server-Übertragungsprozess in vier grundlegende Schritte unterteilen:

1) Der Browser stellt eine Verbindung zum Server her (TCP-Drei-Wege-Handshake).

2) Der Browser sendet eine HTTP-Anforderungsnachricht an den Server.

3) Der Server antwortet auf die Browseranfrage;

4) Trennen. („TCP-Vierwege-Trennung“)

HTTP1.X-Prinzipien

Im Arbeitsprozess von http1.0 erfordert die http-Datenübertragung drei Handshakes und vier Wellen, was die Verzögerung erhöht

Keep-Alive wurde zu http1.1 hinzugefügt, um die TCP-Verbindung aufrechtzuerhalten und einige Verzögerungen zu reduzieren

Probleme mit HTTP 1.x

Verbindungen können nicht wiederverwendet werden. Daher durchläuft jede Anforderung einen Drei-Wege-Handshake und einen langsamen Start. Der Drei-Wege-Handshake wirkt sich in Szenarien mit hoher Latenz deutlicher aus, während der langsame Start bei einer großen Anzahl kleiner Dateianforderungen größere Auswirkungen hat.
Durch Head-Of-Line Blocking (HOLB) wird die Bandbreite nicht vollständig genutzt und nachfolgende Health-Anfragen werden blockiert.HOLBEs handelt sich um die Blockierung einer Reihe von Paketen, da das erste Paket blockiert ist. Wenn eine Seite viele Ressourcen anfordern muss, sorgt HOLB (Head of Line Blocking) dafür, dass die verbleibenden Ressourcen warten, bis andere Ressourcenanforderungen abgeschlossen sind, bevor bei Erreichen der maximalen Anzahl von Anforderungen neue Anforderungen gestartet werden. Folgende Lösungen für Head of Line Blocking wurden bereits ausprobiert:

HTTP 1.0: Die nächste Anfrage muss gesendet werden, nachdem die vorherige Anfrage zurückgegeben wurde.Anfrage-AntwortWenn eine Anfrage über einen längeren Zeitraum nicht beantwortet wird, werden natürlich alle nachfolgenden Anfragen blockiert.
HTTP 1.1: Versuchen Sie, das Problem durch Pipelining zu lösen. Das bedeutet, dass der Browser mehrere Anfragen gleichzeitig senden kann (gleicher Domänenname, gleiche TCP-Verbindung). Pipelining erfordert jedoch, dass die Antworten der Reihe nach zurückgegeben werden. Wenn die vorherige Anfrage zeitaufwändig ist (z. B. die Verarbeitung eines großen Bildes), wartet der Server, selbst wenn er die nachfolgende Anfrage bereits verarbeitet hat, auf die Verarbeitung der vorherigen Anfrage, bevor er mit der geordneten Rückgabe beginnt. Daher löst Pipelining das HOLB-Problem nur teilweise.
Importieren Sie Sprites, kleine Inline-Bilder usw.

Der Anforderungsheader hat einen hohen Overhead. Der Nachrichtenheader enthält in der Regel viele feste Headerfelder wie „User Agent“, „Cookie“, „Accept“ und „Server“ (siehe unten) mit bis zu Hunderten oder sogar Tausenden von Bytes, der Hauptteil hingegen oft nur einige zehn Bytes. Der umfangreiche Inhalt des Headers erhöht die Übertragungskosten in gewissem Maße.
Sicherheitsfaktoren: Bei der Datenübertragung über HTTP 1.x liegt der gesamte übertragene Inhalt im Klartext vor. Weder Client noch Server können die Identität der Gegenpartei überprüfen, was die Sicherheit der Daten bis zu einem gewissen Grad nicht garantieren kann.
Server-Push-Nachrichten werden nicht unterstützt, da HTTP/1.x keinen Push-Mechanismus bietet. Daher gibt es in der Regel zwei Möglichkeiten: Polling, bei dem der Client regelmäßig abfragt, und WebSocket.

2.0 So funktioniert es

Im Jahr 2015 wurde HTTP/2 veröffentlicht. HTTP/2 ersetzt das aktuelle HTTP-Protokoll (HTTP/1.x), ist aber keine Neufassung. Die HTTP-Methoden, Statuscodes und Semantik sind dieselben wie bei HTTP/1.x.HTTP/2 basiert auf SPDY und legt den Fokus auf Performance. Eines der wichtigsten Ziele ist die Verwendung von nur einer Verbindung zwischen Benutzer und Website..

Probleme, die HTTP2 löst

Als Reaktion auf die in http1.x vorhandenen Probleme bietet http2 die folgenden Lösungen:

Binäre Übertragung: HTTP/2 verwendet zur Datenübertragung das Binärformat anstelle des Textformats von HTTP 1.x. Das Binärprotokoll ist effizienter zu analysieren. HTTP/1-Anforderungs- und Antwortnachrichten bestehen aus einer Startzeile, einem Header und einem Entity Body (optional). Jeder Teil ist durch einen Zeilenumbruch getrennt. HTTP/2 unterteilt die Anforderungs- und Antwortdaten in kleinere Frames und kodiert diese binär.
Bevor Sie HTTP/2 verstehen, müssen Sie einige allgemeine Begriffe kennen:
1. Stream: Ein bidirektionaler Stream. Eine Verbindung kann mehrere Streams haben.
2. Nachricht: Dies ist die logische Anfrage und Antwort.
3. Frame: Die kleinste Einheit der Datenübertragung. Jeder Frame gehört zu einem bestimmten Stream oder der gesamten Verbindung. Eine Nachricht kann aus mehreren Frames bestehen. Frame ist die kleinste Einheit der Datenübertragung in HTTP/2. Ein Frame ist wie folgt definiert:
  Länge: Die Länge des Frames. Die standardmäßige maximale Länge beträgt 16 KB. Wenn Sie einen größeren Frame senden möchten, müssen Sie die maximale Framegröße explizit festlegen.
  Typ: Frame-Typ, z. B. DATEN, HEADERS, PRIORITÄT usw.
  Flag und R: reservierte Bits.
  Stream-Kennung: Identifiziert den Stream, zu dem er gehört. Wenn er 0 ist, bedeutet dies, dass dieser Frame zur gesamten Verbindung gehört.
  Frame-Nutzlast: hat je nach Typ unterschiedliche Formate.
Stream hat viele wichtige Funktionen:
1. Eine Verbindung kann mehrere Streams enthalten und die von mehreren Streams gesendeten Daten beeinflussen sich nicht gegenseitig.
2. Der Stream kann einseitig verwendet oder von Client und Server gemeinsam genutzt werden.
3. Der Stream kann durch jedes Segment geschlossen werden.
4. Der Stream bestimmt die Reihenfolge, in der Frames gesendet werden, und das andere Ende verarbeitet sie in der Reihenfolge, in der sie empfangen werden.
5. Ein Stream wird durch eine eindeutige ID identifiziert. Wird der Stream vom Client erstellt, ist die ID eine ungerade Zahl, wird er vom Server erstellt, ist die ID eine gerade Zahl.

Bei der binären Übertragung werden einige Funktionen des TCP-Protokolls auf die Anwendungsebene verlagert. Die ursprüngliche „Header+Body“-Nachricht wird dabei in mehrere kleine binäre „Frames“ aufgeteilt. Dabei werden „HEADERS“-Frames zur Speicherung der Header-Daten und „DATA“-Frames zur Speicherung der Entity-Daten verwendet. Nach der Frame-Formatierung der HTP/2-Daten verschwindet die „Header+Body“-Nachrichtenstruktur vollständig, und das Protokoll erkennt nur noch „Fragmente“.

Bei HTTP/2 erfolgt die gesamte Kommunikation unter demselben Domänennamen über eine einzige Verbindung, die eine beliebige Anzahl bidirektionaler Datenströme übertragen kann. Jeder Datenstrom wird in Form einer Nachricht gesendet, die wiederum aus einem oder mehreren Frames besteht. Mehrere Frames können in beliebiger Reihenfolge gesendet und anhand der Stream-Kennung im Frame-Header wieder zusammengesetzt werden.

Header-Komprimierung

Da Header in HTTP/1 in Textform übertragen werden, müssen bei der Übertragung von Cookies und Benutzeragenten unter Umständen Hunderte bis Tausende von Bytes wiederholt übertragen werden. HTTP/2 verwendet keine herkömmlichen Komprimierungsalgorithmen, sondern entwickelt einen speziellen „HPACK“-Algorithmus, richtet auf Client und Server ein „Wörterbuch“ ein, verwendet Indexnummern zur Darstellung wiederholter Zeichenfolgen und verwendet Huffman-Kodierung zur Komprimierung von Ganzzahlen und Zeichenfolgen, wodurch eine hohe Komprimierungsrate von 50% bis 90% erreicht werden kann.

Die Einzelheiten sind wie folgt:

HTTP/2 verwendet eine „Header-Tabelle“ auf Client und Server, um zuvor gesendete Schlüssel-Wert-Paare zu verfolgen und zu speichern. Es werden nicht mehr bei jeder Anfrage und Antwort dieselben Daten gesendet.
Die Header-Tabelle ist während der HTTP/2-Verbindung immer vorhanden und wird vom Client und Server fortlaufend aktualisiert.
Jedes neue Header-Schlüssel-Wert-Paar wird entweder an das Ende der aktuellen Tabelle angehängt oder ersetzt den vorherigen Wert in der Tabelle.

Multiplexing (Anforderungs- und Antwortmultiplexing) Derselbe Domänenname muss nur eine TCP-Verbindung belegen. Über eine TCP-Verbindung können kontinuierlich Frames an die Gegenstelle gesendet werden. Die Stream-Kennung jedes Frames gibt an, zu welchem Stream er gehört. Beim Empfang durch die Gegenstelle werden alle Frames jedes Streams entsprechend der Stream-Kennung zu einem vollständigen Datenblock zusammengefügt.
Die in der obigen Protokollanalyse erwähnte Stream-ID dient als Mechanismus zur Verbindungsfreigabe. Eine Anfrage entspricht einem Stream und erhält eine ID. Dadurch können mehrere Streams auf einer Verbindung laufen und die Frames jedes Streams beliebig gemischt werden. Der Empfänger kann die Frames anhand der Stream-ID verschiedenen Anfragen zuordnen. Anfragen und Antworten beeinflussen sich nicht gegenseitig.
Multiplexing (MultiPlexing), diese Funktion entspricht der Verbesserung langer Verbindungen. Jede Anforderung kann zufällig gemischt werden, und der Empfänger kann die Anforderung entsprechend der Anforderungs-ID verschiedenen Serveranforderungen zuordnen.
Beim Multiplexing werden Stream-Prioritäten (Stream-Abhängigkeiten) unterstützt, sodass der Client dem Server mitteilen kann, welcher Inhalt eine Ressource mit höherer Priorität ist und zuerst übertragen werden kann.
Server-Push Eine weitere leistungsstarke neue Funktion von HTTP/2 ist die Möglichkeit, dass der Server mehrere Antworten auf eine Client-Anfrage senden kann. Anders ausgedrückt: Zusätzlich zur Antwort auf die ursprüngliche Anfrage kann der Server zusätzliche Ressourcen an den Client senden, ohne dass dieser dies explizit anfordert.
Der Server kann aktiv pushen, und der Client hat auch das Recht zu wählen, ob er empfangen werden soll. Wenn die vom Server gepushte Ressource vom Browser zwischengespeichert wurde, kann der Browser sie durch Senden eines RST_STREAM-Frames ablehnen.
Aktives Pushen entspricht der Same-Origin-Policy. Der Server kann nicht beliebig fremde Ressourcen an den Client pushen, sondern muss dies von beiden Seiten bestätigen.
Verbesserte Sicherheit: HTTP/2 übernimmt die Klartextfunktion von HTTP/1 und kann Daten wie bisher im Klartext übertragen. Die Verwendung verschlüsselter Kommunikation ist nicht erzwungen. Das Format ist zwar weiterhin binär, erfordert aber keine Entschlüsselung.
Da HTTPS der allgemeine Trend ist und gängige Browser wie Chrome und Firefox öffentlich erklärt haben, nur verschlüsseltes HTTP/2 zu unterstützen, ist HTTP/2 tatsächlich verschlüsselt. Anders ausgedrückt: Das im Internet verbreitete HTTP/2 verwendet den Protokollnamen „https“ und läuft auf TLS. Das HTTP/2-Protokoll definiert zwei Zeichenfolgenkennungen: „h2“ für verschlüsseltes HTTP/2 und „h2c“ für Klartext-HTTP/2.

Probleme mit HTTP2

Sowohl http1.x als auch http2 basieren auf TCP. TCP ist ein sicheres und zuverlässiges Übertragungsprotokoll, dennoch ist die Verzögerung beim Verbindungsaufbau etwas hoch. Dies liegt hauptsächlich an der Verzögerung beim Verbindungsaufbau zwischen TCP und TCP+TLS.
Das Problem der Überlastung des TCP-Head-of-Line kann nicht gelöst werden. HTTP2 löst die Überlastung des Head-of-Line auf der HTTP-Schicht durch Multiplexing, das Problem der fehlgeschlagenen erneuten Übertragung von TCP ist jedoch immer noch unlösbar.

HTTP 3.0-Prinzipien

Da TCP schon so lange existiert, wird es in verschiedenen Geräten verwendet und dieses Protokoll wird vom Betriebssystem implementiert, sodass eine Aktualisierung nicht praktikabel ist.

Aus diesem GrundGoogle hat ein auf dem UDP-Protokoll basierendes QUIC-Protokoll erstellt und es auf HTTP/3 verwendet.HTTP/3 hieß früher HTTP-over-QUIC. Dieser Name verdeutlicht auch, dass die größte Neuerung von HTTP/3 die Verwendung von QUIC ist. QUIC (Quick UDP Internet Connections) basiert auf UDP, welches wiederum auf dessen Geschwindigkeit und Effizienz basiert. Gleichzeitig integriert QUIC die Vorteile von TCP, TLS und HTTP/2 und optimiert diese.

Zu den sekundären Zielen von QUIC gehören die Reduzierung der Verbindungs- und Übertragungslatenz sowie die Bandbreitenschätzung in beide Richtungen, um Überlastungen zu vermeiden. Außerdem wird der Algorithmus zur Überlastungssteuerung in den Benutzerbereich statt in den Kernelbereich verschoben und um eine Vorwärtsfehlerkorrektur (FEC) erweitert, um die Leistung bei Fehlern weiter zu verbessern.

Von HTTP3 implementierte Funktionen

Für die Implementierung der schnellen Handshake-Funktion benötigt eine HTTP/2-Verbindung drei RTTs. Bei Sitzungswiederverwendung, d. h. wenn der im ersten Handshake berechnete symmetrische Schlüssel zwischengespeichert wird, sind ebenfalls zwei RTTs erforderlich. Bei einem TLS-Upgrade auf 1.3 benötigt eine HTTP/2-Verbindung zwei RTTs und eine RTT für die Sitzungswiederverwendung. HTTP/3 benötigt jedoch nur eine RTT für die erste Verbindung und keine RTT für nachfolgende Verbindungen.
Der Client und Server, die das QUIC-Protokoll verwenden, sollten 1RTT verwendenSchlüsselaustausch, der verwendete Austauschalgorithmus ist DH (Diffie-Hellman)Diffie-Hellman-Algorithmus.
Beim ersten VerbindenSchlüsselverhandlung und Datenübertragungsprozess zwischen Client und Server, der den grundlegenden Prozess des DH-Algorithmus beinhaltet:
1. Der Client sendet zunächst eine Client-Hello-Anfrage an den Server, mit dem er zum ersten Mal eine Verbindung herstellt.
2. Der Server generiert eine Primzahl p und eine Ganzzahl g sowie eine Zufallszahl als privaten Schlüssel a. Anschließend berechnet er den öffentlichen Schlüssel A = mod p. Der Server verpackt die drei Elemente A, p und g in eine Konfiguration und sendet diese an den Client.
3. Der Client generiert zufällig seinen eigenen privaten Schlüssel b, liest dann g und p aus der Konfiguration und berechnet den öffentlichen Schlüssel des Clients B = mod p. Der Client berechnet dann den Anfangsschlüssel K basierend auf A, p und b. Nachdem B und K berechnet wurden, verwendet der Client K, um die HTTP-Daten zu verschlüsseln und sie zusammen mit B an den Server zu senden.
4. Der Client verwendet seinen eigenen privaten Schlüssel b und den aus der vom Server gesendeten Konfiguration gelesenen öffentlichen Schlüssel des Servers, um den Schlüssel K = mod p für die anschließende Datenverschlüsselung zu generieren.
5. Der Client verwendet den Schlüssel K zum Verschlüsseln der Geschäftsdaten und hängt seinen eigenen öffentlichen Schlüssel an, der dann an den Server weitergegeben wird.
6. Der Server generiert den Client-Verschlüsselungsschlüssel K = mod p basierend auf seinem eigenen privaten Schlüssel a und dem öffentlichen Schlüssel B des Clients.
7. Um die Datensicherheit zu gewährleisten, wird der oben generierte Schlüssel K nur einmal verwendet. Anschließend generiert der Server nach denselben Regeln einen neuen Satz öffentlicher und privater Schlüssel und verwendet diesen Satz zur Generierung eines neuen Schlüssels M.
8. Der Server sendet die mit dem neuen öffentlichen Schlüssel und dem neuen Schlüssel M verschlüsselten Daten an den Client. Der Client berechnet den Schlüssel M basierend auf dem neuen öffentlichen Schlüssel des Servers und seinem ursprünglichen privaten Schlüssel und entschlüsselt ihn.
9. Alle nachfolgenden Dateninteraktionen zwischen dem Client und dem Server werden mit Schlüssel M abgeschlossen, und Schlüssel K wird nur einmal verwendet.

Wenn Client und Server zum ersten Mal eine Verbindung herstellen, übergibt der ServerKonfigurationspaket, das den öffentlichen Schlüssel des Servers und zwei Zufallszahlen enthält,Der Client speichert die Konfiguration, kann es direkt verwendet werden, wenn später die Verbindung wiederhergestellt wird, wodurch 1RTT übersprungen und 0RTT-Geschäftsdateninteraktion realisiert wird.

Der Client speichert die Konfiguration für ein Zeitlimit und der Schlüsselaustausch bei der ersten Verbindung ist auch nach Ablauf der Konfiguration noch erforderlich.

Integrierte TLS-Verschlüsselungsfunktion
1. Sicher nach vornVorwärtssicherheit bedeutet, dass selbst wenn der Schlüssel verloren geht, die zuvor verschlüsselten Daten nicht verloren gehen. Dies betrifft nur die aktuellen Daten und hat keine Auswirkungen auf die vorherigen Daten..
  QUIC nutzt die Gültigkeitsdauer der Konfiguration und generiert anschließend einen neuen Schlüssel, der zur Ver- und Entschlüsselung verwendet und nach Abschluss der Interaktion vernichtet wird, wodurch Vorwärtssicherheit erreicht wird.
2. Vorwärtsfehlerkorrektur Die Vorwärtsfehlerkorrektur, auch als Vorwärtsfehlerkorrekturcode oder FEC bekannt, ist eine Methode zur Erhöhung der Zuverlässigkeit der Datenkommunikation. Sobald in einem Einweg-Kommunikationskanal ein Fehler entdeckt wird, hat der Empfänger kein Recht mehr, eine Übertragung anzufordern.
  FEC ist eine Methode zur Übertragung redundanter Informationen mit Daten, die es dem Empfänger ermöglicht, die Daten zu rekonstruieren, wenn während der Übertragung Fehler auftreten.
  Jedes Mal, wenn QUIC eine Gruppe von Daten sendet, verarbeitet es die DatenXOR-OperationDas Ergebnis wird als FEC-Paket gesendet. Nach Erhalt dieses Datensatzes kann der Empfänger anhand des Datenpakets und des FEC-Pakets eine Überprüfung und Fehlerkorrektur durchführen. Nachdem ein Datenelement in zehn Pakete aufgeteilt wurde, wird jedes Paket nacheinander XOR-verknüpft, und das Ergebnis der Operation wird zusammen mit dem Datenpaket als FEC-Paket übertragen. Geht während der Übertragung ein Datenpaket verloren, können die Daten des verlorenen Pakets anhand der verbleibenden neun Pakete und des FEC-Pakets abgeleitet werden, was die Fehlertoleranz des Protokolls erheblich erhöht.
Multiplexing, Lösung des Head-of-Line-Blockierungsproblems im TCP HTTP2.0-ProtokollMultiplexing-MechanismusEs löst das Head-of-Line-Blockierungsproblem auf der HTTP-Ebene, aberDie TCP-Schicht hat immer noch das Problem der Head-of-Line-Blockierung.
Nachdem das TCP-Protokoll das Datenpaket empfangen hat, kann dieser Teil der Daten in der falschen Reihenfolge eintreffen, aber TCP muss alle Daten sammeln, sortieren und integrieren, damit sie von der oberen Schicht verwendet werden können.Wenn eines der Pakete verloren geht, muss es auf eine erneute Übertragung warten, was zu einem Paketverlust führt, der die Datennutzung der gesamten Verbindung blockiert..
Das QUIC-Protokoll wird basierend auf dem UDP-Protokoll implementiert.Mehrere Streams, zwischen den Strömen istKeine gegenseitige BeeinflussungWenn in einem Datenfluss ein Paketverlust auftritt, sind die Auswirkungen sehr gering, wodurch das Head-of-Line-Blockierungsproblem gelöst wird.
Implementieren Sie eine TCP-ähnliche Flusskontrolle (… dieser Teil ist lang, siehe Referenz)