Czym jest rate limiting po IP?

Rate limiting po IP to mechanizm ograniczający liczbę żądań, które adres IP może wysłać do serwera w określonym czasie. Jeśli przekroczysz limit, serwer tymczasowo odrzuca twoje żądania, zwykle z błędem HTTP 429 ("Too Many Requests"). To jedno z najczęściej stosowanych narzędzi ochrony serwerów przed nadużyciami, atakami odmowy usługi i zautomatyzowanym scrapingiem.

Prawdopodobnie już się z tym spotkałeś, nie zdając sobie sprawy. Gdy strona wyświetla "Zbyt wiele prób, spróbuj ponownie za 5 minut" po kilku nieudanych logowaniach, to rate limiting. Gdy API zwraca błąd po określonej liczbie wywołań na minutę, to rate limiting. Gdy wyszukiwarka tymczasowo blokuje twoje zapytania, bo szukałeś zbyt szybko, to też rate limiting.

Dlaczego jest potrzebny

Serwer webowy ma ograniczone zasoby: CPU, pamięć, przepustowość, połączenia z bazą danych. Każde żądanie zużywa część tych zasobów. Bez żadnego ograniczenia pojedynczy użytkownik (lub zautomatyzowany skrypt) mógłby zmonopolizować serwer, wysyłając tysiące żądań na sekundę, czyniąc usługę niedostępną dla wszystkich innych.

Rate limiting chroni przed kilkoma typami zagrożeń:

Ataki DDoS i brute force. Atak rozproszonej odmowy usługi (DDoS) zalewa serwer żądaniami, by uczynić go niedostępnym. Sam rate limiting nie wystarczy do zablokowania masowego DDoS (przychodzącego z tysięcy różnych IP), ale ogranicza szkody, jakie może wyrządzić pojedynczy IP. Przy atakach brute force (próbowanie tysięcy haseł) rate limiting jest pierwszą linią obrony: ograniczenie do 5-10 prób logowania na minutę czyni atak niepraktycznym.

Nadużywanie scrapingu i crawlingu. Boty wyciągające zawartość stron (ceny, artykuły, dane) wysyłają setki żądań na sekundę. Rate limiting spowalnia te boty do punktu, gdzie masowa ekstrakcja staje się ekonomicznie nieopłacalna (za wolno, za dużo czasu serwera).

Nadużywanie API. Publiczne API (pogoda, geolokalizacja, AI, płatności) mają koszt za żądanie dla dostawcy. Bez rate limitingu użytkownik mógłby zużywać nieproporcjonalne zasoby, czy to przez błąd (pętla w kodzie) czy celowo. Większość API narzuca limity na klucz API i na adres IP.

Sprawiedliwość między użytkownikami. Nawet bez złych intencji "zachłanny" użytkownik (odświeżający stronę 50 razy na minutę lub źle napisany skrypt) może pogarszać doświadczenie dla innych. Rate limiting zapewnia sprawiedliwy podział zasobów.

Jak to działa technicznie

Zasada jest prosta: serwer kojarzy każde żądanie z adresem IP, liczy żądania otrzymane z tego IP w oknie czasowym i odrzuca żądania przekraczające zdefiniowany próg. Ale konkretna implementacja różni się w zależności od zastosowanego algorytmu.

Okno stałe (Fixed Window). Czas dzielony jest na stałe interwały (np. jednominutowe okna). Serwer liczy żądania per IP w każdym oknie. Jeśli osiągniesz 100 żądań w bieżącym oknie, kolejne są odrzucane do początku następnego. To najprostszy algorytm, ale ma wadę: jeśli wyślesz 100 żądań na końcu jednego okna i 100 na początku następnego, wysłałeś 200 żądań w kilka sekund, dwukrotność zamierzonego limitu.

Okno przesuwne (Sliding Window). Zamiast stałych okien serwer patrzy na ostatnie N sekund w dowolnym momencie. Każde żądanie jest liczone w okresie przesuwanym. To wygładza dystrybucję i eliminuje problem okna stałego, ale wymaga więcej pamięci i obliczeń po stronie serwera.

Token Bucket (wiadro z tokenami). Każdy IP ma "wiadro" zawierające stałą liczbę tokenów. Każde żądanie zużywa token. Tokeny regenerują się ze stałą szybkością (np. 10 na sekundę). Jeśli wiadro jest puste, żądanie jest odrzucane. Model ten pozwala na krótkie serie (burst): możesz wysłać wiele żądań naraz, jeśli wiadro jest pełne, potem musisz czekać na regenerację. To najczęściej używany algorytm w produkcji, bo jest zarówno elastyczny, jak i przewidywalny.

