QUIC va dévorer Internet

F5

QUIC (qui n’est pas un acronyme) est un protocole unique en son genre, 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 reprend l’essentiel des avantages offerts par TCP, TLS, SCTP, IPSec et HTTP/2. Il existe une nouvelle version de HTTP, appelée HTTP/3, conçue pour fonctionner sur UDP/QUIC plutôt que sur TCP/TLS.

Dès 2014, Google a déployé une première version de HTTP sur QUIC dans ses navigateurs et ses serveurs web. Un processus de normalisation de l’IETF a débuté en 2016. Après de nombreuses évolutions et collectes de données, celui-ci aboutira à la publication d’une première série de RFC début 2021. Plusieurs grandes entreprises du secteur d’Internet, dont F5, ont commercialisé des produits utilisant QUIC ou déployé QUIC dans leur infrastructure. En octobre 2020, 75 % du trafic de Facebook transitait par HTTP/3 et QUIC.

Ces premiers déploiements, ainsi que l’engouement de l’IETF pour de nouvelles normes reposant sur QUIC, indiquent que celui-ci deviendra une infrastructure importante, voire dominante, pour les applications Internet de pointe.

Présentation technique — Pourquoi QUIC ?

Figure 1. QUIC tire parti des fonctionnalités de nombreux protocoles existants.

La figure 1 donne au lecteur une idée de ce que fait QUIC. Toutefois, cette décomposition fonctionnelle n’explique pas pourquoi les premiers acteurs du secteur à l’adopter se tournent vers QUIC :

1. Latence réduite. Les transferts de données de type Web sont principalement ralentis par la latence de trois couches de négociation : une pour TCP, au moins une pour TLS et une pour le cycle requête/réponse HTTP. Les évolutions récentes de TCP/TLS permettent en principe de ramener ces échanges à un seul aller-retour, même si cela fonctionne rarement en pratique. QUIC les réduira à un aller-retour, et à deux au maximum.
   
   
2. Flux. À l’instar de HTTP/2, QUIC fournit à l’application plusieurs flux d’octets afin d’accroître l’indépendance de données conceptuellement distinctes transmises sur une même connexion. La prise en charge de ces flux directement au niveau de la couche de transport renforce encore cette indépendance. Les flux répondent naturellement aux besoins de la diffusion vidéo en continu, et les principaux fournisseurs de contenus sur Internet sont en bonne voie pour proposer cette diffusion via QUIC.
   
   
3. Meilleure gestion des pertes. La conception de QUIC améliore la capacité de TCP à détecter les pertes de paquets et à s’en remettre. De plus, grâce à l’utilisation de flux multiplexés plutôt que d’un unique flux d’octets ordonné, la perte d’un paquet contenant un objet ne retarde pas nécessairement la livraison d’un autre objet.
   
   
4. Multihébergement. À l’instar de MPTCP et de 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 rejette les numéros de protocole inconnus et les options d’en-tête TCP.
   
   
5. Sécurité et confidentialité. QUIC applique le chiffrement au niveau de la couche de transport, plutôt qu’au-dessus de celle-ci. L’intégralité de la charge utile UDP est authentifiée, ce qui empêche toute modification transparente par des intermédiaires, et la quasi-totalité des informations de transport est chiffrée. Les conséquences de cette approche mériteraient à elles seules un livre blanc. Il suffit de dire qu’elle améliore considérablement la protection de la vie privée et élimine pratiquement la surface d’attaque offerte par TCP. Contrairement à IPSec, cette technologie est aujourd’hui déployée à l’échelle du Web. Elle permet également :
   
   
6. Extensibilité. TCP est difficile à faire évoluer, car ses créateurs ont prévu un espace limité pour les extensions et les équipements intermédiaires imposent les anciens comportements de TCP. QUIC associe un versionnage explicite à une opacité vis-à-vis des équipements intermédiaires afin de permettre de nouvelles innovations au niveau du transport. Cela permettra de prendre en charge de futurs cas d’usage et, à terme, d’améliorer la capacité de transport de gros volumes de données par rapport à TCP.

Outre l’inertie, deux raisons peuvent expliquer pourquoi certaines applications pourraient ne pas migrer vers QUIC :

• Complexité : les applications qui n’ont besoin que d’un seul flux d’octets et pour lesquelles le chiffrement n’est pas important n’ont pas à supporter la charge de travail supplémentaire associée à ces fonctionnalités.
  
  
• Équipements intermédiaires : Une proportion non négligeable des chemins Internet ne prend pas en charge UDP. HTTP/3 a été conçu avec un mécanisme de repli sur TCP pour ces chemins, mais à terme, l’impact sur les performances des grands sites web (Google, Facebook, etc.) rendra probablement obsolètes les équipements concernés, sauf lorsque des États souhaitant exercer une surveillance imposent leur utilisation.

Il est en train de dévorer Internet

