QUIC

QUIC est un protocole de la couche transport qui a été initié par Jim Roskind chez Google. Il a été repris par l'IETF en 2015 dans le but de le normaliser via les RFC 8999, 9000, 9001 et 9002. L'IETF souhaite notamment normaliser ce protocole de communication pour le rendre utilisable par n'importe quel protocole de la couche application. Les acteurs impliqués veulent que QUIC soit plus que "HTTP sur UDP", là où Google désirait prioriser le web. Initialement QUIC signifiait « Quick UDP Internet Connections », mais l'IETF ne le considère pas comme un acronyme et il n'y en a aucune trace dans les RFC. Ce protocole a pour but de remplacer TCP[1] (HTTP/3), il en reprend d'ailleurs la plus grande partie des fonctionnalités comme la réémission des paquets perdus et le contrôle de congestion, ce qui lui a valu le surnom de TCP/2[2].

Il ajoute plusieurs nouvelles fonctionnalités telles qu'une ré-émission des paquets perdus non bloquante, une gestion de la couche transport par l'application et non par le noyau, un chiffrement TLS complet obligatoire là où il est optionnel avec TCP. Cet ajout du protocole TLS au sein de QUIC lui permet également un handshake TLS plus rapide (3 messages contre 6 pour TCP). Par construction, il lutte également contre l'ossification. QUIC est encapsulé dans UDP afin de pouvoir passer les équipements intermédiaires. En effet, la plupart de ces équipements n'autorise que le trafic connu (donc TCP ou UDP).

Présentation

Flux (Stream)

Un flux de données dans le protocole QUIC est une liste ordonnée d'octets. Un flux est créé au sein d'une connexion et est identifié par un stream ID mais chaque flux est indépendant et peut échanger des données en concurrence des autres. Contrairement au protocole TCP qui assure l'ordre d'arrivé des paquets pour la connexion entière, les flux QUIC ne dépendent pas de la bonne transmission des autres flux.

Un flux peut être unidirectionnel ou bidirectionnel[3]. Dans un flux unidirectionnel, seul le créateur peut envoyer des données et le receveur renvoie des acquittements et des messages d'erreur.

Le flux fragmenté dans des paquets UDP est reconstitué dans l'ordre grâce à un offset. L’ordonnancement des paquets d'un flux reçus est optionnel[4] selon l'implémentation et les usages.

Connexion

Une connexion est un état partagé entre le serveur et le client. La partie qui initie la connexion est appelée le client. Elle établit les paramètres nécessaires aux communications chiffrées.

Une connexion possède plusieurs connection IDs[5]. Cet identifiant permet à chaque partie d'identifier la source des paquets et les paramètres de la connexion. La présence de plusieurs identifiants dissimule à un observateur extérieur que les paquets proviennent d'un même émetteur pour un même receveur. Il reste néanmoins l'adresse IP et le port de la connexion UDP.

Les identifiants de connexion sur des paquets UDP autorise le réseau à changer d'adresse IP pendant la connexion. L'utilisateur peut basculer entre plusieurs réseaux WIFI ou téléphonique sans déconnexion. Le protocole TCP oblige la déconnexion et la création d'une nouvelle connexion quand l'adresse IP est différente.

Détails du protocole

Les communicants QUIC s’échangent des paquets QUIC (QUIC packet) (Section 12) qui sont transportés par les datagrammes UDP. L’en-tête des paquets contient les informations d’expéditeur et destinataire et le minimum requis pour décrypter le reste du paquet. Certains types de paquets contiennent un ou plusieurs frames (Section 12.4) qui sont des opérations de contrôle de la connexion (ex: ACK) ou des conteneurs de données (ex: STREAM).

Le paquet de type 1-RTT n’est utilisable qu’après établissement d’une connexion. Il ne contient pas l’identifiant de la connexion expéditrice car l’identifiant destinataire identifie la connexion. Toutes les données après l’adresse de destination peuvent être chiffrée[6]. Le champ Payload contient une liste de frames.

1-RTT Packet {
  Header Form (1) = 0,
  Fixed Bit (1) = 1,
  Spin Bit (1),
  Reserved Bits (2),
  Key Phase (1),
  Packet Number Length (2),
  Destination Connection ID (0..160),
  Packet Number (8..32),
  Packet Payload (8..),
}

Notes et références

Nathan Willis, « Connecting on the QUIC », lwn.net (consulté le 30 mai 2021)
Tatsuhiro Tsujikawa, « Call it TCP/2. One More Time. », github.com (consulté le 2 décembre 2021)
(en) RFC 9000 (lire en ligne), section 2.1
(en) RFC 9000 (lire en ligne), section 2.2
(en) RFC 9000 (lire en ligne), section 5.1
(en) M. Thomson et S. Turner, « Using TLS to Secure QUIC » [html], mai 2021 (ISSN 2070-1721)

Annexes

Bibliographie

[Bortzmeyer 2021] Stéphane Bortzmeyer, « Le protocole QUIC désormais normalisé », Blog de Stéphane Bortzmeyer,‎ 28 mai 2021 (lire en ligne) ;
[Ghedini 2018] (en) Alessandro Ghedini, « The Road to QUIC », The Cloudflare Blog,‎ 26 juillet 2018 (lire en ligne) ;
[Stenberg 2020] Daniel Stenberg (trad. de l'anglais), HTTP/3 expliqué [« HTTP/3 explained »], 2020 (lire en ligne).

Liens externes

[vidéo] Capitole du Libre, Le protocole QUIC, ou la nouvelle couche de transport — Stéphane Bortzmeyer sur YouTube, 20 novembre 2019 (consulté le 30 août 2022).

Cet article est issu de wikipedia. Text licence: CC BY-SA 4.0, Des conditions supplémentaires peuvent s’appliquer aux fichiers multimédias.