Cloudflare est désormais plus rapide et plus sécurisé grâce à Rust : l'équipe de Cloudflare partage une mise à niveau du logiciel qui offre un gain de performance de 25 %

Cloudflare s'efforce sans relâche de créer et d'exploiter le réseau le plus rapide au monde. Nous suivons et rendons compte des performances de notre réseau depuis 2021 : vous pouvez consulter la dernière mise à jour ici.

La construction du réseau le plus rapide nécessite des efforts dans de nombreux domaines. Nous investissons beaucoup de temps dans notre matériel afin de disposer de machines efficaces et rapides. Nous investissons dans des accords de peering afin de pouvoir communiquer avec toutes les parties d'Internet avec un délai minimal. En outre, nous devons également investir dans les logiciels sur lesquels nous exploitons notre réseau, d'autant plus que chaque nouveau produit peut sinon ajouter un délai de traitement supplémentaire.

Quelle que soit la vitesse à laquelle les messages arrivent, nous créons un goulot d'étranglement si ce logiciel met trop de temps à réfléchir à la manière de traiter et de répondre aux demandes. Aujourd'hui, nous sommes ravis de vous faire part d'une mise à niveau importante de notre logiciel qui réduit le temps médian de réponse de 10 ms et offre un gain de performance de 25 %, selon les tests de performance CDN réalisés par des tiers.

Nous avons passé l'année dernière à reconstruire les principaux composants de notre système, et nous venons de réduire considérablement la latence du trafic transitant par notre réseau pour des millions de nos clients. Dans le même temps, nous avons renforcé la sécurité de notre système et réduit le temps nécessaire à la création et à la mise sur le marché de nouveaux produits.


Par où avons-nous commencé ?

Chaque requête qui arrive à Cloudflare commence un parcours à travers notre réseau. Elle peut provenir d'un navigateur chargeant une page web, d'une application mobile appelant une API ou d'un trafic automatisé provenant d'un autre service. Ces requêtes aboutissent d'abord à notre couche HTTP et TLS, puis passent dans un système que nous appelons FL, et enfin dans Pingora, qui effectue des recherches dans le cache ou récupère des données à la source si nécessaire.


FL est le cerveau de Cloudflare. Une fois qu'une requête atteint FL, nous exécutons les différentes fonctionnalités de sécurité et de performance de notre réseau. Il applique la configuration et les paramètres uniques de chaque client, de l'application des règles WAF et de la protection DDoS au routage du trafic vers la plateforme de développement et R2.

Créé il y a plus de 15 ans, FL est au cœur du réseau Cloudflare. Il nous permet d'offrir un large éventail de fonctionnalités, mais au fil du temps, cette flexibilité est devenue un défi. À mesure que nous ajoutions des produits, FL devenait plus difficile à maintenir, plus lent à traiter les requêtes et plus difficile à étendre. Chaque nouvelle fonctionnalité nécessitait des vérifications minutieuses de la logique existante, et chaque ajout introduisait un peu plus de latence, ce qui rendait de plus en plus difficile le maintien des performances que nous souhaitions.

Vous pouvez voir à quel point FL est essentiel à notre système : nous l'avons souvent qualifié de « cerveau » de Cloudflare. C'est également l'une des parties les plus anciennes de notre système : le premier commit dans la base de code a été effectué par l'un de nos fondateurs, Lee Holloway, bien avant notre lancement initial. Nous célébrons notre 15e anniversaire cette semaine, mais ce système a vu le jour 9 mois avant cela !



Comme l'indique le commit, la première version de FL a été mise en œuvre sur la base du serveur web NGINX, avec une logique produit implémentée en PHP. Au bout de trois ans, le système était devenu trop complexe pour être géré efficacement et trop lent pour répondre, et une réécriture presque complète du système en cours d'exécution a été effectuée. Cela a conduit à un autre commit important, cette fois-ci réalisé par Dane Knecht, qui est aujourd'hui notre directeur technique.



À partir de ce moment, FL a été implémenté à l'aide de NGINX, du framework OpenResty et de LuaJIT. Si cela a très bien fonctionné pendant longtemps, ces dernières années, le système a commencé à montrer des signes de vieillissement. Nous devions consacrer de plus en plus de temps à corriger ou à contourner des bogues obscurs dans LuaJIT. La nature hautement dynamique et non structurée de notre code Lua, qui était un avantage lorsque nous avons commencé à implémenter rapidement la logique, est devenue une source d'erreurs et de retards lorsque nous avons essayé d'intégrer de grandes quantités de logique produit complexe. Chaque fois qu'un nouveau produit était lancé, nous devions passer en revue tous les autres produits existants pour vérifier s'ils pouvaient être affectés par la nouvelle logique.

Il était clair que nous devions repenser notre approche. Ainsi, en juillet 2024, nous avons effectué un premier commit pour une implémentation entièrement nouvelle et radicalement différente. Pour gagner du temps dans la recherche d'un nouveau nom, nous l'avons simplement appelée « FL2 » et avons bien sûr commencé à désigner la FL originale sous le nom de « FL1 ».



Rust et la modularisation rigide

