Rate Limiting: принципы работы и настройка ограничения запросов к серверу

Rate limiting - это механизм контроля частоты входящих запросов к серверу или API. Он задаёт допустимое количество обращений от одного клиента за определённый промежуток времени и отклоняет всё, что выходит за рамки лимита. Для системных администраторов и DevOps-инженеров это базовый инструмент защиты от перегрузок, DDoS-атак и недобросовестного использования ресурсов.

Без ограничения частоты запросов один бот или скрипт способен исчерпать ресурсы сервера быстрее, чем вы успеете среагировать. Rate limiting решает три задачи: защищает бэкенд от деградации, обеспечивает равный доступ для легитимных пользователей и снижает поверхность атаки для автоматизированных угроз. В этой статье разберём алгоритмы, практическую настройку в Nginx и альтернативные инструменты.

Что такое rate limiting и зачем он нужен

Rate limiting ограничивает количество запросов, которые клиент может отправить серверу за единицу времени. Ограничение применяется по разным признакам: IP-адресу, API-ключу, идентификатору сессии или заголовкам запроса. Когда клиент превышает лимит, сервер возвращает ошибку, чаще всего HTTP 429 Too Many Requests или 503 Service Unavailable.

Практическая ценность механизма подтверждается реальными сценариями. Открытые WebRTC-сигнальные брокеры без ограничений уязвимы для автоматизированных ботнетов, спама в комнатах и DoS-атак. Учётные записи с rate limiting и сессионными токенами, подписанными DPoP (RFC 9449), позволяют проверять легитимность клиентов и контролировать доступ. Это пример того, как ограничение частоты запросов встраивается в архитектуру безопасности.

Последствия отсутствия rate limiting:

Один агрессивный клиент потребляет всю пропускную способность и CPU, остальные пользователи получают таймауты.
Брутфорс-атаки на формы входа перебирают пароли без препятствий.
Скрейперы массово выгружают данные, увеличивая нагрузку на базу данных.
Публичные API расходуют квоты на нелегитимные вызовы, увеличивая счета за инфраструктуру.

Rate limiting не заменяет полноценную систему защиты, но закрывает базовый уровень. Подробнее о комплексной защите от DDoS на разных уровнях модели OSI читайте в руководстве по эшелонированной защите L3/L4 и L7.

Как работает rate limiting: алгоритмы и параметры

Алгоритм определяет, как сервер считает запросы и когда отклоняет превышение. Выбор алгоритма влияет на поведение системы при всплесках трафика и на то, насколько строго соблюдается лимит. Основные параметры: лимит (максимальное число запросов), окно (период подсчёта) и burst (допустимый кратковременный всплеск).

Алгоритм Token Bucket

Token Bucket - самый распространённый алгоритм, используется в Nginx по умолчанию. Представьте ведро, в которое с постоянной скоростью добавляются токены. Каждый входящий запрос забирает один токен. Если токенов нет, запрос отклоняется или ставится в очередь.

Ключевые параметры:

rate - скорость пополнения токенов, например 10r/s (10 токенов в секунду).
burst - размер ведра, то есть максимальное число токенов, которое может накопиться. Позволяет пропустить короткий всплеск без отказа.

Пример: rate=10r/s, burst=20. Если клиент отправляет 5 запросов в секунду, токены накапливаются. При внезапном всплеске до 25 запросов за секунду сервер пропустит 20 из накопленного резерва, а остальные отклонит. Это сглаживает неравномерный трафик, не блокируя легитимных пользователей.

Алгоритм Leaky Bucket

Leaky Bucket работает иначе. Запросы попадают в очередь фиксированного размера и обрабатываются с постоянной скоростью, как вода, вытекающая из дырявого ведра. Если очередь переполнена, новые запросы отбрасываются.

Отличие от Token Bucket: Leaky Bucket жёстко выравнивает поток, не допуская всплесков вообще. Token Bucket позволяет кратковременные пики за счёт накопленных токенов. Для веб-серверов Token Bucket обычно предпочтительнее, потому что реальный пользовательский трафик неравномерен: страница может запрашивать десятки ресурсов одновременно.

