Rate Limiting (Обмеження частоти запитів та захист API)(Обмеження частоти запитів та захист сервісів (Rate Limiting))

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-адресу.