Rate limiting

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

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

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

Отклонённые запросы могут обрабатываться по-разному:

• Отказ в обслуживании: сервер возвращает клиенту HTTP-код ошибки, чаще всего 429 Too Many Requests (слишком много запросов). В ответе может содержаться заголовок Retry-After, указывающий время, через которое можно повторить запрос.
• Задержка обработки: запрос не отклоняется, но ставится в очередь и обрабатывается с задержкой, чтобы сгладить пиковую нагрузку.
• Понижение приоритета: запрос принимается, но обрабатывается с более низким приоритетом, чем обычные запросы.

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

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

Token Bucket (Токеновое ведро)

Один из наиболее распространённых алгоритмов. В системе имеется «ведро», которое вмещает определённое количество токенов. Токены добавляются в ведро с постоянной скоростью (например, 10 токенов в секунду). Когда приходит запрос, он забирает один токен из ведра. Если токенов нет, запрос отклоняется или ставится в очередь. Алгоритм позволяет обрабатывать кратковременные всплески трафика, так как в ведре может накопиться запас токенов до максимального размера.

Leaky Bucket (Дырявое ведро)

Работает как очередь с фиксированной скоростью обработки. Запросы поступают в «ведро» (очередь), а из него «вытекают» (обрабатываются) с постоянной скоростью. Если ведро переполняется (очередь достигает максимального размера), новые запросы отбрасываются. В отличие от Token Bucket, этот алгоритм сглаживает всплески, не позволяя превысить заданную скорость обработки.

Fixed Window (Фиксированное окно)

Лимит устанавливается на фиксированный интервал времени, например, 100 запросов в минуту. Счётчик запросов сбрасывается в начале каждого нового интервала. Недостаток алгоритма — возможность резкого скачка нагрузки на границе окон: если в конце одного окна было использовано 99 запросов, а в начале следующего — ещё 99, то за короткий промежуток времени будет обработано 198 запросов, что может превысить допустимую нагрузку.

Sliding Window (Скользящее окно)

Более точный алгоритм, который учитывает запросы в скользящем временном окне, а не в фиксированных интервалах. Например, для лимита в 100 запросов в минуту система проверяет количество запросов за последние 60 секунд от текущего момента. Это позволяет избежать скачков нагрузки на границах окон. Часто реализуется с помощью логов с временными метками или с использованием комбинации фиксированных окон с весовыми коэффициентами.

Sliding Window Log (Скользящее окно с логом)

Для каждого клиента хранится лог временных меток его запросов. При новом запросе из лога удаляются все метки, попадающие за пределы окна. Затем проверяется, не превышает ли количество оставшихся меток лимит. Этот алгоритм точен, но требует хранения данных для каждого запроса, что может быть ресурсоёмко при большом количестве клиентов.

Применение

Rate limiting используется в самых разных областях, где требуется контроль над интенсивностью запросов.

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

Почти все публичные API (например, социальных сетей, облачных платформ, платёжных систем) используют rate limiting. Это позволяет:

• Защитить серверную инфраструктуру от перегрузки из-за ошибок в клиентском коде или злонамеренных действий.
• Обеспечить равный доступ к ресурсам для всех пользователей, предотвращая «захват» ресурсов одним клиентом.
• Монетизировать доступ: бесплатные тарифы имеют низкие лимиты, а платные — более высокие.

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

Rate limiting является ключевым элементом защиты от различных типов атак:

• DDoS-атаки: ограничение числа запросов с одного IP-адреса или из одной подсети помогает смягчить последствия распределённых атак на отказ в обслуживании.
• Брутфорс (перебор паролей): ограничение количества попыток входа в систему с одного аккаунта или IP-адреса затрудняет автоматический подбор паролей.
• Web scraping (парсинг): ограничение частоты запросов к страницам сайта препятствует массовому автоматизированному сбору данных.
• Атаки на исчерпание ресурсов: ограничение на количество запросов к ресурсоёмким операциям (например, поиску или генерации отчётов) предотвращает истощение вычислительных мощностей.

Сетевые устройства и протоколы

Rate limiting встроен в протоколы маршрутизации и коммутации. Например, в протоколах BGP (Border Gateway Protocol) и OSPF (Open Shortest Path First) используется rate limiting для предотвращения лавинной рассылки обновлений маршрутной информации, которая может дестабилизировать сеть. На сетевых устройствах (маршрутизаторах, коммутаторах) rate limiting может применяться для ограничения трафика определённых типов (например, broadcast-трафика).

Финансовые системы

В банковских и биржевых системах rate limiting используется для контроля над частотой транзакций, запросов к API и торговых операций. Это необходимо для соблюдения нормативных требований, предотвращения мошенничества и обеспечения стабильности системы.

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

Несмотря на свою эффективность, rate limiting имеет ряд недостатков и критикуется за:

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

Интересные факты

• HTTP-заголовок Retry-After в ответе с кодом 429 может содержать как количество секунд, так и конкретную дату и время, после которых запрос может быть повторён.
• В распределённых системах для реализации rate limiting часто используется Redis благодаря его высокой производительности и поддержке атомарных операций, таких как INCR и EXPIRE.
• Некоторые API предоставляют заголовки X-RateLimit-Limit, X-RateLimit-Remaining и X-RateLimit-Reset, чтобы клиенты могли отслеживать свой текущий лимит и планировать запросы.

Источники

• RFC 6585 — Additional HTTP Status Codes (определяет код 429 Too Many Requests)
• RFC 7231 — Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
• Документация API крупных платформ (например, GitHub, Twitter, Google Cloud) по rate limiting
• Книга «Designing Data-Intensive Applications» by Martin Kleppmann (раздел о дросселировании)
• Статьи о системном проектировании (System Design) на ресурсах вроде High Scalability и AWS Architecture Blog