Abonnez-vous pour recevoir des notifications sur les nouveaux articles :

Comment Cloudflare utilise la plus vaste collection de données de performances du monde pour rendre le réseau mondial le plus rapide du monde encore plus rapide

2025-09-26

Lecture: 7 min.
Cet article est également disponible en English, en Deutsch, en 日本語, en 한국어, en Español, en Nederlands et en 繁體中文.

Cloudflare exploite le réseau le plus rapide de la planète. Nous avons publié aujourd'hui une mise à jour décrivant comment nous repensons la technologie logicielle qui accélère chaque serveur de notre flotte, améliorant ainsi la rapidité dans le monde entier.

Cependant, notre travail ne s'arrête pas là. Pour améliorer encore la rapidité de notre réseau, nous devons également nous assurer que celui-ci gère rapidement les phénomènes de congestion, à l'échelle d'Internet, qui l'affectent chaque jour, en acheminant le trafic vers nos serveurs désormais plus rapides.

Depuis des années, nous investissons dans le contrôle de la congestion. Aujourd'hui, nous sommes ravis d'expliquer comment nous utilisons un super-pouvoir de notre réseau, l'immense base d'utilisateurs de notre offre gratuite, pour optimiser les performances et identifier la meilleure manière d'acheminer le trafic sur notre réseau pour tous nos clients, partout dans le monde.

Les premiers résultats ont montré une augmentation des performances, supérieures en moyenne de 10 % aux performances de référence antérieures. Nous avons atteint cet objectif en appliquant différentes méthodes algorithmiques, afin d'améliorer les performances en fonction des données que nous observons chaque jour sur Internet. Nous sommes ravis de commencer à déployer ces améliorations pour l'ensemble de nos clients.

Comment le trafic arrive-t-il sur notre réseau ?

Internet est une immense collection de réseaux interconnectés, chacun constitué de nombreuses machines (ou « nœuds »). La transmission des données implique de fragmenter ces dernières en paquets de petite taille, puis de les transférer d'une machine à une autre, via une « liaison ». Chacune de ces machines est connectée à de nombreuses autres, et chaque liaison a une capacité limitée.

Lorsque nous envoyons un paquet sur Internet, il effectue une série de « sauts » sur les liaisons entre A et B. À tout moment, une liaison (un « saut ») offre la plus faible capacité disponible pour ce chemin. Peu importe l'endroit où se trouve ce saut dans la connexion ; il deviendra le goulet d'étranglement.

Toutefois, il y a un défi : lorsque vous transmettez des données par Internet, vous ne savez pas quel itinéraire elles vont emprunter. En fait, chaque nœud décide lui-même de l'itinéraire par lequel il doit envoyer le trafic, et différents paquets transitant entre A et B peuvent emprunter des itinéraires totalement différents. La nature dynamique et décentralisée du système est ce qui rend Internet si efficace ; toutefois, elle rend également très difficile le calcul du volume de données pouvant être envoyées.  Alors, comment un système expéditeur peut-il savoir où se situe le goulet d'étranglement et à quelle vitesse envoyer les données ?

Entre les nœuds Cloudflare, notre produit Argo Smart Routing tire parti de notre visibilité du réseau mondial pour accélérer les communications. De même, lorsque nous établissons des connexions vers les serveurs d'origine des clients, nous pouvons tirer parti d'Argo et d'autres informations pour optimiser ces connexions. Cependant, la vitesse d'une connexion entre votre téléphone ou ordinateur portable (le client, ci-dessous) et le datacenter Cloudflare le plus proche dépend de la capacité du saut qui, dans la chaîne entre vous et Cloudflare, présente un goulet d'étranglement situé hors de notre réseau.

Que se passe-t-il lorsque trop de données arrivent en même temps ?

Si trop de données parviennent à un nœud d'un réseau situé sur le chemin d'une requête en cours de traitement, le système demandeur subit des délais, en raison de la congestion du chemin. Les données sont alors mises en file d'attente pendant un certain temps (entraînant le risque d'un phénomène appelé « bufferbloat »), ou certaines données sont tout simplement perdues. Les protocoles tels que TCP et QUIC réagissent à la perte de paquets en retransmettant les données, mais cela provoque un délai et peut même aggraver le problème, en surchargeant encore davantage une capacité limitée.

