QUIC est initialement l’acronyme de « Quick UDP Internet Connections », un protocole développé par Google vers 2012. C’est à la base un projet privé pour permettre d’améliorer les performances et la sécurité des applications web.
Comme les enjeux sont importants, il s’agit quand même de remplacer le protocole de transport d’Internet (TCP), il a été revue pendant plus de 8 ans au sein de l’IETF.
Mai 2021 : L’IETF vient de publier le protocole QUIC sous le nom de « RFC 9000« . Le protocole est normalisé sous la forme de plusieurs RFC : RFC 9001, RFC 9002 et RFC 8999. Cela signifie que la version 1 de QUIC est officiellement officialisée.
Qu'est-ce-qui change ?
Couche de transport complète !
C’est un protocole concurrent de TCP et il est basé sur UDP mais sans ses limitations. Ci-dessous sont emplacement entre UDP et HTTP/3.
Note : Je parlerais dans un second article des différentes versions du protocole HTTP et principalement du petit dernier HTTP/3 étroitement liés à QUIC.
Le chiffrement est obligatoire !
Pour rappel TLS sur TCP utilise deux sous-couches : celle d’enregistrement « Record Layer » et celle de salutation « Handshake Layer ». De plus, il ne permet pas de cacher la taille des paquets.
Comme le montre l’image du dessus, TLS dans sa version 1.3 (la plus rapide actuellement) est dans QUIC et non pas au dessus. Cette nuance permet d’annuler la première sous-couche d’enregistrement et de garder seulement la salutation. Ce qui permet de réduire considérablement la latence.
(Je ferais une page sur la négociation TLS plus tard)
QUIC permet le remplissage (‘padding’ en anglais), c’est à dire qu’il ajoute des données au paquets afin de confondre leurs tailles et donc d’améliorer la vie privée.
Réduction du temps de chargement !
QUIC à été pensé pour le web dans un modèle client-serveur afin de rendre plus rapide la façon d’établir les connexions.
Avec TCP il faut plusieurs aller-retours entre un client et un serveur pour établir la connexion, alors qu’avec QUIC, si un client à déjà parlé à un serveur donné, il peut commencer à envoyer des données sans aller-retour afin que les pages web chargent plus rapidement. Ce phénomène s’explique par le fait que chaque segment de données d’une connexion (d’origine ou transmis) reçoit un identifiant de connexion. Ce marquage des paquets permet d’estimer plus précisément le temps de transmission (RTT) et de ce fait, à l’intérieur d’un même paquet, nous pouvons avoir plusieurs trames (ACK, PING, PADDING, STREAM, CRYPTO, etc…)
Pour comprendre, voici une animation réalisé par Google
Google annonce que QUIC améliore toujours le temps de chargement moyen des pages de 8% dans le monde et jusqu’à 13% dans les régions où la latence est plus élevé.
Avantage pour nous...
...mais pas pour les FAI
Avec TCP le fonctionnement du protocole était visible pour les équipements intermédiaires qui touche au Transport. Par exemple les pares-feux bloquent tout ce qu’ils ne connaissent pas et seuls TCP, UDP et ICMP passent…et encore.
Avec QUIC, comme tous est chiffré, ces équipements ne peuvent plus voir les connexions. Ils ne peuvent donc plus s’adapter. Par exemple, nos Fournisseurs d’accès internet (FAI) peuvent actuellement générer des paquets TCP spécifique pour prévenir les échanges en Torrent.
Étant donné que les en-têtes de paquets contiennent des informations de texte moins clair que ceux qui ont des connexions TCP, des tâches telles que le dépannage, la régulation du trafic, ou la gestion du réseau devenir plus difficile avec les connexions QUIC. Pour cette raison, les opérateurs de réseau et les fabricants de pare-feu, entre autres, ont du mal à garantir la qualité de leurs produits.
Je vous invite à consulter le livre libre de Daniel Stenberg (le papa de CURL). Le livre est disponible en plusieurs langues dont le Français 👌
Exposé réalisé en 2019 par Stéphane Bortzmeyer
Citations des grandes industrie d'Internet :
« QUIC a commencé comme une petite expérience chez Google en 2013 et transporte maintenant la majorité du trafic de Google. La séparation nette entre le transport QUIC et HTTP/3 ouvre la voie à des décennies d’innovation en matière de transport et d’applications. En raison de l’amélioration de la latence, HTTP/3 était activé par défaut pour tous les sites Google et dans Chrome en novembre 2020. Nous attendons avec impatience la croissance continue de HTTP/3, car d’autres l’activent également par défaut.
- Ian Swett, responsable des performances Web, Google
« Microsoft est un participant actif et un pilote de QUIC dans l’industrie ainsi que l’IETF et a ouvert sa mise en œuvre. MsQuic apporte des améliorations de performances et de sécurité à de nombreux scénarios de réseau importants, en particulier une latence de queue réduite et une configuration de connexion sécurisée rapide pour nos services en ligne. Microsoft s’engage à déployer HTTP/3 et QUIC à grande échelle et à favoriser l’innovation dans les protocoles Internet pour offrir des expériences de connectivité sécurisées, fiables et performantes à nos utilisateurs. »
- Krishna Ganugapati, vice-président de l’ingénierie, Microsoft
« Plus de 75 % du trafic de Facebook utilise désormais QUIC. Nous sommes ravis de pouvoir déployer cette technologie à grande échelle, apportant les améliorations de performances et de fiabilité de QUIC aux milliards de personnes qui utilisent nos produits au quotidien. QUIC et le travail accompli par l’IETF nous permettent d’évoluer rapidement et d’innover en permanence au niveau de la couche réseau d’une manière qui n’a jamais été possible avec TCP. »
- Mike Schroepfer, directeur technique, Facebook
« QUIC est une avancée majeure dans les protocoles de transport. Cloudflare est convaincu que ses fonctionnalités de sécurité et de mobilité lui confèrent le potentiel de devenir le protocole de transfert dominant sur Internet. Pour cette raison, nous avons déployé QUIC et HTTP/3 tôt.
- John Graham-Cumming, directeur de la technologie de Cloudflare
« F5 a le privilège d’avoir eu l’opportunité de contribuer au travail important de l’IETF pour établir HTTP/3 comme la nouvelle norme Web. Nos clients BIG-IP et NGINX bénéficieront des améliorations de performances et de sécurité de ce nouveau protocole, et nous sommes prêts à offrir une assistance supplémentaire à mesure que les futures améliorations seront déployées. »
- Geng Lin, vice-président exécutif et directeur technique, F5 Networks
« QUIC améliore déjà l’expérience utilisateur et l’efficacité d’Internet, et l’améliore davantage pour les connexions les plus difficiles. Mais la vraie valeur reste à voir. Un transport crypté signifie que la nouvelle technologie peut être testée et déployée rapidement, juste en mettre à jour votre navigateur. QUIC n’est pas seulement la bonne idée d’aujourd’hui, c’est ce qui rendra possible la bonne idée de demain.
- Mike Bishop, architecte principal, Akamai
« Fastly a été investi pour contribuer au succès de QUIC dès ses débuts, et sa ratification est une étape majeure pour l’écosystème Internet. QUIC et HTTP/3 sont disponibles sur notre réseau et améliorent l’expérience de nos clients et de leurs utilisateurs dans le monde entier. En particulier ceux qui disposent d’une connexion Internet peu fiable. Nous pensons que le véritable potentiel de QUIC réside dans l’accélération d’une toute nouvelle génération d’innovations Internet. Fastly étend déjà et s’appuie sur QUIC pour résoudre de nouveaux problèmes d’infrastructure et de technologie, et nous sommes ravis de continuer à contribuer à cet espace dans notre mission de construire un Internet plus rapide, plus résilient et plus fiable. »
- Tyler McMullen, CTO, Fastly