Limitation de débit et Throttling en Rust : Maîtriser les flux de données

Quand Rust rencontre la surcharge : pourquoi votre service « plante » ?

Imaginez que vous ayez écrit en Rust un service idéal pour les fortes charges. Il vole, utilise tous les avantages des abstractions à coût zéro et de la propriété de la mémoire. Mais voilà le problème — un client « gourmand » arrive et commence à bombarder votre serveur de milliers de requêtes par seconde. Que se passe-t-il ? La base de données plante ? La file d'attente s'étouffe ? Ou, pire encore, vous êtes banni par l'API externe que vous utilisez vous-même ?

En Rust, comme dans tout autre langage, on ne peut pas se passer de rate limiting (limitation de débit) et de throttling (étranglement). Ce n'est pas simplement une « bonne pratique » — c'est une question de survie de votre application en production. Mais Rust a une particularité : nous aimons tout faire efficacement et à partir de zéro. Cependant, il ne sera pas nécessaire de réinventer la roue — nous avons de puissants crates (bibliothèques) et des motifs élégants.

Dans cet article, nous verrons comment implémenter correctement la limitation des requêtes en Rust, en utilisant à la fois des algorithmes classiques (Token Bucket) et des approches asynchrones modernes. Vous apprendrez à protéger votre API contre les attaques DDoS, à ne pas dépasser les limites des services externes et à écrire votre propre throttler qui sera plus rapide qu'en Go ou Python.

Rate Limiting vs Throttling : quelle est la différence ?

Avant de plonger dans le code, clarifions une fois pour toutes les termes. On les confond souvent, mais la différence est cruciale.

\n
• Rate Limiting — c'est une politique de sécurité. Vous dites : « Le client X peut faire au maximum 100 requêtes par minute ». Si la limite est dépassée — vous renvoyez 429 Too Many Requests. C'est la protection de votre backend.
\n
• Throttling — c'est un mécanisme de contrôle de la vitesse. Vous décidez vous-même à quelle vitesse traiter les requêtes pour ne pas surcharger le CPU, les E/S ou la base de données. Le client peut envoyer 1000 requêtes, mais vous les traiterez à raison de 10 par seconde, les autres seront mises en file d'attente.
\n

En Rust, les deux approches peuvent être implémentées avec les mêmes outils, mais avec une logique différente. Nous allons voir les deux.

Algorithmes : Token Bucket et Leaky Bucket

Les algorithmes les plus populaires pour le rate limiting sont Token Bucket et Leaky Bucket. Ils sont simples comme bonjour, mais incroyablement efficaces.

Token Bucket (Seau de jetons)

Imaginez un seau dans lequel N jetons tombent chaque seconde. Quand une requête arrive, elle prend un jeton. Si le seau est vide — la requête est rejetée. Rust est idéal pour implémenter cet algorithme grâce aux opérations atomiques.

Leaky Bucket (Seau percé)

Ici, le seau a un trou dans le fond par lequel s'écoule un nombre fixe de requêtes par seconde. Les requêtes tombent dans le seau par le haut. Si le seau déborde — les requêtes en trop sont rejetées. Cet algorithme est meilleur pour lisser les pics de charge.

En Rust, nous n'écrirons pas ces algorithmes à la main (bien que ce soit instructif). Au lieu de cela, nous utiliserons le crate governor — la référence en matière de rate limiting dans l'écosystème Rust.

Pratique : Installer Governor

Le crate governor est une implémentation rapide, asynchrone et thread-safe de Token Bucket. Il supporte à la fois les modes synchrone et asynchrone, fonctionne avec tokio et async-std.

Ajoutez dans Cargo.toml :

[dependencies]\ngovernor = "0.6"\ntokio = { version = "1", features = ["full"] }\n

Et maintenant, écrivons un simple rate limiter pour un serveur HTTP basé sur hyper ou axum. Pour simplifier, utilisons axum.

use axum::{\n    extract::Request,\n    http::StatusCode,\n    middleware::{self, Next},\n    response::Response,\n    routing::get,\n    Router,\n};\nuse governor::{DefaultDirectRateLimiter, Quota, RateLimiter};\n