Unmittelbar nach dem ersten Aufbau einer Verbindung sendet der Initiator einen Krypto-Frame, der mit dem Einrichten des Handshakes der Sicherheitsschicht beginnt. Die Sicherheitsschicht verwendet TLS 1.3.

Es gibt keine Möglichkeit, TLS bei eine QUIC-Verbindung zu deaktivieren oder zu vermeiden. Das Protokoll ist so konzipiert, dass es für Middleboxen schwer zu manipulieren ist, um eine Ossifikation des Protokolls zu verhindern.

In diesem Abschnitt wird beschrieben, wie die grundlegenden Bausteine des QUIC-Transportprotokolls funktionieren, ohne dabei auf alle Bits und Bytes einzugehen. Wenn du deinen eigenen QUIC-Stack implementieren möchtest, sollte dir diese Beschreibung ein allgemeines Verständnis vermitteln. Alle Details findest du in den aktuellen IETF Internet-Entwürfen und RFCs.

1. Eine Verbindung aufbauen

2. ... die TLS inkludiert

3. und dann verwendet

QUIC Streams bieten eine einfache, geordnete Byte-Stream-Abstraktion.

In QUIC gibt es zwei grundlegende Arten von Streams:

• Unidirektionale Streams übertragen Daten in eine Richtung: vom Initiator des Streams zu seinem Peer.

• Bidirektionale Streams ermöglichen das Senden von Daten in beide Richtungen.

Jeder Stream-Typ kann von jedem Endpunkt erstellt werden, gleichzeitig mit anderen Streams verschachtelte Daten senden und abgebrochen werden.

Eine QUIC-Verbindung ist eine einzelne Konversation zwischen zwei QUIC-Endpunkten. Der Verbindungsaufbau von QUIC kombiniert die Versionsaushandlung mit den kryptografischen und Transport-Handshakes, um die Latenz beim Verbindungsaufbau zu verringern.

Um tatsächlich Daten über eine solche Verbindung zu senden, müssen ein oder mehrere Streams erstellt und verwendet werden.

Verbindungs-ID

Jede Verbindung verfügt über eine Reihe von Verbindungskennungen oder Verbindungs-IDs, von denen jede zur Identifizierung der Verbindung verwendet werden kann. Verbindungs-IDs werden unabhängig von den Endpunkten ausgewählt; jeder Endpunkt wählt die Verbindungs-IDs aus, die sein Peer verwendet.

Die Hauptfunktion dieser Verbindungs-IDs besteht darin, sicherzustellen, dass Änderungen in der Adressierung auf niedrigeren Protokollschichten (UDP, IP und darunter) nicht dazu führen, dass Pakete einer QUIC-Verbindung an den falschen Endpunkt gesendet werden.

Durch die Nutzung der Verbindungs-ID können Verbindungen auf eine Weise zwischen IP-Adressen und Netzwerkschnittstellen migrieren, wie dies TCP niemals könnte. Durch die Migration kann beispielsweise ein laufender Download von einer Mobilfunkverbindung zu einer schnelleren WLAN-Verbindung geändert werden, wenn der Benutzer sein Gerät an einen Standort mit WLAN-Verbindung bringt. Ebenso kann der Download über die Mobilfunkverbindung erfolgen, wenn das WLAN nicht mehr verfügbar ist.

Portnummern

QUIC ist auf UDP aufgebaut, daher wird ein 16-Bit-Portnummernfeld verwendet, um eingehende Verbindungen zu unterscheiden.

Versionsaushandlung

Eine von einem Client stammende QUIC-Verbindungsanforderung teilt dem Server mit, welche QUIC-Protokollversion er sprechen möchte. Der Server antwortet mit einer Liste der unterstützten Versionen, aus denen der Client auswählen kann.

Einer der Erfolgsfaktoren von regulärem TCP und Programmen, die dieses verwenden, ist die standardisierte Socket-API. Sie verfügt über gut definierte Funktionen und ermöglicht ein Verschieben von Programmen zwischen vielen verschiedenen Betriebssystemen, da TCP überall gleich funktioniert.

QUIC ist nicht so weit. Es gibt keine Standard-API für QUIC.

Bei QUIC muss eine der vorhandenen Implementierungen ausgewählt werden, bei deren API man bleiben muss. Dadurch werden Anwendungen bis zu einem gewissen Grad an eine einzelne Bibliothek "gebunden". Das Wechseln zu einer anderen Bibliothek bedeutet eine andere API und kann viel Arbeit erfordern.

Da QUIC normalerweise im User-space implementiert wird, kann es die Socket-API nicht einfach erweitern oder der vorhandenen TCP- und UDP-Funktionalität ähneln. Die Verwendung von QUIC bedeutet die Verwendung einer anderen API als der Socket-API.

Um die zum Herstellen einer neuen Verbindung erforderliche Zeit zu verkürzen, kann ein Client, der zuvor eine Verbindung zu einem Server hergestellt hat, bestimmte Parameter dieser Verbindung zwischenspeichern und anschließend eine 0-RTT-Verbindung mit dem Server herstellen. Auf diese Weise kann der Client Daten sofort senden, ohne auf den Abschluss eines Handshakes warten zu müssen.

Eine der vielleicht längsten Designdiskussionen innerhalb der QUIC-Arbeitsgruppe - Gegenstand von mehreren hundert Mails und stundenlangen Diskussionen - betrifft ein einziges Bit: das Spin Bit.

Die Befürworter dieses Bits bestehen darauf, dass Operatoren und Personen zwischen zwei QUIC-Endpunkten die Latenz messen können.

Die Gegner dieser Funktion mögen das potenzielle Informationsleck nicht.

Ein Bit drehen

Beide Endpunkte, der Client und der Server, behalten für jede QUIC-Verbindung den Spin-Wert 0 oder 1 bei und setzen das Spin Bit für Pakete, die für diese Verbindung gesendet werden, auf den entsprechenden Wert.

Die Implementierung eines Transportprotokolls im User-space ermöglicht eine schnelle Iteration des Protokolls, da das Protokoll vergleichsweise einfach weiterentwickelt werden kann, ohne dass Clients und Server ihren Betriebssystemkern aktualisieren müssen, um neue Versionen bereitzustellen.

QUIC gibt nichts vor, dass eine zukünftige Implementierung in Betriebssystemkernen verhindern könnte - sollte jemand dies für eine gute Idee halten.

Viele Implementierungen

Ein offensichtlicher Effekt der Implementierung eines neuen Transportprotokolls im User-space besteht darin, dass wir viele unabhängige Implementierungen erwarten können.

Verschiedene Anwendungen werden wahrscheinlich auf absehbare Zeit unterschiedliche HTTP/3- und QUIC-Implementierungen inkludieren, oder auf solchen aufbauen.