---
title: Rate Limiting
created: 2026-06-06
updated: 2026-06-06
type: concept
tags: [tech, security, architecture]
confidence: high
contested: false
sources: [synthesized]
---
# ⏱️ Rate Limiting

## Définition Courte
Mécanisme qui **limite le nombre de requêtes** qu'un client peut faire sur une période donnée, pour protéger un service contre les abus et les surcharges.

## Explication Détaillée
**Algorithmes courants** :
- **Fixed Window** : compteur par fenêtre de temps (ex: 100 req/minute). Simple, mais burst aux limites.
- **Sliding Window** : fenêtre glissante, plus précis.
- **Token Bucket** : réservoir de tokens, refillé à rythme constant. Gère bien les bursts.
- **Leaky Bucket** : débit de sortie constant, lisse les pics.

**Niveaux d'application** :
- **L4 (TCP/UDP)** : limite de connexions par IP.
- **L7 (HTTP)** : limite de requêtes par route, utilisateur, ou IP.
- **API métier** : ex: 5 publications par heure par user.

Headers HTTP standards : `X-RateLimit-Limit`, `X-RateLimit-Remaining`, `X-RateLimit-Reset`, `Retry-After`.

## Cas d'Usage
- Protection contre les attaques par force brute (login).
- Empêcher le scraping massif d'une API publique.
- Protéger un backend LLM coûteux (limite de tokens/minute).
- Éviter qu'un client monopolise un service partagé.

## Outils Liés
- **Redis** (Token Bucket rapide).
- **NGINX** (`limit_req`, `limit_conn`).
- **Traefik** (plugins rate-limit).
- **Cloudflare** (rate limiting global).

## Pages Liées
- [[api-gateway]]
- [[concepts-web]]
- [[checklist-mise-en-production]]
- [[securisation-home-lab]]

## Questions Ouvertes
- Comment différencier un bon client rapide d'un attaquant ?
- Le rate limiting au niveau réseau (L4) est-il encore utile à l'ère du HTTPS everywhere ?

## Liens
- [[load-shedding]]