Le protocole de transport QUIC est désormais normalisé

Mais pour comprendre le rôle que joue QUIC sur l’Internet, il faut d’abord réviser un peu à quoi sert un protocole de transport. Si vous avez suivi des cours de réseau informatique et que vous avez eu du mal à assimiler le modèle en couches dit « OSI », ne vous inquiétez pas. Ce modèle est juste un modèle, il est pratique pour, par exemple, découper en chapitres un cours, mais il n’est pas nécessaire dans les vrais réseaux. Ce qu’il faut retenir est simplement que, pour que vous puissiez lire cet article sur le Web, il a fallu plusieurs services sur le trajet, qu’on place en général en couches successives, les couches les plus hautes étant les plus proches de l’utilisateur. Ainsi, la couche Application, c’est le navigateur Web que vous utilisez en ce moment, la couche Physique, ce sont les câbles que vous pouvez toucher. Entre les deux, l’Internet utilise deux couches importantes, la couche Réseau qui est chargée d’acheminer des petites unités d’information, les paquets, et la couche Transport, qui reconstitue des données utiles pour les humains à partir de ces paquets. La couche réseau de l’Internet est le protocole IP (Internet Protocol). Les paquets qu’elle gère, issus du découpage des données envoyées, peuvent ne pas arriver (un réseau physique ne peut jamais garantir que tout se passera bien) ou arriver dans le désordre. On ne peut donc pas utiliser directement ce que fournit la couche Réseau. On va ajouter une couche dite Transport, qui se charge de vérifier que tous les paquets arrivent, de les redemander s’il en manque, et de remettre ces paquets dans l’ordre. L’Internet permet la coexistence de plusieurs protocoles de transport puisque c’est une affaire uniquement entre les deux machines qui communiquent. Mais, traditionnellement, c’est le protocole TCP (Transmission Control Protocol) qui dominait. Il est utilisé par la grande majorité des applications, les principales exceptions étant le DNS (Domain Name System) et certaines applications audio et vidéo. C’est en raison de ce poids de TCP que l’ensemble des protocoles qui font fonctionner l’Internet est souvent nommé « TCP/IP ».

TCP est un chef d’œuvre d’ingénierie qui, depuis quarante ans, a fait circuler des quantités colossales de données dans l’Internet, et tourne sur toutes les machines, de l’ordiphone bas de gamme au très gros serveur. Mais les évolutions de l’Internet ont montré des limites à TCP, au moins pour certains usages. D’où le développement, ces dernières années, du protocole QUIC (c’est un nom, pas un acronyme, donc je ne le développerai pas). Celui-ci est désormais normalisé, dans quatre documents, les RFC (Request for Comments) 8999, 9000, 9001 et 9002. Comme QUIC est un protocole de transport, pas d’application, l’utilisateur ordinaire ne verra pas de différence évidente, mais, derrière son écran, les changements pourront avoir des conséquences importantes.

Que fait QUIC de différent de TCP ? Il existe de nombreuses différences entre les deux protocoles, que je ne peux pas toutes citer ici. Concentrons-nous sur les principales et d’abord le chiffrement. Compte-tenu de l’ampleur de la surveillance exercée sur l’Internet par de nombreux acteurs, le chiffrement est un outil indispensable à la sécurité. Actuellement, quand on utilise TCP, il est en général assuré par le protocole TLS (Transport Layer Security). Les deux machines qui communiquent doivent d’abord établir une session TCP puis seulement après une session TLS. Cela accroit donc la latence, le temps de réponse et cette latence est souvent le facteur dominant dans la perception par l’utilisateur que « ça rame » (alors que les publicités mettent plutôt en avant la capacité du réseau, sans jamais parler de la latence). Au contraire de TCP, QUIC fusionne le transport et le chiffrement. QUIC n’est jamais en clair, tout est systématiquement chiffré, et l’établissement de la session chiffrée se fait en même temps que celui de la session de transport, diminuant la latence. Notons aussi que, toujours pour gêner la surveillance, QUIC chiffre même une partie de son propre fonctionnement, que TCP laissait en clair.

