Glossaire

Qu'est-ce que la limitation de débit ?

La limitation de débit est une défense côté serveur qui plafonne le nombre de requêtes qu'un seul client (identifié par IP, compte ou session) peut effectuer dans une fenêtre de temps donnée, utilisée pour protéger l'infrastructure, prévenir les abus et garantir une utilisation équitable des ressources.

Comprenez comment les sites web et les API limitent les clients à fort volume, les algorithmes derrière les limites de débit (token bucket, sliding window, fixed window), et comment les proxies rotatifs contournent les plafonds par IP.

Expliqué

La limitation de débit est la façon dont les serveurs se protègent contre les abus. Chaque API et site web public limite le nombre de requêtes qu'un seul client peut envoyer dans une fenêtre temporelle : `100 requêtes par IP par minute`, `5000 requêtes par clé API par heure`, `30 connexions par compte par jour`. Lorsqu'un client dépasse le plafond, le serveur renvoie une réponse 429 Too Many Requests (ou dans certains cas ralentit silencieusement les réponses, met la requête en file d'attente, ou commence à servir des CAPTCHAs).

Pour les charges de travail de scraping et de collecte de données, la limitation de débit est le plancher opérationnel qui détermine la vitesse à laquelle vous pouvez aller. La solution naïve, envoyer moins de requêtes, plafonne votre débit. La vraie solution consiste à distribuer les requêtes sur de nombreux identifiants (IP, comptes, ID de session) afin qu'aucun identifiant unique ne dépasse son plafond. C'est la raison d'être des proxies résidentiels en tant que catégorie de produit.

Les algorithmes de limitation de débit côté serveur se présentent sous plusieurs formes. Le token bucket permet au client d'accumuler des jetons à un rythme régulier jusqu'à un plafond, autorisant des pics jusqu'à la taille du plafond. La fenêtre glissante (sliding window) compte les requêtes dans une fenêtre temporelle mobile, lissant le plafond. La fenêtre fixe (fixed window) réinitialise le compteur aux limites de l'horloge (par minute, par heure). Chacune a des implications différentes sur la façon dont les scrapers doivent cadencer leurs requêtes.

Comment ça fonctionne

Pour chaque requête entrante, le serveur identifie le client (par IP, clé API, ID de compte ou jeton de session) et vérifie un compteur pour cet identifiant dans la fenêtre courante. Si le compteur est en dessous de la limite, la requête passe et le compteur s'incrémente. Si le compteur dépasse la limite, le serveur renvoie un 429 avec un en-tête `Retry-After` indiquant le temps d'attente.

La plupart des grandes API utilisent une combinaison d'identifiants : la même IP et le même compte atteignent des compteurs différents avec des limites différentes. Les règles de limitation de débit de Cloudflare, par exemple, peuvent définir une limite par IP, par chemin d'URL, par session ou par toute combinaison. Certains systèmes avancés utilisent des variantes de leaky-bucket ou de sliding-window-counter pour une application plus fluide.

Types

Token Bucket

Un seau se remplit de tokens à un rythme constant jusqu'à un plafond. Chaque requête consomme un token. Permet des pics jusqu'à la taille du seau, lissés dans le temps. L'algorithme le plus courant dans la limitation de débit des API modernes.

Leaky Bucket

Les requêtes entrent dans une file d'attente (seau) qui se vide à un débit fixe. Les requêtes excédentaires débordent et sont rejetées. Lisse les pics plus strictement que le token bucket.

Fenêtre fixe

Le compteur se réinitialise aux limites de l'horloge (chaque minute, chaque heure). Simple à mettre en œuvre, mais présente des problèmes de rafale aux limites de fenêtre (un client peut envoyer 2x le plafond en chevauchant deux fenêtres).

Fenêtre glissante

Le compteur examine les N dernières secondes plutôt que des fenêtres discrètes. Application plus fluide qu'avec une fenêtre fixe. Le journal à fenêtre glissante et le compteur à fenêtre glissante sont des variantes courantes.

Limitation de débit adaptative / comportementale

Les limites s'ajustent en fonction des schémas de requêtes et du score de risque. Utilisé par les fournisseurs anti-bot (Cloudflare, Datadome) — le même client peut être autorisé à 1000 requests/minute ou 10 selon le degré de 'réalisme' du trafic.

Cas d'utilisation courants

Protection des API publiques contre les abus
Prévention des attaques par bourrage d'identifiants (limites de débit à la connexion)
Gestion des coûts d'infrastructure à grande échelle
Application de niveaux d'utilisation équitables entre les clients
Ralentissement des scrapers et des abus de contenu
Limitation des tempêtes de nouvelles tentatives lors des pannes
FAQ

Questions fréquentes Questions FAQ

Questions fréquentes sur limitation de débit.

En distribuant les requêtes sur de nombreuses IP. Si une cible limite le débit à 60 requêtes par IP par minute et que vous effectuez une rotation par requête à travers un pool résidentiel de 10 000 IP, vous pouvez théoriquement atteindre 600 000 requêtes par minute contre la cible sans qu'aucune IP ne dépasse son plafond. En pratique, les signaux comportementaux comptent aussi, mais la rotation d'IP est la technique fondamentale.