Nous ne partions pas de zéro. Nous avons déjà publié un article sur la façon dont nous avons remplacé un autre de nos anciens systèmes par Pingora, qui est construit dans le langage de programmation Rust, à l'aide du runtime Tokio. Nous avons également publié un article sur Oxy, notre framework interne pour la création de proxys dans Rust. Nous écrivons beaucoup en Rust et nous sommes devenus assez bons dans ce domaine.

Nous avons développé FL2 dans Rust, sur Oxy, et avons créé un cadre modulaire strict pour structurer toute la logique de FL2.

Pourquoi Oxy ?

Lorsque nous avons décidé de développer FL2, nous savions que nous ne remplacions pas simplement un ancien système, mais que nous reconstruisions les fondations mêmes de Cloudflare. Cela signifiait que nous avions besoin de plus qu'un simple proxy ; nous avions besoin d'un cadre capable d'évoluer avec nous, de gérer l'immense échelle de notre réseau et de permettre aux équipes d'avancer rapidement sans sacrifier la sécurité ou les performances.

Oxy nous offre une combinaison puissante de performances, de sécurité et de flexibilité. Construit en Rust, il élimine toute une série de bogues qui affectaient notre FL1 basé sur Nginx/LuaJIT, tels que les problèmes de sécurité de la mémoire et les conflits d'accès aux données, tout en offrant des performances de niveau C. À l'échelle de Cloudflare, ces garanties ne sont pas un luxe, elles sont essentielles. Chaque microseconde gagnée par requête se traduit par des améliorations tangibles de l'expérience utilisateur, et chaque crash ou cas limite évité permet à Internet de fonctionner sans heurts. Les garanties strictes de Rust en matière de compilation s'accordent également parfaitement avec l'architecture modulaire de FL2, où nous appliquons des contrats clairs entre les modules du produit et leurs entrées et sorties.

Mais le choix ne se limitait pas au langage. Oxy est le fruit d'années d'expérience dans la création de proxys haute performance. Il alimente déjà plusieurs services Cloudflare majeurs, de notre Zero Trust Gateway à l'iCloud Private Relay d'Apple, nous savions donc qu'il pouvait gérer les divers modèles de trafic et combinaisons de protocoles que FL2 allait rencontrer. Son modèle d'extensibilité nous permet d'intercepter, d'analyser et de manipuler le trafic de la couche 3 à la couche 7, et même de décapsuler et de retraiter le trafic à différentes couches. Cette flexibilité est essentielle à la conception de FL2, car elle nous permet de traiter de manière cohérente tout le trafic, du HTTP au trafic IP brut, et de faire évoluer la plateforme pour prendre en charge de nouveaux protocoles et fonctionnalités sans avoir à réécrire les éléments fondamentaux.

Oxy est également doté d'un ensemble complet de fonctionnalités intégrées qui nécessitaient auparavant de grandes quantités de code sur mesure. Des éléments tels que la surveillance, les rechargements logiciels, le chargement et l'échange de configurations dynamiques font tous partie du cadre. Cela permet aux équipes produit de se concentrer sur la logique métier unique de leur module plutôt que de réinventer la plomberie à chaque fois. Cette base solide nous permet d'apporter des modifications en toute confiance, de les livrer rapidement et d'être sûrs qu'elles se comporteront comme prévu une fois déployées.

Redémarrages en douceur - pour que l'Internet continue de fonctionner

L'une des améliorations les plus importantes apportées par Oxy concerne la gestion des redémarrages. Tout logiciel en développement et en amélioration continus devra tôt ou tard être mis à jour. Dans le cas des logiciels de bureau, c'est facile : il suffit de fermer le programme, d'installer la mise à jour et de le rouvrir. Sur le web, c'est beaucoup plus compliqué. Nos logiciels sont utilisés en permanence et ne peuvent pas simplement s'arrêter. Une requête HTTP interrompue peut empêcher le chargement d'une page, et une connexion interrompue peut vous exclure d'un appel vidéo. La fiabilité n'est pas facultative.

Dans FL1, les mises à niveau impliquaient le redémarrage du processus proxy. Redémarrer un proxy signifiait mettre fin au processus dans son intégralité, ce qui interrompait immédiatement toutes les connexions actives. Cela était particulièrement pénible pour les connexions de longue durée telles que les WebSockets, les sessions de streaming et les API en temps réel. Même les mises à niveau planifiées pouvaient entraîner des interruptions visibles pour les utilisateurs, et les redémarrages imprévus lors d'incidents pouvaient être encore pires.

Oxy change cela. Il comprend un mécanisme intégré de redémarrage en douceur qui nous permet de déployer de nouvelles versions sans interrompre les connexions, dans la mesure du possible. Lorsqu'une nouvelle instance d'un service basé sur Oxy démarre, l'ancienne cesse d'accepter de nouvelles connexions mais continue à servir celles qui existent déjà, permettant à ces sessions de se poursuivre sans interruption jusqu'à leur fin naturelle.

Cela signifie que si vous avez une session WebSocket en cours lorsque nous déployons une nouvelle version, cette session peut se poursuivre sans interruption jusqu'à ce qu'elle se termine naturellement, plutôt que d'être interrompue par le redémarrage. Dans l'ensemble du parc Cloudflare, les déploiements sont orchestrés sur plusieurs heures, de sorte que le déploiement global est fluide et presque invisible pour les utilisateurs finaux.

Nous allons encore plus loin en utilisant l'activation des sockets...