Rate begränsande förklaras: skydda ditt API utan att blockera verkliga användare
Ratebegränsande stoppar en dålig skådespelare - eller ett buggy script - från att hamra din webbplats i marken, utan att smälla dörren på alla andra. Att välja gränserna är den svåra delen.
Rate limiting caps anger hur många förfrågningar en klient kan göra i ett tidsfönster. Det skyddar inloggningsformulär, sökning och API: er från brute force, skrapning och runaway skript. Mekanismen är enkel; plocka gränser som stoppar angripare utan att fånga riktiga människor är den del som tar tanke - särskilt eftersom hela kontor och mobila nätverk delar en enda IP-adress.
Varje webbplats har några slutpunkter som lockar problem. Inloggningsformuläret, återställningen av lösenordet, sökrutan, det offentliga API:et. Lämnas obevakad, kan ett skript slå dem tusentals gånger i sekunden - gissa lösenord, skrapa katalogen eller bara fungera entusiastiskt för att någon glömde ett pausuttalande.
Rate limiting är locket som säger "det räcker". Idén tar en mening; att få det rätt tar lite mer.
Idén
Tillåt varje klient ett rimligt antal förfrågningar per tidsenhet och avvisa eller sakta de som överstiger det. En person som klickar runt på en webbplats gör kanske tio förfrågningar per minut. Ett brutalt manus gör tusentals. Det finns en enorm mängd utrymme mellan dessa två siffror, vilket är vad som gör det här arbetet alls.
Vilken algoritm och varför det spelar roll
Det finns tre vanliga tillvägagångssätt och skillnaden mellan dem är mer praktisk än det låter.
Fast fönster
Räkna förfrågningar per kalenderminut; återställ räknaren högst upp i varje minut. Enkelt, billigt, och det har en uppenbar brist: en klient kan göra sin fulla ersättning vid 10:00:59 och dess fulla ersättning igen vid 10:01:00, leverera dubbelt den avsedda kursen i en två-sekunders burst. Bra för grov skydd, inte för något du bryr dig om.
Glidande fönster
Räkna begäranden under de efterföljande sextio sekunderna istället för den aktuella kalenderminuten. Detta stänger gränshålet och är vad de flesta faktiskt vill ha när de säger "100 begäran per minut".
Token hink
Föreställ dig en hink med 60 polletter som fylls på en gång per sekund. Varje förfrågan spenderar en token. Begäran i en sund takt dränerar den aldrig; en burst kan spendera flera på en gång, och ihållande översvämning tömmer den och blir vägrad tills den fylls på.
Token hink är vanligtvis rätt standard, eftersom det matchar hur verklig användning faktiskt ser ut. En person som laddar en sida avfyrar ett dussin förfrågningar samtidigt och gör sedan ingenting i trettio sekunder. En strikt per sekund-gräns straffar det helt normala beteendet; en hink absorberar det.
Att välja gränser
Misstaget är en global gräns som tillämpas överallt. Dina slutpunkter har väldigt olika riskprofiler och väldigt olika legitima användningsmönster, så de vill ha väldigt olika siffror.
| Slutpunkt | Utgångspunkt | Överskrid |
|---|---|---|
| Logga in, återställ lösenord | 5 10 per minut per IP | Utmaning, sedan blockera |
| Anmälan, kontaktformulär | 35 per minut per IP | Utmaning |
| Sök | 2030 per minut per IP | Gasreglage |
| Offentligt API, oautentiserat | 60 per minut per IP | 429 med försök-efter |
| Offentligt API, per API-nyckel | Per din plan nivåer | 429 med försök-efter |
| Allmänt surfande på sidan | 300+ per minut per IP | Gasreglage |
Det är utgångspunkter, inte rekommendationer för din webbplats - rätt siffror kommer från att titta på din egen trafik. Ta en vecka med loggar, hitta den 99: e percentilförfrågan för verkliga sessioner på varje slutpunkt och ställ in gränsen meningsfullt över den. Om din mest trafikerade verkliga användare gör 40 sökningar per minut, kommer en gräns på 30 att generera arga e-postmeddelanden.
Den delade IP-fällan
Detta är den som fångar människor, och det fångar dem på ett sätt som är osynligt från din sida.
En IP-adress är ofta inte en person. Ett kontor med 200 personer bakom en NAT-gateway är en IP. Ett campus är en IP. Mobiloperatörer rutinmässigt sätta tusentals abonnenter bakom carrier-grade NAT, dela en handfull adresser. VPN-tjänster för företag koncentrerar ett helt företag till en utgångsnod.
Ange en aggressiv per-IP-gräns och du blockerar inte en missbrukande användare, du blockerar alla på det företaget, och de upplever det som "din webbplats är trasig" snarare än "vi har varit begränsade". De kommer inte att maila dig. De kommer bara att gå.
Om du kan, betygsätt gränsen för något mer specifikt än en IP-adress – en API-nyckel, en session, ett användarkonto. För oautentiserad trafik där IP är allt du har, föredra en utmaning över ett hårt block när gränsen resor. Ett delat kontor klarar utmaningen och fortsätter; ett manus gör det inte.
Misslyckas artigt
När du avvisar en förfrågan, gör det på det sätt som standarden förväntar sig, eftersom klienten i andra änden kan mycket väl vara en legitim integration som kommer att bete sig korrekt om du berättar hur.
Återgå 429 För många förfrågningar inte 403, vilket betyder "du är inte tillåten", ett annat och oåterkalleligt meddelande. Inkludera en Retry-After Om du kör ett offentligt API, skicka det aktuella gränstillståndet på varje svar, inte bara avslagen, så en välskriven klient kan sakta ner innan den träffar väggen snarare än efter.
Och håll din hastighetsgräns svar billigt. Om det kostar dig en databasfråga att avvisa en begäran kan en bestämd angripare fortfarande göra dig utmattad med bara avslag. Detta är ett annat argument för att begränsa vid kanten, där avslaget sker innan din ansökan alls är inblandad.
Saker som är värda att undantas
- Verifierade sökrobotar. Googlebot kryper i skurar, och hastighetsbegränsande det kan tyst skada din indexering. Verifiera och undanta.
- Din egen övervakning. Upptidskontroller från en fast adress bör inte konkurrera med dina gränser.
- Webhook-avsändare. Betalningsleverantörer försöker igen aggressivt genom design; en gräns som blockerar dem kan förlora dig order.
- Statiska tillgångar. En sidvisning är dussintals tillgångsförfrågningar. Begränsa dem per IP fångar normal surfning omedelbart.
Vanliga frågor
Vad är Rate Limiting?
Begränsningstak anger hur många förfrågningar en enskild klient kan göra inom en tidsperiod, avvisa eller sakta ner något utöver det. Det skyddar inloggningsformulär, sökslutpunkter och API:er från försök med brute force, skrapning och felanvändning av skript, samtidigt som normal användning förblir orörd eftersom legitim trafik ligger långt under tröskeln för en angripare. behov.
Vad är en bra prisgräns för ett API?
Det beror på slutpunkten snarare än platsen. Inloggnings- och lösenordsåterställningsslutpunkter motiverar 5 till 10 förfrågningar per minut per IP, registreringsformulär 3 till 5, sök 20 till 30 och ett oautentiserat offentligt API runt 60. Härleda dina faktiska siffror från dina egna loggar genom att hitta den 99: e percentilen begäran takt av äkta sessioner och ställa in gränsen bekvämt över den.
Vilken HTTP-statuskod ska en kursgräns returnera?
429 För många förfrågningar, åtföljd av ett Retry-After-huvud som anger hur länge klienten ska vänta. Använd inte 403 Forbidden, vilket signalerar att klienten inte är tillåten alls snarare än att den ska sakta ner och försöka igen. Offentliga API:er bör också returnera nuvarande gränstillstånd för lyckade svar så att klienter kan strypa innan de avvisas.
Varför blockerar hastighetsbegränsande verkliga användare?
Oftast för att många delar en IP-adress. Kontor bakom en NAT-gateway, universitetscampus, företags-VPN och mobiloperatörer som använder NAT av operatörskvalitet kan lägga hundratals eller tusentals äkta användare bakom en enda adress. En per-IP-gräns som är inställd för en person blockerar därför alla. Begränsa till en API-nyckel, session eller konto där det är möjligt, och föredra en utmaning över ett hårt block annars.
Vad är Token Bucket Algorithm?
Token hink modeller en hink som håller ett fast antal tokens som påfyller i en jämn takt. Varje begäran förbrukar en token, och förfrågningar avvisas när hinken är tom. Detta tolererar korta skurar, vilket är hur verklig surfning beter sig, samtidigt som det täcker ihållande begäran priser - vilket gör det bättre för webbtrafik än en strikt fast fönsterräknare.
Hastighetsbegränsning är en av de kontroller där standardkonfigurationen sällan är rätt och rätt konfiguration finns i dina åtkomstloggar. Tillbringa en timme med en veckas trafik innan du väljer dina nummer, och du kommer att undvika den mycket längre eftermiddagen att räkna ut varför en kunds hela kontor inte kan logga in.
Se hur NordicCDN gör detta för din webbplats:
Mads har arbetat inom IT - mestadels värd - sedan han var 16. Han tog tidigt del i ett SaaS-företag och hjälpte till att växa fram till Vismas förvärv, har byggt och drivit datacenternätverk och fungerat som CTO för ett danskt datacenter. Han startade NordicCDN för att göra snabb och säker infrastruktur enkel att använda.
