Greboca  

DLFP - Dépêches  -  Le protocole QUIC désormais normalisé

 -  Mai 2021 - 

Le protocole de transport QUIC (couche 4 du modèle OSI) vient d’être normalisé, sous la forme de plusieurs RFC. QUIC, déjà largement déployé, peut changer pas mal de choses sur le fonctionnement de l’Internet, en remplaçant, au moins partiellement, TCP. C’est quoi, QUIC, et à quoi ça sert ? Logo du groupe de travail QUIC

Sommaire

Couche transport

QUIC n’est pas un protocole d’application (couche 7) comme peuvent l’être HTTP ou SSH. Les utilisateurs ordinaires ne verront pas la différence, ils se serviront des mêmes applications, via les mêmes protocoles applicatifs. QUIC est un protocole de transport (couche 4 du traditionnel modèle en couches OSI), donc un concurrent de TCP, dont il vise à résoudre certaines limites, notamment dans le contexte du Web.

Quelles limites ? Pour comprendre, il faut revenir à ce à quoi sert la couche de transport.

Placée entre les paquets d’IP, qui peuvent arriver ou pas, dans l’ordre ou pas, et les applications, qui comptent en général sur un flux d’octets ordonnés, où rien ne manque, la couche transport est chargée de surveiller l’arrivée des paquets, de signaler à l’émetteur qu’il en manque pour qu’il puisse réémettre, et de mettre dans le bon ordre les données. Dit comme ça, cela semble simple, mais cela soulève beaucoup de problèmes intéressants. Par exemple, il ne faut pas envoyer toutes les données sans réfléchir : le réseau n’est peut-être pas capable de les traiter, et un envoi trop brutal pourrait mener à la congestion du réseau. De même, en cas de pertes de paquet, il faut certes ré-émettre, mais aussi diminuer le rythme d’envoi, la perte pouvant être le signal que le réseau est saturé. C’est à la couche transport de gérer cette congestion, en essayant de ne pas la déclencher ou en tout cas de ne pas l’aggraver. En pratique, la couche transport est donc très complexe, comme le montre le nombre de RFC sur TCP.

Maintenant que nous avons révisé les tâches de la couche transport, quelles sont ces limites de TCP dont je parlais, et qui justifient le développement de QUIC ?

Notez d’abord qu’elles ont surtout été mentionnées dans le contexte du Web. Celui-ci pose en effet des problèmes particuliers, notamment le désir d’une faible latence (quand on clique, on veut une réponse tout de suite) et le fait que l’affichage d’une seule page nécessite le chargement de plusieurs ressources (images, vidéos, code JavaScript, CSS, etc). La combinaison de TCP et de TLS n’est pas satisfaisante question latence, puisqu’il faut d’abord établir la connexion TCP, avant de pouvoir commencer la négociation qui mènera à l’établissement de la session TLS. Ensuite, TCP souffre du manque de parallélisme : quand on veut récupérer plusieurs ressources, il faut soit ouvrir plusieurs connexions TCP, qui ne partageront alors plus d’information (délai aller-retour, taux de perte, etc) ou de calculs (cryptographie…), soit multiplexer à l’intérieur d’une connexion TCP, ce que fait HTTP/2 mais, alors, on risque le head-of-line blocking, où la récupération d’une ressource bloque les suivantes, et le fait que la perte d’un seul paquet va faire ralentir tous les téléchargements.

QUIC en deux mots

Quels sont les concepts de base de QUIC ? QUIC gère des connexions entre machines, comme TCP. Par contre, contrairement à TCP, ces connexions portent ensuite des ruisseaux (streams) séparés, ayant leur propre contrôle de congestion, en plus du contrôle global à la connexion. Les ruisseaux peuvent être facilement et rapidement créés. Ce n’est pas par hasard que le concept ressemble à celui des ruisseaux de HTTP/2, dans les deux cas, le but était de s’adapter au désir des navigateurs Web de charger toutes les ressources d’une page en parallèle, sans pour autant « payer » l’établissement d’une connexion pour chaque ressource.

Avec QUIC, le chiffrement est obligatoire. Il n’y a pas de version de QUIC en clair. Non seulement les données applicatives sont chiffrées, comme avec TLS ou SSH mais une bonne partie de la couche transport l’est également. Pourquoi ?

  • En raison de la prévalence de la surveillance massive sur l’Internet ; moins on expose de données, moins il y a de risques.
  • Afin d’éviter que les middleboxes (les boitiers intermédiaires qui regardent au-dessus de la couche 3) ne se croient capables d’analyser le fonctionnement de la couche transport, et ne se croient autorisées à y intervenir, ce qui mènerait à une ossification de l’Internet. Si tout est chiffré, on pourra faire évoluer le protocole sans craindre l’intervention de ces fichus intermédiaires.
  • Certains FAI (Fournisseur d’accès à l’Internet) ont déjà exploité le caractère visible de TCP pour des attaques, par exemple en envoyant des paquets RST (ReSeT) pour couper le trafic BitTorrent. TLS et SSH ne protègent pas contre ce genre d’attaques.
  • L’observation de la couche transport peut permettre d’identifier les services utilisés et d’en dé-prioritiser certains. Le chiffrement du transport peut donc aider à préserver la neutralité du réseau.

On peut prévoir que les habituels adversaires du chiffrement protesteront d’ailleurs contre QUIC, en l’accusant de gêner la visibilité (ce qui est bien le but).

