Podstawowe algorytmy ograniczania ruchu
Wśród najczęściej opisywanych w dokumentacjach bramek API algorytmów rate limitingu wymienia się fixed window, sliding window, token bucket oraz leaky bucket. Fixed window dzieli czas na stałe przedziały i liczy żądania w ramach każdego z nich, co jest proste w implementacji, ale może prowadzić do skoków ruchu na granicach okien czasowych. Sliding window łagodzi ten efekt poprzez ciągłe przesuwanie okna pomiaru.
Token bucket opiera się na puli tokenów uzupełnianej ze stałą prędkością — każde żądanie zużywa jeden token, a brak dostępnych tokenów skutkuje odrzuceniem lub opóźnieniem żądania. Leaky bucket działa w podobny sposób, lecz kładzie nacisk na wygładzenie tempa przetwarzania żądań niezależnie od ich chwilowej intensywności.
Poziomy stosowania limitów
Limity mogą być definiowane na poziomie pojedynczego klienta (na podstawie klucza API lub adresu IP), pojedynczego endpointu, całej usługi lub globalnie dla całej bramki. W praktyce organizacje często łączą kilka poziomów jednocześnie, aby zabezpieczyć zarówno pojedynczych konsumentów API, jak i całą infrastrukturę przed nadmiernym obciążeniem.
Konsekwencje przekroczenia limitu
Standardową praktyką opisywaną w specyfikacjach API jest zwracanie kodu odpowiedzi HTTP 429 (Too Many Requests) wraz z nagłówkami informującymi o czasie, po którym klient może ponowić żądanie. Takie podejście pozwala klientom API na wdrożenie mechanizmów ponawiania żądań (retry) w sposób nieobciążający dodatkowo systemu.
Który algorytm rate limitingu jest najczęściej stosowany?
Token bucket oraz sliding window są jednymi z najczęściej wdrażanych podejść ze względu na równowagę między elastycznością a przewidywalnością zachowania systemu pod obciążeniem.
Czy rate limiting chroni przed atakami DDoS?
Rate limiting ogranicza skutki nadmiernego ruchu na poziomie aplikacji, jednak w przypadku dużych ataków wolumetrycznych zwykle wymagane są dodatkowe mechanizmy na poziomie sieciowym.