Rate Limiting en PHP : protéger son API des surcharges et des bots

Rate Limiting et Throttling en PHP : maîtrisez le flux de requêtes

Imaginez : vous lancez une API géniale pour votre service. Tout fonctionne parfaitement, jusqu'à ce qu'un client « fou » commence à bombarder votre serveur avec des milliers de requêtes par seconde. Ou pire encore, un bot scraper décide d'aspirer toute votre base de données. Ça vous parle ? Si non, vous avez de la chance. Mais il vaut mieux être prêt. C'est là qu'entrent en scène le rate limiting et le throttling – deux chevaliers qui protégeront votre backend des surcharges.

Dans cet article, nous allons voir comment implémenter la limitation de requêtes en PHP, examiner des exemples de code concrets et comprendre quelle méthode choisir pour votre projet. Spoiler : vous n'aurez pas à réinventer la roue, mais connaître les algorithmes de base est utile.

Rate Limiting vs Throttling : quelle différence ?

Ces termes sont souvent utilisés comme synonymes, mais il existe une nuance subtile entre eux.

\n
• Rate Limiting – une limite stricte. Vous dites : « Maximum 100 requêtes par minute ». Une fois la limite atteinte, le client reçoit un HTTP 429 Too Many Requests et va boire un café.
\n
• Throttling – un contrôle plus souple. Au lieu de bloquer, vous ralentissez simplement le traitement des requêtes au-delà de la limite, les mettez en file d'attente ou réduisez leur priorité.
\n

En pratique, le throttling en PHP est souvent implémenté via des délais (sleep) ou des files d'attente, tandis que le rate limiting repose sur le comptage des requêtes par unité de temps. Pour la plupart des passerelles API, une combinaison des deux approches est optimale.

Pourquoi c'est crucial pour votre projet ?

Il y a au moins trois raisons d'implémenter la limitation de requêtes PHP :

\n
• Protection contre les DDoS et les bots – même un simple script peut faire tomber un serveur si la fréquence des appels n'est pas contrôlée.
\n
• Répartition équitable des ressources – un client « gourmand » ne doit pas priver les autres utilisateurs du service.
\n
• Stabilité et prévisibilité – vous savez à quel pic de charge vous attendre et pouvez configurer votre infrastructure en conséquence.
\n

Algorithmes de Rate Limiting : choisir sa stratégie

Avant d'écrire du code, examinons trois algorithmes populaires. Chacun a ses avantages et ses inconvénients.

1. Fixed Window (Fenêtre fixe)

L'approche la plus simple. On divise le temps en segments (par exemple, par minutes). On mémorise le nombre de requêtes dans la fenêtre actuelle. Limite atteinte ? On bloque jusqu'à la fenêtre suivante.

Inconvénient : aux limites des fenêtres, un pic est possible – un client peut envoyer 100 requêtes à la fin d'une minute et 100 autres au début de la suivante, soit 200 en 2 secondes.

2. Sliding Window (Fenêtre glissante)

Un algorithme plus précis. Au lieu de segments fixes, on examine les N dernières secondes. Les requêtes « vieillissent » et sortent de la fenêtre. Cela élimine les pics aux limites.

3. Token Bucket (Seau de jetons)

Un algorithme élégant issu du monde des réseaux. Un « seau » contient des jetons. Chaque requête consomme un jeton. Les jetons se régénèrent à une vitesse définie. Si le seau est vide, la requête est rejetée. Idéal pour le throttling php, car il permet de petits pics de trafic.

Implémentation pratique : du simple au complexe

Passons au code. Commençons par un exemple basique avec des fichiers, puis examinons des solutions industrielles.

Rate Limiter basique avec fichiers (pour l'apprentissage)

Cet exemple utilise des fichiers pour stocker les compteurs. Pas adapté à la production, mais il illustre parfaitement le principe.

<?php\nclass SimpleRateLimiter {\n    private string $storageDir;\n    private int $maxRequests;\n    private int $windowSeconds;\n\n    public function __construct(string $storageDir, int $maxRequests = 100, int $windowSeconds = 60) {\n        $this->storageDir = rtrim($storageDir, '/') . '/';\n        $this->maxRequests = $maxRequests;\n        $this->windowSeconds =