Was ist QUIC?

Es passiert selten, dass ein neue Protokoll auf IP-Basis eingeführt wird. Bislang waren ICMP, UDP und TCP die beherrschenden höheren Protokolle. QUIC wurde am 27. Mai 2021 als Version 1.0 veröffentlicht. Der Name ist angeblich eine Abkürzung von "Quick UDP Internet Connections". Andere sagen einfach HTTP/3 dazu.

Einordnung

QUIC ist im Grunde eine neue Art Pakete über das Internet zu übertragen, welche die Vorteile von UDP und TCP kombiniert und einige Nachteiler von HTTP/1 und HTTP2 ausmerzt. Wer noch Bilder des OSI-Schichtenmodel kennt, wird hier Ähnlichkeiten erkennen. Wir starten aber bei IP und halten und nicht mit den physikalischen Schichten darunter auf. Basierend auf IP setzen weitere Protokolle aus, die uns allen gut bekannt sein sollten.

  • ICMP
    Die meisten werden ICMP von den Programmem PING und TRACEROUTE kennen aber ICMP ist mehr. Damit signalisieren auch Router und Hosts, wenn System nicht erreichbar sind (ICMP not reachable), Pakete fragmentiert werden müssen oder es keinen Leitweg gibt
  • UDP
    Das "leichtere" UDP wird primär für Informationen wie Audio/Video genutzt, bei denen verlorene oder verzögerte Pakete unterschlagen werden können und wenig Einfluss auf die Qualität haben. Es würde eher stören, den Fluss anzuhalten, bis ein verlorenes Paket nachgeliefert würde.
  • TCP
    TCP hingegen ist das klassische Protokoll zur fehlerfreien Übertragung binärer Daten. TCP stellt sicher, dass alle Pakete unverändert, in der richtigen Reihenfolge und verlustfrei übertragen werden. Notfalls fordert der TCP-Stack fehlende Pakete solange neu an, bis die Daten vorliegen. Damit dies funktioniert, gibt es einen Handshake zu Beginn, in dem sich die Endpunkte über verschiedene Parameter abstimmen.

Da bei der Übertragung von Daten in der Regle weder Verluste noch Veränderungen erlaubt sind, bedienen sich die meisten Protokolle wie SMTP, HTTP, SMB FTP etc. dem transportgesicherten Protokoll TCP. Für die Verschlüsselung müssen die Dienste allerdings selbst sorgen und z.B. über die bestehende TCP-Verbindung eine TLS-Verbindung aufbauen. Oben drauf sitzt dann ein Browser, der per HTTP die Inhalte überträgt und anzeigt.

Über die "Socket"-Schnittstelle können Anwendungen frei den gewünschten Transport wählen. Allerdings ist QUIC nicht Bestandteil der SOCKETS-Schnittstelle und läuft zusätzlich im Userspace und nicht mehr im Kernel. Es dürfte also wieder mehrere QUIC-Bibliotheken unterschiedlicher Hersteller für unterschiedliche Betriebssysteme geben. Das macht die Fehlersuche nicht unbedingt einfacher und als Softwareentwickler müssen Sie sich damit neu beschäftigen. Zum Glück wird QUIC auf dem Client von Google, Microsoft etc. als Teil des Browser umgesetzt und auf der Serverseite dürfte die Arbeit bei den Webentwicklern (Apache, nginx, IIS) oder der Content Delivery Networks liegen. Insofern ist QUIC eher für "Netzwerker" und "Administratoren" ein Thema.

Die TLS-Verschlüsselung liefert bei Windows z.B. SCHANNEL.DLL mit der CryptoAPI und die HTTP/1,HTTP/2-Übertragung kann man sich den .NET Libraries (Siehe PowerShell als HTTP-Client und PowerShell als HTTPServer) bedienen. QUIC und HTTP/3 sind aktuell noch Funktionen der Browser und Webserver. Ich habe noch nicht gesehen, dass QUIC z.B. Einzug in SYSTEM.HTTP erhält. Das erwarte ich aber auch nicht, wenn Sie sich den QUIC Handshake anschauen. Das bleibt Aufgabe des Browsers . Damit obliegt es auch dem Client, zwischen den Protokollen auszuwählen und ggfls. zu wechseln.