Google Chrome, les clients d’applications Google et l’application Facebook prennent déjà en charge HTTP/3. Les versions de Safari, Edge et Firefox le prennent également en charge, mais cette fonctionnalité est (pour l’instant) désactivée par défaut.

Côté serveur, les implémentations et/ou les déploiements de Google, Microsoft, Facebook, Apple, Cloudflare, LiteSpeed, F5 BIG-IP, NGINX, Fastly et Akamai sont déjà disponibles ou sur le point de l’être. Récemment, un grand fournisseur d’accès à Internet européen a indiqué que 20 % de ses paquets utilisaient QUIC. Environ 5 % des sites web utilisaient HTTP/3 en février 2021, mais nous nous attendons à ce que ce chiffre augmente une fois la RFC publiée.

En outre, les organismes de normalisation travaillent activement à étendre QUIC au-delà du cas d’usage de HTTP. Des projets de normes de l’IETF proposent de faire transiter DNS, WebSockets, SIP, ainsi que des tunnels TCP et UDP sur QUIC. QUIC est arrivé un peu trop tard pour être pleinement intégré aux architectures 5G, mais son intérêt et son applicabilité pour les fournisseurs de services sont évidents. Enfin, les API de haut niveau de HTTP/2 et HTTP/3 sont assez similaires : tout protocole ou toute application fonctionnant sur HTTP/2 peut donc être facilement adapté pour fonctionner sur HTTP/3 et QUIC plutôt que sur TCP.

Menaces et opportunités

QUIC et HTTP/3 façonneront de nombreux marchés. Les sites web et applications à hautes performances auront tout intérêt à passer à HTTP/3 et QUIC une fois l’écosystème arrivé à pleine maturité, et nous nous attendons à ce que nos clients demandent la prise en charge de HTTP/3 à un rythme similaire à celui de leur déploiement de HTTP/2.

Les produits de sécurité doivent être fondamentalement repensés dans un Internet dominé par QUIC. L’inspection des paquets est beaucoup plus difficile sans accès aux clés de session TLS, généralement possible uniquement si l’on possède la clé privée du domaine. Cela renforce l’intérêt d’une solution de sécurité intégrée à un proxy de niveau applicatif, plutôt que d’une série d’équipements à fonction unique.

De plus, la protection traditionnelle contre les attaques DDoS doit être adaptée. Non seulement l’identification et l’inspection des paquets sont plus difficiles, mais les SYN cookies TCP ont été remplacés par des « paquets Retry », qui ne peuvent pas être facilement usurpés par des intermédiaires. Il existe des mécanismes de coordination standard permettant aux serveurs de déléguer la génération et la validation des paquets Retry, mais là encore, cela nécessite un travail de développement.

L’équilibrage de charge traditionnel de couche 4 empêchera la migration d’adresse QUIC, car il ne peut pas reconnaître comme étant le même un flux dont l’adresse ou les ports changent, puis l’acheminer vers le même serveur. Là encore, il existe des normes permettant de coordonner les opérations et de résoudre ce problème, mais cela nécessite des investissements.

Le groupe de travail MASQUE de l’IETF travaille sur la généralisation de la tunnellisation du trafic via QUIC, qui pourrait servir de base à des solutions VPN de nouvelle génération. Les propriétés de QUIC sont bien mieux adaptées au multiplexage de flux arbitraires que celles de TLS sur TCP. Ces tunnels peuvent également remplacer les tunnels IPSec par une cryptographie à l’échelle du Web, améliorant ainsi certains cas d’usage des fournisseurs de services, et même permettre d’optimiser les connexions QUIC pour les différents types de liaisons 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 les pertes de TCP ne peuvent pas utiliser ces signaux, mais il existe un signal de latence explicite destiné au réseau, et d’autres signaux pourraient voir le jour. Comme davantage d’informations sur le transport sont masquées par le chiffrement, les captures de paquets sont moins utiles. Cependant, il existe un format standard émergent de journalisation adopté par de nombreuses implémentations de QUIC, et des outils d’analyse sont en cours de développement pour en tirer parti.

F5 suit de près les évolutions

Les équipes de F5 suivent depuis des années les travaux de normalisation menés au sein de l’IETF et y contribuent lorsqu’elles estiment que cela peut aider nos clients. BIG-IP suit les versions préliminaires de QUIC et de HTTP/3 depuis le début, notamment les versions publiques depuis TMOS v15.1.0.1. NGINX propose une version alpha de HTTP/3 et l’intégrera prochainement à la branche principale.

Nous continuerons à suivre les tendances dans ce domaine et à développer de nouveaux produits innovants qui tireront parti des nouvelles possibilités offertes par ces protocoles.

Conclusion

QUIC bénéficie d’un large soutien de la part du secteur et pourrait servir de fondement à la plupart des applications qui génèrent de la valeur commerciale sur Internet. Toute organisation proposant des applications sur Internet devrait commencer à réfléchir à la manière d’adapter ses activités aux nouvelles menaces et opportunités qu’apportent ces protocoles.

À propos de l’auteur

F5

Autres articles de F5