Eén script met fouten roept uw ​​API in een strakke lus aan. Zonder grenzen kan het de service voor elke andere gebruiker vertragen of een hoge cloudrekening opleveren. Het beperken van de API-snelheid is de vangrail die ervoor zorgt dat één klant niet meer dan zijn eerlijke deel neemt.

Om te laten zien hoe de algemene algoritmen zich gedragen, hebben we kleine Python-versies geschreven en deze gesimuleerde verzoektimings gegeven. De onderstaande resultaten zijn afkomstig van die run. Ze leren modellen, geen productiecode, en echte gateways hebben meer functies.

Wat is snelheidsbeperking?

Snelheidslimiet telt verzoeken per klant en wijst verzoeken af ​​of vertraagt ​​deze boven een overeengekomen limiet, zoals 100 verzoeken per minuut. Een verwant idee, throttling, betekent vaak dat verzoeken worden vertraagd in plaats van afgewezen. Een quotum is doorgaans een groter bedrag voor een langere periode, zoals 10.000 oproepen per maand met een tariefplan.

Waarom API’s het nodig hebben

• Stabiliteit: verkeerspieken kunnen databases of downstream-services niet overweldigen.
• Eerlijkheid: De ene zware klant kan de andere niet uithongeren.
• Beveiliging: limieten vertragen inlogpogingen met brute kracht en scraping.
• Kostenbeheersing: dure operaties, zoals het aanroepen van AI-modellen, blijven binnen het budget.

Snelheidsbeperking is een kerncontrole in de OWASP API Security Top 10, onder onbeperkt gebruik van bronnen. Onze API-testen met Postman gids laat zien hoe u de herhaalde verzoeken kunt verzenden die nodig zijn om dit te controleren.

Token emmer

Stel je een emmer voor die maximaal 5 tokens kan bevatten. Voor elk verzoek is een token nodig. Tokens worden bijgevuld met 1 per seconde, en de emmer kan nooit meer dan 5 bevatten. Als de emmer leeg is, wordt het verzoek afgewezen.

class TokenBucket:
    def __init__(self, capacity, refill_per_sec):
        self.capacity = capacity
        self.rate = refill_per_sec
        self.tokens = capacity
        self.last = 0.0

    def allow(self, now):
        elapsed = now - self.last
        self.tokens = min(self.capacity, self.tokens + elapsed * self.rate)
        self.last = now
        if self.tokens >= 1:
            self.tokens -= 1
            return True
        return False

We hebben zeven verzoeken tegelijk verzonden, en later meer:

burst of 7 at t=0:  [True, True, True, True, True, False, False]
t=2.0:              [True, True, False]
t=10:               5 allowed of 10

De eerste 5 gingen als een klap door, daarna was de emmer leeg. Twee seconden later waren er 2 tokens bijgevuld, dus er kwamen nog 2 verzoeken voorbij. Na een lange pauze was de bucket weer vol, maar de maximumlimiet was 5. Dit burst-and-steady-gedrag past bij echt verkeer, en daarom zijn token-buckets gebruikelijk in API-gateways. De leaky bucket is een nauwe verwant die verzoeken met een vaste snelheid verwerkt, waardoor de uitvoer wordt afgevlakt in plaats van bursts toe te staan.

Vast raam versus schuifraam

Een teller met een vast venster is de eenvoudigste aanpak: sta tien verzoeken per minuut toe en reset de teller wanneer de minuut verandert. Het heeft een bekende fout aan de grens. We hebben 10 verzoeken verzonden met een tijdsduur van 59,9 seconden en nog eens 10 met een tijdsduur van 60,0 seconden, met een limiet van 10 per periode van 60 seconden:

fixed window allowed around boundary: 20 of 20
sliding log allowed around boundary:  10 of 20

Het vaste venster stond alle twintig verzoeken binnen een tiende van een seconde toe, het dubbele van de beoogde snelheid, omdat ze in twee verschillende vensters vielen. Een sliding log onthoudt de tijd van elk recent verzoek en telt die van de afgelopen 60 seconden, zodat er terecht slechts 10 werden toegestaan.

De wisselwerking is het geheugen. Een glijdend logboek slaat een tijdstempel per verzoek op. De schuifraamteller is een populaire middenweg. Het schat de snelheid door de huidige en vorige venstertellingen te combineren, waarbij weinig geheugen en een goede nauwkeurigheid wordt gebruikt.

Vergelijking van algoritmen

Waardoor te beperken

• API-sleutel of gebruikers-ID: de eerlijkste optie voor geverifieerde API’s.
• IP-adres: handig voor openbare eindpunten, maar veel gebruikers kunnen één IP-adres delen en aanvallers kunnen deze wisselen.
• Eindpunt: dure handelingen, zoals zoeken, exporteren of inloggen, verdienen strengere limieten.
• Planniveau: gratis en betaalde klanten krijgen vaak verschillende limieten.

Inlogeindpunten hebben speciale zorg nodig. Beperk zowel per account als per IP, zodat aanvallers hun gissingen niet zomaar over veel IP’s of veel accounts kunnen verspreiden.

