BLOG | BÜRO DES CTO

QUIC wird das Internet auffressen

F5 Miniaturansicht
F5
Veröffentlicht am 22. Februar 2021


QUIC (kein Akronym) ist ein einzigartiges Biest, man sollte es sich aber am besten als neues Transportprotokoll vorstellen, das viele seit langem bestehende Probleme im Internet löst und den größten Teil des Nutzens von TCP, TLS, SCTP, IPSec und HTTP/2 nutzt. Es gibt eine neue Version von HTTP namens HTTP/3, die über UDP/QUIC statt TCP/TLS funktioniert.

Google hat bereits 2014 eine frühe Version von HTTP über QUIC in seinen Browsern und Webservern bereitgestellt. Im Jahr 2016 begann ein IETF-Standardisierungsprozess. Nach umfangreicher Entwicklung und Datenerfassung wird dies Anfang 2021 zum ersten Stapel von RFCs führen. Mehrere große Internetunternehmen, darunter F5, haben entweder Produkte ausgeliefert, die QUIC verwenden, oder QUIC in ihrer Infrastruktur implementiert. Im Oktober 2020 liefen 75 % des Facebook-Datenverkehrs über HTTP/3 und QUIC.

Diese frühen Einsätze und die Begeisterung für neue Standards auf der Grundlage von QUIC in der IETF deuten darauf hin, dass dies ein wichtiges und möglicherweise dominierendes Substrat für hochmoderne Anwendungen im Internet werden wird.

Technischer Überblick – Warum QUIC?

Schnelle Ebenen
Abbildung 1. QUIC nutzt Funktionen aus vielen älteren Protokollen.

Abbildung 1 gibt dem Leser eine Vorstellung davon, was QUIC macht. Diese funktionale Zerlegung erklärt jedoch nicht, warum die ersten Anwender in der Industrie auf QUIC umsteigen:

  1. Geringere Latenz. Webähnliche Datenübertragungen werden von der Latenz dreier Handshake-Ebenen dominiert: eine für TCP, mindestens eine für TLS und eine für HTTP-Anforderung/-Antwort. Aktuelle Entwicklungen bei TCP/TLS ermöglichen es, dies im Prinzip auf einen einzigen Roundtrip zu reduzieren, obwohl dies in der Praxis selten funktioniert. QUIC reduziert dies auf einen, höchstens zwei Hin- und Rückwege.

  2. Ströme. Wie HTTP/2 stellt QUIC der Anwendung mehrere Byte-Streams zur Verfügung, um die Unabhängigkeit konzeptionell unterschiedlicher Daten zu erhöhen, die über dieselbe Verbindung übermittelt werden. Diese Unabhängigkeit wird noch verstärkt, wenn man dies im Transportmittel tut. Streams erfüllen natürlich die Anforderungen für die Bereitstellung von Streaming-Videos und die großen Internet-Content-Provider sind bereits auf dem besten Weg, Streaming über QUIC bereitzustellen.

  3. Bessere Verlustreaktion. Das Design von QUIC verbessert die Fähigkeit von TCP, Paketverluste zu erkennen und zu beheben. Darüber hinaus führt die Bereitstellung von Multiplex-Streams anstelle eines einzelnen geordneten Byte-Streams nicht zwangsläufig dazu, dass der Verlust eines Pakets mit einem Objekt die Auslieferung eines anderen Objekts verzögert.

  4. Multihoming. Ähnlich wie MPTCP und SCTP können QUIC-Verbindungen jedem Endpunkt mehrere IP-Adressen zugeordnet werden. Im Gegensatz zu diesen Protokollen hat QUIC gute Chancen, sich in einem Internet durchzusetzen, in dem unbekannte Protokollnummern und TCP-Headeroptionen weggelassen werden.

  5. Sicherheit und Datenschutz. QUIC wendet die Verschlüsselung auf der Transportebene an, statt darüber. Die gesamte UDP-Nutzlast wird authentifiziert, wodurch jede transparente Änderung durch Vermittler verhindert wird, und fast alle Transportinformationen werden verschlüsselt. Die Auswirkungen hiervon sind Gegenstand eines eigenen Whitepapers. Es genügt zu sagen, dass dies die Datenschutzeigenschaften erheblich verbessert und die Angriffsfläche, die TCP bietet, praktisch eliminiert. Im Gegensatz zu IPSec läuft dies heute im Web-Maßstab. Es führt auch zu:

  6. Erweiterbarkeit. TCP lässt sich nur schwer ändern, da seine Entwickler nur begrenzten Erweiterungsraum gelassen haben und Middleboxes altes TCP-Verhalten erzwingen. QUIC kombiniert explizite Versionierung mit Undurchsichtigkeit gegenüber Middleboxes, um weitere Innovationen beim Transport zu ermöglichen. Dadurch werden zukünftige Anwendungsfälle unterstützt und letztendlich die Massentransportkapazität im Vergleich zu TCP verbessert.

