Rate limiting

TL;DR

Rate limiting (ограничение частоты) — это механизм ограничения количества запросов от одного источника за единицу времени. Защищает от DDoS-атак, брутфорса паролей и злоупотребления API.

Краткое определение

Rate limiting — это механизм безопасности, который ограничивает частоту запросов от одного клиента (IP-адреса, пользователя, API-ключа) для защиты сервера от перегрузки и злонамеренных действий.

Оригинал и перевод

• Язык: английский
• Оригинал: Rate limiting
• Расшифровка: Rate (частота) + Limiting (ограничение)
• Буквальный перевод: ограничение частоты
• Русские аналоги: лимитирование запросов, ограничение скорости, троттлинг

Синонимы и варианты написания

• Rate limit
• Throttling (тросселирование)
• Request limiting
• Ограничение скорости запросов
• Лимит запросов в секунду

Где используется

• Веб-серверы: Nginx (limit_req_zone), Apache (mod_ratelimit)
• API шлюзы: Kong, Tyk, Apigee, AWS API Gateway
• Приложения: собственная реализация через Redis, базу данных
• CDN: Cloudflare, AWS CloudFront (rate limiting rules)
• Формы авторизации: защита от перебора паролей
• Платёжные системы: предотвращение повторных списаний

Когда это важно

Rate limiting критичен в следующих сценариях:

• Публичные API — защита от злоупотребления и DDoS
• Формы логина — предотвращение брутфорса (макс. 3-5 попыток в минуту)
• Платежи и заказы — идемпотентность + ограничение повторных отправок
• Скрейпинг контента — ограничение автоматического сбора данных
• Высоконагруженные системы — равномерное распределение ресурсов между клиентами

Как работает (принцип)

Запрос 1 → счётчик = 1 ✅ Разрешено
Запрос 2 → счётчик = 2 ✅ Разрешено
Запрос 3 → счётчик = 3 ✅ Разрешено
...
Запрос 10 → счётчик = 10 ✅ Разрешено
Запрос 11 → счётчик = 11 ❌ БЛОК (429 Too Many Requests)

Основные алгоритмы:

• Token bucket — «ведро токенов»: каждый запрос потребляет токен, токены пополняются со временем
• Leaky bucket — «протекающее ведро»: запросы обрабатываются с фиксированной скоростью
• Fixed window — фиксированные интервалы (например, 100 запросов в минуту)
• Sliding window — скользящее окно для более точного учёта

Примеры конфигурации

Nginx: rate limiting по IP

# Зона: 10 MB памяти, 10 запросов в секунду на IP
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;

server {
    location /api/ {
        # burst=20 — очередь до 20 запросов
        # nodelay — не ждать, сразу возвращать 429
        limit_req zone=api_limit burst=20 nodelay;
        limit_req_status 429;
        
        proxy_pass http://backend;
    }
    
    # Для login — строже: 1 запрос в секунду
    location /login {
        limit_req_zone $binary_remote_addr zone=login_limit:10m rate=1r/s;
        limit_req zone=login_limit burst=5 nodelay;
    }
}

PHP: простая реализация через Redis

function checkRateLimit($redis, $userId, $limit = 100, $window = 60) {
    $key = "rate_limit:{$userId}";
    $current = $redis->incr($key);
    
    if ($current === 1) {
        $redis->expire($key, $window);
    }
    
    return $current <= $limit;
}

// Использование
if (!checkRateLimit($redis, $userIp, 10, 60)) {
    http_response_code(429);
    echo json_encode(['error' => 'Too Many Requests']);
    exit;
}

HTTP статусы для rate limiting

• 429 Too Many Requests — стандартный ответ при превышении лимита
• 503 Service Unavailable — иногда используется при общей перегрузке
• Retry-After — заголовок с рекомендацией, когда повторить запрос

HTTP/1.1 429 Too Many Requests
Retry-After: 60
Content-Type: application/json

{"error": "Rate limit exceeded. Try again in 60 seconds."}

Типичные ошибки при настройке

• ❌ Слишком строгие лимиты — блокировка легитимных пользователей
• ❌ Отсутствие burst — нет буфера для пиковых нагрузок
• ❌ Лимит только по IP — проблема для NAT/прокси (один IP = много пользователей)
• ❌ Нет заголовка Retry-After — клиенты не знают, когда повторить
• ❌ Rate limiting после бизнес-логики — ресурсы уже потрачены до проверки

Аналоги и связанные термины

• Throttling — мягкое ограничение (замедление вместо блокировки)
• Quota — лимит на более длительный период (день, месяц)
• Backpressure — обратное давление в потоках данных
• WAF (Web Application Firewall) — комплексная защита веб-приложений
• DDoS protection — защита от распределённых атак

Смотри также (статьи на сайте)

• Nginx: полный гайд для веб-разработчиков — основы настройки Nginx
• Nginx + PHP-FPM: ошибки 502 и 504 — интеграция с PHP-FPM
• Защита от DDoS и брутфорса — безопасность веб-приложений

Смотри также (сниппеты)

• Rate limiting: зона запросов в Nginx — готовая конфигурация limit_req_zone
• Rate limiting: зона соединений — ограничение по количеству соединений
• Rate limiting с задержкой — использование delay параметра

Смотри также (термины)

• DDoS-атака — распределённая атака отказа в обслуживании
• Идемпотентность — свойство операции давать одинаковый результат при повторении
• Upstream — группа бэкенд-серверов в Nginx
• Backpressure — механизм обратной связи в потоках

Мини-FAQ

Rate limiting и кэш — одно и то же?

Ответ: Нет. Rate limiting ограничивает частоту запросов, кэш ускоряет ответы на повторяющиеся запросы. Это дополняющие механизмы.

Это защита сервера от DDoS?

Ответ: Частично. Rate limiting защищает от перегрузки приложения, но не остановит мощный сетевой DDoS. Нужен комплексный подход (CDN, WAF, фильтрация трафика).

Можно ли обойти rate limiting?

Ответ: Да, при распределённых атаках (ботнет из тысяч IP). Для защиты нужны: анализ поведения, CAPTCHA, геоблокировка, CDN с DDoS-защитой.

Какой лимит выставить для API?

Ответ: Зависит от сценария:

• Публичное API: 60-100 запросов в минуту на ключ
• Login форма: 3-5 попыток в минуту на IP
• Поиск/фильтры: 10-30 запросов в минуту
• Платежи: 1-2 запроса в минуту + идемпотентность