Forklaret prisbegrænsning: 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 svære del.
Rate limiting caps angiver, hvor mange anmodninger en klient kan foretage i et tidsvindue. Det beskytter loginformularer, søgning og API'er mod brutal kraft, skrabning og løbske scripts. Mekanismen er let; 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 slutpunkter, der tiltrækker problemer. Login-formularen, nulstilling af adgangskode, søgefeltet, det offentlige API. Forladt ubevogtet, kan et script ramme dem tusindvis af gange i sekundet - gætte adgangskoder, skrabe kataloget eller bare fejle 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æt tempoet ned for dem, der overstiger det. En person, der klikker rundt på et websted, giver måske ti anmodninger i minuttet. Et brutalt manuskript giver 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 bekymrer dig om.
Glidende vindue
Tæl anmodninger i de efterfølgende 60 sekunder i stedet for det aktuelle kalenderminut. Dette lukker grænsehullet og er, hvad de fleste mennesker faktisk ønsker, når de siger "100 anmodninger i minuttet".
Tegneskovl
Forestil dig en spand med 60 poletter, der genopfylder én gang i sekundet. 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.
Tokenbucket er normalt den rigtige standard, fordi den matcher, hvordan den virkelige brug faktisk ser ud. En person, der læser en side, affyrer et dusin anmodninger på én gang og gør derefter ingenting i tredive sekunder. En streng pr. sekund-grænse straffer den helt normale opførsel; en skovl absorberer den.
Valg af grænser
Fejlen er en global grænse, der anvendes overalt. Dine slutpunkter har vidt forskellige risikoprofiler og vidt forskellige legitime brugsmønstre, så de ønsker vidt forskellige tal.
| Slutpunkt | Udgangspunkt | Overskridelse |
|---|---|---|
| Login, nulstilling af adgangskode | 510 pr. minut pr. IP | Udfordring, så blokér |
| Tilmelding, kontaktformular | 35 pr. minut pr. IP | Udfordring |
| Søgning | 20-30 pr. minut pr. IP | Gashåndtag |
| Offentlig API, ikke godkendt | 60 pr. minut pr. IP | 429 med et nyt forsøg |
| Offentlig API, pr. API-nøgle | Pr din plan niveauer | 429 med et nyt forsøg |
| Generel browsing af sider | 300+ pr. minut pr. IP | Gashåndtag |
Det er udgangspunkter, ikke anbefalinger til dit websted - de rigtige tal kommer fra at se på din egen trafik. Tag en uge med logfiler, find den 99. procentvise anmodningsrate for reelle sessioner på hvert slutpunkt, og sæt grænsen på en meningsfuld måde over den. Hvis din travleste ægte bruger foretager 40 søgninger i minuttet, vil en grænse på 30 generere vrede e-mails.
Den delte IP-fælde
Det er den, der fanger folk, og den fanger dem på en måde, der er usynlig fra din side.
En enkelt IP-adresse er ofte ikke en enkelt person. Et kontor med 200 personer bag én NAT-gateway er én IP-adresse. En universitetscampus er én IP. Mobiloperatører sætter rutinemæssigt tusindvis af abonnenter bag NAT af operatørkvalitet og deler en håndfuld adresser. Virksomhedernes VPN’er 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" snarere end "vi har været satsbegrænset". De vil ikke sende dig en mail. De går bare.
Hvis det er muligt, kan du bedømme grænser for noget mere specifikt end en IP-adresse – en API-nøgle, en session eller en brugerkonto. Hvis du ønsker uautoriseret trafik, hvor IP-adressen er alt, hvad du har, skal du foretrække en udfordring frem for en hård blokering, når grænseværdien overskrides. Et fælles kontor klarer udfordringen og fortsætter; et manuskript 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, for klienten i den anden ende kan meget vel være en legitim integration, der vil opføre sig korrekt, hvis du fortæller det hvordan.
Returret 429 for mange anmodninger ikke 403, hvilket betyder "du er ikke tilladt", en anden og uoprettelig besked. Medtag en Retry-After Overskriften fortæller, hvor længe du skal vente. Hvis du kører en offentlig API, skal du sende den aktuelle grænsetilstand på 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 billigt. Hvis det koster dig en databaseforespørgsel at afvise en anmodning, kan en bestemt angriber stadig udmatte dig ved kun at bruge afvisninger. Dette er endnu et argument for at begrænse ved 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 rundt i serier, og hastighedsbegrænsning kan stille og roligt skade din indeksering. Kontroller 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 dine ordrer.
- Statiske aktiver. En sidevisning er dusinvis af anmodninger om aktiver. Hvis du begrænser dem pr. IP, får du straks adgang til normal browsing.
Ofte stillede spørgsmål
Hvad er Rate Begrænsning?
Ratebegrænsende lofter angiver, hvor mange anmodninger en enkelt klient kan fremsætte inden for en given periode, og afviser eller forsinker alt andet end det. Det beskytter login-formularer, søgeendepunkter og API'er mod brute-force forsøg, skrabning og dårlig opførsel scripts, mens normal brug forbliver uberørt, fordi legitim trafik sidder langt under tærsklen en angriber behov.
Hvad er en god satsgrænse for et API?
Det afhænger af slutpunktet snarere end stedet. Endepunkter for nulstilling af login og adgangskode berettiger 5 til 10 anmodninger pr. minut pr. IP, tilmeldingsformularer 3 til 5, søgning 20 til 30 og en ikke-godkendt offentlig API omkring 60. Afled dine faktiske tal fra dine egne logs ved at finde den 99. percentil anmodningsrate af ægte sessioner og indstille grænsen komfortabelt over den.
Hvilken HTTP-statuskode skal en satsgrænse returnere?
429 For mange anmodninger, ledsaget af en Genforsøg-efter-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 sætte farten ned og prøve igen. Offentlige API'er bør også returnere den aktuelle grænsetilstand for vellykkede svar, så klienter kan slække på dem, før de bliver afvist.
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 pr. IP-grænse, der er indstillet til én person, blokerer derfor dem alle. Begræns en API-nøgle, session eller konto, hvor det er muligt, og foretrække en udfordring frem for en hård blokering.
Hvad er Token Bucket Algorithm?
Tokenskovl modellerer en skovl, der indeholder et fast antal tokens, der genopfylder med en stabil hastighed. Hver anmodning bruger én token, og anmodninger afvises, når spanden er tom. Dette tolererer korte udbrud, hvilket er, hvordan reel browsing opfører sig, mens den stadig dækker vedvarende anmodningshastigheder - hvilket gør det bedre egnet til webtrafik end en streng fast vinduestæller.
Ratebegrænsende 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 med IT – mest som vært – 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 og sikker infrastruktur enkel at bruge.