Leaky Bucket (dziurawe wiadro). Żądania trafiają do kolejki (wiadra) i są przetwarzane ze stałą szybkością (szybkość wycieku). Jeśli wiadro jest pełne, nowe żądania są odrzucane. W odróżnieniu od Token Bucket, Leaky Bucket wymusza ściśle stałą szybkość wyjściową, bez serii. Przydatny, gdy chcesz idealnie równomiernego przepływu przetwarzania.

Gdzie stosowany jest rate limiting

Rate limiting może być stosowany na różnych poziomach infrastruktury sieciowej, i w praktyce często tak jest: kilka warstw nakłada się na siebie.

Na poziomie serwera web. Nginx, Apache i większość serwerów web zawiera moduły rate limitingu. Nginx np. używa algorytmu Leaky Bucket ze swoją dyrektywą limit_req. Definiujesz liczbę żądań na sekundę per IP, a Nginx zajmuje się resztą. Skuteczne dla podstawowej ochrony, ale serwer i tak musi odebrać i częściowo przetworzyć każde żądanie przed odrzuceniem.

Na poziomie reverse proxy lub load balancera. Umieszczenie rate limitingu przed serwerami aplikacyjnymi (na reverse proxy jak Nginx lub HAProxy, lub load balancerze) pozwala blokować żądania zanim dotrą do aplikacji. Bardziej efektywne pod względem zasobów.

Na poziomie CDN lub firewalla aplikacyjnego (WAF). Usługi jak Cloudflare, AWS WAF czy Akamai stosują rate limiting na brzegu sieci (edge), zanim żądanie w ogóle dotrze do twojej infrastruktury. To najskuteczniejsza warstwa przeciw atakom wolumenowym, bo żądanie jest blokowane jak najbliżej źródła.

Na poziomie aplikacji. Sama aplikacja może implementować rate limiting, często z większą granularnością: per zalogowany użytkownik, per endpoint, per typ operacji. Np. API może zezwalać na 1000 żądań GET na minutę, ale tylko 10 żądań POST na endpoint tworzenia konta, bo nadużywane próby tworzenia kont to częsty wektor ataku.

Nagłówki HTTP związane z rate limitingiem

Gdy serwer stosuje rate limiting, zwykle komunikuje informacje o limitach przez nagłówki HTTP w odpowiedzi. Nie ma uniwersalnego standardu, ale najczęstsze konwencje to:

X-RateLimit-Limit: maksymalna liczba żądań dozwolonych w bieżącym oknie czasowym. X-RateLimit-Remaining: liczba pozostałych żądań przed osiągnięciem limitu. X-RateLimit-Reset: moment (jako Unix timestamp lub pozostałe sekundy), w którym okno się resetuje i licznik wraca do zera. Retry-After: standardowy nagłówek HTTP wskazujący, jak długo czekać przed ponowną próbą, zwracany z odpowiedzią 429.

Draft IETF (RFC 6585 dla kodu 429 i nowsze propozycje) próbuje standaryzować te nagłówki, ale w praktyce każde API używa własnej konwencji. Jeśli budujesz aplikację konsumującą API, zawsze czytaj dokumentację API, by wiedzieć, jak komunikuje swoje limity.

Dlaczego sam IP nie zawsze wystarcza

Rate limiting po IP ma fundamentalny problem: adres IP nie zawsze odpowiada jednemu użytkownikowi.

CGNAT. Wielu operatorów komórkowych i niektórzy ISP używają CGNAT (Carrier-Grade NAT), przez co setki lub tysiące użytkowników dzielą jeden publiczny adres IPv4. Jeśli ograniczysz IP do 100 żądań na minutę, w rzeczywistości ograniczasz wszystkich użytkowników za tym CGNAT do łącznego limitu 100 żądań. Jeden normalny użytkownik może wyczerpać kwotę dla wszystkich innych.

Sieci korporacyjne i uniwersyteckie. Tysiące pracowników lub studentów może korzystać z internetu przez jeden publiczny IP (lub małą liczbę adresów). Rate limiting po IP karze ich zbiorowo.

VPN i proxy. Użytkownicy VPN często dzielą adres IP z setkami innych osób. Ścisły rate limiting po IP może blokować legalnych użytkowników po prostu dlatego, że korzystają z tego samego serwera VPN co bot.

Dynamiczne adresy IP. Z drugiej strony, atakujący może łatwo zmienić adres IP (używając puli proxy, botnetu lub po prostu włączając tryb samolotowy na telefonie) i ominąć rate limiting po IP. Jeśli limit jest per IP, a atakujący ma dostęp do 10 000 adresów, efektywny limit jest pomnożony przez 10 000.

