EMZETT.
Увійти

Обмеження частоти запитів: ліміти та стримування зловживань

Коротко: Обмеження частоти запитів (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, Nginx limit_req, правила Cloudflare/WAF).
  • Безсерверні середовища/кілька екземплярів: лічильники не в пам’яті процесу, а централізовано (Redis, база даних).
  • Відповідайте HTTP 429 Too Many Requests з Retry-After та за бажання заголовками RateLimit-Limit/Remaining/Reset.
  • Клієнтам слід повторювати з експоненційною відстрочкою + jitter.
  • Додатково тайм-аути, обмеження розміру, пагінація та квоти (на день/місяць).

Межі та практика

Саме лише обмеження частоти не зупинить розподілені атаки (DDoS): для цього CDN/WAF, виявлення ботів, захист вище за потоком. Не блокуйте й сумлінних користувачів: виводьте ліміти з реальних вимірювань, повідомлення про помилку зрозуміле, журналювання/тривога за стійкого перевищення. Тестуйте ліміти, документуйте ліміти в документації API. Конфіденційність: IP-адреси — персональні дані, зберігайте їх недовго.

Див. також: Debounce і throttle