Определение
Rate limiting — управляющий контроль трафика, накладывающий верхнюю границу на частоту, с которой клиент может выполнять конкретное действие в заданном окне времени. Когда клиент превышает порог, сервер отвечает ошибкой — обычно HTTP 429 Too Many Requests — или молча отбрасывает лишние запросы. Окно сбрасывается либо по фиксированному расписанию (счётчик «фиксированного окна»), либо скользяще («скользящее окно»), и скользящие окна обеспечивают более ровное применение, мешая взрывной эксплуатации на границе окна.
Rate limiting — один из старейших и наиболее повсеместных средств веб-безопасности. OWASP (Open Web Application Security Project) рекомендует его как основную защиту от перебора паролей, credential stuffing и автоматизированного злоупотребления формами. Cloudflare предлагает rate limiting как функцию своего WAF: правила настраиваются по пути URL, методу HTTP, IP, значению cookie и заголовку запроса. AWS WAF, Azure Front Door и Google Cloud Armor предоставляют эквивалентные возможности.
Как работает rate limiting
Rate limiter ведёт счётчик для каждого уникального идентификатора клиента — чаще всего исходный IP, иногда идентификатор аккаунта, API-ключ или session cookie. Когда приходит запрос, сервер сверяет текущее значение счётчика для этого идентификатора. Если оно ниже порога, запрос пропускается, а счётчик увеличивается. Если значение на пороге или выше — запрос отклоняется ответом 429 либо обрабатывается согласно настроенной политике.
Хранилище счётчиков обычно реализуют на Redis или Memcached ради быстрых распределённых поисков по нескольким экземплярам сервера — это требование для горизонтально масштабируемых приложений. Документация Cloudflare описывает применение rate limiting на уровне edge-сети: правила применяются до того, как запросы достигают origin, размазывая снижение нагрузки по глобальной инфраструктуре.
Распространённые параметры в конкурсном контексте:
- Голосов на IP в окне времени: самая частая конфигурация. Пример: не более 1 голоса на IP за окно 24 часа.
- Голосов на аккаунт за конкурс: применяется на уровне приложения, ключом служит идентификатор авторизованного пользователя.
- Регистраций на IP в час: применяется на эндпоинте создания аккаунтов, чтобы тормозить ботовое фарминг-создание.
- API-вызовов на токен в минуту: актуально для платформ с публичным API голосования.
Rate limiting можно применять и вероятностно — например, более жёсткие лимиты к запросам с поведенческими или fingerprint-сигналами автоматизации, и более мягкие — к сессиям с уверенными «человеческими» индикаторами.
Где вы это встречаете
Rate limiting — повсеместный контроль практически в каждой веб-платформе. Операторы конкурсов сталкиваются с ним прежде всего в трёх местах: эндпоинте отправки голоса, форме регистрации и (если требуется подтверждение по email) в конвейере отправки писем. API-интеграции конкурсов сталкиваются с лимитами на API-эндпоинтах платформы.
Для вас как пользователя rate limiting заметнее всего проявляется ошибкой HTTP 429 или специфичным сообщением вроде «Вы уже проголосовали» или «Подождите перед следующим голосом». Многие платформы используют мягкий rate limiting — принимают запрос и молча отбрасывают дубль, чтобы не подсказывать злоумышленникам наличие контроля.
Документация Cloudflare WAF указывает, что правила rate limiting можно сначала перевести в режим «только лог» во время фазы анализа, а затем переключить в блокировку, как только подобран адекватный порог. Этот двухэтапный подход помогает не блокировать случайно легитимные всплески голосов.
Практические примеры
Конкурс кулинарных блогеров в России настраивает систему голосования с лимитом 24 часа на IP. На последней неделе вы пытаетесь отправить 50 голосов подряд с одного бытового IP. Первый принят; следующие 49 получают ответ 429. Браузер показывает сообщение, объясняющее лимит «один раз в день».
SaaS-платформа конкурсов, размещающая сотни одновременных конкурсов, использует rate limiting Cloudflare на edge. Бот, направляющий на один конкурс 10 000 запросов в минуту, ограничивается до 60 запросов в минуту на edge, а лишние запросы вообще не доходят до origin-сервера. Журналы origin показывают только лимитированный трафик, и нагрузка CPU не растёт.
OWASP-аудит микросайта стартапа выявляет отсутствие rate limiting на эндпоинте повторной отправки подтверждающего email как уязвимость — атакующий мог бы засыпать ящик жертвы тысячами писем. Аудит рекомендует ограничение в 3 повторные отправки на адрес в час, что соответствует руководству OWASP по предотвращению перебора.
Связанные понятия
Обнаружение аномалий — более развитый дополнитель rate limiting: где rate limiting задаёт жёсткие пороги, обнаружение аномалий находит отклонения от усвоенного поведения, перехватывая мошеннические кампании, держащиеся чуть ниже фиксированных лимитов. ASN-разнообразие важно, когда лимиты применяются на IP и злоумышленник распределяет запросы по множеству IP, чтобы оставаться ниже порога — анализ на уровне ASN отлавливает агрегатный паттерн. reCAPTCHA v3 даёт поведенческую оценку риска, которую можно совместить с rate limiting, чтобы избирательно применять более жёсткие лимиты к сессиям с подозрением на автоматизацию.
Ограничения / Оговорки
Rate limiting по IP менее эффективен в средах carrier-grade NAT, где один публичный IP может представлять сотни легитимных мобильных абонентов. Лимит 1 голос на IP за 24 часа неверно помешает большинству из них голосовать. Поэтому в конкурсах rate limiting нужно сочетать с дедупликацией по аккаунту или cookie, когда мобильная аудитория значительна. Кроме того, слишком агрессивные лимиты могут портить опыт легитимным голосующим из общих сетей — университетских кампусов, корпоративных офисов или крупных публичных Wi-Fi хотспотов.
