← Dokumentace WAF / rate-limiting-rules

Výpočet frekvence požadavků

Cloudflare sleduje frekvenci požadavků pomocí samostatných čítačů pro každou jedinečnou kombinaci hodnot v charakteristiky.

Uvažujme například pravidlo s těmito vlastnostmi:

• IP adresa
• HTTP hlavička x-api-key

Pokud dva požadavky sdílejí stejné x-api-key hodnotu hlavičky, ale pocházejí z různých IP adres, Cloudflare je počítá odděleně, protože se liší kombinace jejich charakteristik.

Čítače se nesdílí mezi datacentry, s výjimkou datacenter přiřazených ke stejné geografické lokalitě.

Ve výchozím nastavení vychází frekvence požadavků z počtu příchozích požadavků. Zákazníci s plánem Enterprise a Advanced Rate Limiting může také založit rychlost na nákladech na obsloužení každého požadavku. Viz Omezení frekvence požadavků na základě složitosti s dalšími informacemi.

Zvažte následující konfiguraci pravidla omezení frekvence požadavků:

Následující diagram znázorňuje, jak Cloudflare zpracovává čtyři příchozí požadavky v kontextu výše uvedeného pravidla omezení frekvence požadavků.

Požadavek 1 odpovídá výrazu pravidla, proto se pravidlo omezení frekvence vyhodnotí. Cloudflare definuje čítač požadavků pro hodnoty charakteristik v kontextu pravidla omezení frekvence a nastaví čítač na 1. Protože je hodnota čítače v rámci stanovených limitů v Požadavky, požadavek je povolen.

Požadavek 2 odpovídá výrazu pravidla, a proto Cloudflare vyhodnocuje pravidlo omezení frekvence požadavků. Hodnoty charakteristik neodpovídají žádnému existujícímu čítači (hodnota X-API-Key hlavička je jiná). Cloudflare proto definuje samostatný čítač v kontextu tohoto pravidla a nastaví jej na 1. Hodnota čítače je v rámci limitu požadavků stanoveného v Požadavky, a proto je tento požadavek povolen.

Požadavek 3 odpovídá výrazu pravidla a má stejné hodnoty charakteristik pravidla jako požadavek 1. Cloudflare proto zvyšuje hodnotu existujícího čítače a nastavuje ji na 2. Hodnota čítače je nyní nad limitem definovaným v Požadavky, a proto se požadavek 3 zablokuje.

Požadavek 4 neodpovídá výrazu pravidla, protože hodnota pro Content-Type hlavička neodpovídá hodnotě ve výrazu. Cloudflare proto pro tento požadavek nevytvoří nový čítač pravidla. Požadavek 4 není v kontextu tohoto pravidla omezení frekvence požadavků vyhodnocen a postupuje k dalším pravidlům v procesu vyhodnocování požadavků.

Zvažte následující konfiguraci pravidla omezení frekvence požadavků. Počítací výraz pravidla určuje, že se čítač zvýší o jednu, když je stavový kód odpovědi HTTP roven 400:

Následující diagram znázorňuje, jak Cloudflare zpracovává těchto čtyři příchozí požadavky přijaté během 10sekundového období v kontextu výše uvedeného pravidla omezení frekvence požadavků.

Požadavek 1 odpovídá výrazu pravidla, proto se pravidlo omezení frekvence vyhodnotí. Požadavek se odešle na origin server a přeskočí veškerý obsah z mezipaměti, protože pravidlo omezení frekvence obsahuje pole odpovědi (http.response.code) ve výrazu pro počítání. Origin server odpoví 400 stavový kód. Vzhledem k tomu, že výraz pro počítání odpovídá, Cloudflare vytvoří čítač požadavků pro hodnoty vlastností v kontextu pravidla rate limiting a nastaví tento čítač na 1.

Požadavek 2 odpovídá výrazu pravidla, a proto Cloudflare vyhodnocuje pravidlo omezení frekvence požadavků. Čítač požadavků pro hodnoty charakteristik je stále v rámci maximálního počtu požadavků definovaného v Požadavky. Origin server odpovídá 200 stavový kód. Vzhledem k tomu, že odpověď neodpovídá výrazu pro počítání, čítač se nezvyšuje a zachovává si svou hodnotu (1).

Požadavek 3 odpovídá výrazu pravidla, a proto Cloudflare vyhodnocuje pravidlo omezení frekvence požadavků. Požadavek je stále v rámci maximálního počtu požadavků definovaného v Požadavky. Origin server odpovídá 400 stavový kód. Výraz pro počítání odpovídá, což nastaví čítač na 2.