Si les fournisseurs d'infrastructure cloud, parmi lesquels figure Cloudflare, ne gèrent pas la congestion avec précision, ils risquent de surcharger le système, ralentissant ainsi le débit de données transmises. D'ailleurs, c'est ce qui s'est produit aux débuts d'Internet. Pour éviter ce problème, la communauté qui gère l'infrastructure d'Internet a développé des systèmes permettant de contrôler la congestion, permettant ainsi à chacun de transmettre ses données à tour de rôle, sans surcharger le réseau. Il s'agit d'un défi continuellement changeant, car le réseau devient toujours plus complexe et la recherche de la meilleure approche de mise en œuvre du contrôle de la congestion est une quête incessante. De nombreux algorithmes différents ont été développés, qui prennent différentes sources d'informations et de signaux, assurent l'optimisation selon une méthode particulière et répondent à la congestion de différentes manières.

Les algorithmes de contrôle de la congestion emploient un certain nombre de signaux pour estimer le débit d'envoi de trafic pertinent, sans savoir comment le réseau est configuré. Un signal important a été la perte. Lorsqu'un paquet est reçu, le système destinataire envoie un accusé de réception « ACK », indiquant au système expéditeur que le paquet a été reçu. Si le paquet est perdu en cours de route, le système expéditeur ne reçoit jamais l'accusé de réception et, après un délai d'expiration, considère le paquet comme perdu.

Des algorithmes plus récents ont utilisé des données supplémentaires. Il existe, par exemple, un algorithme populaire appelé BBR (« Bottleneck Bandwidth and Round-trip propagation time »), que nous utilisons pour une grande partie de notre trafic. À chaque connexion, cet algorithme tente d'élaborer un modèle du volume maximal de données pouvant être transmis durant une période donnée, en utilisant des estimations du temps aller-retour, ainsi que des informations sur les pertes.

L'algorithme dont l'utilisation est la plus pertinente souvent de la charge de travail. Par exemple, pour le trafic interactif, comme un appel vidéo, un algorithme privilégiant l'envoi d'un volume de trafic excessif peut entraîner l'accumulation de files d'attente, conduisant à une latence élevée et à une expérience vidéo insatisfaisante. Cependant, si on optimisait l'envoi de trafic uniquement pour ce scénario d'utilisation et on évitait ce phénomène en envoyant moins de trafic, le réseau n'utiliserait pas au mieux la connexion pour les clients effectuant des téléchargements en masse. Le résultat de l'optimisation des performances varie en fonction de nombreux facteurs différents.  Toutefois, nous avons de la visibilité sur bon nombre de ces facteurs !

L'algorithme BBR a représenté un développement intéressant dans l'approche du contrôle de la congestion, puisqu'il évoluait d'approches réactives, basées sur les pertes de paquets, vers une optimisation proactive, reposant sur des modèles. Il a ainsi permis d'améliorer considérablement les performances des réseaux modernes. Nos données nous offrent la possibilité d'aller encore plus loin, en appliquant différentes méthodes algorithmiques pour améliorer les performances. 

Comment pouvons-nous faire mieux ?

Tous les algorithmes existants sont contraints d'utiliser uniquement les informations collectées pendant la durée de vie de la connexion actuelle. Heureusement, nous savons à tout moment bien plus de choses que cela sur l'état d'Internet ! La visibilité dont dispose Cloudflare sur le trafic nous permet de voir bien plus que ce qu'un client ou un FAI pourrait observer à un moment donné.

Tous les jours, nous acheminons du trafic provenant de pratiquement tous les grands réseaux de la planète. Lorsqu'une requête entre dans notre système, nous savons avec quel appareil client nous communiquons, sur quel type de réseau repose la connexion et si nous nous adressons à des fournisseurs d'accès Internet (FAI) grand public ou à des fournisseurs d'infrastructure cloud.

Nous connaissons les schémas de charge d'Internet dans le monde entier, ainsi que les régions où nous pensons que les systèmes sont surchargés, que ce soit sur notre réseau ou hors de celui-ci. Nous connaissons les réseaux qui possèdent des propriétés stables, ceux qui présentent des pertes de paquets élevées en raison des connexions de données cellulaires, ainsi que ceux qui empruntent des liaisons satellites en orbite terrestre basse et modifient radicalement leurs itinéraires toutes les 15 secondes. 

Comment est-ce que ça fonctionne ?

Nous avons entrepris la migration de notre pile technologique réseau vers une nouvelle plateforme, reposant sur Rust, qui offre davantage de flexibilité pour expérimenter avec les différents paramètres algorithmiques que nous utilisons pour gérer le contrôle de la congestion. Ensuite, nous avions besoin de données.

