Algorithmes de limitation du débit

La limitation du débit plafonne le nombre de requêtes qu’un client peut effectuer pendant une période donnée. Elle protège votre API contre les abus, les clients hors de contrôle et les pics de trafic accidentels, tout en répartissant équitablement la capacité entre les utilisateurs.

Depuis .NET 7, ASP.NET Core fournit un intergiciel de limitation du débit intégré dans Microsoft.AspNetCore.RateLimiting, avec quatre algorithmes intégrés.

L’algorithme de fenêtre fixe autorise N requêtes par bloc de temps fixe. Lorsque le bloc se termine, le compteur revient à zéro.

Cette approche est simple, mais les rafales à la limite entre deux fenêtres peuvent brièvement doubler le débit effectif.

La fenêtre glissante atténue le problème des limites entre fenêtres en divisant la fenêtre en segments et en faisant avancer les segments arrivés à expiration, de sorte que la limite s’applique sur toute fenêtre continue.

Le seau de jetons contient des jetons. Chaque requête en consomme un, et les jetons sont réapprovisionnés à un rythme régulier. Il autorise de courtes rafales allant jusqu’à la capacité du seau, tout en maintenant une moyenne à long terme.

Le limiteur de concurrence est différent : il plafonne le nombre de requêtes en cours de traitement au même moment, et non par unité de temps. Il est idéal pour protéger les opérations coûteuses.

Chaque limiteur peut mettre en file d’attente les requêtes qui dépassent la limite au lieu de les rejeter immédiatement. QueueLimit définit la taille de la file et QueueProcessingOrder définit l’ordre de traitement (les plus anciennes ou les plus récentes en premier).

Adaptez l’algorithme à l’objectif :

• Fenêtre fixe : la solution la plus simple, suffisante dans de nombreux cas.
• Fenêtre glissante : plus régulière, elle évite les rafales aux limites des fenêtres.
• Seau de jetons : il autorise des rafales contrôlées.
• Concurrence : elle limite la charge simultanée, et non le débit.

Les limites sont appliquées par clé de partition — généralement l’utilisateur, la clé d’API ou l’adresse IP — afin qu’un client bruyant ne puisse pas épuiser le quota de tout le monde. Une partition unique et partagée limiterait tout le trafic conjointement.

Une requête rejetée renvoie HTTP 429 Too Many Requests. Une API bien conçue renvoie également un en-tête Retry-After indiquant au client quand réessayer.

Ces notions sont liées : la limitation du débit encadre la fréquence à court terme, les quotas encadrent les totaux sur une période plus longue (par jour ou par mois), et la régulation ralentit les requêtes au lieu de les rejeter. L’intergiciel se concentre sur la limitation du débit.

Vérifiez votre compréhension des algorithmes.

Vous avez découvert les concepts de limitation du débit :

• Quatre algorithmes : fenêtre fixe, fenêtre glissante, seau de jetons et concurrence.
• Le seau de jetons autorise les rafales ; la concurrence plafonne la charge simultanée.
• Les limites sont appliquées par clé de partition ; les files d’attente absorbent les dépassements.
• Les requêtes rejetées reçoivent 429 avec Retry-After.

Ensuite : configurer l’intergiciel.