QUIC augmente également le parallélisme de la communication, ce qui est surtout intéressant pour le Web. En effet, une seule page Web peut déclencher automatiquement le chargement de nombreuses ressources, comme les feuilles de style ou les images. TCP obligeait à les télécharger l’une après l’autre, augmentant la latence, ou bien à ouvrir plusieurs sessions TCP, qui ne pouvaient alors plus partager les calculs complexes que nécessite le bon fonctionnement de la couche Transport. QUIC permet, à l’intérieur d’une même session, le chargement de plusieurs ressources, sans que la lenteur de l’une ne ralentisse les autres.

Enfin (mais rappelez-vous que QUIC a bien d’autres fonctions, que je ne peux pas toutes présenter ici), QUIC permet le changement d’adresse IP en pleine session, par exemple si un ordiphone passe de 4G à WiFi ou réciproquement, les sessions QUIC en cours ne sont pas interrompues.

QUIC est un protocole de transport, pas d’application. Pour les usages typiques, comme le Web, il faut lui ajouter des protocoles d’application. Dans le cas du Web, ce sera la nouvelle version de HTTP (HyperText Transfer Protocol), HTTP/3, qui sera la première version à tourner sur QUIC. Sa normalisation est actuellement en cours de finalisation. Là encore, si vous êtes simple utilisateur ou utilisatrice, vous n’aurez rien à changer à vos habitudes, le fonctionnement extérieur sera le même. Le client HTTP/3 (votre navigateur) sait parler HTTP/3 ou bien se rabattre automatiquement sur une ancienne version de HTTP si le serveur distant ne connaît pas HTTP/3 ou si un pare-feu trop zélé bloque QUIC.

Le développement de QUIC a commencé il y a plusieurs années et, aujourd’hui, plusieurs services, comme ceux de Google, sont déjà accessibles avec QUIC. Les navigateurs Web Chrome et Firefox ont déjà QUIC, quoique pas forcément dans la version installée sur votre machine, il faudra peut-être attendre un peu. Le déploiement effectif de QUIC va se faire dans les années qui viennent mais, évidemment, il n’est pas prévu de remplacer complètement TCP, qui continuera à bien servir l’Internet comme il le fait depuis 1981, date de parution de sa norme.

Et à l’Afnic ? Rappelez-vous que QUIC est surtout conçu pour le Web et optimisé pour lui. Des services comme EPP (Extensible Provisioning Protocol, présenté dans mon article sur l’enregistrement des noms de domaine) qui n’ont pas de demande pour le parallélisme (au contraire, ils doivent respecter l’ordre des requêtes) ou pour la latence réduite (puisque les sessions EPP sont typiquement très longues) n’ont pas spécialement besoin de QUIC. Le DNS, lui, pourrait utiliser le parallélisme de QUIC, et un DNS tournant sur QUIC est en cours de normalisation (l’Afnic y participe, dans le cadre de son implication dans la normalisation ouverte). Ceci dit, DoQ (DNS over QUIC) ne semble pas très proche. Le premier protocole qui profitera de QUIC à l’Afnic sera peut-être plutôt RDAP (Registration Data Access Protocol, le successeur de whois), qui tourne sur HTTP et, lui, pourrait tirer profit du parallélisme et de la réduction de la latence. Mais rien n’est encore décidé, les bibliothèques logicielles permettant de faire du QUIC ne sont pas encore très disponibles dans les versions stables des systèmes d’exploitation typiques.

En résumé, nous voici à l’aube d’une nouvelle ère, qui verra peut-être le protocole de transport dominant de l’Internet changer. Ce n’est pas si fréquent !

Retrouvez Stéphane Bortzmeyer pour un tutoriel sur QUIC le 31/08/2021 lors de la JCSA21