INTEGRITY Dokumentace

Výpočet frekvence požadavků

Cloudflare sleduje frekvence požadavků udržováním samostatných čítačů pro každou unikátní kombinaci hodnot v charakteristiky.

Zvažte například pravidlo s těmito charakteristikami:

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 jejich kombinace charakteristik liší.

Čítače se nesdílejí mezi datovými centry, s výjimkou datových center přiřazených ke stejné geografické lokalitě.

Ve výchozím nastavení je frekvence požadavků založena na počtu příchozích požadavků. Zákazníci Enterprise s Advanced Rate Limiting může limit založit také na nákladech na obsloužení každého požadavku. Viz Rate limiting založený na komplexitě pro více informací.

Příklad A

Zvažte následující konfiguraci pravidla rate limitingu:

Pravidlo rate limitingu č. 1

When incoming requests match:
http.request.uri.path eq "/form" and any(http.request.headers["content-type"][*] eq "application/x-www-form-urlencoded")

Choose action: Block

Doba trvání (mitigační timeout): 10 minut

Požadavky: 1

Období: 10 sekund

Se stejnými charakteristikami:

  • ID datového centra (při vytvoření pravidla v dashboardu zahrnuto ve výchozím nastavení)
  • IP
  • Hodnota hlavičky > x-api-key

Následující diagram ukazuje, jak Cloudflare zpracuje čtyři příchozí požadavky v kontextu výše uvedeného pravidla rate limitingu.

Příklad rate limitingu se čtyřmi požadavky, kde je jeden z požadavků omezen. Podrobnosti najdete níže.

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

Požadavek 2 odpovídá výrazu pravidla, a proto Cloudflare vyhodnotí pravidlo rate limitingu. Hodnoty charakteristik neodpovídají žádnému existujícímu čítači (hodnota X-API-Key hlavička je jiná). Cloudflare proto v kontextu tohoto pravidla definuje samostatný čítač 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 zvýší hodnotu existujícího čítače a nastaví jej na 2. Hodnota čítače je nyní nad limitem definovaným v Požadavky, a proto je požadavek 3 zablokován.

Požadavek 4 neodpovídá výrazu pravidla, protože hodnota Content-Type hlavička neodpovídá hodnotě ve výrazu. Cloudflare proto pro tento požadavek nevytvoří nový čítač pravidla. Požadavek 4 není vyhodnocen v kontextu tohoto pravidla rate limitingu a je předán dalším pravidlům v průběhu vyhodnocování požadavku.

Příklad B

Zvažte následující konfiguraci pravidla rate limitingu. Počítací výraz pravidla definuje, že se čítač zvýší o jedna, když je HTTP stavový kód odpovědi 400:

Pravidlo rate limitingu č. 2

When incoming requests match:
http.request.uri.path eq "/form"

Choose action: Block

Doba trvání (mitigační timeout): 10 minut

Požadavky: 1

Období: 10 sekund

Se stejnými charakteristikami:

  • ID datového centra (při vytvoření pravidla v dashboardu zahrnuto ve výchozím nastavení)
  • IP
  • Hodnota hlavičky > x-api-key

Increment counter when: http.request.uri.path eq "/form" and http.response.code eq 400

Následující diagram ukazuje, jak Cloudflare zpracuje tyto čtyři příchozí požadavky přijaté během 10sekundového období v kontextu výše uvedeného pravidla rate limitingu.

Příklad rate limitingu se čtyřmi požadavky, kde pravidlo rate limitingu používá v počítacím výrazu pole odpovědi (HTTP kód odpovědi). Podrobnosti níže.

Protože požadavek 1 odpovídá výrazu pravidla, pravidlo rate limitingu se vyhodnotí. Požadavek se odešle na origin s vynecháním cachovaného obsahu, protože pravidlo rate limitingu obsahuje pole odpovědi (http.response.code) v počítacím výrazu. Origin odpoví 400 stavovým kódem. Protože došlo ke shodě s výrazem pro počítání, Cloudflare vytvoří čítač požadavků pro hodnoty charakteristik v kontextu pravidla rate limitingu a nastaví tento čítač na 1.

Požadavek 2 odpovídá výrazu pravidla, a proto Cloudflare vyhodnotí pravidlo rate limitingu. Čí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 odpoví 200 (stavový kód). Protože odpověď neodpovídá počítacímu výrazu, čítač se nenavýší a zachová svou hodnotu (1).

Požadavek 3 odpovídá výrazu pravidla, a Cloudflare proto vyhodnotí pravidlo rate limitingu. Požadavek je stále v rámci maximálního počtu požadavků definovaného v Požadavky. Origin odpoví 400 stavovým kódem. Dochází ke shodě s výrazem pro počítání, což nastaví čítač na 2.

