{"id":4820,"date":"2026-08-11T20:59:13","date_gmt":"2026-08-11T18:59:13","guid":{"rendered":"https:\/\/www.sycope.com\/?post_type=dictionary-item&#038;p=4820"},"modified":"2026-08-12T19:02:33","modified_gmt":"2026-08-12T17:02:33","slug":"rate-limiting","status":"publish","type":"dictionary-item","link":"https:\/\/www.sycope.com\/pl\/post\/dictionary-item\/rate-limiting","title":{"rendered":"Rate Limiting"},"content":{"rendered":"<p><strong>Rate limiting<\/strong> (ograniczanie tempa \u017c\u0105da\u0144) to mechanizm, kt\u00f3ry pilnuje, ile zapyta\u0144 jeden klient mo\u017ce wys\u0142a\u0107 do serwera, <a href=\"https:\/\/www.sycope.com\/pl\/post\/dictionary-item\/api\">API<\/a> lub us\u0142ugi w danym czasie. Gdy klient przekroczy ustalony limit, kolejne zapytania zostaj\u0105 odrzucone \u2014 zwykle z kodem <a href=\"https:\/\/www.sycope.com\/pl\/post\/dictionary-item\/http-https\">HTTP<\/a> <code>429 Too Many Requests<\/code> (czyli \u201ezbyt wiele \u017c\u0105da\u0144\u201d) \u2014 albo celowo op\u00f3\u017anione. Dzi\u0119ki temu us\u0142uga zostaje dost\u0119pna dla wszystkich, zasoby dziel\u0105 si\u0119 sprawiedliwie, a wiele nadu\u017cy\u0107 (ataki <a href=\"https:\/\/www.sycope.com\/pl\/post\/dictionary-item\/ddos-distributed-denial-of-service\">DDoS<\/a>, \u0142amanie hase\u0142, masowe logowania wykradzionymi danymi, scraping) staje si\u0119 trudniejszych.<\/p>\n<h2>Jak dzia\u0142a rate limiting?<\/h2>\n<p>Rate limiter opiera si\u0119 na trzech rzeczach. Pierwsza to <strong>klucz<\/strong>, kt\u00f3ry m\u00f3wi, kto wysy\u0142a zapytanie \u2014 mo\u017ce nim by\u0107 adres IP, klucz API, identyfikator u\u017cytkownika lub sesji. Druga to <strong>limit<\/strong>, czyli ile zapyta\u0144 wolno wys\u0142a\u0107. Trzecia to <strong>okno czasowe<\/strong>, czyli w jakim przedziale ten limit obowi\u0105zuje (np. 100 zapyta\u0144 na minut\u0119). Dla ka\u017cdego klucza system zlicza zapytania w bie\u017c\u0105cym oknie i por\u00f3wnuje wynik z limitem. Gdy pula si\u0119 wyczerpie, nast\u0119pne zapytania s\u0105 blokowane lub ustawiane w kolejce, dop\u00f3ki okno si\u0119 nie odnowi.<\/p>\n<p>Wyb\u00f3r klucza ma znaczenie. Limit po samym adresie IP jest prosty, ale zawodzi w dw\u00f3ch sytuacjach. Po pierwsze, gdy wielu u\u017cytkownik\u00f3w dzieli jeden adres \u2014 tak dzia\u0142a NAT, proxy czy CGNAT, czyli mechanizmy, kt\u00f3re chowaj\u0105 wiele urz\u0105dze\u0144 za jednym adresem. Po drugie, gdy atak idzie z wielu adres\u00f3w naraz. Limit po kluczu API albo koncie u\u017cytkownika jest dok\u0142adniejszy, o ile ruch jest zalogowany. W praktyce stosuje si\u0119 kilka limit\u00f3w jednocze\u015bnie \u2014 osobno na adres IP, na u\u017cytkownika i na konkretny endpoint, czyli pojedynczy adres us\u0142ugi w API.<\/p>\n<h2>Jakie s\u0105 algorytmy rate limitingu?<\/h2>\n<p>Spos\u00f3b liczenia zapyta\u0144 wp\u0142ywa na trzy rzeczy: jak dok\u0142adny jest limit, jak bardzo toleruje chwilowe skoki ruchu (tzw. burst) i ile zu\u017cywa pami\u0119ci. Oto pi\u0119\u0107 najcz\u0119stszych podej\u015b\u0107:<\/p>\n<ul>\n<li><strong>Fixed window (sta\u0142e okno)<\/strong> \u2014 dzieli czas na r\u00f3wne odcinki (np. ka\u017cda pe\u0142na minuta) i liczy zapytania w bie\u017c\u0105cym odcinku. Prosty i oszcz\u0119dny pami\u0119ciowo. Ma jednak s\u0142abo\u015b\u0107 zwan\u0105 <em>problemem granicy okna<\/em>: wysy\u0142aj\u0105c zapytania tu\u017c przed ko\u0144cem jednego okna i tu\u017c po starcie nast\u0119pnego, klient mo\u017ce w kr\u00f3tkim czasie przepu\u015bci\u0107 podw\u00f3jny limit.<\/li>\n<li><strong>Sliding window log (przesuwne okno z logiem)<\/strong> \u2014 zapami\u0119tuje dok\u0142adny czas ka\u017cdego zapytania. Przy nowym zapytaniu usuwa te starsze ni\u017c d\u0142ugo\u015b\u0107 okna i liczy reszt\u0119. Najdok\u0142adniejszy i najsprawiedliwszy, ale przy du\u017cym ruchu zjada sporo pami\u0119ci.<\/li>\n<li><strong>Sliding window counter (przesuwne okno licznikowe)<\/strong> \u2014 przybli\u017ca okno przesuwne. Bierze liczniki bie\u017c\u0105cego i poprzedniego okna i wa\u017cy je w zale\u017cno\u015bci od tego, ile czasu ju\u017c up\u0142yn\u0119\u0142o. Dobry kompromis: prawie znosi problem granicy, a pami\u0119ci zu\u017cywa umiarkowanie.<\/li>\n<li><strong>Token bucket (kube\u0142ek z \u017cetonami)<\/strong> \u2014 kube\u0142ek nape\u0142nia si\u0119 \u017cetonami ze sta\u0142\u0105 szybko\u015bci\u0105, a\u017c do pewnej pojemno\u015bci. Ka\u017cde zapytanie zu\u017cywa jeden \u017ceton. Klient, kt\u00f3ry chwil\u0119 nie wysy\u0142a\u0142 zapyta\u0144, zbiera zapas \u017ceton\u00f3w i mo\u017ce potem nadrobi\u0107 kr\u00f3tkim skokiem \u2014 przy zachowaniu \u015bredniego tempa. Cz\u0119sty domy\u015blny wyb\u00f3r dla publicznych API.<\/li>\n<li><strong>Leaky bucket (ciekn\u0105cy kube\u0142ek)<\/strong> \u2014 zapytania trafiaj\u0105 do kolejki, kt\u00f3ra opr\u00f3\u017cnia si\u0119 ze sta\u0142\u0105 szybko\u015bci\u0105. Gdy kolejka si\u0119 przepe\u0142ni, nadmiar jest odrzucany. Wymusza r\u00f3wne, wyg\u0142adzone tempo bez miejsca na skoki \u2014 przydatny, gdy chcemy wyr\u00f3wna\u0107 ruch wychodz\u0105cy.<\/li>\n<\/ul>\n<h2>Gdzie wdra\u017ca si\u0119 rate limiting?<\/h2>\n<p>Ograniczanie tempa dzia\u0142a na wielu warstwach infrastruktury, cz\u0119sto naraz:<\/p>\n<ul>\n<li><strong>Brzeg sieci \/ CDN<\/strong> \u2014 zatrzymuje nadmiarowy lub z\u0142o\u015bliwy ruch jak najbli\u017cej \u017ar\u00f3d\u0142a, zanim dotrze do serwera docelowego.<\/li>\n<li><strong>WAF (<a href=\"https:\/\/www.sycope.com\/pl\/post\/dictionary-item\/waf-web-application-firewall\">Web Application Firewall<\/a>, czyli zapora aplikacji webowych)<\/strong> \u2014 \u0142\u0105czy limity z regu\u0142ami dla konkretnych \u015bcie\u017cek (np. ostre limity na <code>\/login<\/code> i na wyszukiwark\u0119).<\/li>\n<li><strong>API gateway (brama API)<\/strong> \u2014 egzekwuje zasady dla ca\u0142ego ruchu API, np. limity na klucz API, na plan abonamentu, na endpoint.<\/li>\n<li><strong>Reverse proxy \/ load balancer<\/strong> \u2014 np. modu\u0142y rate limit w serwerach takich jak Nginx czy HAProxy.<\/li>\n<li><strong>Warstwa aplikacji<\/strong> \u2014 najbardziej szczeg\u00f3\u0142owa kontrola, oparta na logice biznesowej (np. limit kosztu zapytania, a nie tylko ich liczby).<\/li>\n<\/ul>\n<p>W \u015brodowiskach rozproszonych liczniki musz\u0105 by\u0107 wsp\u00f3lne dla wielu instancji (np. w bazie Redis). Pojawia si\u0119 tu kompromis. Silna sp\u00f3jno\u015b\u0107 daje dok\u0142adny limit, ale kosztem op\u00f3\u017anie\u0144. Sp\u00f3jno\u015b\u0107 ostateczna jest szybsza, ale dopuszcza chwilowe przekroczenia.<\/p>\n<h2>Jak rate limiting chroni przed atakami?<\/h2>\n<p>Z perspektywy bezpiecze\u0144stwa rate limiting spowalnia i utrudnia atak, ale sam w sobie nie jest pe\u0142n\u0105 ochron\u0105:<\/p>\n<ul>\n<li><strong><a href=\"https:\/\/www.sycope.com\/pl\/post\/dictionary-item\/brute-force\">Brute force<\/a> i <a href=\"https:\/\/www.sycope.com\/pl\/post\/dictionary-item\/credential-stuffing\">credential stuffing<\/a><\/strong> \u2014 limit pr\u00f3b logowania na konto i na IP mocno spowalnia zgadywanie hase\u0142 oraz testowanie wykradzionych par login\u2013has\u0142o. Daje to zespo\u0142om czas na reakcj\u0119. (Brute force to zgadywanie has\u0142a metod\u0105 pr\u00f3b i b\u0142\u0119d\u00f3w; credential stuffing to masowe podstawianie danych wykradzionych z innych serwis\u00f3w.)<\/li>\n<li><strong>Ataki DDoS na warstw\u0119 aplikacji (<a href=\"https:\/\/www.sycope.com\/pl\/post\/dictionary-item\/application-layer-attack-l7\">L7<\/a>)<\/strong> \u2014 odrzucanie \u017c\u0105da\u0144 ponad pr\u00f3g ogranicza skutki zalewania kosztownych endpoint\u00f3w. Przy atakach wolumetrycznych, kt\u00f3re po prostu zapychaj\u0105 \u0142\u0105cze, potrzebne s\u0105 dodatkowe mechanizmy na brzegu sieci.<\/li>\n<li><strong>Scraping i nadu\u017cycia API<\/strong> \u2014 limity na klienta utrudniaj\u0105 masowe pobieranie danych i przeszukiwanie zasob\u00f3w.<\/li>\n<li><strong>Wyczerpanie zasob\u00f3w<\/strong> \u2014 ograniczanie tempa, zw\u0142aszcza oparte na koszcie \u017c\u0105dania, chroni przed pojedynczymi klientami, kt\u00f3rzy zjadaj\u0105 nieproporcjonalnie du\u017co procesora, pami\u0119ci czy \u0142\u0105cza.<\/li>\n<\/ul>\n<h2>Dlaczego rate limiting jest wa\u017cny dla monitoringu i SOC?<\/h2>\n<p>Zdarzenia rate limitingu to cenna informacja dla zespo\u0142\u00f3w bezpiecze\u0144stwa i monitoringu sieci (<a href=\"https:\/\/www.sycope.com\/pl\/post\/dictionary-item\/soc-security-operations-center\">SOC<\/a> to centrum operacji bezpiecze\u0144stwa, <a href=\"https:\/\/www.sycope.com\/pl\/post\/dictionary-item\/ndr-network-detection-and-response\">NDR<\/a> to wykrywanie zagro\u017ce\u0144 w ruchu sieciowym). Nag\u0142y wzrost odpowiedzi <code>429<\/code> z jednego klucza API albo z puli adres\u00f3w to sygna\u0142: kto\u015b pr\u00f3buje nadu\u017cy\u0107, klient jest \u017ale skonfigurowany albo zaczyna si\u0119 atak. Zestawienie liczby odrzuce\u0144 z konkretnymi endpointami (np. logowanie, reset has\u0142a) pomaga odr\u00f3\u017cni\u0107 atak na konta od zwyk\u0142ego skoku ruchu. Analiza wzorc\u00f3w \u017c\u0105da\u0144 \u2014 jak cz\u0119sto przychodz\u0105, z jakich adres\u00f3w IP i agent\u00f3w, jak rozk\u0142adaj\u0105 si\u0119 w ci\u0105gu doby \u2014 pozwala wykry\u0107 automatyzacj\u0119 i ruch bot\u00f3w, kt\u00f3rych samo blokowanie po progu mo\u017ce nie zauwa\u017cy\u0107.<\/p>\n<h2>Czym r\u00f3\u017cni si\u0119 rate limiting od throttlingu?<\/h2>\n<p>Poj\u0119cia bywaj\u0105 mylone, ale r\u00f3\u017cni\u0105 si\u0119 reakcj\u0105 na przekroczenie progu. <strong>Rate limiting<\/strong> egzekwuje twardy limit \u2014 \u017c\u0105dania ponad pr\u00f3g s\u0105 odrzucane (zwykle <code>429<\/code>). <strong>Throttling<\/strong> jest \u0142agodniejszy: przyjmuje \u017c\u0105dania, ale zwalnia ich obs\u0142ug\u0119 \u2014 op\u00f3\u017ania, kolejkuje albo obni\u017ca priorytet nadmiarowego ruchu, zamiast go odrzuca\u0107. W praktyce throttling bywa jedn\u0105 z mo\u017cliwych reakcji w ramach polityki rate limitingu, a wiele bram API stosuje oba podej\u015bcia razem.<\/p>\n<h2>Jak klient powinien reagowa\u0107 na 429?<\/h2>\n<p>Odpowied\u017a <code>429 Too Many Requests<\/code> cz\u0119sto zawiera nag\u0142\u00f3wek <code>Retry-After<\/code>, kt\u00f3ry m\u00f3wi, ile klient ma odczeka\u0107 przed kolejn\u0105 pr\u00f3b\u0105 (w sekundach lub jako data). Wiele API dodaje te\u017c nag\u0142\u00f3wki informacyjne, np. <code>X-RateLimit-Limit<\/code>, <code>X-RateLimit-Remaining<\/code> i <code>X-RateLimit-Reset<\/code>. Dobrze napisany klient honoruje <code>Retry-After<\/code> i stosuje <strong>exponential backoff z jitterem<\/strong> \u2014 czyli wyd\u0142u\u017ca odst\u0119py mi\u0119dzy pr\u00f3bami i dorzuca ma\u0142\u0105 losow\u0105 warto\u015b\u0107, \u017ceby ponowienia nie nadchodzi\u0142y zsynchronizowanymi falami. Ignorowanie tych sygna\u0142\u00f3w tylko pog\u0142\u0119bia przeci\u0105\u017cenie.<\/p>\n<h2>Dowiedz si\u0119 wi\u0119cej<\/h2>\n<ul>\n<li><a href=\"https:\/\/www.sycope.com\/pl\/post\/zaawansowane-metody-ochrony-przed-atakami-ddos-w-frimach\">Zaawansowane metody ochrony przed atakami DDoS w firmach<\/a> \u2014 Rate limiting ogranicza tempo ruchu, co pomaga t\u0142umi\u0107 skutki atak\u00f3w DDoS.<\/li>\n<li><a href=\"https:\/\/www.sycope.com\/pl\/post\/podatnosc-idor-jak-wykryc-atak-na-aplikacje-webowe-przez-analize-ruchu-http\">Podatno\u015b\u0107 IDOR \u2013 jak wykry\u0107 atak na aplikacje webowe przez analiz\u0119 ruchu HTTP<\/a> \u2014 Rate limiting utrudnia masowe pr\u00f3by odwo\u0142a\u0144 do zasob\u00f3w przy podatno\u015bci IDOR.<\/li>\n<li><a href=\"https:\/\/www.sycope.com\/pl\/post\/bledy-dns-i-bezpieczenstwo-dns-dnssec-ochrona-przed-atakami-dns-i-dns-managemen-errors\">B\u0142\u0119dy DNS i bezpiecze\u0144stwo DNS \u2013 DNSSEC, ochrona przed atakami DNS i DNS management errors<\/a> \u2014 Rate limiting ogranicza nadmiar zapyta\u0144 <a href=\"https:\/\/www.sycope.com\/pl\/post\/dictionary-item\/dns\">DNS<\/a> i pomaga blokowa\u0107 nadu\u017cycia.<\/li>\n<li><a href=\"https:\/\/www.sycope.com\/pl\/post\/dictionary-item\/api-security\">API Security<\/a> \u2014 Rate limiting jest podstawow\u0105 kontrol\u0105 bezpiecze\u0144stwa API przed nadu\u017cyciami.<\/li>\n<\/ul>\n","protected":false},"featured_media":0,"template":"","class_list":["post-4820","dictionary-item","type-dictionary-item","status-publish","hentry"],"acf":{"tytul":"Rate Limiting","ikona":"","krotki_opis":"Mechanizm pilnuj\u0105cy, ile \u017c\u0105da\u0144 jeden klient mo\u017ce wys\u0142a\u0107 w danym oknie czasowym; po przekroczeniu progu odrzuca je (HTTP 429) lub op\u00f3\u017ania, chroni\u0105c dost\u0119pno\u015b\u0107 i ograniczaj\u0105c nadu\u017cycia."},"_links":{"self":[{"href":"https:\/\/www.sycope.com\/pl\/wp-json\/wp\/v2\/dictionary-item\/4820","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.sycope.com\/pl\/wp-json\/wp\/v2\/dictionary-item"}],"about":[{"href":"https:\/\/www.sycope.com\/pl\/wp-json\/wp\/v2\/types\/dictionary-item"}],"wp:attachment":[{"href":"https:\/\/www.sycope.com\/pl\/wp-json\/wp\/v2\/media?parent=4820"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}