Hintergrund
Was eine Zeit lang als HTTP-over-QUIC bekannt war, hat nun seinen Namen geändert und wird offiziell zu HTTP/3. Dies wurde durch den ursprünglichen Vorschlag von Mark Nottingham ausgelöst
Warum brauchen Sie QUIC
Mit der rasanten Entwicklung des mobilen Internets und dem allmählichen Aufstieg des Internets der Dinge werden die Szenarien der Netzwerkinteraktion immer häufiger, auch der Inhalt der Netzwerkübertragung wird immer größer und die Benutzer haben immer höhere Anforderungen an Netzwerkübertragungseffizienz und WEB-Antwortgeschwindigkeit.
Traditionelle Protokolle wie TCP hatten jedoch immer die folgenden Nachteile:
Das Verlassen auf die Implementierung des Betriebssystems macht das Protokoll selbst starr.
TCP wird vom Betriebssystem auf Kernelebene implementiert, und Anwendungen können es nur verwenden und nicht direkt ändern. Obwohl die Update-Iteration der Anwendung sehr schnell und einfach ist. Aber die Iteration von TCP ist sehr langsam, der Grund dafür ist, dass das Upgrade des Betriebssystems sehr mühsam ist.
Mobile Endgeräte sind jetzt beliebter, aber einige Benutzer mobiler Endgeräte hinken bei Betriebssystem-Upgrades möglicherweise noch mehrere Jahre hinterher. Noch gravierender ist die Systemaktualisierungsverzögerung auf der PC-Seite: Windows XP wird immer noch von einer großen Anzahl von Benutzern verwendet, obwohl es seit fast 20 Jahren existiert.
Das Serversystem ist nicht auf Benutzeraktualisierungen angewiesen, aber da die Betriebssystemaktualisierung die Aktualisierung der zugrunde liegenden Software und Laufzeit beinhaltet, ist es relativ konservativ und langsam.
Das bedeutet, dass selbst wenn TCP relativ gute Feature-Updates hat, es schwierig ist, es schnell zu fördern. Wie TCP Fast Open. Obwohl es 2013 vorgeschlagen wurde, unterstützen viele Systemversionen von Windows es immer noch nicht.Die
Handshake-Verzögerung für den Verbindungsaufbau ist groß.
Ob HTTP1.0/1.1 oder HTTPS, HTTP2, alle verwenden TCP für die Übertragung. Auch HTTPS und HTTP2 erfordern zur sicheren Übertragung die Verwendung des TLS-Protokolls. Es gibt zwei Handshake-Verzögerungen:
1. Verzögerung beim TCP-Verbindungsaufbau, verursacht durch TCP-Dreiwege-Handshake.
2. Für einen vollständigen TLS-Handshake sind mindestens 2 RTTs erforderlich, und für einen vereinfachten Handshake ist eine Handshake-Verzögerung von 1 RTT erforderlich.
Bei vielen kurzen Verbindungsszenarien hat eine solche Handshake-Verzögerung einen großen Einfluss und kann nicht beseitigt werden
Head-of-Line-Blocking
Head-of-Line-Blocking wird hauptsächlich durch den Zuverlässigkeitsmechanismus des TCP-Protokolls eingeführt. TCP verwendet Seriennummern, um die Reihenfolge der Daten zu identifizieren, und die Daten müssen der Reihe nach verarbeitet werden.Wenn die vorherigen Daten verloren gehen, wird die Anwendungsschicht nicht zur Verarbeitung benachrichtigt, selbst wenn die nachfolgenden Daten eintreffen.
Außerdem gibt es Head-of-Line-Blocking auf TLS-Protokollebene, da das TLS-Protokoll Daten nach Datensätzen verarbeitet und bei Datenverlust in einem Datensatz nicht der gesamte Datensatz korrekt verarbeitet werden kann.
Kurz gesagt, es gibt strukturelle Probleme in den Protokollen vor TCP und TLS 1.2. Wenn Sie weiterhin ein brandneues Protokoll der Anwendungsschicht zusätzlich zu den bestehenden TCP- und TLS-Protokollen implementieren, hängt dies vom Betriebssystem, zwischengeschalteten Geräten, und Benutzer. Die Bereitstellungskosten sind sehr hoch und der Widerstand ist sehr hoch.
Daher wählt das QUIC-Protokoll UDP, weil UDP selbst kein Verbindungskonzept hat und keinen Drei-Wege-Handshake erfordert, es optimiert die Handshake-Verzögerung für den Verbindungsaufbau und realisiert gleichzeitig die Zuverlässigkeit von TCP, die Sicherheit von TLS , und die Parallelität von HTTP2 auf Anwendungsebene.Nur die Client- und Serveranwendungen müssen das QUIC-Protokoll unterstützen, wodurch die Einschränkungen des Betriebssystems und der zwischengeschalteten Geräte vollständig vermieden werden.
Die Verknöcherung von Zwischengeräten
kann daran liegen, dass das TCP-Protokoll zu lange verwendet wird und zudem sehr zuverlässig ist. Daher haben viele unserer Zwischengeräte, einschließlich Firewalls, NAT-Gateways und Gleichrichter, einige herkömmliche Aktionen.
Beispielsweise lassen einige Firewalls nur 80 und 443 passieren und lassen andere Ports nicht passieren. Das NAT-Gateway schreibt beim Übersetzen der Netzwerkadresse den Header der Transportschicht neu, was beide Parteien daran hindern kann, das neue Transportformat zu verwenden. Gleichrichter und Zwischenproxies entfernen aus Sicherheitsgründen manchmal einige Optionsfelder, die sie nicht verstehen.
Das TCP-Protokoll unterstützt ursprünglich das Hinzufügen und Ändern von Ports, Optionen und Funktionen. Aufgrund der langen Geschichte der Verwendung des TCP-Protokolls und bekannter Ports und Optionen haben sich die Zwischengeräte jedoch bereits auf diese unausgesprochenen Regeln verlassen, sodass die Änderung dieser Inhalte leicht durch die Zwischenverbindungen gestört wird und fehlschlägt.
Warum QUIC die Vormachtstellung von TCP erschüttern kann
Das QUIC-Protokoll ist eine von Google vorgeschlagene Reihe von UDP-basierten Open-Source-Protokollen. Es kombiniert die Vorteile von TCP und UDP. Die Übertragung ist effizient und zuverlässig und löst das aktuelle Dilemma von TCP. Die Vorteile von QUIC sind wie folgt:
Einfachere Update-Iteration: TCP- und UDP-Protokolle werden vom Betriebssystem-Kernel implementiert, und der Bereitstellungsfortschritt ist langsam. QUIC wird direkt auf Client-Basis implementiert und kann schnelle iterative Updates
ohne Head-of-Line-Blocking-Multiplexing realisieren: Um die Zuverlässigkeit zu gewährleisten, verwendet TCP Sequence Number und Ack basierend auf Byte-Sequenznummern, um das ordnungsgemäße Eintreffen von Nachrichten zu bestätigen, und die Daten müssen in Übereinstimmung mit der sequentiellen Verarbeitung sein, was zu einer Head-of-Line-Blockierung führen kann. HTTP2 unterstützt Multiplexing, aber aufgrund der obligatorischen Verwendung von TLS gibt es immer noch eine Head-of-Line-Blockierung auf TLS-Protokollebene.Die grundlegendste Übertragungseinheit von QUIC ist Packet, das die Größe von MTU nicht überschreiten wird Der Verschlüsselungs- und Authentifizierungsprozess basiert auf Paketen und erstreckt sich nicht über mehrere Pakete. Auf diese Weise kann das Head-of-Line-Blocking im TLS-Protokoll vermieden werden. Streams sind voneinander unabhängig.Wenn Stream2 beispielsweise ein Pakcet verliert, wirkt sich dies nicht auf Stream3 undStream4 aus, sodass es keine TCP-Head-of-Line-Blockierung gibt.
Freie Wahl der Staukontrolle: Die TCP-Staukontrolle umfasst eigentlich vier Algorithmen: Langsamer Start, Stauvermeidung, schnelle Neuübertragung und schnelle Wiederherstellung. Das QUIC-Protokoll verwendet derzeit standardmäßig den kubischen Staukontrollalgorithmus des TCP-Protokolls und unterstützt auch CubicBytes, Reno , RenoBytes, BBR, PCC und andere Überlastungskontrollalgorithmen. Aus der Perspektive des Überlastungsalgorithmus selbst wird QUIC nur gemäß dem TCP-Protokoll neu implementiert. Welche Aspekte des QUIC-Protokolls wurden also verbessert? Die Hauptpunkte sind wie folgt:
steckbar: verschiedene Überlastungskontrollalgorithmen können auf Anwendungsebene implementiert werden, es ist kein Betriebssystem erforderlich, es ist keine Kernel-Unterstützung erforderlich, und sogar verschiedene Verbindungen einer einzelnen Anwendung können verschiedene Überlastungskontrollkonfigurationen unterstützen, das heißt bequem für
die Erweiterung: Das Anwendungsprogramm kann die Änderung der Überlastkontrolle realisieren, ohne anzuhalten und zu aktualisieren. Wir müssen nur die Konfiguration auf der Serverseite ändern, neu laden und
mehr Ack-Blöcke Die Option kann dem Absender den Bereich der empfangenen kontinuierlichen Segmente mitteilen, was für den Absender praktisch ist, um eine selektive Neuübertragung durchzuführen.
Da die maximale Länge des TCP-Headers nur 60 Bytes beträgt und der Standard-Header 20 Bytes belegt, beträgt die maximale Länge der Tcp-Option nur 40 Bytes, plus die Tcp-Timestamp-Option belegt 10 Bytes [25], ist also reserviert Sack-Optionen sind nur 30 Bytes groß.
Die Länge jedes Sack-Blocks beträgt 8 plus die 2 Bytes des Sack-Option-Headers, was bedeutet, dass die Tcp-Sack-Option nur maximal 3 Blöcke bereitstellen kann.
Quic Ack Frame kann jedoch gleichzeitig 256 Ack-Blöcke bereitstellen In einem Netzwerk mit einer relativ hohen Paketverlustrate können mehr Sack-Blöcke die Wiederherstellungsgeschwindigkeit des Netzwerks verbessern und die Anzahl der Neuübertragungen reduzieren
Schnellerer Handshake: TCP benötigt drei Handshakes zum Verbindungsaufbau und es gibt eine Wartezeit, bei Verwendung von TLS-Verschlüsselung wird die Verzögerung weiter erhöht. QUIC hat ein ähnliches Design wie TCP Fast Open. Wenn Sie schon einmal verbunden waren, können Sie ohne Handshaking direkt mit der Datenübertragung beginnen, und die Verzögerung beim Verbindungsaufbau beträgt 0.
Verbindungserhalt: Eine TCP-Verbindung wird durch ein Vierer-Tupel (Quell-IP, Quell-Port, Ziel-IP, Ziel-Port) gekennzeichnet, bei Änderung einer der Angaben muss die TCP-Verbindung zum Server neu aufgebaut werden. Die QUIC-Verbindung wird nicht mehr durch IP und Port-Quadrupel identifiziert, sondern durch eine 64-Bit-Zufallszahl als ID, sodass auch bei Änderung der IP oder des Ports, solange die ID unverändert bleibt, die Verbindung bestehen bleibt. Das bedeutet: Bei IP-Adress- und Port-Änderungen (z. B. Umschalten von WLAN auf Traffic) kann die Kommunikation ohne erneuten Verbindungsaufbau fortgesetzt werden
QUIC-Nachteile
Da QUIC so gut ist, warum ist es immer noch nicht sehr beliebt? Es gibt folgende Gründe
QUIC basiert auf UDP. Derzeit werden viele Netzbetreiber die Priorität von UDP-Paketen herabsetzen, was die UDP-Paketverlustrate besonders hoch macht. Es gibt relativ wenige Browser, die
das QUIC-Protokoll unterstützen.
Alibaba Cloud CDN unterstützt derzeit langsam QUIC
Kuaishou hat KQUIC auch selbst entwickelt