Ограничение скорости передачи¶

Ограничение скорости передачи (также известно как рейтлимитинг, от англ. rate limiting) — это метод управления трафиком, применяемый в компьютерных сетях, веб-сервисах, телекоммуникационных системах и базах данных, который искусственно ограничивает количество операций (запросов, пакетов данных, транзакций) за определённый интервал времени. Основная цель рейтлимитинга — предотвращение перегрузки системы, обеспечение равномерного доступа к ресурсам, защита от злонамеренных действий (например, DDoS-атак, перебора паролей) и соблюдение условий лицензирования или соглашений об уровне обслуживания (SLA).

¶Принцип работы

Механизм ограничения скорости основан на отслеживании интенсивности событий и принятии решения о пропуске или блокировке (отклонении) последующих запросов при превышении заданного порога. Фундаментальным понятием является «окно» — временной интервал, в течение которого подсчитывается количество попыток.

¶Ключевые параметры

• **Лимит (англ. limit)**: максимальное количество разрешённых операций.
• **Окно (англ. window)**: временной промежуток, к которому привязан лимит (например, 100 запросов за 1 минуту).
• **Ключ (англ. key)**: идентификатор, по которому ведётся подсчёт (IP-адрес, идентификатор пользователя, токен доступа, cookie).

Когда число операций за текущее окно достигает лимита, последующие операции либо отклоняются (например, с HTTP-кодом 429 «Too Many Requests»), либо ставятся в очередь, либо обрабатываются с задержкой.

¶Алгоритмы реализации

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

¶Алгоритм «счётчика в фиксированном окне»

Простейший подход: для каждого ключа (например, IP-адреса) ведётся счётчик, который сбрасывается в начале каждого окна (например, в каждую новую минуту). Ограничение легко реализовать на уровне оперативной памяти с помощью хеш-таблиц. Недостаток — «потолочный эффект» (англ. burst at boundary): в самом конце окна и в начале следующего может произойти двойной всплеск нагрузки (до 2x лимита за короткий отрезок времени).

¶Алгоритм «скользящего окна» (Sliding Window)

Более точный подход, при котором учитывается не фиксированная календарная единица, а скользящий интервал. Обычно реализуется в виде скользящего окна журнала (лога) или скользящего счётчика. В первом случае хранится метка времени каждого запроса, и лимит проверяется по количеству записей за последние N секунд. Во втором — используется два счётчика (текущий и предыдущий) для аппроксимации точного значения. Этот алгоритм избегает резких скачков нагрузки на границе окон.

¶Алгоритм «дырявого ведра»

Моделирует работу ведра с отверстием: запросы поступают сверху, а «выходят» снизу с постоянной скоростью. Если ведро переполняется (новые запросы приходят быстрее, чем успевают «вытекать»), лишние запросы отбрасываются. Фактически, это не просто счётчик пиковой нагрузки, а регулятор средней скорости и частоты перестроения трафика. Широко применяется в телекоммуникациях для управления синхронизацией кадров.

¶Алгоритм «ведра токенов»

Популярный в сетевом оборудовании и API-шлюзах. Ведро заполняется «токенами» с постоянной скоростью (например, 10 токенов в секунду), но имеет максимальную ёмкость (например, 100 токенов). Каждый запрос потребляет один токен. Если токенов нет — запрос отклоняется или ожидает. Позволяет пропускать кратковременные всплески трафика (так как токены могут накапливаться), но ограничивает среднюю скорость.

¶Области применения

¶Веб-сервисы и API

Практически все публичные API (например, VK API, Яндекс.Карты, API социальных сетей) применяют ограничение скорости. Это защищает бэкенд от случайного или злонамеренного перегруза одним клиентом. Типичные настройки: 100 запросов в минуту для бесплатного тарифа, 1000 — для платного. При превышении клиент получает ответ с кодом 429 Too Many Requests и заголовками, указывающими лимит и время сброса (например, X-RateLimit-Limit, X-RateLimit-Remaining, Retry-After).

¶Защита от атак

