Publié le 31 décembre 2025 à 18h27. Cloudflare a rendu public tokio-quiche, une bibliothèque Rust open source conçue pour simplifier l’implémentation des protocoles QUIC et HTTP/3, en combinant son implémentation Quiche éprouvée avec l’environnement d’exécution asynchrone Tokio.
- tokio-quiche intègre l’implémentation QUIC et HTTP/3 de Cloudflare, Quiche, avec le runtime Tokio, évitant aux développeurs de gérer manuellement les complexités liées à UDP et aux boucles d’événements.
- La bibliothèque utilise une architecture basée sur des acteurs, avec des composants dédiés au routage des paquets et à la gestion des connexions, assurant ainsi l’isolation et la composabilité.
- tokio-quiche propose une abstraction
ApplicationOverQuicpour faciliter l’intégration de différents protocoles basés sur QUIC, tels que HTTP/3 et DNS sur QUIC.
Cloudflare a développé tokio-quiche au fil des années et l’utilise déjà en production dans des services à grande échelle tels qu’Apple iCloud Private Relay, les serveurs HTTP/3 basés sur Oxy et le client WARP MASQUE. Ces systèmes démontrent la capacité de la bibliothèque à gérer des millions de requêtes HTTP/3 par seconde avec une faible latence et un débit élevé.
Quiche, l’implémentation de base de QUIC et HTTP/3 développée par Cloudflare en Rust, est conçue comme une bibliothèque de bas niveau sans gestion des entrées/sorties (I/O). Elle implémente la machine à états de transport QUIC, incluant l’établissement de connexion, le contrôle de flux et le multiplexage de flux, sans imposer de contraintes sur la manière dont les applications gèrent les I/O. Cependant, l’utilisation directe de Quiche nécessite une gestion manuelle des sockets UDP, de l’envoi et de la réception des datagrammes, ainsi que de la synchronisation des données des paquets, ce qui peut être source d’erreurs et chronophage.
tokio-quiche simplifie ce processus en encapsulant ces tâches d’intégration dans une caisse réutilisable. Elle combine l’implémentation sans I/O de Quiche avec le runtime asynchrone Tokio et expose une API qui gère automatiquement les sockets UDP, le routage des paquets et les appels à la machine à états Quiche.
Au cœur de tokio-quiche se trouve une architecture basée sur des acteurs. Chaque acteur est une tâche légère dotée d’un état local qui communique avec les autres acteurs par le biais de messages envoyés sur des canaux. Cette approche est particulièrement adaptée aux implémentations de protocoles sans I/O, qui possèdent un état interne et fonctionnent sur des messages tels que des tampons de données.
L’acteur principal est l’acteur de boucle I/O, qui transfère les paquets entre Quiche et le socket UDP. Un type de message clé est la structure Incoming, qui décrit les paquets UDP reçus. L’intégration asynchrone suit un modèle fixe : la boucle I/O attend de nouveaux messages, les traduit en entrées pour Quiche, fait avancer la machine à états QUIC, puis traduit les sorties en paquets sortants qui sont renvoyés sur le socket.
Pour chaque socket UDP, tokio-quiche crée deux tâches importantes : InboundPacketRouter, qui gère la réception des datagrammes et les achemine vers le canal de connexion approprié en fonction de leur identifiant de connexion, et IoWorker, qui gère la boucle I/O pour chaque connexion et pilote une instance unique de Quiche Connection, en combinant les appels à Quiche avec la logique spécifique à l’application via ApplicationOverQuic. Cette conception isole l’état de la connexion au sein de chaque acteur et maintient le traitement QUIC séparé du code de protocole de niveau supérieur.
QUIC est un protocole de transport polyvalent qui peut prendre en charge plusieurs protocoles d’application, tels que HTTP/3, DNS sur QUIC et Media sur QUIC, conformément aux spécifications de l’IETF. Pour éviter de lier tokio-quiche à un protocole spécifique, Cloudflare a défini une interface ApplicationOverQuic. Cette interface définit les méthodes nécessaires pour interagir avec Quiche et les I/O sous-jacents, et expose des événements de haut niveau et des points d’extension pour l’application qui implémente le protocole. Par exemple, le client de débogage et de test HTTP/3 h3i utilise une implémentation non HTTP/3 de ApplicationOverQuic.
En plus de cette fonctionnalité, tokio-quiche propose une implémentation dédiée à HTTP/3, nommée H3Driver. H3Driver connecte le module HTTP/3 de Quiche à l’acteur de boucle I/O et convertit les événements HTTP/3 bruts en événements de haut niveau avec des flux de corps asynchrones, adaptés au code d’application. H3Driver est générique et propose des variantes ServerH3Driver et ClientH3Driver qui ajoutent un comportement spécifique au serveur et au client, respectivement.
Cloudflare considère tokio-quiche comme une base solide plutôt que comme un framework HTTP/3 complet. La bibliothèque expose des fonctionnalités de protocole de bas niveau et des exemples de boucles d’événements client et serveur, laissant aux projets de niveau supérieur le soin d’implémenter des serveurs HTTP complets, des clients DNS sur QUIC, des VPN basés sur MASQUE et d’autres applications QUIC. En publiant cette bibliothèque, Cloudflare espère réduire les obstacles à l’adoption de QUIC, HTTP/3 et MASQUE par les équipes Rust, et aligner les intégrations externes sur la même pile de transport utilisée dans ses propres services Edge.
Pour en savoir plus sur les détails techniques, consultez le blog de Cloudflare.
À ne pas manquer
