Rate limiting

Příklady z praxe

1. 01

   Ochrana přihlašování v e-shopu

   E-shop přidá limit na endpoint pro přihlášení, protože roboti zkoušejí hesla ve velkém. Po překročení krátkého okna server vrátí 429 a další pokusy ze stejného zdroje dočasně odmítne. Útočník tím nezíská neomezený počet pokusů a běžný uživatel většinou žádný rozdíl nepozná.

   const hits = new Map();
   
   function rateLimit(req, res, next) {
     const key = req.ip;
     const now = Date.now();
     const windowMs = 60_000;
     const maxHits = 10;
     const record = hits.get(key) ?? { count: 0, resetAt: now + windowMs };
   
     if (now > record.resetAt) {
       record.count = 0;
       record.resetAt = now + windowMs;
     }
   
     record.count += 1;
     hits.set(key, record);
   
     if (record.count > maxHits) {
       res.set("Retry-After", Math.ceil((record.resetAt - now) / 1000));
       return res.status(429).json({ error: "Too many requests" });
     }
   
     next();
   }

2. 02

   Klient respektuje odpověď 429

   Mobilní aplikace volá cizí API pro dostupnost zásilek a občas narazí na limit poskytovatele. Klient přečte hlavičku Retry-After, počká a teprve potom požadavek zopakuje. Výsledkem je méně chyb v logu a menší riziko, že poskytovatel aplikaci úplně zablokuje.

   async function requestWithRetry(url) {
     const response = await fetch(url);
   
     if (response.status !== 429) return response;
   
     const retryAfter = Number(response.headers.get("Retry-After") || "1");
     await new Promise(resolve => setTimeout(resolve, retryAfter * 1000));
     return fetch(url);
   }

Časté omyly

MýtusRate limiting vyřeší DDoS sám o sobě.

Ve skutečnostiRate limiting pomáhá proti nadměrným požadavkům v konkrétním kontextu, ale rozsáhlý distribuovaný útok může přicházet z mnoha zdrojů. Pro DDoS je potřeba i síťová ochrana, filtrace a architektura připravená na špičky.

MýtusStačí limitovat podle IP adresy.

Ve skutečnostiIP adresa může zastupovat mnoho legitimních uživatelů, například za firemní proxy nebo mobilním operátorem. Spolehlivější ochrana často kombinuje IP adresu s účtem, API klíčem, endpointem a typem akce.

Časté dotazy

Jaký je rozdíl mezi rate limiting a throttling?

Rate limiting omezuje počet operací za čas, zatímco throttling se často používá pro širší zpomalování provozu. V praxi se výrazy někdy překrývají: API může po překročení limitu vrátit chybu 429, zařadit požadavky do fronty nebo snížit propustnost. Důležité je rozlišit, zda systém požadavek odmítá, nebo ho jen záměrně zdržuje.

Co znamená chyba 429 Too Many Requests?

HTTP 429 Too Many Requests znamená, že klient poslal příliš mnoho požadavků v daném kontextu. Kontext může být účet, IP adresa, API klíč, endpoint nebo jiný identifikátor. Server může přidat hlavičku Retry-After, která říká, kdy má klient další pokus zopakovat. Klient by neměl okamžitě spouštět opakované požadavky bez čekání.

Jak nastavit správný rate limit pro API?

Rate limiting se nastavuje podle ceny operace, rizika zneužití, očekávaného chování uživatelů a kapacity závislých systémů. Čtení veřejných dat může mít mírnější limit než přihlášení nebo reset hesla. Praktické nastavení vyžaduje měření reálného provozu, sledování odmítnutých požadavků a úpravy podle toho, zda limit zasahuje legitimní klienty.

Chrání rate limiting proti DDoS útokům?

Rate limiting sám o sobě nezastaví velký distribuovaný útok, protože útočník může posílat provoz z mnoha zdrojů. Limit ale pomáhá omezit škody u konkrétních účtů, klíčů, endpointů nebo menších automatizovaných útoků. Pro DDoS je potřeba kombinovat rate limiting s ochranou na síťové vrstvě, filtrováním provozu a kapacitní rezervou.

Zdroje

1. RFC 6585: Additional HTTP Status Codes(otevře se v novém okně)RFC Editor, 2012
2. RFC 9331: The Explicit Congestion Notification (ECN) Protocol for Low Latency, Low Loss, and Scalable Throughput (L4S)(otevře se v novém okně)RFC Editor, 2023
3. 429 Too Many Requests(otevře se v novém okně)MDN Web Docs
4. RFC 9110: HTTP Semantics(otevře se v novém okně)RFC Editor, 2022

Související pojmy

• Token bucketToken bucket je algoritmus pro řízení rychlosti požadavků, paketů nebo úloh pomocí virtuální nádoby s tokeny. Tokeny se doplňují nastaveným tempem až do maximální kapacity a každá akce je spotřebuje. Díky tomu lze omezit dlouhodobý průměr, ale zároveň povolit krátké nárazové špičky.
• Leaky bucketLeaky bucket je algoritmus pro omezení nebo vyhlazení toku požadavků, paketů či událostí pomocí pomyslného kbelíku, který odtéká stálou rychlostí. Příchozí dávky se ukládají do fronty, přebytky při zaplnění propadnou a výstup zůstává předvídatelný i při nárazové zátěži v API, sítích i zpracování zpráv.
• API GatewayAPI Gateway je vstupní vrstva mezi klientem a sadou backendových služeb, která přijímá požadavky, směruje je na správné API, vynucuje bezpečnostní pravidla a často řeší limity, logování nebo transformace odpovědí. Pomáhá skrýt vnitřní strukturu systému a sjednotit chování pro web, mobilní aplikaci i partnery.
• BackpressureBackpressure je mechanismus, kterým pomalejší část systému dává rychlejší části najevo, že má zpomalit, počkat nebo zahodit část práce. Používá se u streamů, front, sítí a event-driven aplikací, aby se nekonečně nehromadila data v paměti a aby přetížení nespadlo až na celý proces.
• Automatické škálováníAutomatické škálování je řízení výpočetní kapacity služby podle aktuální nebo očekávané zátěže bez ručního zásahu operátora. Systém přidává či odebírá instance, kontejnery, vlákna nebo jiné prostředky podle metrik a pravidel, aby aplikace zvládla špičky, neplatila zbytečnou rezervu a zůstala stabilní.
• DDoSDDoS je útok, při kterém velké množství rozptýlených zařízení současně zahltí server, linku nebo aplikaci provozem tak, že přestane obsluhovat legitimní uživatele. Na rozdíl od prostého DoS pochází zátěž z tisíců různých adres, takže ji nelze odstavit zablokováním jednoho zdroje. Cílem není krádež dat, ale nedostupnost služby.
• Brute force útokBrute force útok je metoda prolomení hesla, klíče nebo jiného tajemství systematickým zkoušením možných kombinací, dokud útočník nenarazí na tu správnou. Nevyužívá žádnou chybu v algoritmu, spoléhá se čistě na výpočetní výkon a čas. Obranou je délka a entropie tajemství, pomalé hashovací funkce, omezení počtu pokusů a druhý faktor.
• Traffic shapingTraffic shaping je technika řízení síťového provozu, která zdržuje odesílání paketů ve frontě tak, aby výsledný tok nepřekročil zvolenou rychlost a tvar. Na rozdíl od policingu, který nadbytečné pakety zahazuje, shaping je vyrovnává v čase pomocí bufferu, čímž snižuje ztrátovost za cenu vyšší latence.