Обмеження частоти запитів: ліміти та стримування зловживань
Коротко: Обмеження частоти запитів (rate limiting) обмежує, як часто клієнт може звертатися до інтерфейсу за період; захищає від перевантаження, перебору та скрапінгу й супроводжується відповіддю HTTP 429.
Докладніше: Без обмежень один клієнт (або бот) може навантажити сервер, базу даних і рахунок. Типові цілі: вхід (добір паролів), реєстрація/скидання пароля (поштовий спам), дорогі кінцеві точки (пошук, ШІ), скрапінг, чесне використання публічного API.
Подробиці
Алгоритми
- Фіксоване вікно: не більше 100 запитів за хвилину; просто, але дає піки на межі вікна (до 2× у швидкій послідовності).
- Ковзне вікно: точніше, дещо складніше.
- Token bucket: відро наповнюється зі швидкістю r, кожен запит коштує токен; допускає короткі сплески до розміру відра.
- Leaky bucket: згладжує до постійної швидкості витікання.
- Ліміт паралелізму: не більше N паралельних запитів на користувача.
Хто враховується?
Оберіть ключ: IP-адреса (обережно: NAT/шкільні мережі ділять один IP; за проксі читайте реальний IP з X-Forwarded-For лише в довірених проксі), обліковий запис, ключ API, комбінація (наприклад, обліковий запис + IP під час входу). Суворіше для анонімних, щедріше для користувачів, що ввійшли/платять. Захист входу: додатково обмежуйте за іменем користувача, зростаючі затримки, captcha, блокування зі сповіщенням.
Реалізація
- Лічильники в Redis (
INCR+EXPIRE) або бібліотеки (Upstash Ratelimit,express-rate-limit, Nginxlimit_req, правила Cloudflare/WAF). - Безсерверні середовища/кілька екземплярів: лічильники не в пам’яті процесу, а централізовано (Redis, база даних).
- Відповідайте HTTP 429 Too Many Requests з
Retry-Afterта за бажання заголовкамиRateLimit-Limit/Remaining/Reset. - Клієнтам слід повторювати з експоненційною відстрочкою + jitter.
- Додатково тайм-аути, обмеження розміру, пагінація та квоти (на день/місяць).
Межі та практика
Саме лише обмеження частоти не зупинить розподілені атаки (DDoS): для цього CDN/WAF, виявлення ботів, захист вище за потоком. Не блокуйте й сумлінних користувачів: виводьте ліміти з реальних вимірювань, повідомлення про помилку зрозуміле, журналювання/тривога за стійкого перевищення. Тестуйте ліміти, документуйте ліміти в документації API. Конфіденційність: IP-адреси — персональні дані, зберігайте їх недовго.
Див. також: Debounce і throttle