Die HTTP/3-Payload wird durch einen HTTP/3-Header umspannt, der seinerseits in QUIC-Frame und und dann im QUIC Paket enthalten ist, welches per UDP über den IP-Stack übertragen wird. QUIC unterscheidet noch die eigentlichen Pakete mit einer laufenden Nummer und Frames:

Nun wissen wir aus dem TCP-Stack, dass neben der Src-IP/Dst-IP und Port auch noch Sequence-Nummern, Prüfsummern etc. übertragen werden, um eine fehlerfreie Übertragung zu gewährleisten. UDP ist "verbindungslos" und daher muss QUIC diese Flusskontrolle etc. übernehmen. Im Vergleich zu TCP wird es erst einmal nicht viel weniger.

Der Vorteil ist von QUIC liegt nicht in der Reduzierung von Datenmengen.

QUIC Verbindungsaufbau

Das funktioniert seid Jahrzehnten eigentlich super aber ehe Sie fragen, warum das nun nicht mehr ausreicht und Google schon 2014 an einem Vorläufer von QUIC gearbeitet hat, möge über folgende Problematik nachdenken:

  1. Ein Anwender gibt im Browser eine Adresse wie z.B. https://www.msxfaq.de ein. Der Browser löst den Namen per DNS auf.
  2. TCP-Connection mit NAT
    Der Browser baut eine TCP-Verbindung zu Server auf. Ein Router muss dazu eine TCP-Connection und NAT einrichten und der Server darauf antworten. Das ist ein klassischer Handshake mit drei Paketen (Siehe auch TCP SYN ACK RES).
  3. TLS-Handshake
    Dann muss der Browser eine TLS-Verbindung starten, indem er ein Client-HELLO sendet, welche der Server per Server-HELLO und Zertifikat bestätigt und dann die ausgehandelten Parameter bestätigt werden. (Siehe auch TLS Handshake mit NetMon)
  4. HTTP-Request
    Erst danach kann der Client die gewünschte Seite, z.B. "index.htm" anfordern und bekommt diese Datei über die bestehende Verbindung.
  5. Weitere Dateien
    Der Browser rendert die Seite und erkennt, dass er noch weiter Informationen (Bilder, Stylesheet, JavaScript etc. nachladen muss) Damit es schneller geht, baut er weitere TCP-Verbindungen auf, die einen NAT-Port und einen TLS-Handshare benötigen.

Es ist gut zu erkennen, dass schon der Verbindungsaufbau aus vielen Paketen besteht und viele Ressourcen belegt. Viele Dinge sind einfach auch der Rückwärtskompatibilität geschuldet. Bei QUIC wird nur eine UDP-Verbindung aufgebaut und da TLS 1.3 vorausgesetzt wird, brauchten wir auch keine aufwändigen Handshakes zum Aushandeln von Cipher-Suites und TLS-Versionen, die auf alle alten Clients Rücksicht nehmen müssten.

Der QUIC-Aufbau kann schon nach einem Roundtrip etabliert sein.

HTTP/3 vs. HTTP/1 oder HTTP/2

Interessant wird dies nun mit der Kombination der drei HTTP-Definitionen. Eine Webseite wird als HTML-Datei bereitgestellt aber das Übertragungsprotokoll ist HTTP. QUIC ist immer HTTP/3, während HTTP/1 und HTTP/2 auf TCP basieren. Aber was ist der Unterschied von HTTP/3 zu HTTP/1 und HTTP/2?

Version Connections TLS Bild

 

HTTP/1 over TCP

Die soeben beschrieben baut der HTTP-Client eine Verbindung auf und für weitere Dateien werden weitere Verbindungen geöffnet. Das "kostet" viel Handshake und viele TCP-Connections, was sowohl auf dem Webserver aber auch auf Firewalls, Proxy-Server und NAT-Router nachteilig ist. Allerdings ist jede Verbindung unabhängig und ein Paketverlust behindert nur diese Verbindung. Das Problem ist noch größer, wenn eine Webseite viele Inhalte von anderen Servern bezieht, insbesondere die Tracker von Werbefirmen.

mehrere TCP

 Ohne
SSL3
1.0
1.1
1.2

 

HTTP/2 over TCP

