QUIC
Cet article est une ébauche concernant Internet.
Vous pouvez partager vos connaissances en l’améliorant (comment ?) selon les recommandations des projets correspondants.
QUIC est un protocole de transport fiable et sécurisé, en mode connecté, mis au point par Jim Roskind employé chez Google.
Il est repris par l'IETF en 2015 dans le but de le normaliser par les RFC 8999, 9000, 9001 et 9002 et le rendre ainsi 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ésire prioriser le web. Initialement QUIC signifie « 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.
Le protocole est destiné à remplacer TCP[1] (HTTP/3) dont il reprend la plus grande partie des fonctionnalités comme la réémission des paquets perdus et le contrôle de congestion, ce qui lui vaut le surnom de TCP/2[2].
QUIC ajoute de 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 alors qu'il est optionnel avec TCP. Cet ajout du protocole TLS au sein de QUIC permet également un handshake TLS plus rapide avec trois messages contre six pour TCP. Par construction, il lutte également contre l'ossification. QUIC est encapsulé dans UDP afin de pouvoir passer les équipements intermédiaires qui n'autorisent que le trafic connu comme TCP ou UDP.
Présentation
[modifier | modifier le code]Terminologies
[modifier | modifier le code]Flux (Stream)
[modifier | modifier le code]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ée 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
[modifier | modifier le code]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
[modifier | modifier le code]
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écoder 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..),
}
Connexions
[modifier | modifier le code]Création
[modifier | modifier le code]Fermeture
[modifier | modifier le code]Streams
[modifier | modifier le code]Création
[modifier | modifier le code]Erreurs
[modifier | modifier le code]Fermeture
[modifier | modifier le code]Notes et références
[modifier | modifier le code]- Nathan Willis, « Connecting on the QUIC », lwn.net (consulté le )
- Tatsuhiro Tsujikawa, « Call it TCP/2. One More Time. », github.com (consulté le )
- (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], (ISSN 2070-1721)
Annexes
[modifier | modifier le code]Bibliographie
[modifier | modifier le code]- [Bortzmeyer 2021] Stéphane Bortzmeyer, « Le protocole QUIC désormais normalisé », Blog de Stéphane Bortzmeyer, (lire en ligne). ;
- [Ghedini 2018] (en) Alessandro Ghedini, « The Road to QUIC », The Cloudflare Blog, (lire en ligne). ;
- [Stenberg 2020] Daniel Stenberg (trad. de l'anglais), HTTP/3 expliqué [« HTTP/3 explained »], (lire en ligne).
Liens externes
[modifier | modifier le code]- [vidéo] Capitole du Libre, « Le protocole QUIC, ou la nouvelle couche de transport — Stéphane Bortzmeyer », sur YouTube, (consulté le ).