Другие алгоритмы: Fixed Window (простой счётчик за фиксированный интервал, уязвим к скачкам на границе окна) и Sliding Window (более точный, но требовательный к памяти). Для большинства задач Nginx с Token Bucket достаточно.

Настройка rate limiting в Nginx: пошаговое руководство

Nginx реализует rate limiting через модуль ngx_http_limit_req_module. Настройка состоит из двух шагов: определение зоны в контексте http и применение лимита в location, server или http.

Базовая настройка: ограничение по IP-адресу

Зона хранения состояния определяется директивой limit_req_zone. В примере ниже ключом выступает IP-адрес клиента, скорость - 10 запросов в секунду, burst - 20:

http {
    limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;

    server {
        location / {
            limit_req zone=perip burst=20 nodelay;
        }
    }
}

Разбор директив:

$binary_remote_addr - бинарное представление IP-адреса клиента. Компактнее, чем $remote_addr, экономит память.
zone=perip:10m - имя зоны и размер выделяемой памяти. 10 мегабайт хватает примерно на 160 000 IP-адресов.
rate=10r/s - базовая скорость пополнения токенов.
burst=20 - допустимый размер очереди для всплесков.
nodelay - обрабатывать запросы из burst без задержки. Без этого параметра запросы сверх rate, но в пределах burst, обрабатываются с задержкой, распределённой по времени.

При превышении лимита Nginx возвращает 503 Service Unavailable. Это поведение можно изменить директивой limit_req_status 429;, чтобы отдавать семантически корректный код для API.

Готовые конфигурации для защиты Nginx от DDoS с мониторингом через Prometheus и автоматической блокировкой через fail2ban собраны в отдельном практическом руководстве.

Расширенные сценарии: rate limiting для API и микросервисов

Для API часто нужны разные лимиты на разные эндпоинты. Например, публичный поиск можно ограничить мягче, а отправку форм - строже. Настройка через несколько зон:

http {
    limit_req_zone $binary_remote_addr zone=api_general:10m rate=30r/s;
    limit_req_zone $binary_remote_addr zone=api_write:10m rate=5r/s;

    server {
        location /api/v1/search {
            limit_req zone=api_general burst=50 nodelay;
            proxy_pass http://backend;
        }

        location /api/v1/submit {
            limit_req zone=api_write burst=10 nodelay;
            limit_req_status 429;
            proxy_pass http://backend;
        }
    }
}

Для микросервисов за Nginx rate limiting применяется к проксируемым запросам. Директива limit_req работает до передачи запроса бэкенду, поэтому защищает upstream-серверы от перегрузки. Если за Nginx стоит балансировщик, ключ $binary_remote_addr будет содержать IP балансировщика, а не клиента. В этом случае используйте заголовок X-Forwarded-For или X-Real-IP с соответствующей настройкой set_real_ip_from.

Для балансировки нагрузки между несколькими бэкендами с сохранением сессий используйте upstream с ip_hash, подробнее в статье про алгоритмы балансировки в Nginx.

Альтернативные инструменты rate limiting

Nginx покрывает большинство сценариев, но в распределённых и облачных средах могут понадобиться другие решения. Выбор зависит от масштаба, архитектуры и требований к отказоустойчивости.

Rate limiting в Cloudflare Workers

Cloudflare Workers - serverless-платформа, которая выполняет код на edge-узлах. Встроенная защита от DDoS и автоматическое масштабирование снимают с вас задачу управления инфраструктурой. Rate limiting здесь реализуется через учётные записи и сессионные токены: аккаунты позволяют выдавать безопасные токены, подписанные DPoP, для проверки легитимности клиентов.

Преимущество Workers - отсутствие единой точки отказа. Всплески трафика не приводят к деградации, потому что платформа распределяет нагрузку глобально. Это актуально для WebRTC-сигнальных серверов и других приложений реального времени, где важна низкая задержка.

Rate limiting в Kubernetes

В Kubernetes rate limiting настраивается на уровне Ingress-контроллеров. NGINX Ingress Controller поддерживает аннотации nginx.ingress.kubernetes.io/limit-rps, limit-burst-multiplier и limit-whitelist. Traefik предлагает middleware RateLimit с параметрами average и burst.

Пример аннотации для NGINX Ingress:

metadata:
  annotations:
    nginx.ingress.kubernetes.io/limit-rps: "20"
    nginx.ingress.kubernetes.io/limit-burst-multiplier: "3"
    nginx.ingress.kubernetes.io/limit-whitelist: "10.0.0.0/8"

Для API Gateway в Kubernetes часто используют Kong, Ambassador или Istio. Они предоставляют rate limiting как часть политик безопасности на уровне сервисной сетки. Если вы разворачиваете Kubernetes-кластер, облачная инфраструктура Timeweb Cloud предоставляет управляемые кластеры с возможностью гибкого масштабирования ресурсов.

Сравнение инструментов:

Инструмент	Масштаб	Сложность настройки	Особенности
Nginx	Один сервер или небольшой кластер	Низкая	Простая конфигурация, минимальные накладные расходы
Cloudflare Workers	Глобальный, serverless	Средняя	Встроенная DDoS-защита, нет единой точки отказа
Kubernetes Ingress	Кластер	Средняя	Интеграция с оркестрацией, аннотации
API Gateway (Kong, Istio)	Микросервисы	Высокая	Политики на уровне сервисной сетки, гибкие правила

Лучшие практики и типичные ошибки при настройке rate limiting

Правильная настройка rate limiting требует баланса между защитой и удобством пользователей. Слишком строгие лимиты блокируют легитимный трафик, слишком мягкие не дают защиты.

Рекомендации:

Начинайте с замеров реального трафика. Проанализируйте логи, определите пиковые значения запросов в секунду от одного IP и установите лимит с запасом 2-3x.
Всегда задавайте burst. Без него даже обычная загрузка страницы с десятком ресурсов может вызвать ложное срабатывание.
Используйте limit_req_status 429 для API и 503 для веб-страниц, чтобы клиенты корректно обрабатывали ответ.
Настройте мониторинг срабатываний. Метрики Nginx покажут, как часто срабатывает лимит и не блокируете ли вы реальных пользователей. Пять ключевых метрик для отслеживания описаны в шпаргалке по мониторингу Nginx.
Для CDN и прокси учитывайте реальный IP клиента через X-Forwarded-For, иначе ограничение будет применяться к IP прокси.

Типичные ошибки:

Установка rate без burst - блокирует легитимные всплески при загрузке страниц.
Игнорирование nodelay - запросы в очереди обрабатываются с задержкой, что ухудшает пользовательский опыт.
Отсутствие тестирования - конфигурация проверяется только в бою, когда уже заблокированы реальные клиенты.
Единый лимит для всех эндпоинтов - статические файлы и тяжёлые API-запросы требуют разных порогов.
Забытый whitelist для внутренних сервисов - мониторинг или health-check блокируются вместе с внешним трафиком.

Rate limiting как часть стратегии защиты от DDoS

Rate limiting - важный слой защиты, но не панацея. Распределённая DDoS-атака с тысяч IP-адресов обходит ограничение по IP, потому что каждый адрес отправляет немного запросов. Для полной защиты нужен многоуровневый подход.

Эффективная стратегия включает:

Rate limiting на уровне приложения - ограничивает частоту запросов от одного клиента, защищает от HTTP flood и брутфорса.
WAF - фильтрует вредоносные запросы по сигнатурам и поведенческому анализу.
CDN - поглощает объёмный трафик на edge-узлах, не доводя его до origin-сервера.
Анализ трафика - выявляет аномалии и автоматически блокирует подозрительные источники.

Геофильтрация дополняет rate limiting, блокируя трафик из нерелевантных регионов. Сравнение подходов Cloudflare, AWS WAF и самописных решений на Nginx и iptables с готовыми конфигурациями - в статье по геофильтрации. Для сетевого уровня защиту можно усилить правилами на маршрутизаторах MikroTik, о чём рассказано в руководстве по RouterOS.

Rate limiting закрывает прикладной уровень и предотвращает исчерпание ресурсов конкретного сервера. В сочетании с сетевыми фильтрами и WAF он создаёт эшелонированную защиту, которая выдерживает большинство автоматизированных атак. Начните с базовой конфигурации Nginx из этой статьи, замерьте реальный трафик и постепенно ужесточайте лимиты на основе данных мониторинга.