Die "Viele Connections"-Probleme löst HTTP/2 so, dass in einer physikalischen Verbindung mehrere logische Verbindungen kombiniert werden. Der Download mehrerer Bilder, CSS-Dateien etc. erfolgt miteinander. Wir sparen Verbindungen, den Aufbau per TCP und den TLS Handshake. Auf die Authentifizierung hat dies keinen Einfluss. Beim Webserver kann ein Thread sich alleine um die Session kümmern. Werden Informationen von mehreren Webseiten, z.B. Werbetracker, nachgeladen, dann werden aber auch hier weitere TCP-Connections aufgebaut.

1xTCP

 Ohne
SSL3
1.0
1.1
1.2

 

HTTP/3 oder QUIC

Ich wüsste nicht, dass HTTP/3 auch über TCP geht. Aber mit QUIC wird nun UDP als Transport verwendet. Über eine Connection werden mehrere virtuelle Verbindungen etabliert. Da aber der Transport darunter UDP statt TCP ist, wird im Gegensatz zu HTTP/2 bei einem Paketverlust nicht die komplette Verbindung bis zur Nachlieferung des fehlenden Pakets vom TCP-Stack angehalten, sondern der Empfang geht einfach weiter. Wir haben also den Vorteil einer einzelnen Verbindung ohne den Nachteil von TCP kombiniert.

Im Vergleich zu HTTP/2 haben wir also unabhängige Streams über eine Verbindung und zwingende Verschlüsselung.

1xUDP

1.3

 

Spätestens jetzt sollten Sie verstanden haben, welches Potential in QUIC steckt.

Weitere Vorteile

Damit ist aber immer noch nicht alles gesagt. Es kommen bei QUIC noch weitere Aspekte dazu. Hier daher noch einmal die Aspekte als Auflistung:

  • Connection establishment latency
    Anders als bei TCP mit darauf aufgesetztem TLS ist die Verbindung bei QUIC schon nach zwei Paketen ausgehandelt.
  • Improved congestion control
    QUIC kann nicht nur mehr NACKs (256) gegenüber TCP nutzen sondern adaptiert die Senderate angeblich "besser" als TCP, d.h. die Reaktion auf Paketverlust aber auch wieder das Hochfahren nach Engpässen. Vor einigen Jahren hat Google hier schon mal sich überschätzt und durch die Anpassungen sich einen Vorteil auf Kosten der klassischen TCP-Implementierung verschafft. Das ist dann nicht so gut angekommen.
  • Multiplexing without head-of-line blocking
    Um Connections zu sparen, kann HTTP/2 mehrere logische Verbindungen, über eine reale Connection mischen, was bei Paketverlusten natürlich den "Fluss" stört. Mit UDP kann der Datenfluss weiter gehen, währen die fehlenden Daten nachgefordert werden.
  • Forward error correction (FEC)
    Wenn Paketverluste zunehmen, kann QUIC mehrere Pakete als "Gruppe" definieren und ein zusätzliches "Parity"-Paket senden. Wie bei RAID mit Festplatten kann dann der Verlust eines Pakets der Gruppe über die Parity-Information kompensiert werden.
  • Connection Migration
    Beim klassischen IPv4 ist eine Verbindung anhand der Felder Source-IP, Source-Port, Destination-IP, Destination-Port definiert. Ändert sich die IP-Adresse eines Clients, z.B. durch einen Netzwerkwechsel, Loadbalancer-Schwenk o.ä., dann muss mit TCP die Verbindung neu aufgebaut werden. Bei QUIC generiert der Client eine zufällige 64bit-ConnectionID, über die die Verbindung vom Server immer wieder "erkannt" und ohne Unterbrechung fortgesetzt werden kann.

Die Verbesserungen liegen also nicht nur in einem schnelleren anfänglichen  Aufbau der Verbindung sondern schon an fundamentalen Veränderungen.

Allerdings nutzt QUIC als darunterliegendes Protokoll 80/UDP und 443/UDP, welche in vielen Firewalls bei Firmen wohl nicht geöffnet sein werden. Die Firewalls müssen erst ertüchtigt werden, um diese Verbindungen zu überwachen. Bei privaten Anwendern hinter ihrem Homeoffice-Router dürfte das aber alles kein Problem sein.

Weitere Links