Ce qu'est le rate limiting, les différences entre fenêtre fixe, fenêtre glissante, token bucket et leaky bucket, avec un simulateur en direct, le statut 429, Retry-After et un exemple Nginx.
Le rate limiting plafonne le nombre de requêtes qu'un visiteur, une clé ou une adresse IP peut envoyer sur une période donnée. Les requêtes au-delà du plafond sont refusées, généralement avec le statut HTTP 429 Too Many Requests et un en-tête Retry-After indiquant quand réessayer. Il protège les formulaires de connexion, les formulaires de contact et les API contre les afflux de requêtes et les factures qui s'envolent.
Les quatre algorithmes de rate limiting courants
Si votre site a une page de connexion, un formulaire de contact, un tunnel de paiement ou une API appelée par d'autres applications, quelqu'un finira par la bombarder, par accident ou volontairement. Le rate limiting est la règle qui définit à partir de quand c'est trop. Ci-dessous, vous pouvez cliquer sur des boutons pour envoyer des requêtes et voir chaque algorithme les accepter ou les refuser, puis copier une configuration Nginx fonctionnelle.
La RFC 6585 définit 429 Too Many Requests comme le statut d'un client qui a envoyé trop de requêtes en un temps donné. La réponse peut comporter un en-tête Retry-After indiquant au client combien de temps attendre.
Par défaut, le module limit_req répond aux requêtes refusées par un 503. Vous pouvez le remplacer par 429 avec la directive limit_req_status, ce que préfèrent la plupart des API car cela indique précisément à l'appelant ce qui s'est passé.
Pas encore. Les champs RateLimit et RateLimit-Policy proviennent d'un Internet-Draft d'un groupe de travail de l'IETF encore en cours en octobre 2026 ; certains services envoient donc plutôt les anciens en-têtes X-RateLimit. Considérez-les comme des indications utiles.
Un token bucket permet à un appelant de dépenser en rafale les jetons accumulés, puis de se caler sur le rythme de recharge. Un leaky bucket lisse le trafic en un débit de sortie fixe. La documentation de Nginx indique que son module limit_req utilise la méthode du leaky bucket.
Non. Il gère bien les abus provenant de quelques sources, mais un trafic réparti sur des milliers d'adresses nécessite aussi une protection chez votre hébergeur ou votre CDN. Le rate limiting est une couche, pas toute la défense.
Cette configuration autorise 5 requêtes par seconde par adresse IP sur le chemin de connexion, avec une rafale de 10 servie immédiatement, et répond aux requêtes en trop par 429 au lieu du 503 par défaut.
La zone de 10m stocke les compteurs ; la documentation indique qu'un mégaoctet contient environ 16 mille états de 64 octets.
Pour un seul serveur, un token bucket tient en quelques lignes. Stockez les compteurs dans un stockage partagé si vous utilisez plus d'un serveur.
Chaque clé reçoit 10 jetons qui se rechargent à raison de 1 par seconde. Un appel refusé reçoit un 429 et un Retry-After en secondes entières.
Statut 429 avec un Retry-After de 30 secondes.
Chaque algorithme autorise environ 5 requêtes toutes les 5 secondes (ou un seau de 5 qui avance à 1 par seconde). Envoyez des requêtes, laissez passer le temps et observez ce qui passe.
Algorithme
Fenêtre fixe
Fenêtre glissante
Token bucket
Leaky bucket
Envoyer 1 requête
Envoyer une rafale de {n}
Attendre 1 seconde
Réinitialiser
Temps : {v} s
Acceptées : {n}
Refusées avec 429 : {n}
Journal des requêtes
t={v}s acceptée
t={v}s refusée (429)
Aucune requête pour l'instant. Cliquez sur un bouton ci-dessus.
Un modèle pédagogique par pas d'une seconde. Les vrais limiteurs mesurent en millisecondes.
Commencer gratuitement · Sans carte bancaire