Rate Limiting в API: зачем и как настроить

Зачем нужен Rate Limiting

Rate Limiting — механизм ограничения количества запросов к API документацию за определённый период времени. Без него ваш API уязвим к нескольким проблемам:

• DDoS и brute-force атаки — злоумышленник может отправлять тысячи запросов в секунду
• Парсинг и скрейпинг — боты могут массово выгружать данные
• Случайные перегрузки — баг в клиентском коде может вызвать лавину запросов
• Несправедливое использование — один клиент может занять все ресурсы сервера

Rate Limiting защищает сервер, обеспечивает справедливое распределение ресурсов и является стандартной практикой для любого публичного API.

Алгоритмы Rate Limiting

Fixed Window (фиксированное окно)

Самый простой алгоритм: счётчик запросов обнуляется в фиксированные моменты времени (например, каждую минуту). Клиент может сделать N запросов в текущем окне.

Проблема: на границе окон клиент может отправить 2N запросов за короткий период — N в конце одного окна и N в начале следующего.

Sliding Window (скользящее окно)

Комбинация fixed window и взвешенного подсчёта. Учитывает запросы из предыдущего окна пропорционально оставшемуся времени. Более точный, чем fixed window, с минимальными дополнительными затратами.

Token Bucket (корзина токенов)

Корзина заполняется токенами с фиксированной скоростью. Каждый запрос забирает один токен. Если корзина пуста — запрос отклоняется. Позволяет короткие всплески трафика (burst), если корзина накопила токены.

Параметры: размер корзины (burst capacity) и скорость пополнения (rate).

Leaky Bucket (протекающее ведро)

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

Sliding Window Log

Хранит timestamp каждого запроса. Подсчитывает количество запросов за последние N секунд. Самый точный, но самый затратный по памяти.

Заголовки Rate Limiting

Стандартные заголовки (RFC 6585 и draft-ietf-httpapi-ratelimit-headers) информируют клиента о лимитах:

X-RateLimit-Limit: 100        # Максимум запросов в окне
X-RateLimit-Remaining: 42     # Осталось запросов
X-RateLimit-Reset: 1640995200 # Время сброса (Unix timestamp)
Retry-After: 30               # Секунд до повторной попытки (при 429)

При превышении лимита возвращайте HTTP 429 Too Many Requests с заголовком Retry-After.

Стратегии ограничения

По IP-адресу

Простейшая стратегия. Подходит для защиты от ботов, но не различает пользователей за NAT — десятки легитимных пользователей могут делить один IP.

По API-ключу или токену

Более точная идентификация клиента. Позволяет устанавливать разные лимиты для разных тарифы. Стандарт для коммерческих API.

По пользователю

Ограничение привязано к аутентифицированному пользователю. Работает для SaaS-приложений с учётными записями.

По эндпоинту

Разные лимиты для разных API-эндпоинтов. Эндпоинт поиска может иметь лимит 10 запросов/мин, а получение профиля — 100 запросов/мин.

Реализация на разных уровнях

На уровне веб-сервера (nginx)

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

    server {
        location /api/ {
            limit_req zone=api burst=20 nodelay;
            limit_req_status 429;
        }
    }
}

На уровне приложения (PHP с Redis)

function checkRateLimit(string $key, int $limit, int $window): bool {
    $redis = getRedis();
    $current = $redis->incr($key);
    if ($current === 1) {
        $redis->expire($key, $window);
    }
    return $current <= $limit;
}

На уровне API Gateway

Облачные API Gateway (AWS, Google Cloud, Azure) предоставляют встроенный rate limiting с гибкой конфигурацией. Это оптимальный вариант для микросервисной архитектуры.

Best Practices

1. Всегда возвращайте заголовки лимитов — клиент должен знать о лимитах до их превышения
2. Используйте 429 статус — не 403 и не 503. HTTP 429 специально предназначен для rate limiting
3. Документируйте лимиты — в API-документации укажите лимиты для каждого эндпоинта
4. Предусмотрите burst — Token Bucket позволяет кратковременные всплески для легитимного использования
5. Разделяйте лимиты по критичности — эндпоинт авторизации должен иметь более строгие лимиты
6. Мониторьте срабатывания — отслеживайте количество 429-ответов для обнаружения атак или слишком строгих лимитов

Тестирование Rate Limiting

Проверьте работу rate limiting с помощью HTTP-чекера Enterno.io — отправьте несколько запросов подряд к вашему API и убедитесь, что заголовки лимитов присутствуют в ответе, а при превышении возвращается 429.

Итоги

Rate Limiting — обязательный компонент любого API. Выберите алгоритм под ваши требования (Token Bucket для гибкости, Sliding Window для точности), реализуйте на подходящем уровне (nginx, приложение или API Gateway), и всегда информируйте клиентов о лимитах через стандартные заголовки.