Les données sur lesquelles reposent ces expériences doivent refléter la mesure que nous cherchons à optimiser, à savoir l'expérience utilisateur. Il ne suffit pas d'envoyer des données à pratiquement tous les réseaux de la planète ; nous devons également être capables d'évaluer l'expérience des clients. Alors, comment faisons-nous cela, à notre échelle ?

Tout d'abord, nous disposons de journaux « passifs » détaillés qui enregistrent la vitesse à laquelle les données peuvent être envoyées depuis notre réseau, ainsi que le temps que met le système destinataire à accuser réception. Ces données couvrent l'ensemble de notre trafic et nous donnent une idée de la rapidité avec laquelle les données ont été reçues par le client. En revanche, elles ne nous assurent pas d'être bien informés sur l'expérience utilisateur.

Ensuite, nous disposons d'un système permettant de collecter les données de mesures utilisateur réelles (Real User Measurement, RUM), qui enregistrent, dans les navigateurs web pris en charge, des informations concernant des indicateurs tels que le temps de chargement des pages (Page Load Time, PLT). Tout client Cloudflare peut activer cette fonctionnalité et recevra des informations détaillées dans son tableau de bord. Nous utilisons par ailleurs ces métadonnées sous une forme agrégée pour l'ensemble de nos clients et réseaux, afin de comprendre l'expérience que vivent réellement nos clients. 

Cependant, les données RUM ne sont disponibles que pour une petite proportion des connexions à l'échelle de notre réseau. Nous nous sommes donc efforcés de trouver un moyen de prédire les mesures RUM en extrapolant ces dernières à partir des données dont nous disposons uniquement dans les journaux passifs. Voici, par exemple, les résultats d'une expérience que nous avons réalisée en comparant deux algorithmes différents à une base de référence à complexité cubique.

Et voici la même échelle de temps, observée à travers la prédiction reposant sur nos journaux passifs. Les courbes sont très similaires, mais surtout, le rapport entre les courbes est très similaire. C'est énorme ! Nous pouvons utiliser un volume relativement faible de données RUM pour valider nos conclusions, mais surtout, nous pouvons optimiser notre réseau de manière beaucoup plus précise en utilisant le flux de données intégral extrait de nos journaux passifs.

Une extrapolation trop poussée perd en fiabilité, et c'est pourquoi nous travaillons également avec certains de nos plus grands clients pour améliorer notre visibilité du comportement du réseau du point de vue de leurs clients. Ceci nous permettra d'étendre encore davantage ce modèle prédictif et, en retour, nous serons en mesure de fournir à nos clients des informations sur la véritable expérience vécue par leurs clients, d'une manière qu'aucune autre plateforme ne peut proposer.

Et maintenant ?

Nous réalisons actuellement nos expériences et appliquons des algorithmes améliorés de contrôle de la congestion à l'ensemble du trafic QUIC de notre offre gratuite. À mesure que nous en apprendrons davantage, que nous vérifierons nos conclusions avec des clients plus complexes et que nous étendrons nos recherches au trafic TCP, nous déploierons progressivement cette approche à tous nos clients, pour l'ensemble du trafic, en 2026 et au-delà. Les conclusions ont conduit à une amélioration atteignant 10 % par rapport aux valeurs de référence !

Nous collaborons avec un nombre restreint d'entreprises pour tester ce service dans le cadre d'un programme d'accès anticipé. Si vous souhaitez en savoir plus, contactez-nous !

Nous protégeons des réseaux d'entreprise entiers, aidons nos clients à développer efficacement des applications à l'échelle d'Internet, accélérons tous les sites web ou applications Internet, repoussons les attaques DDoS, tenons les pirates informatiques à distance et pouvons vous accompagner dans votre parcours d'adoption de l'architecture Zero Trust.

Accédez à 1.1.1.1 depuis n'importe quel appareil pour commencer à utiliser notre application gratuite, qui rend votre navigation Internet plus rapide et plus sûre.

Pour en apprendre davantage sur notre mission, à savoir contribuer à bâtir un Internet meilleur, cliquez ici. Si vous cherchez de nouvelles perspectives professionnelles, consultez nos postes vacants.
RapiditéSemaine anniversaireIARapidité et fiabilité

Suivre sur X

Cloudflare|@cloudflare

Publications associées

29 septembre 2025 à 14:00

15 années d'aide à la construction d'un Internet meilleur : retour sur la semaine anniversaire 2025

Systèmes centraux propulsés par Rust, mises à jour post-quantiques, accès développeur pour étudiants, intégration PlanetScale, partenariats open source, programme de stages plus ambitieux que jamais....