Обмеження частоти запитів

Коротко: Метод обмеження того, як часто користувач/IP-адреса може робити запити за період часу — захищає від зловживань (наприклад, добору під час входу, спаму) і перевантаження.

Докладніше: Часто реалізується через швидкий кеш на кшталт Redis (лічильник на користувача/IP зі строком дії). Якщо обмеження застосовується до КОЖНОГО запиту (включно з нешкідливими сторінками лише для читання), кожен перегляд сторінки коштує додаткового мережевого звернення туди й назад — це помітно в часі завантаження.

Наш контекст: В Emzett спершу працювало глобально на кожному запиті; потім його обмежили так, щоб суто читальні сторінки GET/HEAD без форм були виключені (вхід, оформлення замовлення, чат і адміністрування лишаються повністю захищеними), щоб заощадити час завантаження та навантаження на Redis.

Подробиці

Найпоширеніший метод обмеження — «ковзне вікно»: замість простого підрахунку «скільки запитів з останньої повної хвилини» розглядається ковзне часове вікно (наприклад, «скільки запитів за останні 60 секунд, рахуючи від зараз») — це не дає використати повний ліміт безпосередньо перед межею хвилини й одразу після неї та тим самим фактично пропустити вдвічі більше запитів, ніж дозволено. Бібліотеки на кшталт @upstash/ratelimit реалізують це безсерверно через Redis, без потреби самим писати логіку часових вікон:

const ratelimit = new Ratelimit({
  redis,
  limiter: Ratelimit.slidingWindow(100, "1 m"), // 100 запитів за хвилину
});
const { success } = await ratelimit.limit(`edge:${ip}`);
if (!success) {
  return new Response("Too many requests", { status: 429 });
}

Важливо, ЯКИЙ ідентифікатор використовується для підрахунку: проста IP-адреса проста, але проблемна за спільних NAT/корпоративних мереж (багато реальних користувачів ділять один видимий IP) і легко обходиться ротацією IP; комбінація IP + обліковий запис користувача (де доступна) точніша. У глобально розподілених edge-середовищах (таких як Vercel Edge Functions) саме сховище лічильників теж має бути глобально узгодженим — локальний лічильник у пам’яті на кожен екземпляр сервера фактично множив би ліміт під час паралельної роботи кількох екземплярів, тому потрібне центральне сховище на кшталт Redis.

Див. також: Upstash Redis