Cloudflare a culminé l’une de ses refontes les plus profondes depuis sa création : FL2, une nouvelle implémentation du « cerveau » qui orchestre la sécurité et la performance de son réseau mondial. Construite en Rust sur le framework interne Oxy, FL2 remplace progressivement l’ancien FL1 (NGINX/OpenResty/LuaJIT) et propose désormais un –10 ms en réponse médiane ainsi qu’un +25 % en performances lors de tests indépendants. De plus, elle réduit de moitié la consommation de CPU et de mémoire, renforce la sécurité dès la conception et accélère le déploiement de nouvelles fonctionnalités.

Parallèlement, l’entreprise a actualisé son rapport sur la vitesse : elle affirme aujourd’hui être le réseau le plus rapide dans 48 % des 1000 principales réseaux « eyeball » (opérateurs avec la plus grande base d’utilisateurs) entre novembre 2024 et mars 2025, contre 44 % lors du précédent bilan. La progression est particulièrement visible en Afrique — grâce à des déploiements Edge Partner en dernière étape — et sur des marchés comme Japon, où l’écart avec le second fournisseur dépasse déjà 5 % en p95 de connexion TCP. Au Canada, la course s’annonce très serrée, avec seulement environ 1 ms de différence entre les trois premiers.

Pourquoi réécrire le « cerveau » du réseau

Pendant 15 ans, FL1 a accumulé une logique de sécurité et d’accélération (WAF, DDoS, règles, routing vers les Workers et R2…). Cette flexibilité a engendré des coûts croissants : acoplamentos complexes, latence additionnelle à chaque ajout de produit, ainsi qu’un entretien délicat en raison de bugs subtils de LuaJIT. Le diagnostic a été clair : pour maintenir de nouveaux produits sans subir cette pénalité de latence, il fallait repenser la base.

FL2 : Rust + Oxy + modules avec contrats stricts

Rust dans le noyau. Rust offre une sécurité mémoire et des performances proches de C, avec des vérifications en compilation qui éliminent des classes entières de défaillances (débordements, data races). Sur cette base, Oxy — le cadre interne de proxies haute performance — fournit une « plomberie » réutilisable : télémétrie, recours à chaud, configuration dynamique et extensibilité de Niveau 3 à Niveau 7.

Architecture modulaire. Toute la logique du produit est organisée en modules avec des phases définies, des entrées/sorties typées, et une règle d’or : les modules ne font pas d’E/S directe. Si un module doit sortir des données vers un autre, il doit l’indiquer explicitement. Le compilateur valide ces contrats et évite les dépendances implicites. Résultat : moins de travail inutile, moins de latence et moins de régressions lors de l’introduction de nouveaux produits.

Filtres par requête. Chaque module définit des filtres pour décider quand il doit s’exécuter. Le système ne sélectionne que ce qui est nécessaire pour chaque requête, supprimant le « coût fixe » lié à chaque produit qui ralentissait FL1.

Redémarrages sans coupure. Grâce à Oxy et systemd socket activation, les déploiements sont effectués sans interrompre les WebSockets, streams ou API en temps réel : le nouveau processus démarre, l’ancien cesse d’accepter de nouvelles connexions mais continue de traiter celles en cours jusqu’à leur fin naturelle.

Migration sans interruption : Rust dans FL1, tests en masse et mécanismes de secours

• Modules Rust dans FL1. Pour éviter de gérer deux versions par produit, Cloudflare a permis d’exécuter des modules Rust dans OpenResty. Cela a permis aux équipes de migrer la logique sans suspendre les livraisons.
• Tests end-to-end à grande échelle. Le système Flamingo lance des milliers de tests simultanés contre des environnements de préproduction et de production, comparant FL1 et FL2 en termes de comportement, d’utilisation des ressources et d’indicateurs de niveau de service. Les déploiements progressifs sont automatiquement “pausés” ou “reconvertis” si un problème est détecté.
• Vérification de sécurité. Si FL2 reçoit une requête qu’il ne peut traiter, il la « cède » à FL1 (fallback au niveau réseau). Cela réduit le risque tout en augmentant la part de trafic sur FL2, permettant de comparer continuellement les sorties pour garantir une équivalence fonctionnelle.

Aujourd’hui, la majorité des clients utilisent déjà FL2. La prochaine étape est la migration complète du service de terminaison HTTP/TLS (toujours sous NGINX), prévue pour 2026, avec l’arrêt définitif de FL1.

Ce que signifient vraiment les chiffres (au-delà des métriques)

