17. Formats de paquets
17. Formats de paquets
Toutes les valeurs numériques sont codées dans l'ordre des octets réseau (c'est-à-dire, big-endian) et toutes les tailles de champs sont en bits. La notation hexadécimale est utilisée pour décrire la valeur des champs.
17.1 Codage et décodage des numéros de paquet
Les numéros de paquet sont des entiers dans la plage de 0 à 2^62-1 (Section 12.3). Lorsqu'ils sont présents dans un paquet, ils sont codés en 1 à 4 octets. Le nombre de bits nécessaires pour représenter le numéro de paquet est réduit en n'incluant que les bits les moins significatifs du numéro de paquet.
Le numéro de paquet codé est protégé comme décrit dans la Section 5.4 de [QUIC-TLS].
L'expéditeur DOIT utiliser une taille de numéro de paquet capable de représenter plus du double de la différence entre le plus grand numéro de paquet accusé réception et le numéro de paquet envoyé. Un pair recevant le paquet décodera alors correctement le numéro de paquet, à moins que le paquet ne soit retardé en transit de sorte qu'il arrive après que de nombreux paquets numérotés plus haut ont été reçus.
En conséquence, la taille du codage du numéro de paquet est au moins un de plus que le logarithme en base 2 du nombre de numéros de paquet contigus non accusés réception, y compris le nouveau paquet.
17.2 Paquets à en-tête long
Les en-têtes longs sont utilisés pour les paquets envoyés avant l'établissement des clés 1-RTT. Une fois que les clés 1-RTT sont disponibles, un expéditeur passe à l'envoi de paquets utilisant l'en-tête court (Section 17.3). La forme longue permet aux paquets spéciaux -- tels que le paquet de négociation de version -- d'être représentés dans ce format de paquet uniforme à longueur fixe.
Les paquets avec des en-têtes longs sont identifiés par le bit de forme d'en-tête étant défini à 1.
17.2.1 Paquet de négociation de version
Un paquet de négociation de version n'est intrinsèquement pas spécifique à une version. Lors de la réception par un client, il sera identifié comme un paquet de négociation de version basé sur le champ Version ayant une valeur de 0.
17.2.2 Paquet Initial
Un paquet Initial utilise des en-têtes longs avec une valeur de type de 0x00. Il transporte les premières trames CRYPTO envoyées par le client et le serveur pour effectuer l'échange de clés, et il transporte des trames ACK dans les deux directions.
17.2.3 0-RTT
Un paquet 0-RTT utilise des en-têtes longs avec une valeur de type de 0x01. Un paquet 0-RTT a un espace de numéros de paquet (Section 12.3) d'ApplicationData.
17.2.4 Paquet Handshake
Un paquet Handshake utilise des en-têtes longs avec une valeur de type de 0x02. Il est utilisé pour transporter des messages de négociation cryptographique et des accusés de réception du serveur et du client.
17.2.5 Paquet Retry
Un paquet Retry utilise un en-tête de paquet long avec une valeur de type de 0x03. Il transporte un jeton de validation d'adresse créé par le serveur. Il est utilisé par un serveur qui souhaite effectuer un réessai (voir Section 8.1).
17.3 Paquets à en-tête court
Cette version de QUIC définit un seul type de paquet qui utilise l'en-tête de paquet court.
17.3.1 Paquet 1-RTT
Un paquet 1-RTT utilise un en-tête de paquet court. Il est utilisé après que la version et les clés 1-RTT sont négociées.
17.4 Bit de rotation de latence
Le bit de rotation de latence, situé au bit 0x20 de l'en-tête court, permet la surveillance passive de la latence à partir de points d'observation sur le chemin réseau. Le bit de rotation n'est présent que dans l'en-tête de paquet court, car il est possible de mesurer le RTT initial d'une connexion en observant la négociation. Par conséquent, le bit de rotation est disponible après que la négociation de version et l'établissement de connexion sont terminés.