QUIC utilise le classique protocole TLS pour le chiffrement mais pas de la manière habituelle. Normalement, TLS fait la poignée de main initiale, l’échange des clés et le chiffrement des données. Avec QUIC, TLS ne fait que la poignée de main initiale et l’échange des clés. Une fois les clés obtenues, QUIC chiffrera tout seul comme un grand, en utilisant les clés fournies par TLS.

Les détails de mise en œuvre

Puisqu’on a parlé des middleboxes : déployer un nouveau protocole de transport dans l’Internet d’aujourd’hui est très difficile, en raison du nombre d’équipements qui interfèrent avec le trafic (les routeurs NAT, par exemple). Conceptuellement, QUIC aurait pu tourner directement sur IP. Mais il aurait alors été bloqué dans beaucoup de réseaux. D’où le choix de ses concepteurs de le faire passer sur UDP. QUIC utilise UDP comme il utiliserait IP. On lit parfois que QUIC, ce serait « HTTP au-dessus d’UDP », mais c’est une grosse incompréhension. QUIC est une couche de transport complète, concurrente de TCP, dont le fonctionnement sur UDP n’est qu’un détail nécessaire au déploiement. QUIC n’a aucune des propriétés d’UDP. Par exemple, comme TCP, mais contrairement à UDP, QUIC teste la réversibilité du trafic, ce qui empêche l’usurpation d’adresses IP et toutes les attaques UDP qui reposent dessus.

QUIC est parfois présenté comme « tournant en mode utilisateur et pas dans le noyau du système d’exploitation ». En fait, ce n’est pas spécifique à QUIC. Tout protocole de transport peut être mis en œuvre en mode utilisateur ou noyau (et il existe des mises en œuvre de TCP qui fonctionnent en dehors du noyau). Mais il est exact qu’en pratique la plupart des mises en œuvre de QUIC ne sont pas dans le noyau du système, l’expérience prouvant que les mises à jour du système sont souvent trop lentes, par rapport au désir de faire évoluer en permanence la couche transport. Et puis, sur Microsoft Windows, Google, premier promoteur de QUIC, n’aime pas dépendre de Microsoft pour les performances de son navigateur Chrome.

Les normes

Les RFC normalisant QUIC sont :

  • RFC 9000 est la norme principale, décrivant le socle de base de QUIC ;
  • RFC 9001 normalise l’utilisation de TLS avec QUIC ;
  • RFC 9002 spécifie les mécanismes de récupération de QUIC, quand des paquets sont perdus et qu’il faut ré-émettre, sans pour autant écrouler le réseau ;
  • RFC 8999 est consacré aux invariants de QUIC, aux points qui ne changeront pas dans les nouvelles versions de QUIC.

J’ai dit que QUIC, comme TCP, est un protocole de transport généraliste, et qu’on peut faire tourner plusieurs applications différentes dessus. En pratique, QUIC a été conçu essentiellement en pensant à HTTP mais dans le futur, d’autres protocoles pourront profiter de QUIC, notamment s’ils ont des problèmes qui ressemblent à ceux du Web (désir de faible latence, et de multiplexage).

Pour HTTP, la version de HTTP qui tourne sur QUIC se nomme HTTP/3 et sera normalisée dans un futur RFC. Comme HTTP/2, HTTP/3 a un encodage binaire, mais il ne fait plus de multiplexage, celui-ci étant désormais assuré par QUIC.

Le passé

QUIC a eu une histoire longue et compliquée. À l’origine, vers 2012, QUIC était un projet Google. Si les motivations étaient les mêmes que celles du QUIC actuel, et que certains concepts étaient identiques, il y avait quand même deux importantes différences techniques : le QUIC de Google utilisait un protocole de cryptographie spécifique, au lieu de TLS, et il était beaucoup plus marqué pour son utilisation par HTTP uniquement. Et il y a aussi bien sûr une différence politique, QUIC était un protocole privé d’une entreprise particulière, il est maintenant une norme IETF (Internet Engineering Task Force).

Et pour aller encore plus loin

Commentaires : voir le flux Atom ouvrir dans le navigateur

par Stéphane Bortzmeyer, Xavier Claude, orfenor, Ysabeau, Benoît Sibaud, eggman, yPhil, Stefane Fermigier, palm123, Ltrlg, kp, Yves Bourguignon, ted

DLFP - Dépêches

LinuxFr.org

Tribune April : Techsoup et Solidatech, instruments d'influence

 -  27 mars - 

Après une première position sur Solidatech en 2020, l'April a passé à nouveau du temps pour étudier et comprendre la place des structures Solidatech (...)


TuxRun et le noyau Linux

 -  27 mars - 

Il y a quelques années, je vous avais présenté TuxMake, un utilitaire pour faciliter la (cross-)compilation du noyau Linux supportant une grande (...)


Retour d’expérience sur l’utilisation de GrapheneOS (ROM Android libre)

 -  18 mars - 

Suite à la dépêche Comparatif : GrapheneOS vs LineageOS, je souhaitais faire part d’un retour d’expérience sur l’utilisation de GrapheneOS sur un (...)


Ubix Linux, le datalab de poche

 -  16 mars - 

Ubix Linux est une distribution Linux libre et open-source dérivée de Debian.Le nom « Ubix » est la forme contractée de « Ubics », acronyme issu de (...)


Open Food Facts : récit d’un contributeur

 -  15 mars - 

Récit de mon aventure en tant que contributeur pour le projet Open Food Facts, la base de donnée alimentaire ouverte et collaborative, où je suis (...)