QUIC wird das Internet verschlingen

F5

QUIC (kein Akronym) ist ein einzigartiges Konstrukt, lässt sich aber am besten als neues Transportprotokoll verstehen, das viele seit Langem bestehende Probleme im Internet löst und einen Großteil der Vorteile von TCP, TLS, SCTP, IPSec und HTTP/2 vereint. Es gibt eine neue HTTP-Version namens HTTP/3, die für den Betrieb über UDP/QUIC anstelle von TCP/TLS konzipiert ist.

Google setzte bereits 2014 eine frühe Version von HTTP über QUIC in seinen Browsern und Webservern ein. 2016 begann ein IETF-Standardisierungsprozess. Nach umfangreicher Weiterentwicklung und Datenerhebung wird dieser Anfang 2021 zur Veröffentlichung der ersten RFCs führen. Mehrere große Internetunternehmen, darunter F5, haben entweder Produkte auf den Markt gebracht, die QUIC verwenden, oder QUIC in ihrer Infrastruktur implementiert. Im Oktober 2020 wurden 75 % des Datenverkehrs von Facebook über HTTP/3 und QUIC übertragen.

Diese frühen Implementierungen und die Begeisterung für neue, auf QUIC aufbauende Standards innerhalb der IETF deuten darauf hin, dass QUIC zu einer wichtigen und möglicherweise dominierenden Grundlage für hochmoderne Anwendungen im Internet werden wird.

Technischer Überblick – warum QUIC?

Abbildung 1. QUIC übernimmt Funktionen aus vielen älteren Protokollen.

Abbildung 1 vermittelt dem Leser einen Eindruck davon, was QUIC leistet. Diese funktionale Aufschlüsselung verdeutlicht jedoch nicht, warum frühe Anwender in der Industrie auf QUIC umsteigen:

1. Geringere Latenz. Bei Web-ähnlichen Datenübertragungen wird die Latenz vor allem durch drei Handshake-Ebenen bestimmt: eine für TCP, mindestens eine für TLS und eine für HTTP-Anfrage und -Antwort. Neuere Entwicklungen bei TCP/TLS können dies theoretisch auf einen einzigen Roundtrip reduzieren, was in der Praxis jedoch nur selten funktioniert. QUIC reduziert dies auf einen Roundtrip, höchstens jedoch auf zwei.
   
   
2. Streams. 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 übertragen werden. Durch die Umsetzung auf der Transportschicht wird diese Unabhängigkeit noch weiter erhöht. Streams eignen sich von Natur aus für die Anforderungen der Streaming-Videoübertragung, und große Internet-Content-Anbieter sind bereits auf dem besten Weg, Streaming über QUIC bereitzustellen.
   
   
3. Bessere Reaktion auf Paketverluste. Das Design von QUIC verbessert gegenüber TCP die Fähigkeit, Paketverluste zu erkennen und auszugleichen. Da QUIC zudem mehrere gebündelte Datenströme statt eines einzigen, in der richtigen Reihenfolge zu verarbeitenden Bytestroms bereitstellt, muss der Verlust eines Pakets, das ein Objekt enthält, die Übertragung eines anderen Objekts nicht verzögern.
   
   
4. Multihoming. Ähnlich wie bei MPTCP und SCTP können QUIC-Verbindungen für jeden Endpunkt mehreren IP-Adressen zugeordnet werden. Im Gegensatz zu diesen Protokollen hat QUIC gute Chancen, auch in einem Internet zu funktionieren, das unbekannte Protokollnummern und TCP-Header-Optionen verwirft.
   
   
5. Sicherheit und Datenschutz. QUIC setzt die Verschlüsselung auf der Transportschicht ein und nicht auf einer darüberliegenden Schicht. Die gesamte UDP-Nutzlast wird authentifiziert, wodurch unbemerkte Änderungen durch zwischengeschaltete Instanzen verhindert werden, und nahezu alle Transportinformationen werden verschlüsselt. Die Auswirkungen dessen wären an sich schon ein eigenes Whitepaper wert. Es genügt zu sagen, dass dies die Datenschutzeigenschaften erheblich verbessert und die von TCP gebotene Angriffsfläche praktisch vollständig beseitigt. Anders als IPSec wird dies bereits heute im Webmaßstab eingesetzt. Dies führt außerdem zu:
   
   
6. Erweiterbarkeit. TCP lässt sich nur schwer ändern, da seine Entwickler nur begrenzten Raum für Erweiterungen vorgesehen haben und Middleboxes veraltetes TCP-Verhalten erzwingen. QUIC kombiniert eine explizite Versionierung mit Intransparenz gegenüber Middleboxes, um weitere Innovationen auf der Transportschicht zu ermöglichen. Dadurch können künftig neue Anwendungsfälle unterstützt und die Kapazität für die Übertragung großer Datenmengen im Vergleich zu TCP langfristig verbessert werden.

Abgesehen von der Trägheit gibt es zwei Gründe, warum einige Anwendungen möglicherweise nicht auf QUIC umsteigen:

• Komplexität: Anwendungen, die nur einen einzigen Bytestrom benötigen und für die Verschlüsselung keine Rolle spielt, brauchen den mit diesen Funktionen verbundenen zusätzlichen Aufwand nicht.
  
  
• Middleboxes: Ein nicht unerheblicher Anteil der Internetpfade lässt UDP nicht zu. HTTP/3 wurde für diese Pfade mit einem Rückfall auf TCP konzipiert, doch letztlich dürften die Auswirkungen auf die Leistung großer Websites (Google, Facebook usw.) dazu führen, dass die dafür verantwortlichen Geräte obsolet werden – außer dort, wo überwachungswillige Nationalstaaten etwas anderes vorschreiben.

