429 Too Many Requests: limity četnosti, Retry-After a falešné poplachy

Co 429 znamená a co s ním přichází

429 je definováno v RFC 6585 jako stav pro omezení četnosti: klient odeslal za dané časové období příliš mnoho požadavků. Specifikace záměrně nechává otevřené dvě věci: jak server identifikuje klienta a jak se požadavky počítají. Proto se limity četnosti mezi službami tak liší.

V praxi servery počítají podle IP adresy, podle klíče API, podle relace, podle účtu, nebo podle kombinace těchto věcí, a používají pevná okna, klouzavá okna nebo tokenové kbelíky. Dvě identické rychlosti požadavků proto mohou být v pořádku na jednom koncovém bodu a blokované na jiném na stejném webu.

Odpověď nese signály, které potřebujete:

• Retry-After je ten standardní. RFC 9110 povoluje buď počet sekund, nebo datum HTTP, a slušně se chovající klient tak dlouho čeká, než to zkusí znovu.
• Hlavičky limitu četnosti jako RateLimit-Limit, RateLimit-Remaining a RateLimit-Reset, nebo starší varianty X-RateLimit-, odhalují rozpočet a kdy se resetuje. Jde o konvence, ne o součást RFC 9110, takže přesné názvy ověřte v dokumentaci API.
• Tělo by mělo limit vysvětlit lidsky čitelnými slovy. Mnoho API pojmenovává, jaká kvóta byla překročena, což ušetří spoustu hádání.

429 není ve výchozím stavu cachovatelné, takže by ho prostředníci neměli dál servírovat, jakmile se okno resetuje.

Limit četnosti, nebo skutečný výpadek?

Tyto dvě věci se neustále pletou, protože obě se projeví jako selhávající požadavky. Rozlišující testy jsou rychlé:

• Samotný kód. Limit četnosti odpoví 429. Přetížený server nebo server v režimu údržby odpoví 503. Oba mohou nést Retry-After, a proto si je lidé pletou, ale znamenají různé věci: 429 říká "vy konkrétně posíláte příliš mnoho", 503 říká "služba jako celek teď nemůže přijímat práci". Pro tuto stranu viz návod na 503.
• Doba odezvy. Limity četnosti odmítají rychle, obvykle v milisekundách, protože rozhodnutí padne dřív, než proběhne jakákoli skutečná práce. Přetížení odpovídá pomalu nebo vyprší časový limit.
• Kdo je postižen. Limit četnosti zasáhne jednu identitu klienta. Otestujte to z jiné IP adresy nebo s jiným klíčem API: pokud to uspěje, zatímco omezený klient pořád selhává, jde o limit, ne o výpadek.
• Vzorec v čase. Omezování četnosti je periodické a samo se čistí. Selhání se shlukují, pak přesně na resetu okna přestanou, a pak se vrátí. Výpadek se zdvořile nevrátí podle rozvrhu.
• Souvislost s vlastním objemem. Pokud selhání začala, když jste zvýšili frekvenci kontrol, přidali paralelní pracovní procesy nebo spustili dávkovou úlohu, příčina je na vaší straně spojení.

Proč si monitoring může 429 spustit sám na sebe

Monitoring je opakující se požadavek z malé sady adres na stejnou URL, což je blízko tvaru, na jaký jsou omezovače četnosti stavěné, aby ho zachytily. Velmi krátký interval kontroly to zhoršuje, protože kontroly každou minutu vynásobené mnoha sledovanými URL se rychle sčítají proti rozpočtu na jednu IP. Totéž platí pro spuštění kontroly z mnoha lokalit najednou: zdroj vidí nárazovou vlnu místo stálého pramínku, a limity pro nárazy se spustí jako první.

Na volbě URL taky záleží. Vyhledávací stránky, koncové body API a cokoli, co zapisuje, bývá omezováno přísněji než statická domovská stránka. A pokud monitoring a aplikace sdílejí jeden klíč API, obě soupeří o jedinou kvótu. Výsledkem je monitor, který hlásí web jako selhávající, zatímco web je naprosto zdravý, a omezovač četnosti dělá svou práci správně.

Jak opravit 429

1. Než cokoli změníte, přečtěte si hlavičky odpovědi:

   curl -sS -o /dev/null -D - https://example.com/api/items

   Retry-After a jakékoli hlavičky limitu četnosti vám řeknou skutečný rozpočet, což je lepší než hádat intervaly.
2. Respektujte Retry-After. Okamžité opakování blokádu u mnoha implementací prodlouží. Počkejte uvedenou dobu.
3. V klientském kódu ubírejte exponenciálně s náhodným rozptylem (jitter), aby se souběžní klienti nesynchronizovali a nezkoušeli to znovu v jednom náporu.
4. Snižte frekvenci požadavků. U monitoringu přesuňte kontrolovaný koncový bod na delší interval, nebo kontroly rozprostřete, aby mnoho lokalit nespustilo požadavek ve stejnou vteřinu.
5. Monitorujte levnou, reprezentativní URL. Odlehčený zdravotní koncový bod nebo domovská stránka vám řekne, že web je nahoře, aniž byste utráceli kvótu, kterou potřebujete pro skutečný provoz.
6. Vyjměte monitorovacího klienta z omezovače. Zařaďte adresy kontrolních bodů na seznam povolených, nebo dejte monitoringu vlastní klíč API s vlastním rozpočtem, aby nikdy nesoupeřil s produkčním provozem.
7. Pokud omezovač vlastníte vy, zkontrolujte, že je limit správný. Zeptejte se, zda rozpočet odpovídá skutečnému využití, zda je na IP, i když by měl být na účet, a zda sdílené proxy nebo firemní NAT neschovávají mnoho uživatelů za jednu adresu.

Sledování 429 bez jejich vyvolávání

Limity četnosti se obvykle nejdřív objeví u nejvytíženějších klientů, což znamená, že na ně narazí platící zákazníci a integrace dřív než kdokoli z vašeho týmu. Naplánovaná HTTP kontrola, která ověřuje očekávaný stavový kód, ukáže 429 jako jasnou, časově označenou událost místo roztroušených hlášení "API je nestabilní", a časování vám řekne, zda je limit periodický, nebo trvalý. Nastavte interval s rozvahou: dostatečně často, abyste problémy rychle zaznamenali, dostatečně šetrně, aby kontrola sama nikdy nebyla tím, co limit spustí. Širší rodinu odmítnutí, včetně 401 a 403, pokrývá přehled 4xx.