QUIC va dévorer Internet

QUIC (ce n'est pas un acronyme) est une bête unique, mais il est préférable de le considérer comme un nouveau protocole de transport qui résout de nombreux problèmes de longue date sur Internet et capture la plupart de la valeur fournie par TCP, TLS, SCTP, IPSec et HTTP/2. Il existe une nouvelle version de HTTP appelée HTTP/3 qui est conçue pour fonctionner sur UDP/QUIC au lieu de TCP/TLS.

Google a déployé une première version de HTTP sur QUIC dans ses navigateurs et serveurs Web dès 2014. Un processus de normalisation de l’IETF a débuté en 2016. Après de nombreuses évolutions et collectes de données, cela donnera lieu au premier lot de RFC début 2021. Plusieurs grandes sociétés Internet, dont F5, ont livré des produits utilisant QUIC ou ont déployé QUIC dans leur infrastructure. En octobre 2020, 75 % du trafic de Facebook passait par HTTP/3 et QUIC.

Ces premiers déploiements et la ferveur pour de nouvelles normes basées sur QUIC au sein de l’IETF indiquent que cela deviendra un substrat important, et peut-être dominant, pour les applications de pointe sur Internet.

Présentation technique : Pourquoi QUIC ?

La figure 1 donne au lecteur une idée de ce que fait QUIC. Cependant, cette décomposition fonctionnelle ne précise pas pourquoi les premiers utilisateurs de l’industrie se tournent vers QUIC :

1. Latence réduite. Les transferts de données de type Web sont dominés par la latence de trois couches de poignées de main : une pour TCP, au moins une pour TLS et une pour la requête/réponse HTTP. Les développements récents de TCP/TLS peuvent en principe réduire cela à un seul aller-retour, bien que cela fonctionne rarement dans la pratique. QUIC réduira cela à un aller-retour, et au maximum à deux.
   
   
2. Les ruisseaux. Comme HTTP/2, QUIC fournit à l'application plusieurs flux d'octets pour augmenter l'indépendance des données conceptuellement distinctes transmises sur la même connexion. Le faire dans les transports ne fait qu’augmenter cette indépendance. Les flux s'adaptent naturellement aux besoins de diffusion de vidéos en streaming et les principaux fournisseurs de contenu Internet sont en bonne voie pour proposer du streaming via QUIC.
   
   
3. Meilleure réponse aux pertes. La conception de QUIC améliore la capacité de TCP à détecter et à récupérer les pertes de paquets. De plus, en présentant des flux multiplexés au lieu d'un seul flux d'octets ordonnés, la perte d'un paquet contenant un objet ne retarde pas nécessairement la livraison d'un objet différent.
   
   
4. Multihébergement. Tout comme MPTCP et SCTP, les connexions QUIC peuvent être associées à plusieurs adresses IP pour chaque point de terminaison. Contrairement à ces protocoles, QUIC a de bonnes chances de traverser un Internet qui laisse tomber des numéros de protocole et des options d'en-tête TCP inconnus.
   
   
5. Sécurité et confidentialité. QUIC applique le cryptage au niveau de la couche de transport, plutôt qu'au-dessus. L'ensemble de la charge utile UDP est authentifié, empêchant toute modification transparente par des intermédiaires, et presque toutes les informations de transport sont cryptées. Les ramifications de tout cela constituent un livre blanc à elles seules. Il suffit de dire que cela améliore considérablement les propriétés de confidentialité et élimine pratiquement la surface d’attaque fournie par TCP. Contrairement à IPSec, ce protocole fonctionne aujourd’hui à l’échelle du Web. Cela conduit également à :
   
   
6. Extensibilité. TCP est difficile à modifier car ses créateurs ont laissé un espace d’extension limité et parce que les boîtiers intermédiaires imposent l’ancien comportement TCP. QUIC combine le versionnage explicite avec l'opacité des boîtes intermédiaires pour permettre de nouvelles innovations dans le transport. Cela permettra de prendre en charge les futurs cas d'utilisation et, à terme, d'améliorer la capacité de transport en masse par rapport à TCP.

Outre l'inertie, il existe deux raisons pour lesquelles certaines applications peuvent ne pas migrer vers QUIC :

• Complexité : les applications qui n'ont besoin que d'un seul flux d'octets et ne se soucient pas du chiffrement n'ont pas besoin de la charge de travail supplémentaire associée à ces fonctionnalités.
  
  
• Boîtiers intermédiaires : Un pourcentage non négligeable de chemins Internet n’admettent pas l’UDP. HTTP/3 a été conçu avec un repli TCP pour ces chemins, mais en fin de compte, l'impact sur les performances des principaux sites Web (Google, Facebook, etc.) est susceptible de rendre obsolètes les appareils responsables, sauf lorsque les États-nations désirant une surveillance en décident autrement.

Il dévore Internet

Google Chrome, Google App Clients et l’application Facebook prennent déjà en charge HTTP/3. Les implémentations de Safari, Edge et Firefox le prennent en charge, mais (pour l'instant) sont désactivées par défaut.

Côté serveur, les implémentations et/ou déploiements de Google, Microsoft, Facebook, Apple, Cloudflare, LiteSpeed, F5 BIG-IP, NGINX, Fastly et Akamai ont été livrés ou sont sur le point de l'être. Récemment, un important FAI européen a signalé que 20 % de ses paquets étaient QUIC . Environ 5 % des sites Web utilisent HTTP/3 en février 2021, mais nous nous attendons à ce que ce chiffre augmente une fois la RFC publiée.

De plus, de nombreux travaux sont en cours au sein des organismes de normalisation pour amener QUIC au-delà du cas d’utilisation HTTP. Les projets de normes de l'IETF proposent le DNS, les Websockets, le SIP et les tunnels TCP et UDP via QUIC. QUIC est arrivé un peu trop tard pour être pleinement intégré aux architectures 5G, mais l'intérêt et l'applicabilité de QUIC aux fournisseurs de services sont évidents. Enfin, les API supérieures pour HTTP/2 et HTTP/3 sont assez similaires, donc tout protocole ou application qui s'exécute sur HTTP/2 peut être facilement porté pour s'exécuter sur HTTP/3 et QUIC au lieu de TCP.

Menaces et opportunités

QUIC et HTTP/3 façonneront une variété de marchés . Les sites Web et applications performants ont tout intérêt à passer à HTTP/3 et QUIC une fois que l’écosystème aura atteint sa pleine maturité, et nous nous attendons à ce que nos clients exigent la prise en charge de HTTP/3 à un rythme similaire à celui de leur déploiement de HTTP/2.

Les produits de sécurité nécessitent une réévaluation fondamentale dans un Internet dénommé QUIC. L'inspection des paquets est beaucoup plus difficile sans accès aux clés de session TLS, ce qui n'est généralement possible qu'avec la possession de la clé privée du domaine. Cela renforce la valeur d’une solution de sécurité intégrée à un proxy au niveau de l’application, plutôt qu’à une série de périphériques à fonction unique.

De plus, la défense DDoS traditionnelle a besoin d’être améliorée. Non seulement l’identification et l’inspection des paquets sont plus difficiles, mais les syncookies TCP ont été remplacés par des « paquets de nouvelle tentative », qui ne peuvent pas être facilement falsifiés par des intermédiaires. Il existe des méthodes de coordination standard qui permettent aux serveurs de décharger la génération et la validation des paquets de nouvelle tentative, mais encore une fois, cela nécessite des efforts de développement.

L'équilibrage de charge traditionnel de couche 4 interrompt la migration d'adresse QUIC, car il ne peut pas associer un flux qui modifie son adresse ou ses ports à lui-même, puis l'acheminer vers le même serveur. Là encore, il existe des normes pour coordonner et surmonter ce problème, mais cela nécessite des investissements.

Le groupe de travail MASQUE de l'IETF travaille sur le tunneling de trafic généralisé sur QUIC, qui pourrait être la base des schémas VPN de nouvelle génération . Les propriétés de QUIC sont bien meilleures pour multiplexer des flux arbitraires que TLS sur TCP. Ces tunnels peuvent également remplacer les tunnels IPSec par une cryptographie à l'échelle du Web, améliorant ainsi certains cas d'utilisation des fournisseurs de services et même fournir un moyen d' optimiser les connexions QUIC pour les types de liens mobiles avec le consentement explicite du client.

QUIC nécessitera de nouveaux outils de mesure et d’analyse du réseau. Les systèmes capables de mesurer la latence et la perte TCP ne peuvent pas utiliser ces signaux, mais il existe un signal de latence explicite envoyé au réseau, et d’autres signaux peuvent être en route. Avec davantage d’informations de transport cachées derrière le cryptage, les captures de paquets sont moins utiles. Cependant, il existe un format de journalisation standard émergent que de nombreuses implémentations QUIC suivent, et que les utilisateurs créent des outils d'analyse pour exploiter.

F5 suit de près l'évolution de la situation

Le personnel de F5 surveille les efforts de normalisation au sein de l'IETF depuis des années et contribue là où nous pensons que cela aidera nos clients. BIG-IP a suivi les versions préliminaires de QUIC et HTTP/3 depuis le début, y compris les versions publiques depuis TMOS v15.1.0.1. NGINX dispose d'une version alpha HTTP/3 et la fusionnera prochainement avec la version principale.

Nous continuerons de surveiller les tendances dans ce domaine et de créer de nouveaux produits passionnants pour refléter les nouvelles capacités offertes par ces protocoles.

Conclusion

QUIC bénéficie d’un large soutien industriel et du potentiel pour être la base de la plupart des applications qui offrent une valeur commerciale sur Internet. Quiconque fournit des applications sur Internet devrait commencer à réfléchir à la manière dont ses opérations devraient évoluer pour refléter les nouvelles menaces et opportunités qu’apportent ces protocoles.