Forklaret satsbegrænsende: Beskyt din API uden at blokere rigtige brugere
Rate begrænsende stopper en dårlig skuespiller - eller en buggy script - fra hamring dit websted i jorden, uden smække døren på alle andre. At vælge grænserne er den hårde del.
Rate begrænsende caps hvor mange anmodninger en klient kan gøre i et vindue af tid. Det beskytter login formularer, søgning og API'er fra brute force, skrabning og løbske scripts. Mekanismen er nem; at vælge grænser, der stopper angribere uden at fange rigtige mennesker, er den del, der tager tanke - især fordi hele kontorer og mobilnetværk deler en enkelt IP-adresse.
Hvert websted har et par endepunkter, der tiltrækker problemer. Login-formularen, nulstilling af adgangskode, søgefeltet, den offentlige API. Venstre ubevogtet, et script kan ramme dem tusindvis af gange i sekundet - gætte adgangskoder, skrabe kataloget eller bare fejlbehæftet entusiastisk, fordi nogen glemte en pauseerklæring.
Ratebegrænsende er den grænse, der siger "det er nok". Ideen tager en sætning; at få det rigtigt tager lidt mere.
Idéen
Tillad hver klient et rimeligt antal anmodninger pr. tidsenhed, og afvis eller sænk dem, der overstiger det. En person, der klikker rundt på et websted, gør måske ti anmodninger i minuttet. Et brute-force script gør tusinder. Der er en enorm mængde plads mellem disse to tal, hvilket er det, der gør dette arbejde overhovedet.
Hvilken algoritme, og hvorfor det betyder noget
Der er tre fælles tilgange, og forskellen mellem dem er mere praktisk end det lyder.
Fast vindue
Tæl anmodninger pr. kalenderminut; nulstil tælleren øverst i hvert minut. Enkel, billig, og det har en åbenbar fejl: en klient kan gøre sin fulde godtgørelse på 10:00:59 og dens fulde godtgørelse igen på 10:01:00, levere dobbelt den tilsigtede sats i en to-sekunders burst. Fint for grov beskyttelse, ikke for noget, du holder af.
Glidende vindue
Tæl anmodninger i de efterfølgende tres sekunder i stedet for det aktuelle kalenderminut. Dette lukker grænsehullet og er hvad de fleste mennesker faktisk vil have, når de siger "100 anmodninger pr. minut".
Token spand
Forestil dig en spand med 60 poletter, der genopfylder på en per sekund. Hver anmodning bruger et symbol. Anmodninger i et fornuftigt tempo dræner det aldrig; en burst kan bruge flere på én gang, og vedvarende oversvømmelser tømmer det og bliver afvist, indtil det genopfyldes.
Token spand er normalt den rigtige standard, fordi det matcher, hvordan reel brug faktisk ser ud. En person, der læser en side, affyrer et dusin anmodninger på én gang og gør derefter ingenting i 30 sekunder. En streng per-sekund grænse straffer, at helt normal adfærd; en spand absorberer det.
Valg af grænser
Fejlen er en global grænse, der anvendes overalt. Dine slutpunkter har vildt forskellige risikoprofiler og vildt forskellige legitime brugsmønstre, så de vil have vildt forskellige tal.
| Slutpunkt | Udgangspunkt | Overskrides |
|---|---|---|
| Login, nulstilling af adgangskode | 5 10 pr. Minut pr. IP | Udfordring, derefter blok |
| Tilmelding, kontaktformular | 3 5 pr. Minut pr. IP | Udfordring |
| Søgning | 2030 pr. minut pr. IP | Throttle |
| Offentlig API, ikke godkendt | 60 pr. minut pr. IP | 429 med Prøv-Efter |
| Offentlig API, pr. API-nøgle | Per din plan niveauer | 429 med Prøv-Efter |
| Generel browsing | 300+ pr. minut pr. IP | Throttle |
Det er udgangspunkter, ikke anbefalinger til dit websted - de rigtige tal kommer fra at se på din egen trafik. Tag en uge med logs, find den 99. percentil anmodningsrate for rigtige sessioner på hvert endepunkt, og sæt grænsen meningsfuldt over den. Hvis din travleste ægte bruger gør 40 søgninger i minuttet, vil en grænse på 30 generere vrede e-mails.
Den delte IP-fælde
Dette er den, der fanger folk, og det fanger dem på en måde, der er usynlig fra din side.
En enkelt IP-adresse er ofte ikke en enkelt person. Et kontor på 200 personer bag en NAT-gateway er en IP. En universitetscampus er en IP. Mobiloperatører sætter rutinemæssigt tusindvis af abonnenter bag NAT af operatørkvalitet og deler en håndfuld adresser. En virksomheds VPN koncentrerer en hel virksomhed om én udgangsnode.
Indstil en aggressiv pr. IP-grænse, og du blokerer ikke en misbrugende bruger, du blokerer alle hos det pågældende firma, og de oplever det som "din hjemmeside er brudt" i stedet for "vi har været satsbegrænset". De vil ikke e-maile dig. De vil bare gå.
Hvor du kan, satsgrænse på noget mere specifikt end en IP-nøgle, en API-nøgle, en session, en brugerkonto. For uautentificeret trafik, hvor IP er alt, hvad du har, foretrækker en udfordring over en hård blok, når grænsen ture. Et fælles kontor består udfordringen og fortsætter; et script gør det ikke.
Svigter høfligt
Når du afviser en anmodning, skal du gøre det på den måde, som standarderne forventer, fordi klienten i den anden ende kan være en legitim integration, der vil opføre sig korrekt, hvis du fortæller det hvordan.
Tilbage 429 for mange ansøgninger ikke 403, hvilket betyder "du er ikke tilladt", en anden og uoprettelig besked. Medtag en Retry-After Hvis du kører en offentlig API, skal du sende den aktuelle grænsetilstand for hvert svar, ikke kun afvisningerne, så en velskrevet klient kan bremse, før den rammer væggen i stedet for efter.
Og hold din satsgrænse svar billige. Hvis det koster dig en databaseforespørgsel at afvise en anmodning, kan en bestemt angriber stadig udmatte dig med kun afvisninger. Dette er et andet argument for at begrænse på kanten, hvor afvisningen sker, før din ansøgning overhovedet er involveret.
Ting, der er værd at undtage
- Bekræftede søgerobotter. Googlebot kravler i bursts, og satsbegrænsende det kan stille og roligt skade din indeksering. Bekræft og undtag.
- Din egen overvågning. Kontrol af oppetid fra en fast adresse bør ikke konkurrere med dine grænser.
- Webhook afsendere. Betalingsudbydere forsøger igen aggressivt ved design; en grænse, der blokerer dem, kan miste dig ordrer.
- Statiske aktiver. En sidevisning er snesevis af aktivanmodninger. Begrænsning af dem pr. IP fanger normal browsing med det samme.
Ofte stillede spørgsmål
Hvad er satsbegrænsende?
Rate begrænsende caps hvor mange anmodninger en enkelt klient kan gøre inden for en periode, afvise eller bremse noget ud over det. Det beskytter login-formularer, søgeendepunkter og API'er mod forsøg på brute-force, skrabning og dårlig opførsel af scripts, mens normal brug forbliver uberørt, fordi legitim trafik ligger langt under tærsklen for en angriber behov.
Hvad er en god satsgrænse for et API?
Det afhænger af slutpunktet i stedet for stedet. Login og password reset-slutpunkter retfærdiggør 5 til 10 anmodninger pr. Minut pr. IP, tilmeldingsformularer 3 til 5, søg 20 til 30 og en ikke-godkendt offentlig API omkring 60. Afled dine faktiske tal fra dine egne logfiler ved at finde den 99. percentil anmodningsrate for ægte sessioner og indstille grænsen komfortabelt over den.
Hvilken HTTP-statuskode skal en satsgrænse returnere?
429 For mange anmodninger, ledsaget af en Retry-After-overskrift, der angiver, hvor længe klienten skal vente. Brug ikke 403 Forbidden, som signalerer, at klienten slet ikke er tilladt, snarere end at den skal bremse og forsøge igen. Offentlige API'er bør også returnere nuværende grænsetilstand for vellykkede svar, så klienter kan kvæle, før de afvises.
Hvorfor blokerer satsbegrænsende rigtige brugere?
Næsten altid, fordi mange mennesker deler en IP-adresse. Kontorer bag en NAT-gateway, universitetscampusser, virksomheds-VPN'er og mobiloperatører, der bruger NAT af operatørkvalitet, kan sætte hundreder eller tusindvis af ægte brugere bag en enkelt adresse. En grænse pr. IP indstillet til én person blokerer derfor dem alle. Begræns på en API-nøgle, session eller konto, hvor det er muligt, og foretrække en udfordring frem for en hård blok ellers.
Hvad er Token Bucket Algorithm?
Token spand modeller en spand holder et fast antal tokens, der genopfylder med en stabil hastighed. Hver anmodning forbruger en token, og anmodninger afvises, når spanden er tom. Dette tolererer korte udbrud, hvilket er, hvordan ægte browsing opfører sig, mens det stadig dækker vedvarende anmodningshastigheder - hvilket gør det bedre egnet til webtrafik end en streng fast vinduestæller.
Ratebegrænsning er en af de kontroller, hvor standardkonfigurationen sjældent er rigtig, og den korrekte konfiguration sidder i dine adgangslogfiler. Tilbring en time med en uges trafik, før du vælger dine numre, og du vil undgå den langt længere eftermiddag for at finde ud af, hvorfor en kundes hele kontor ikke kan logge ind.
Se, hvordan NordicCDN gør dette for dit websted:
Mads har arbejdet i IT - for det meste hosting - siden han var 16. Han tog tidligt ejerskab i en SaaS-virksomhed og var med til at udvide den til Visma, har opbygget og drevet datacenternetværk og fungeret som CTO for et dansk datacenter. Han startede NordicCDN for at gøre hurtig, sikker infrastruktur enkel at bruge.
