Перейти к основному контенту
Tech Path Finder
КурсыИнтервьюКод-ревьюБлог
Tech Path Finder

Персонализированный путеводитель в IT. Квизы, мок-интервью, код ревью и аналитика прогресса.

@potapov_me

Платформа

  • Курсы
  • Прогресс
  • Мок-интервью
  • Код ревью
  • Живое ревью с ИИ
  • Тренажёр переговоров
  • Закладки

Контент

  • Блог
  • Главная
  • Обратная связь

Компания

  • О проекте
  • Тарифы
  • Условия использования
  • Конфиденциальность
  • Согласие на обработку данных
  • Cookie
  • Реквизиты

Аккаунт

  • Войти
  • Зарегистрироваться
  • Профиль

© 2026 Tech Path Finder. Все права защищены.

·ИП Потапов К.С.·Политика конфиденциальности·
Сделано с ❤️ в России
  1. Ограничение запросов
rate_limiting

Ограничение запросов

Алгоритмы токен-бакета и скользящего окна, квоты, ограничение скорости и заголовок Retry-After

Ограничение скорости запросов

Ограничение скорости запросов — это механизм, который ограничивает количество запросов, которые клиент может отправить на сервер за определенный промежуток времени. Это критически важная мера для защиты сервиса от перегрузки, DDoS-атак и злоупотреблений.

#Сравнение алгоритмов rate limiting

АлгоритмПроизводительностьСправедливостьBurst поддержкаСложность реализацииПример использования
Token BucketВысокаяСредняяДа (взрывной режим)НизкаяAPI с высокой нагрузкой, где допустимы всплески
Sliding WindowСредняяВысокаяНетСредняяСервисы, где важно равномерное распределение квоты
Fixed WindowВысокаяНизкаяНетНизкаяПростые случаи, MVP
Leaky BucketВысокаяВысокаяНетСредняяСистемы с постоянным потоком запросов

#Основные алгоритмы

  • Token Bucket (Токен-бакет):

    • Представляет собой "бакет" с фиксированным количеством токенов (например, 100).
    • Бакет пополняется со скоростью R токенов в секунду.
    • Каждый запрос забирает один токен. Если токенов нет, запрос отклоняется с кодом 429 Too Many Requests.
    • Позволяет "взрывной" режим (burst): если бакет полон, клиент может сделать до 100 запросов сразу.
  • Sliding Window (Скользящее окно):

    • Отслеживает время каждого запроса в течение последнего временного интервала (например, 1 минута).
    • При каждом новом запросе удаляются записи о запросах, вышедших за пределы окна.
    • Если количество запросов в окне превышает лимит, запрос отклоняется.
    • Более справедливый, чем фиксированное окно, так как не создает "пиков" в начале нового периода.

#Практический пример: Реализация rate limiting

HTTP-запрос с превышением лимита:

HTTP/1.1 429 Too Many Requests X-RateLimit-Limit: 100 X-RateLimit-Remaining: 0 Retry-After: 60 Content-Type: application/problem+json { "type": "https://api.example.com/errors/rate-limit", "title": "Too Many Requests", "status": 429, "detail": "You have exceeded your request limit. Please try again in 60 seconds.", "instance": "/api/v1/users" }

Реализация на сервере (Node.js/Redis):

const redis = require('redis'); const client = redis.createClient(); // Middleware для rate limiting const rateLimit = (limit = 100, windowMs = 60 * 1000) => { return async (req, res, next) => { const key = `rate-limit:${req.ip}`; // Получаем текущее время и количество запросов const now = Date.now(); const windowStart = now - windowMs; // Удаляем старые записи (вне окна) await client.zremrangebyscore(key, 0, windowStart); // Получаем количество запросов в текущем окне const count = await client.zcount(key, windowStart, now); if (count >= limit) { // Превышен лимит const retryAfter = Math.ceil((windowStart + windowMs - now) / 1000); return res.status(429).json({ type: 'https://api.example.com/errors/rate-limit', title: 'Too Many Requests', status: 429, detail: `You have exceeded your request limit. Please try again in ${retryAfter} seconds.`, instance: req.path }); } // Добавляем текущий запрос в список await client.zadd(key, now, now.toString()); await client.expire(key, Math.ceil(windowMs / 1000)); // Устанавливаем заголовки res.setHeader('X-RateLimit-Limit', limit); res.setHeader('X-RateLimit-Remaining', limit - count - 1); res.setHeader('Retry-After', Math.ceil((windowStart + windowMs - now) / 1000)); next(); }; }; // Использование app.use('/api/*', rateLimit(100, 60 * 1000)); // 100 запросов в минуту

#Процесс внедрения rate limiting (по этапам)

ЭтапДействияОтветственныеСроки
ПроектированиеОпределение лимитов, выбор алгоритма, планирование стратегии депрекацииАрхитектор, Security EngineerНа этапе проектирования API
РазработкаРеализация middleware, интеграция с Redis, тестирование граничных случаевРазработчикиВ процессе разработки
ТестированиеНагрузочное тестирование, проверка поведения при превышении лимитовQA, DevOpsПеред PR и в CI
РелизДокументация для клиентов, анонс лимитов, мониторингTechnical Writer, Release ManagerПри релизе
ПоддержкаАнализ использования, корректировка лимитов, обработка жалобDevOps, Support TeamПостоянно

#Часто задаваемые вопросы (FAQ)

Q: Как работает ограничение скорости запросов с алгоритмом токен-бакета? A: Токен-бакет: пополнение, забор, 429, взрывной режим. Токен-бакет: capacity=100, refill_rate=10/sec. Запрос: взять 1 токен. Если пустой → 429 Too Many Requests, Retry-After: 1. Взрывной режим: до 100 запросов сразу, если бакет полон.

Q: Какой HTTP-статус код возвращается при превышении лимита запросов? A: Код 429 Too Many Requests используется для указания на то, что пользователь отправил слишком много запросов за определенный период времени. Сервер должен включать заголовок Retry-After, чтобы клиент знал, когда можно повторить запрос.

Q: В чем преимущество скользящего окна (sliding window) перед фиксированным? A: Скользящее окно предотвращает ситуацию, когда в начале нового периода (например, новой минуты) клиент может сделать в два раза больше запросов, чем лимит, потому что предыдущий период еще не закончился. Оно обеспечивает более равномерное использование квоты.

Q: Какие заголовки обычно используются для информирования клиента о лимитах? A: Стандартные заголовки для rate limiting: X-RateLimit-Limit (общий лимит), X-RateLimit-Remaining (оставшееся количество запросов) и Retry-After (время в секундах до следующей попытки).

Rate Limiting — это критически важная мера для защиты сервиса от перегрузки, DDoS-атак и злоупотреблений.

Далее: Идемпотентность