17. Paketformate
17. Paketformate
Alle numerischen Werte werden in Netzwerk-Byte-Reihenfolge (d. h. Big-Endian) codiert, und alle Feldgrößen sind in Bits angegeben. Hexadezimal-Notation wird zur Beschreibung des Werts von Feldern verwendet.
17.1 Paketnummer-Codierung und -Decodierung
Paketnummern sind Ganzzahlen im Bereich von 0 bis 2^62-1 (Abschnitt 12.3). Wenn sie in einem Paket vorhanden sind, werden sie in 1 bis 4 Bytes codiert. Die Anzahl der Bits, die zur Darstellung der Paketnummer erforderlich sind, wird reduziert, indem nur die niedrigstwertigen Bits der Paketnummer enthalten sind.
Die codierte Paketnummer wird wie in Abschnitt 5.4 von [QUIC-TLS] beschrieben geschützt.
Der Sender MUSS eine Paketnummerngröße verwenden, die in der Lage ist, einen Bereich darzustellen, der mehr als doppelt so groß ist wie die Differenz zwischen der größten bestätigten Paketnummer und der zu sendenden Paketnummer. Ein Peer, der das Paket empfängt, wird dann die Paketnummer korrekt decodieren, es sei denn, das Paket wird während der Übertragung so verzögert, dass es nach vielen höher nummerierten Paketen ankommt.
Als Ergebnis ist die Größe der Paketnummer-Codierung mindestens eins mehr als der Basis-2-Logarithmus der Anzahl zusammenhängender unbestätigter Paketnummern, einschließlich des neuen Pakets.
17.2 Long-Header-Pakete
Long-Header werden für Pakete verwendet, die vor der Etablierung von 1-RTT-Schlüsseln gesendet werden. Sobald 1-RTT-Schlüssel verfügbar sind, wechselt ein Sender zum Senden von Paketen mit dem Short-Header (Abschnitt 17.3). Die Long-Form ermöglicht es, dass spezielle Pakete -- wie das Version-Negotiation-Paket -- in diesem einheitlichen Paketformat mit fester Länge dargestellt werden.
Pakete mit Long-Headern werden durch das Header-Form-Bit identifiziert, das auf 1 gesetzt ist.
17.2.1 Version-Negotiation-Paket
Ein Version-Negotiation-Paket ist inhärent nicht versionsspezifisch. Bei Empfang durch einen Client wird es als Version-Negotiation-Paket identifiziert, basierend darauf, dass das Versionsfeld einen Wert von 0 hat.
17.2.2 Initial-Paket
Ein Initial-Paket verwendet Long-Header mit einem Typwert von 0x00. Es trägt die ersten CRYPTO-Frames, die vom Client und Server zum Durchführen des Schlüsselaustauschs gesendet werden, und es trägt ACK-Frames in beide Richtungen.
17.2.3 0-RTT
Ein 0-RTT-Paket verwendet Long-Header mit einem Typwert von 0x01. Ein 0-RTT-Paket hat einen Paketnummernraum (Abschnitt 12.3) von ApplicationData.
17.2.4 Handshake-Paket
Ein Handshake-Paket verwendet Long-Header mit einem Typwert von 0x02. Es wird verwendet, um kryptografische Handshake-Nachrichten und Bestätigungen vom Server und Client zu übertragen.
17.2.5 Retry-Paket
Ein Retry-Paket verwendet einen Long-Paket-Header mit einem Typwert von 0x03. Es trägt ein vom Server erstelltes Adressvalidierungs-Token. Es wird von einem Server verwendet, der einen Retry durchführen möchte (siehe Abschnitt 8.1).
17.3 Short-Header-Pakete
Diese Version von QUIC definiert einen einzelnen Pakettyp, der den Short-Paket-Header verwendet.
17.3.1 1-RTT-Paket
Ein 1-RTT-Paket verwendet einen Short-Paket-Header. Es wird verwendet, nachdem die Version und 1-RTT-Schlüssel ausgehandelt wurden.
17.4 Latency-Spin-Bit
Das Latency-Spin-Bit, das sich an Bit 0x20 des Short-Headers befindet, ermöglicht passives Latenz-Monitoring von Beobachtungspunkten auf dem Netzwerkpfad. Das Spin-Bit ist nur im Short-Paket-Header vorhanden, da es möglich ist, die initiale RTT einer Verbindung durch Beobachtung des Handshakes zu messen. Daher ist das Spin-Bit verfügbar, nachdem Versionsaushandlung und Verbindungsaufbau abgeschlossen sind.