• Подбор паролей (Brute Force): если сервер фиксирует более 5 неудачных попыток входа с одного IP-адреса за минуту, последующие попытки блокируются на 15 минут. Это значительно затрудняет перебор.
• DDoS-атаки: рейтлимитинг на уровне сетевого экрана или балансировщика нагрузки позволяет отсечь потоки запросов от ботнетов, не дожидаясь заполнения каналов связи.

¶Контроль доступа к базам данных

Системы управления базами данных (например, PostgreSQL, MySQL, MongoDB) могут ограничивать количество одновременных соединений или запросов в секунду для отдельного пользователя или приложения, чтобы «шумный сосед» не занял все ресурсы кластера.

¶Телекоммуникации

В сетях с коммутацией пакетов (IP-телефония, LTE) алгоритмы ограничения скорости используются для реализации классов обслуживания (QoS, Flyku). Например, для видеозвонков гарантируется 2 Мбит/с, а остальной трафик одного абонента — ограничивается.

¶Реализация на практике

¶Серверная сторона

• Middleware (промежуточное ПО) — самый распространённый способ. В веб-фреймворках (Django, Express.js, Spring Boot) существуют готовые библиотеки, которые встраиваются в цепочку обработки запросов.
• Балансировщики нагрузки (Nginx, HAProxy) — могут настраивать рейтлимитинг на уровне limit_req_zone или stick-table.
• Специализированные кэши (Redis) — часто используются для хранения счётчиков окон алгоритмов, так как Redis поддерживает атомарные операции инкремента и установку времени жизни (TTL) ключей.

¶Клиентская сторона

При разработке приложений или скриптов, которые вызывают API с лимитами, применяется стратегия «экспоненциальной задержки» (exponential backoff) и автоматического повторения запроса после получения кода 429.

¶Критика и ограничения

• Неравномерность для пользователя: агрессивный рейтлимитинг может блокировать легитимных пользователей (например, при использовании общего IP-адреса в офисной сети или сети мобильного оператора с динамическими IP).
• Сложность настройки: слишком низкий лимит вредит продукту, слишком высокий — не даёт защиты. Требуется мониторинг и постоянная корректировка порогов на основе статистики.
• Атаки на обход: злоумышленники могут использовать распределённые сети (ботнеты) с множеством разных IP-адресов, делая рейтлимитинг по IP неэффективным. В таких случаях требуется комбинация с CAPTCHA, анализом поведения (User-Agent, время между запросами) и машинным обучением.
• Жертвенность распределённых систем: если рейтлимитинг реализован на каждом узле кластера независимо, злоумышленник может исчерпать лимит на одном узле (50 запросов), а другой узел продолжит обрабатывать его запросы (ещё 50), что удваивает эффективную нагрузку. Решением служит централизованный стейт (через Redis) или консистентное хеширование.

¶Примеры в российской практике

• Портал «Госуслуги»: в периоды высокого спроса (запись к врачу, сдача отчётов) применяется ограничение на количество запросов с одной учётной записи или с одного IP-адреса для предотвращения «бронирования» времени ботами.
• Российские облачные провайдеры (Yandex Cloud, VK Cloud, Selectel): при реализации API-шлюзов (API Gateway) используют рейтлимитинг как на уровне тарифных планов, так и для защиты от DDoS-атак.
• Социальная сеть «ВКонтакте» (принадлежит VK): API платформы ограничивает количество вызовов методов в сутки и в секунду для каждого пользователя. В случае превышения кода 429 сбрасывается в ответ.
• Банковские системы (СберБанк, Т-Банк, ВТБ): ограничение количества попыток ввода PIN-кода или CVC2-кода при оплате картами (3–5 неудачных попыток — блокировка на 24 часа) — классический пример рейтлимитинга для защиты от мошенничества.

¶Источники

• Fielding, R. et al. «Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content» (RFC 7231, 2014) — определение кода 429.
• Mahmood, Z. (ed.) «Cloud Computing: Methods and Practical Approaches» (Springer, 2013) — раздел о рейтлимитинге в Scale-архитектурах.
• Документация библиотек: express-rate-limit (Node.js), django-ratelimit (Python), Go-Ratelimit (Go).
• Стандарты DWDM и сетевого планирования: McGuire, A. «Telecommunications Networks: A Practical Guide» (2007) — описание алгоритма «дырявое ведро» в телекоммуникациях.