À mesure que les architectures pilotées par les API deviennent la colonne vertébrale des expériences numériques modernes, sécuriser ces points de terminaison contre les abus, les attaques de robots et les pics de trafic soudains n'est plus une option, c'est une nécessité. L'un des outils les plus efficaces dans l'arsenal d'un ingénieur est la limitation de débit (Rate Limiting). Cependant, le choix de l'algorithme approprié peut avoir un impact significatif sur les performances du système et l'expérience utilisateur. Dans cet article, nous plongeons au cœur de deux stratégies parmi les plus répandues : l'algorithme du Bucket de jetons et l'approche de la Fenêtre glissante (Sliding Window Log).
Pourquoi la limitation de débit est essentielle
Avant de sélectionner un algorithme, il est essentiel de comprendre les menaces que nous cherchons à atténuer. La limitation de débit sert trois objectifs principaux : protéger les services backend contre la surcharge, prévenir les abus malveillants tels que les attaques par force brute, et garantir une utilisation équitable parmi les clients dans les environnements multi-locataires. Sans ces contrôles, un seul client malveillant peut consommer toutes les ressources disponibles, entraînant une déni de service (DoS) pour les utilisateurs légitimes.
L'algorithme du Bucket de jetons : Efficacité face aux pics
L'algorithme du Bucket de jetons est largement apprécié pour sa simplicité et sa capacité à gérer les pics de trafic avec souplesse. Imaginez un seau d'une capacité fixe. Des jetons sont ajoutés au seau à un taux constant. Chaque requête entrante consomme un jeton. Si le seau est vide, la requête est rejetée ou retardée.
Caractéristiques clés
- Gestion des pics : Contrairement aux compteurs à fenêtre fixe rigides, les buckets de jetons permettent de courts pics de trafic jusqu'à la capacité du seau.
- Débit lisse : Sur une période donnée, le débit moyen correspond au taux de remplissage.
- Faible surcharge : Il nécessite une mémoire minimale, ce qui le rend idéal pour les systèmes distribués où le partage d'état est coûteux.
Concept de mise en œuvre
Lors de la mise en œuvre de cela dans une passerelle API comme NGINX ou Kong, vous configurez généralement un taux qui définit la vitesse à laquelle les jetons sont rechargés. Voici un extrait de configuration conceptuel pour une passerelle basée sur Lua :
-- Configuration du Bucket de jetons
local token_bucket = require "resty.token_bucket"
-- Définir la capacité du seau et le taux de remplissage
local bucket = token_bucket:new({
capacity = 100, -- Taille maximale du pic
refill_rate = 10, -- Jetons par seconde
key = "client_ip" -- Limite de débit par adresse IP
})
if bucket:consume() then
-- Requête autorisée
return ngx.HTTP_OK
else
-- Limite de débit dépassée
return ngx.HTTP_TOO_MANY_REQUESTS
end
La Fenêtre glissante (Sliding Window Log) : Précision dans le suivi
Bien que le Bucket de jetons soit excellent pour lisser le trafic, il peut parfois être trop permissif ou imprécis lors de changements rapides du volume de requêtes. La Fenêtre glissante (Sliding Window Log, souvent appelée Sliding Window Counter) offre une mesure plus précise des taux de requêtes sur une période de temps glissante.
Fonctionnement
Cet algorithme maintient une liste (journal) des horodatages de chaque requête dans la fenêtre actuelle. Lorsqu'une nouvelle requête arrive, le système vérifie le journal, supprime les horodatages plus anciens que la taille de la fenêtre (par exemple, les 60 dernières secondes) et compte les entrées restantes. Si le dépassement de la limite est atteint, la requête est refusée.
Compromis
L'inconvénient principal de la Fenêtre glissante est la consommation de mémoire. Stocker un horodatage pour chaque requête peut devenir coûteux à de forts volumes de trafic. Cependant, elle permet d'éviter l'« effet de bord » observé dans les compteurs à fenêtre fixe, où les pics de trafic au début d'une nouvelle fenêtre peuvent surcharger le backend deux fois plus que d'habitude.
Choisir la bonne stratégie
Alors, laquelle choisir ? Si votre API doit absorber des pics de trafic soudains provenant de campagnes marketing ou d'événements viraux, le Bucket de jetons est généralement le meilleur choix grâce à sa flexibilité et à sa faible empreinte mémoire. Inversement, si vous construisez un système de facturation strict ou une API avec des plafonds rigides où chaque requête compte précisément, la Fenêtre glissante offre le contrôle granulaire nécessaire pour appliquer les limites avec précision.
Conclusion
Mettre en œuvre une limitation de débit robuste est une pierre angulaire de la sécurité des applications. Que vous optiez pour la tolérance aux pics du Bucket de jetons ou pour la précision de la Fenêtre glissante, comprendre les mécanismes sous-jacents vous permet de configurer efficacement votre passerelle API. En équilibrant performances, utilisation de la mémoire et exigences de sécurité, vous pouvez protéger votre infrastructure tout en maintenant une expérience fluide pour vos utilisateurs.