Rate limiting begrænser hvor mange requests en klient kan lave inden for et tidsvindue. Du anvender det på flere lag fordi hvert lag ser noget forskellige, og du grupperer det efter hvad der identificerer angriberen.
Rate limiting begrænser hvor mange requests en klient kan lave inden for et tidsvindue. Du anvender det på flere lag fordi hvert lag ser noget forskellige, og du grupperer det efter hvad der identificerer angriberen.
429 Too Many Requests med Retry-After så klienter trækker sig pænt tilbage i stedet for at hamre væk.# Define a shared-memory zone keyed by client IP.
# rate=10r/s = the steady refill rate (token bucket).
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
server {
location /api/ {
# burst=20: allow a short spike of 20 queued requests
# nodelay: serve the burst immediately instead of spacing it out
limit_req zone=api burst=20 nodelay;
# Return 429 (not the default 503) so clients see a rate-limit signal
limit_req_status 429;
proxy_pass http://backend;
}
}
Her genopfyldes hver IP ved 10 requests/sekund, må burst op til 20, og alt over det får 429.
Rate limiting er dit billigste, altid-tændt forsvar mod Layer 7 floods, credential stuffing og løbske scrapers. At lag det (edge for volumen, proxy for origin, app for forretningslogik) og gruppere det korrekt stopper angribere mens rigtige brugere — og legitime burst — passerer uberørt. At sætte grænser fra rigtige baselines er hvad der holder det fra at blive et blackout af din egen fremstilling.
Et bibliotek af IT-interviewspørgsmål med detaljerede svar — fra Junior til Senior.
Donér