Es gibt neben Trägheit zwei Gründe, warum einige Anwendungen möglicherweise nicht auf QUIC umsteigen:

  • Komplexität: Anwendungen, die nur einen einzigen Bytestream benötigen und sich nicht um die Verschlüsselung kümmern, benötigen den zusätzlichen Arbeitsaufwand, der mit diesen Funktionen verbunden ist, nicht.

  • Mittelboxen: Ein nicht zu vernachlässigender Prozentsatz der Internetpfade lässt kein UDP zu. HTTP/3 wurde mit TCP-Fallback für diese Pfade entwickelt, doch die Leistungseinbußen bei wichtigen Websites (Google, Facebook usw.) werden die entsprechenden Geräte vermutlich letztlich obsolet machen, es sei denn, Nationalstaaten, die eine Überwachung wünschen, schreiben etwas anderes vor.

Es frisst das Internet

Google Chrome, Google App Clients und die App von Facebook unterstützen bereits HTTP/3. Safari-, Edge- und Firefox-Implementierungen unterstützen es, sind aber (derzeit) standardmäßig deaktiviert.

Auf der Serverseite wurden Implementierungen und/oder Bereitstellungen von Google, Microsoft, Facebook, Apple, Cloudflare, LiteSpeed, F5 BIG-IP, NGINX, Fastly und Akamai entweder bereits ausgeliefert oder stehen kurz davor. Kürzlich meldete ein führender europäischer ISP , dass 20 % seiner Pakete QUIC waren . Im Februar 2021 verwenden etwa 5 % der Websites HTTP/3 , aber wir erwarten, dass dieser Wert steigt, sobald der RFC veröffentlicht ist.

Darüber hinaus wird in Standardisierungsorganisationen intensiv daran gearbeitet, QUIC über den HTTP-Anwendungsfall hinaus zu bringen. Die Standardsentwürfe der IETF schlagen DNS, Websockets, SIP sowie TCP- und UDP-Tunnel über QUIC vor. QUIC kam etwas zu spät, um vollständig in 5G-Architekturen integriert zu werden, aber das Interesse und die Anwendbarkeit von QUIC für Dienstanbieter sind klar. Schließlich sind die oberen APIs für HTTP/2 und HTTP/3 ziemlich ähnlich, sodass jedes Protokoll oder jede Anwendung, die auf HTTP/2 läuft, problemlos portiert werden kann, um über HTTP/3 und QUIC statt über TCP zu laufen.

Bedrohungen und Chancen

QUIC und HTTP/3 werden zahlreiche Märkte prägen . Für leistungsstarke Websites und Anwendungen besteht ein starker Anreiz, auf HTTP/3 und QUIC umzusteigen, sobald das Ökosystem vollständig ausgereift ist. Außerdem erwarten wir, dass unsere Kunden HTTP/3-Unterstützung in einem ähnlichen Tempo fordern werden, wie sie HTTP/2 bereitstellen.

