Тротлинг (Throttling) — намеренное ограничение скорости или частоты запросов к серверу или API. Применяется для защиты от перегрузки, обеспечения справедливого распределения ресурсов и монетизации через тарифные ограничения. Тротлинг отличается от блокировки: он замедляет или откладывает запросы, а не отклоняет их.
Как работает тротлинг
Существует несколько алгоритмов тротлинга:
- Token Bucket — «корзина токенов»: токены накапливаются с фиксированной скоростью, каждый запрос тратит токен. Позволяет bursts.
- Leaky Bucket — запросы обрабатываются с постоянной скоростью независимо от интенсивности поступления
- Fixed Window — N запросов за фиксированный период (100 req/min). Прост, но уязвим к burst на границе окна.
- Sliding Window — скользящее окно устраняет проблему Fixed Window
В Nginx тротлинг настраивается через limit_req:
http {
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
server {
location /api/ {
limit_req zone=api burst=20 nodelay;
}
}
}Это ограничивает каждый IP до 10 запросов/секунду с burst до 20. Клиент получает HTTP 429 при превышении лимита.
История
Тротлинг стал актуальным с ростом публичных API в 2000-х. Twitter в 2006 году одним из первых ввёл rate limiting для своего API. AWS API Gateway, Google APIs и большинство публичных сервисов сегодня имеют многоуровневые лимиты: по IP, по API-ключу, по аккаунту. В облачных средах тротлинг CPU — отдельный сценарий: VPS-провайдер ограничивает потребление процессорных ресурсов при перегрузке хоста.
На что обращать внимание
HTTP-статус 504 или 503 при тротлинге означают перегрузку на уровне приложения. Правильный ответ на тротлинг API — HTTP 429 с заголовком Retry-After, указывающим время ожидания. Клиентский код должен обрабатывать 429 и реализовывать exponential backoff.
Для веб-приложений тротлинг защищает от brute-force атак: ограничение попыток входа по IP снижает эффективность перебора паролей. Redis часто используется как backend для хранения счётчиков тротлинга из-за скорости атомарных операций и встроенного TTL.
Тротлинг CPU в облаке и VPS
Отдельный сценарий тротлинга — ограничение CPU со стороны хостинг-провайдера. На shared-хостинге и бюджетных VPS провайдеры ограничивают потребление CPU-циклов: при постоянной загрузке 100% CPU вводится burst-ограничение.
В контейнерных средах (Docker, Kubernetes) тротлинг CPU настраивается через cgroup: параметр cpu.cfs_quota_us ограничивает количество CPU-времени, доступного контейнеру. docker run --cpus="0.5" ограничивает контейнер половиной ядра. Kubernetes tasks с resources.limits.cpu используют тот же механизм.
Признаки CPU-тротлинга на VPS: высокое steal в выводе top (CPU-время, отобранное гипервизором), нестабильное время ответа при равномерной нагрузке. iostat -x 1 и vmstat 1 помогают идентифицировать тротлинг. Если %steal регулярно превышает 10% — сервер на переполненном физическом хосте или нужно переходить на тариф с выделенными CPU.
Для API-тротлинга важна правильная обработка ошибок на стороне клиента. Клиентская библиотека должна перехватывать HTTP 429 и реализовывать exponential backoff с jitter: первая повторная попытка через 1 секунду, вторая — 2 секунды, третья — 4 секунды и так далее. Это предотвращает «шторм ретраев» — ситуацию, когда все клиенты одновременно повторяют запросы после снятия ограничения.