• –10 ms en médiane et des pics réduits en p95/p99 se traduisent par une meilleure conversion en commerce en ligne, moins d’abandons en médias, et une réduction du jank dans les applications en temps réel.
• < ½ CPU et mémoire libèrent des marges pour développer de nouvelles fonctionnalités (plus d’inspections, plus de règles, plus de Workers) sans pénaliser la latence.
• Feedback en 48 heures (contre plusieurs semaines auparavant) permettant de réagir rapidement aux besoins des clients stratégiques et d’adapter le produit au marché sans friction organisationnelle.

Où la vitesse se traduit concrètement

• Afrique. Edge Partner (points de présence intégrés dans les ISP de dernière étape) évite les détours vers des hubs distants.
• Japon. Plus d’emplacements et de peering local expliquent l’avantage face au second fournisseur.
• Canada. La compétition est féroce : à peine 1 ms sépare les trois principaux fournisseurs.

Sécurité par design et par processus

Rust réduit la surface d’erreurs mémoire ; l’architecture modulaire limite l’impact des changements. Pourtant, Cloudflare maintient des standards stricts : linting rigoureux, code review, batteries de tests et politique d’investigation de tout crash inexplicable. La combinaison donne moins d’incidents et plus de temps pour analyser la cause racine en cas de problème.

Feuille de route

• Achèvement de la migration HTTP/TLS en Rust et arrêt de FL1 prévu début 2026.
• Optimisation des interconnexions entre modules, extension du support aux trafics non-HTTP (RPC, streams) et poursuite de la réduction des microsecondes via RUM et peering ciblé là où les données montrent un potentiel d’amélioration.

Conclusion

FL2 n’est pas simplement « Rust pour Rust ». C’est une architecture + processus + opération conçus pour atteindre trois objectifs majeurs : moins de latence, plus de sécurité, et une livraison plus rapide. Un « cerveau » modulaire exécutant uniquement ce qui est nécessaire, des proxies pouvant redémarrer sans couper de sessions, et un réseau qui mesure sa propre performance pour ajuster ses investissements expliquent cette avancée : un –10 ms en médiane, +25 % de rendement, et un leadership dans presque la moitié des réseaux majeurs du globe. Ce qui reste difficile à réaliser, mais simple à dire : identifier là où ils ne sont pas number 1, le corriger, et en parler en toute transparence.

Questions fréquentes

Q : Qu’est-ce que FL2 précisément et en quoi améliore-t-il FL1 ?
R : FL2 est la nouvelle plateforme d’orchestration de Cloudflare, codée en Rust sur Oxy. Elle remplace FL1 (NGINX/OpenResty/LuaJIT) avec modules typés, filtres par requête et redémarrages sans coupure. Résultat : –10 ms de latence médiane, +25 % de performances, et moins de la moitié des ressources CPU/mémoire.

Q : Pourquoi utiliser Rust pour un plan de données à grande échelle ?
R : Pour sécurité mémoire (moins de crashes et de « use-after-free ») et de performance. En associé à Oxy, Rust permet recours à chaud, configuration dynamique et sert de base commune pour des produits très variés, du Zero Trust au CDN.

Q : Comment FL2 évite-t-il de rompre des connexions en production ?
R : Avec des redémarrages gracieux et systemd socket activation : le nouveau processus démarre, l’ancien continue d’attendre la fin des connexions en cours. Ainsi, WebSockets et streams ne sont pas interrompus lors des déploiements ou correctifs à chaud.

Q : Quel rôle jouent les Edge Partner dans l’amélioration de la vitesse ?
R : Ils rapprochent le point de service de l’utilisateur dans les réseaux de dernière étape, réduisant ainsi les sauts et la latence, notamment en Afrique et au Japon.

Q : Comment Cloudflare décide-t-il où investir pour améliorer la vitesse ?
R : En utilisant RUM et des comparatifs continus avec d’autres CDN (par exemple, p95 de connexion TCP). En cas de retards dans une région ou un ASN, on priorise peering, capacité ou déploiement de nouveaux points de présence.

Q : Que change pour mon site ou API si je suis client ?
R : Vous devriez observer de meilleurs TTFB et une moins grande variabilité en heures de pointe. Aucun changement ne nécessite votre intervention : FL2 reste transparent pour l’utilisateur final.

Q : Quand toute la plateforme sera-t-elle « en Rust » ?
R : La migration principale est terminée ; il ne reste plus que la finalisation de HTTP/TLS et l’extinction de FL1, prévues pour début 2026.

Q : La modularité n’engendre-t-elle pas un surcoût ?
R : Au contraire : les filtres par requête empêchent l’exécution de modules non pertinents. Moins de travail total → moins de latence et meilleur usage de CPU/mémoire.

Q : Quelles implications cela a-t-il pour la sécurité et la conformité ?
R : Les contrats typés et modules limités réduisent le risque de changements latéraux. Avec des revues, des tests et de la télémétrie, la tracéabilité s’améliore pour audits et gestion d’incidents.