Rate Limiting (Ограничение частоты запросов и защита API)

1. Обзор концепции и системная проблема

Без надежного механизма ограничения частоты запросов любой открытый веб-сервис или API-эндпоинт находится под постоянной угрозой технического или финансового коллапса:

• Финансовое исчерпание (AI Billing Drain): злоумышленник или зацикленный скрипт может отправить 100 000 запросов к вашему роуту генерации кода или картинок за 5 минут, сгенерировав счет на $5,000 в OpenAI или Anthropic.
• Брутфорс и Credential Stuffing: автоматические ботнеты перебирают миллионы паролей на форме входа /api/auth/login, перегружая базу данных тяжелыми операциями хеширования bcrypt/Argon2.
• Каскадное падение базы данных (Denial of Service): массовый параллельный вызов некешированных эндпоинтов поиска исчерпывает пул соединений PostgreSQL, парализуя работу всего приложения.

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

2. Архитектурная таксономия и ментальная модель

Архитектурный выбор алгоритмов и уровней внедрения ограничения трафика:

┌─────────────────────────────────────────────────────────────┐
│                 RATE LIMITING ALGORITHMIC TAXONOMY          │
├─────────────────────────────────────────────────────────────┤
│ 1. Fixed Window: Простой счетчик с обнулением каждую минуту  │
│    (Уязвим к всплескам 2x трафика на границе интервала)     │
├─────────────────────────────────────────────────────────────┤
│ 2. Sliding Window Counter: Гибридное скользящее окно         │
│    Weight = Prev_Count * (1 - Elapsed_Ratio) + Curr_Count   │
│    (Идеальный компромисс: точность + ничтожное потребление RAM) │
├─────────────────────────────────────────────────────────────┤
│ 3. Token Bucket: Пополнение токенами с постоянной скоростью  │
│    (Позволяет легитимные всплески трафика до емкости ведра)  │
├─────────────────────────────────────────────────────────────┤
│ 4. Leaky Bucket: Постоянная скорость утечки очереди         │
│    (Оптимально для сглаживания исходящих запросов к API)     │
└─────────────────────────────────────────────────────────────┘

1. Гибридное скользящее окно (Sliding Window Counter):
   • Сохраняет счетчики для текущего и предыдущего интервалов времени. При каждом запросе вычисляет взвешенную сумму на основе того, сколько процентов времени прошло в текущем окне. Исключает аномалии на стыке минут.
2. Иерархия идентификаторов клиента (Subject Identification):
   • Публичный уровень: IP-адрес (для анонимных запросов и защиты от DDoS).
   • Аутентифицированный уровень: User_ID или Organization_ID (игнорирует общие корпоративные NAT/VPN-сети).
   • Токенный уровень: Гранулярные квоты по типу купленного тарифа (Free, Pro, Enterprise).
3. Распределенный бэкенд хранения состояния (Redis Cluster / Upstash):
   • Централизованное хранилище быстрой памяти (In-Memory), синхронизирующее счетчики между десятками экземпляров бэкенда за микросекунды.

3. Технический пайплайн и внутренняя механика

Жизненный цикл проверки запроса через Redis с атомарным Lua-скриптом:

1. Экстракция идентификатора и маршрута: Middleware перехватывает входящий запрос. Формируется комбинированный ключ: rate:auth:${req.ip} для формы логина или rate:llm:${user.id} для AI-роута.
2. Атомарное выполнение Lua-скрипта в Redis: Чтобы избежать состояния гонки (Race Condition) между параллельными запросами, вся логика упаковывается в один Lua-скрипт:
   • Считывается текущий таймстемп.
   • Удаляются записи, старше размера скользящего окна (60 секунд).
   • Рассчитывается количество активных токенов.
3. Принятие решения:
   • Если лимит не превышен: счетчик увеличивается на 1 (или на стоимость запроса в токенах), устанавливается TTL ключа, и запрос передается дальше в контроллер.
   • Если лимит превышен: формируется ответ об отказе.
4. Формирование стандартных HTTP-заголовков: Сервер возвращает клиенту метаданные:

   HTTP/1.1 429 Too Many Requests
   Content-Type: application/json
   Retry-After: 24
   X-RateLimit-Limit: 10
   X-RateLimit-Remaining: 0
   X-RateLimit-Reset: 1718293840
   

5. Телеметрия и алертинг: Событие превышения лимита фиксируется в системе мониторинга; в случае аномального всплеска из одной подсети срабатывает правило блокировки в файрволе.

4. Практические инженерные сценарии в продакшене

01. Защита дорогих генеративных AI-роутов (Token-Aware Limiting)

Роут генерации кода списывает токены пропорционально сложности запроса:

• Вместо простого подсчета запросов рейт-лимитер списывает с виртуального баланса пользователя точное количество сгенерированных токенов.
• Пользователи бесплатного тарифа имеют лимит в 50 000 токенов в сутки. При исчерпании лимита API блокирует генерацию до начала следующего дня.

02. Защита формы аутентификации от брутфорса (Credential Defense)

Эндпоинт /api/auth/sign-in:

• Разрешается не более 5 неудачных попыток ввода пароля в течение 15 минут для одной комбинации IP + Email.
• На 6-ю попытку система требует прохождения капчи или отправляет ссылку для сброса пароля на почту, полностью нивелируя попытки перебора по словарю.

03. Сглаживание исходного трафика к сторонним платежным шлюзам

Интеграция со Stripe, где действует лимит в 100 запросов в секунду:

• Внутренний микросервис использует очередь с алгоритмом Leaky Bucket.
• Даже если внутренние агенты компании одновременно создают 500 платежей во время Черной пятницы, очередь отправляет запросы строго равномерным потоком (80 req/s), устраняя риск блокировки учетной записи Stripe.

5. Подводные камни, типовые ошибки и безопасность

• Блокировка целых офисов из-за наивного IP Rate Limiting: Если применить строгий лимит исключительно по IP к авторизованным пользователям, один активный сотрудник бизнес-центра заблокирует работу всех своих коллег, которые выходят в интернет через общую NAT-адресу компании. После логина всегда лимитируйте по user_id.
• Race Condition при использовании раздельных операций GET и INCR: Если проверять лимит командой GET, а затем увеличивать его через INCR, злоумышленник может отправить 100 одновременных асинхронных запросов, и все они пройдут проверку одновременно до обновления счетчика. Используйте атомарные скрипты.
• Переполнение памяти Redis при хранении меток времени: Использование неупорядоченных списков для хранения меток каждого запроса без установки жесткого TTL быстро забивает гигабайты оперативной памяти во время массированной атаки.
• Игнорирование заголовков прокси (X-Forwarded-For Spoofing): Если ваш сервер стоит за Cloudflare или Nginx и вы читаете IP непосредственно из сокета, вы получите локальный адрес прокси. С другой стороны, слепая доверие к непроверенному заголовку X-Forwarded-For позволяет злоумышленнику подделать любой IP-адрес.