Sicherheitsprodukte müssen in einem QUIC-basierten Internet grundlegend neu bewertet werden. Ohne Zugriff auf TLS-Sitzungsschlüssel ist die Paketprüfung wesentlich schwieriger, da diese normalerweise nur mit dem Besitz des privaten Schlüssels der Domäne möglich ist. Dies steigert den Wert einer Sicherheitslösung, die in einen Proxy auf Anwendungsebene integriert ist, statt in eine Reihe von Geräten mit Einzelfunktion.

Darüber hinaus muss die herkömmliche DDoS-Abwehr optimiert werden. Nicht nur ist die Paketidentifizierung und -prüfung schwieriger, sondern TCP-Syncookies wurden auch durch „Retry-Pakete“ ersetzt, die von Vermittlern nicht so leicht gefälscht werden können. Es gibt standardmäßige Koordinationsmethoden, die es Servern ermöglichen, die Generierung und Validierung von Retry-Paketen auszulagern, aber auch das erfordert Entwicklungsaufwand.

Durch herkömmliches Layer 4-Load Balancing wird die QUIC-Adressmigration unterbrochen, da es einen Datenfluss, der seine Adresse oder Ports ändert, nicht mit sich selbst verknüpfen und dann zum selben Server weiterleiten kann. Auch hier gibt es Standards zur Koordinierung und Überwindung dieses Problems, aber es sind Investitionen erforderlich.

Die MASQUE-Arbeitsgruppe der IETF arbeitet an einem allgemeinen Verkehrstunneling über QUIC, das die Grundlage für VPN-Schemata der nächsten Generation bilden könnte. Die Eigenschaften von QUIC sind für das Multiplexen beliebiger Datenflüsse viel besser als TLS über TCP. Diese Tunnel können außerdem IPSec-Tunnel durch Kryptografie im Webmaßstab ersetzen, wodurch einige Anwendungsfälle von Dienstanbietern verbessert werden . Außerdem bieten sie mit ausdrücklicher Zustimmung des Clients sogar eine Möglichkeit , QUIC-Verbindungen für mobile Verbindungstypen zu optimieren .

QUIC erfordert neue Tools zur Netzwerkmessung und -analyse. Systeme, die TCP-Latenz und -Verlust messen könnten, können diese Signale nicht verwenden, aber es gibt ein explizites Latenzsignal für das Netzwerk und möglicherweise sind weitere Signale unterwegs. Da hinter der Verschlüsselung mehr Transportinformationen verborgen sind, ist die Paketerfassung weniger nützlich. Es gibt jedoch ein neues Standardprotokollierungsformat, dem viele QUIC-Implementierungen folgen und für dessen Nutzung Benutzer Analysetools entwickeln.

F5 verfolgt die Entwicklungen aufmerksam

Die Mitarbeiter von F5 beobachten die Standardisierungsbemühungen der IETF seit Jahren und leisten dort ihren Beitrag, wo wir meinen, dass dies unseren Kunden hilft. BIG-IP hat die Entwurfsversionen von QUIC und HTTP/3 von Anfang an verfolgt, einschließlich der öffentlichen Versionen seit TMOS v15.1.0.1. NGINX verfügt über eine Alpha-Version von HTTP/3 und wird diese in Kürze in die Hauptlinie integrieren.

Wir werden die Trends in diesem Bereich weiterhin beobachten und neue und spannende Produkte entwickeln, die den neuen Möglichkeiten dieser Protokolle Rechnung tragen.

Abschluss

QUIC verfügt über breite Unterstützung aus der Branche und hat das Potenzial, die Grundlage für die meisten Anwendungen zu bilden, die geschäftlichen Mehrwert über das Internet liefern. Jeder, der Anwendungen über das Internet bereitstellt, sollte darüber nachdenken, wie sich seine Betriebsabläufe ändern müssen, um den neuen Gefahren und Chancen Rechnung zu tragen, die diese Protokolle mit sich bringen.