Požadavek 4 odpovídá výrazu pravidla, a proto Cloudflare vyhodnocuje pravidlo omezení frekvence požadavků. Požadavek už není v rámci maximálního počtu požadavků definovaného v Požadavky (čítač má hodnotu 2 a maximální počet požadavků je 1). Cloudflare použije akci definovanou v konfiguraci pravidla Rate Limiting a na deset minut zablokuje požadavek 4 i všechny další požadavky, které tomuto pravidlu Rate Limiting odpovídají.

Ne všechny požadavky stojí na obsloužení stejně. Jednoduché čtení přes API může využít minimum zdrojů, zatímco složitý databázový dotaz nebo export souboru může vyžadovat výrazně více. Rate limiting založený na počtu požadavků je posuzuje stejně: 100 nenáročných požadavků a 100 náročných požadavků zvýší stejný čítač o stejnou hodnotu.

Omezení frekvence požadavků na základě složitosti tento problém řeší tak, že sleduje skóre nákladů, které váš origin server přiřadí každému požadavku, a vynucuje maximální celkové skóre na klienta za dané období. Díky tomu lze klienta, který odesílá několik nákladných požadavků, omezit ještě předtím, než dosáhne vysokého počtu požadavků, bez ohledu na celkový počet odeslaných požadavků.

Chcete-li použít omezení frekvence požadavků založené na složitosti, musí váš origin server vracet hlavičku HTTP odpovědi obsahující číselné skóre pro každý požadavek. Toto skóre představuje složitost neboli náklady na obsloužení daného požadavku. Hodnota musí být mezi 1 a 1,000,000. Název hlavičky, ze které pravidlo hodnotu čte, si nastavíte sami.

Pravidla omezení frekvence požadavků na základě složitosti musí obsahovat následující vlastnosti:

• Skóre za období: Maximální celkové skóre povolené za období. Jakmile celkové skóre překročí tuto hodnotu, provede se akce pravidla.
• Období: Časové okno pro vyhodnocení celkového skóre.
• Název hlavičky odpovědi: HTTP hlavička odpovědi, kterou nastavuje váš origin server a která obsahuje skóre pro každý požadavek.

Cloudflare udržuje čítače s celkovým skóre všech požadavků, které mají pro charakteristiky pravidla stejné hodnoty odpovídající výrazu pravidla. Skóre se zvyšuje o hodnotu, kterou origin server poskytne v odpovědi, pokud dojde ke shodě s výrazem pro počítání (ve výchozím nastavení je stejný jako výraz pravidla). Jakmile celkové skóre překročí nakonfigurované maximální skóre za dané období, uplatní se akce pravidla.

Pokud origin server neposkytne hlavičku HTTP odpovědi s hodnotou skóre nebo pokud je hodnota skóre mimo povolený rozsah, příslušný čítač omezení frekvence požadavků se neaktualizuje.

Zvažte následující konfiguraci pravidla omezení frekvence požadavků. Při shodě pravidla se čítač skóre složitosti zvýší na základě hodnoty v x-score hlavičku odpovědi poskytnutou původním serverem.

Následující diagram znázorňuje, jak Cloudflare zpracovává čtyři příchozí požadavky přijaté během jedné minuty v kontextu výše uvedeného pravidla omezení frekvence požadavků.

Požadavek 1 odpovídá výrazu pravidla, proto se pravidlo omezení frekvence vyhodnotí. Origin server odpoví stavovým kódem 200 stavový kód a skóre složitosti 100 v x-score HTTP hlavičku odpovědi. Cloudflare vytvoří čítač požadavků pro hodnoty charakteristik v kontextu pravidla omezení frekvence požadavků a nastaví tento čítač na 100.

Požadavek 2 odpovídá výrazu pravidla, a proto Cloudflare vyhodnocuje pravidlo omezení frekvence požadavků. Čítač požadavků pro hodnoty charakteristik je stále v rámci maximálního skóre za období. Origin server odpoví 200 stavový kód a čítač požadavků se zvýší o 200. Aktuální skóre složitosti požadavku je nyní 300.

Požadavek 3 odpovídá výrazu pravidla, a proto Cloudflare vyhodnocuje pravidlo omezení frekvence požadavků. Čítač požadavků pro hodnoty charakteristik je stále v rámci maximálního skóre za období. Origin server odpoví 200 stavový kód a čítač požadavků se zvýší o 150. Aktuální skóre složitosti požadavku je nyní 450.

Požadavek 4 odpovídá výrazu pravidla, a proto Cloudflare vyhodnocuje pravidlo omezení frekvence požadavků. Požadavek už není v rámci maximálního skóre za období definovaného v pravidle (čítač má hodnotu 450 a maximální skóre je 400). Cloudflare použije akci definovanou v konfiguraci pravidla Rate Limiting a na deset minut zablokuje požadavek 4 i všechny další požadavky, které tomuto pravidlu Rate Limiting odpovídají.