Публичный API под высокой нагрузкой периодически ошибочно блокирует легитимных пользователей из-за rate limiting, при этом злоумышленники всё равно обходят лимиты через множество IP. Как пересмотреть стратегию защиты, учитывая противоречие между производительностью, точностью и безопасностью?

Короткий ответ

Нужно выбрать алгоритм и уровень ограничения (per-IP, per-account, per-API-key, поведенческий анализ) под конкретный профиль трафика: простые алгоритмы (fixed window) дёшевы, но грубы и дают всплески на границах окна; скользящее окно или token bucket точнее, но дороже по вычислениям и состоянию при высокой нагрузке; одного универсального порога часто недостаточно против распределённой атаки.

Как это работает подробнее

Fixed window считает запросы в фиксированных интервалах и обнуляет счётчик на границе, что даёт эффект всплеска (burst) на стыке окон; sliding window и token bucket сглаживают эту проблему ценой необходимости хранить больше состояния (временные метки запросов или текущее число токенов) в быстром хранилище вроде Redis, что увеличивает нагрузку при очень высоком трафике.

• Компромисс. Более точные алгоритмы (sliding window, token bucket с детальным состоянием) снижают ложные блокировки легитимных пользователей, но увеличивают нагрузку на инфраструктуру лимитирования при росте трафика; грубые алгоритмы дёшевы, но создают всплески и легко обходятся распределённой атакой. Выбор зависит от того, что дороже для бизнеса — потерянные легитимные запросы или риск недостаточной защиты, а также от реальной архитектуры трафика (доля пользователей за общим IP/NAT).

Пример кода

example.txtКопировать

Fixed window (окно 60с, лимит 100):
  00:00:59 -- 100 запросов проходят
  00:01:00 -- окно сброшено, ещё 100 запросов проходят сразу
  -> 200 запросов за 2 секунды на границе окна
Token bucket (ёмкость 100, пополнение 100/60с):
  запросы расходуют токены постепенно, burst ограничен ёмкостью bucket,
  не зависит от произвольной границы окна

Что использовать на практике

• Практика. Для защиты от распределённых атак per-IP недостаточно — добавляют лимиты по API-ключу/аккаунту и поведенческий анализ (резкий рост необычных паттернов запросов, нетипичная география), а для легитимных пользователей вводят более мягкие меры при первом превышении (задержка, капча) вместо немедленной блокировки.

Подводные камни

• Риск. Усиливают лимиты только по одному измерению (IP), не замечая, что это бьёт по легитимным пользователям за NAT/VPN и не останавливает атаку с множества IP; выбирают дорогой точный алгоритм без оценки его стоимости на масштабе; не разделяют лимиты по критичности эндпоинтов.