Dlatego nowoczesne systemy rate limitingu zwykle łączą IP z innymi identyfikatorami: kluczem API, tokenem uwierzytelniającym, odciskiem przeglądarki, ciasteczkiem sesji. IP pozostaje przydatnym kryterium, ale rzadko wystarczającym samodzielnie.

Co się dzieje, gdy jesteś ograniczony

Najczęstsza odpowiedź to kod HTTP 429 (Too Many Requests). Serwer może też zwrócić 503 (Service Unavailable), jeśli ograniczenie wynika z ogólnego przeciążenia, a nie z indywidualnego przekroczenia.

Niektóre usługi nie blokują całkowicie dostępu, lecz degradują usługę: spowalniają odpowiedzi (throttling), obniżają jakość wyników lub dodają CAPTCHA, by zweryfikować, że jesteś człowiekiem.

Inne usługi blokują cicho, bez zwracania jawnego błędu. Nadal odpowiadają kodem 200 (OK), ale zwracają puste dane lub zdegradowane wyniki. Ten "cichy rate limiting" (shadow banning) jest powszechny w mediach społecznościowych i niektórych wyszukiwarkach i jest zaprojektowany, by być trudnym do wykrycia przez boty.

Jak programiści radzą sobie z rate limitingiem

Jeśli budujesz aplikację konsumującą API, musisz prawidłowo obsługiwać rate limiting. Standardowa metoda to "exponential backoff": gdy otrzymujesz odpowiedź 429, czekasz określony czas przed ponowną próbą i podwajasz ten czas przy każdym kolejnym niepowodzeniu. Np.: pierwsza próba po 1 sekundzie, druga po 2 sekundach, trzecia po 4 sekundach itd.

Dobre praktyki obejmują:

Czytanie nagłówków Retry-After i X-RateLimit-Reset, by wiedzieć dokładnie, kiedy ponowić próbę, zamiast zgadywać. Implementację cache'a, by unikać powtarzania tych samych żądań. Grupowanie żądań (batching), gdy API na to pozwala. Rozłożenie żądań w czasie zamiast wysyłania ich seriami. Przewidzenie circuit breakera, który przestanie wywoływać API na jakiś czas, jeśli błędy 429 się kumulują, by nie pogarszać sytuacji.

Rate limiting a prywatność

Rate limiting po IP oznacza, że serwer identyfikuje i śledzi żądania po adresie IP. To forma przetwarzania danych osobowych (adres IP jest uważany za dane osobowe w wielu jurysdykcjach, zwłaszcza pod RODO w Europie). Firmy implementujące rate limiting powinny w teorii wspominać o tym przetwarzaniu w swojej polityce prywatności.

Z perspektywy użytkownika rate limiting po IP oznacza też, że twoja aktywność jest zliczana. Jeśli używasz VPN lub proxy ze względu na prywatność, rate limiting może paradoksalnie cię karać: dzielisz IP z innymi użytkownikami i wspólna kwota wyczerpuje się szybciej.

Obchodzenie rate limitingu

Zmiana adresu IP (przez VPN, rotacyjny proxy lub tryb samolotowy na telefonie) pozwala ominąć rate limiting oparty wyłącznie na IP. Komercyjne serwisy scrapingowe używają puli tysięcy rezydencjalnych adresów IP, by rozłożyć żądania i utrzymać się poniżej progów per IP.

Ale nowoczesne systemy ochrony nie ograniczają się do IP. Łączą analizę odcisku przeglądarki, zachowania przeglądania (rytm kliknięć, ruchy myszy, czas na stronach), CAPTCHA i analizę wzorców żądań, by odróżnić ludzi od botów, nawet gdy IP zmienia się przy każdym żądaniu.

Wyścig między systemami rate limitingu a technikami obchodzenia jest permanentny. Metody działające dziś mogą być wykryte jutro. Jeśli jesteś po stronie serwera, najlepsza strategia to łączenie wielu warstw ochrony zamiast polegania na samym IP.

Przykłady typowych limitów

Te limity różnią się ogromnie w zależności od usługi, planu cenowego i kontekstu. Płatne API oferuje zwykle znacznie wyższe limity niż plan darmowy. Wrażliwy endpoint (logowanie, płatność, tworzenie konta) ma znacznie niższe limity niż endpoint odczytu danych.

Rate limiting po IP to podstawowa ochrona dla każdego serwera wystawionego na internet. Zapobiega nadużyciom, chroni zasoby i zapewnia sprawiedliwy dostęp. Ale sam adres IP to coraz mniej wiarygodny identyfikator z CGNAT, VPN i proxy. Nowoczesne systemy łączą IP z innymi sygnałami, by odróżnić ruch legalny od nadużyć, i to ta kombinacja stanowi różnicę między skuteczną ochroną a prostym filtrem łatwym do obejścia.