Es erobert das Internet

Google Chrome, Google App Clients und die Facebook-App unterstützen HTTP/3 bereits. Die Implementierungen in Safari, Edge und Firefox unterstützen es ebenfalls, allerdings ist es dort (vorerst) 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 veröffentlicht oder stehen kurz davor. Kürzlich berichtete ein führender europäischer Internetanbieter, dass 20 % seiner Pakete QUIC verwendeten. Im Februar 2021 nutzten etwa 5 % der Websites HTTP/3, doch wir erwarten, dass dieser Anteil nach der Veröffentlichung des RFC steigen wird.

Darüber hinaus arbeiten Standardisierungsorganisationen intensiv daran, QUIC über den HTTP-Anwendungsfall hinaus zu etablieren. Standardentwürfe der IETF sehen 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, doch das Interesse von Dienstanbietern an QUIC und dessen Eignung für ihre Zwecke sind offensichtlich. Schließlich sind die übergeordneten APIs für HTTP/2 und HTTP/3 sehr ähnlich, sodass sich jedes Protokoll und jede Anwendung, die auf HTTP/2 aufsetzt, problemlos für die Ausführung über HTTP/3 und QUIC anstelle von TCP portieren lässt.

Bedrohungen & Chancen

QUIC & HTTP/3 werden eine Vielzahl von Märkten prägen. Leistungsstarke Websites und Anwendungen haben einen starken Anreiz, auf HTTP/3 und QUIC umzusteigen, sobald das Ökosystem vollständig ausgereift ist. Wir gehen davon aus, dass unsere Kunden HTTP/3-Unterstützung in einem ähnlichen Tempo nachfragen werden, wie sie HTTP/2 eingeführt haben.

Sicherheitsprodukte müssen in einem vom QUIC-Protokoll geprägten Internet grundlegend neu bewertet werden. Die Paketinspektion ist ohne Zugriff auf TLS-Sitzungsschlüssel erheblich schwieriger. Dieser Zugriff ist in der Regel nur mit dem privaten Schlüssel der Domain möglich. Dadurch steigt der Wert einer Sicherheitslösung, die in einen Proxy auf Anwendungsebene integriert ist, gegenüber einer Reihe von Geräten mit jeweils nur einer Funktion.

Darüber hinaus muss die herkömmliche DDoS-Abwehr überarbeitet werden. Nicht nur die Identifizierung und Überprüfung von Paketen ist schwieriger, sondern TCP-Syncookies wurden auch durch „Retry-Pakete“ ersetzt, die von zwischengeschalteten Instanzen nicht ohne Weiteres gefälscht werden können. Es gibt standardisierte Koordinierungsverfahren, mit denen Server die Erzeugung und Validierung von Retry-Paketen auslagern können, doch auch dies erfordert Entwicklungsaufwand.

Herkömmliches Layer-4-Load-Balancing verhindert die QUIC-Adressmigration, da es einen Datenfluss, dessen Adresse oder Ports sich ändern, nicht mehr sich selbst zuordnen und anschließend an denselben Server weiterleiten kann. Auch hier gibt es Standards zur Koordination und Behebung dieses Problems, deren Umsetzung jedoch Investitionen erfordert.

Die MASQUE-Arbeitsgruppe der IETF arbeitet an einer allgemeinen Tunnelung des Datenverkehrs über QUIC, die als Grundlage für VPN-Lösungen der nächsten Generation dienen könnte. QUIC eignet sich wesentlich besser als TLS über TCP für das Multiplexing beliebiger Datenströme. Diese Tunnel können außerdem IPSec-Tunnel durch webskalierbare Kryptografie ersetzen, wodurch sich einige Anwendungsfälle von Dienstanbietern verbessern lassen, und sogar eine Möglichkeit bieten, QUIC-Verbindungen für mobile Verbindungstypen zu optimieren – mit ausdrücklicher Zustimmung des Clients.

QUIC wird neue Werkzeuge zur Netzwerkmessung und -analyse erfordern. Systeme, die TCP-Latenz und -Verluste messen konnten, können diese Signale nicht nutzen. Es gibt jedoch ein explizites Latenzsignal für das Netzwerk, und weitere Signale könnten folgen. Da mehr Transportinformationen durch Verschlüsselung verborgen werden, sind Paketmitschnitte weniger nützlich. Allerdings gibt es ein neues standardisiertes Protokollierungsformat, dem viele QUIC-Implementierungen folgen und für dessen Nutzung derzeit Analysewerkzeuge entwickelt werden.

F5 verfolgt die Entwicklungen aufmerksam

Die Mitarbeiter von F5 verfolgen seit Jahren die Standardisierungsbemühungen der IETF und leisten Beiträge, wenn wir der Ansicht sind, dass dies unseren Kunden zugutekommt. BIG-IP verfolgt die Entwurfsversionen von QUIC und HTTP/3 von Anfang an, einschließlich der öffentlichen Versionen seit TMOS v15.1.0.1. Für NGINX gibt es eine HTTP/3-Alpha-Version, die in Kürze in den Mainline-Zweig integriert wird.

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

Fazit

QUIC wird in der Branche breit unterstützt und hat das Potenzial, die Grundlage für die meisten Anwendungen zu bilden, die über das Internet geschäftlichen Mehrwert schaffen. Wer Anwendungen über das Internet bereitstellt, sollte sich Gedanken darüber machen, wie die eigenen Betriebsabläufe angepasst werden müssen, um den neuen Bedrohungen und Chancen Rechnung zu tragen, die diese Protokolle mit sich bringen.

Über den Autor

F5

Weitere Blogbeiträge von F5