URL: https://linuxfr.org/news/le-protocole-quic-desormais-normalise Title: Le protocole QUIC désormais normalisé Authors: Stéphane Bortzmeyer Xavier Claude, orfenor, Ysabeau, Benoît Sibaud, eggman, yPhil, Stefane Fermigier, palm123, Ltrlg, kp, Yves Bourguignon et ted Date: 2021-03-12T16:33:37+01:00 License: CC By-SA Tags: quic, http3 et tls Score: 4 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](https://quicwg.org/asset/badge.png) ---- [La norme de base de QUIC, le RFC 9000](https://www.rfc-editor.org/info/rfc9000) [La norme d'interaction entre QUIC et TLS, le RFC 9001](https://www.rfc-editor.org/info/rfc9001) [La norme sur les invariants de QUIC, le RFC 8999](https://www.rfc-editor.org/info/rfc8999) [Le livre libre et gratuit de Daniel Stenberg, qui couvre HTTP/3 mais aussi QUIC](https://http3-explained.haxx.se/) [Sa version en français](https://http3-explained.haxx.se/fr) [Une liste bien gérée des nombreuses mises en œuvre de QUIC](https://github.com/quicwg/base-drafts/wiki/Implementations) [La norme sur la récupération en cas de perte de paquets, le RFC 9002](https://www.rfc-editor.org/info/rfc9002) [L'arrivée de QUIC dans Firefox](https://hacks.mozilla.org/2021/04/quic-and-http-3-support-now-in-firefox-nightly-and-beta/) ---- # 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](https://fr.wikipedia.org/wiki/Mod%C3%A8le_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](https://en.wikipedia.org/wiki/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](https://en.wikipedia.org/wiki/Protocol_ossification). 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](https://datatracker.ietf.org/doc/html/rfc9000) est la norme principale, décrivant le socle de base de QUIC ; * [RFC 9001](https://datatracker.ietf.org/doc/html/rfc9001) normalise l’utilisation de TLS avec QUIC ; * [RFC 9002](https://datatracker.ietf.org/doc/html/rfc9002) 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](https://datatracker.ietf.org/doc/html/rfc8999) 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 - La norme de base sur TCP, le [RFC 793](https://www.rfc-editor.org/info/rfc793) - Une [liste commentée des RFC à lire sur TCP](https://www.rfc-editor.org/info/rfc7414) - Le [RFC sur HTTP/2](https://www.rfc-editor.org/info/rfc7540) - Le [RFC sur la surveillance massive, et l’engagement de l’IETF](https://www.rfc-editor.org/info/rfc7258) à lutter contre cette attaque - Sur la notion d’« image montrée au réseau », le [RFC 8546](https://www.rfc-editor.org/info/rfc8546) - Un [ancien article de LinuxFr.org sur QUIC](https://linuxfr.org/news/google-veut-reduire-la-latence-sur-internet-avec-quic)