Het 429-antwoord

Wanneer een client de limiet overschrijdt, retourneert u HTTP 429 Too Many Requests, niet 500 of 403. Voeg headers toe die de client vertellen wat er is gebeurd en wanneer hij het opnieuw moet proberen. Onze simulatie produceerde deze set voor een klant zonder verdere verzoeken:

HTTP/1.1 429 Too Many Requests
RateLimit-Limit: 100
RateLimit-Remaining: 0
RateLimit-Reset: 30
Retry-After: 30

Retry-After is een standaard HTTP-header. De RateLimit-* headers komen uit een IETF-concept en veel API’s gebruiken hun eigen X-RateLimit-* varianten. Wat je ook kiest, documenteer het. Zie ons Cheatsheet voor HTTP-statuscodes voor meer informatie over statuscodes.

Als opdrachtgever omgaan met grenzen

Als u het onmiddellijk opnieuw probeert na een 429, wordt het nog erger. Als duizenden clients dit op hetzelfde moment doen, raken ze de server in gesynchroniseerde golven. De oplossing is exponentiële back-off met jitter: wacht langer na elke fout en voeg willekeur toe.

def backoff(attempt, base=0.5, cap=30, rng=random.Random(4)):
    return round(min(cap, base * 2 ** attempt) * rng.random(), 2)

[backoff(a) for a in range(6)]
# [0.12, 0.1, 0.79, 0.62, 0.53, 6.43]

Dit is ‘full jitter’: een willekeurige wachttijd tussen nul en een exponentieel groeiend plafond. Het wachten ziet er onregelmatig uit, en dat is het punt. Klanten spreiden zich uit in plaats van het samen opnieuw te proberen. We hebben de willekeurige generator geplaatst zodat de uitvoer kon worden gereproduceerd.

Gedistribueerde snelheidsbeperking

Omdat er meerdere API-servers achter een load balancer staan, kan elke server die op zichzelf rekent, een client de limiet laten overschrijden door verzoeken over hen heen te verspreiden. Teams bewaren tellers meestal in een gedeelde winkel zoals Redis, met atomaire bewerkingen of een kort script, zodat twee servers niet allebei het laatste token kunnen pakken. Gateways zoals Kong, NGINX, Envoy en cloud API-gateways bieden dit als configuratie. We hebben voor dit artikel geen gedistribueerde installatie uitgevoerd.

Tarieflimieten testen

• Stuur verzoeken tot de limiet en bevestig dat ze slagen.
• Stuur er nog één en bevestig een 429 met de juiste headers.
• Wacht op de resettijd en bevestig dat de verzoeken opnieuw slagen.
• Controleer de limieten per sleutel: het gebruik van de ene client mag de andere niet blokkeren.
• Test de grens tussen vensters op het dubbele burst-probleem.
• Gebruik een laadtool, zoals beschreven in belastingtesten versus stresstesten, om het gedrag onder zware gelijktijdigheid te controleren.

In unit-tests injecteer je de huidige tijd, zoals onze simulatie doet met now, zodat tests nooit hoeven te slapen.

Grenzen ontwerpen waarmee gebruikers kunnen leven

Het kiezen van de cijfers is net zo belangrijk als het kiezen van het algoritme. Begin vanuit echt verkeer: kijk hoeveel verzoeken uw zwaarste legitieme klanten per minuut doen, en stel daar comfortabel limieten boven. Een limiet die normaal gebruik blokkeert, creëert supporttickets en geen veiligheid.

• Publiceer de limieten in uw API-documentatie, per eindpunt en per abonnement.
• Waarschuw voordat u blokkeert. Headers die de resterende verzoeken weergeven, zorgen ervoor dat goed opgevoede clients vanzelf langzamer gaan werken.
• Bied alternatieven voor zware polling, zoals webhooks, bulkeindpunten of grotere pagina’s.
• Bewaak 429-tarieven. Een plotselinge stijging kan een aanval betekenen, een clientrelease met fouten of limieten die nu te krap zijn.
• Sta opzettelijk uitzonderingen toe, bijvoorbeeld verhoogde limieten voor een partner, vastgelegd in de configuratie in plaats van hardgecodeerd.

Bepaal ook wat er gebeurt met verzoeken die net over de limiet binnenkomen. Sommige API’s zetten een klein aantal extra verzoeken kort in de wachtrij in plaats van deze af te wijzen, waardoor korte pieken worden gladgestreken. Anderen geven voorrang aan essentiële eindpunten, zoals betalingen, boven minder kritische eindpunten zoals analyses, zodat belangrijk verkeer blijft stromen wanneer het systeem onder druk staat.

Tot slot

Een goede tariefbeperking is een contract tussen API en klant. De server kiest een eerlijk algoritme, meestal een token-bucket of een schuifvenster, en legt de limieten duidelijk uit met een 429 en Retry-After. De cliënt respecteert die signalen en trekt zich met jitter terug. Begin met royale limieten per API-sleutel, houd het werkelijke gebruik in de gaten en verscherp deze alleen waar dat nodig is.

Veelgestelde vragen

Blijf leren