Požadavek 4 odpovídá výrazu pravidla, a proto Cloudflare vyhodnotí pravidlo rate limitingu. Požadavek již 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 aplikuje akci definovanou v konfiguraci pravidla rate limitingu a na deset minut zablokuje požadavek 4 i všechny další požadavky odpovídající pravidlu rate limitingu.

Rate limiting založený na komplexitě

Ne všechny požadavky jsou stejně nákladné na obsloužení. Jednoduché čtení z API může spotřebovat minimum prostředků, 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ů k nim přistupuje stejně — 100 lehkých požadavků i 100 nákladných požadavků navyšuje tentýž čítač.

Rate limiting založený na komplexitě to řeší sledováním skóre nákladů, které každému požadavku přiřazuje váš origin server, a vynucováním maximálního celkového skóre na klienta za dané období. Klient, který odešle několik nákladných požadavků, tak může být omezen dříve, než dosáhne vysokého počtu požadavků, bez ohledu na celkový počet odeslaných požadavků.

Pro použití rate limitingu založeného na složitosti musí váš origin server vracet HTTP hlavičku odpovědi obsahující číselné skóre pro každý požadavek. Toto skóre představuje složitost nebo náklady na obsloužení daného požadavku. Hodnota musí být mezi 1 a 1 000 000. Název hlavičky, kterou pravidlo čte, si nakonfigurujete.

Pravidla rate limitingu založená na komplexitě musí obsahovat následující vlastnosti:

Cloudflare udržuje čítače s celkovým skóre všech požadavků se stejnými hodnotami charakteristik pravidla, které odpovídají výrazu pravidla. Skóre se zvyšuje o hodnotu poskytnutou originem v odpovědi, když dojde ke shodě s počítacím výrazem (ve výchozím stavu je stejný jako výraz pravidla). Když je celkové skóre vyšší než nakonfigurované maximální skóre za období, uplatní se akce pravidla.

Pokud origin server neposkytne HTTP hlavičku odpovědi s hodnotou skóre nebo je hodnota skóre mimo povolený rozsah, odpovídající čítač rate limitingu se neaktualizuje.

Příklad C

Zvažte následující konfiguraci pravidla rate limitingu. Při shodě pravidla se čítač skóre složitosti zvýší podle hodnoty v x-score hlavičky odpovědi poskytnuté origin serverem.

Pravidlo rate limitingu č. 3

When incoming requests match:
(http.request.uri.path eq "/graphql")

Se stejnými charakteristikami:

  • ID datového centra (při vytvoření pravidla v dashboardu zahrnuto ve výchozím nastavení)
  • Hodnota hlavičky > x-api-key

When rate exceeds: Založeno na složitosti

  • Skóre za období: 400
  • Období: 1 minuta
  • Název hlavičky odpovědi: x-score

Choose action: Block

With the following behavior: Blokovat po zvolenou dobu

Doba trvání (mitigační timeout): 10 minut

Následující diagram ukazuje, jak Cloudflare zpracuje čtyři příchozí požadavky přijaté během jedné minuty v kontextu výše uvedeného pravidla rate limitingu.

Příklad rate limitingu se čtyřmi požadavky, kde je pravidlo rate limitingu nakonfigurováno tak, aby zohledňovalo skóre složitosti poskytnuté v HTTP hlavičce „x-score“. Podrobnosti najdete níže.

Protože požadavek 1 odpovídá výrazu pravidla, pravidlo rate limitingu se vyhodnotí. Origin odpoví s 200 stavový kód a skóre složitosti 100 v x-score HTTP hlavičky odpovědi. Cloudflare vytvoří čítač požadavků pro hodnoty charakteristik v kontextu pravidla rate limitingu a nastaví tento čítač na 100.

Požadavek 2 odpovídá výrazu pravidla, a proto Cloudflare vyhodnotí pravidlo rate limitingu. Čítač požadavků pro hodnoty charakteristik je stále v rámci maximálního skóre za období. Origin odpoví 200 stavovým kódem 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 Cloudflare proto vyhodnotí pravidlo rate limitingu. Čítač požadavků pro hodnoty charakteristik je stále v rámci maximálního skóre za období. Origin odpoví 200 stavovým kódem 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 vyhodnotí pravidlo rate limitingu. Požadavek již 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 aplikuje akci definovanou v konfiguraci pravidla rate limitingu a na deset minut zablokuje požadavek 4 i všechny další požadavky odpovídající pravidlu rate limitingu.