Rate limit

Rate limit (ограничение частоты запросов) — механизм, который ограничивает число запросов от одного клиента (по IP, API-ключу, аккаунту) за определённый промежуток времени. Клиент, превысивший лимит, получает ответ 429 Too Many Requests с заголовком Retry-After, указывающим, когда можно повторить запрос.

Зачем нужен rate limiting

• Защита от перегрузки: предотвращает исчерпание ресурсов сервера при атаке или ошибке клиента.
• Защита от DDoS: ограничивает ущерб от флуда запросами с одного IP.
• Монетизация API: разные лимиты для разных тарифных планов (Free: 100 req/день, Pro: 10 000 req/день).
• Защита от брутфорса: лимит на эндпоинты авторизации предотвращает перебор паролей.

Алгоритмы rate limiting

Token Bucket (корзина жетонов)

В корзину с заданной ёмкостью добавляются жетоны с фиксированной скоростью. Каждый запрос тратит жетон. При пустой корзине запросы отклоняются. Допускает кратковременные пики: если жетоны накоплены, можно послать несколько запросов подряд. Используется в nginx (limit_req_zone с burst).

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

Запросы попадают в очередь фиксированного размера и обрабатываются с постоянной скоростью. Излишки отбрасываются. Не допускает пиков — скорость строго равномерная. Используется для сглаживания трафика.

Fixed Window Counter

Считает запросы в фиксированном временном окне (например, в текущей минуте). Простой, но имеет граничный эффект: 100 запросов в конце одной минуты + 100 в начале следующей = 200 за 2 секунды.

Sliding Window Log

Хранит метки времени запросов. При каждом новом запросе считает, сколько запросов было за последние N секунд. Точный, но требует хранения всех меток.

История

Алгоритмы token bucket и leaky bucket разработаны в 1980-х для управления сетевым трафиком в телекоммуникациях — RFC 1363 (1992) описывает leaky bucket для ATM-сетей. В API-дизайне rate limiting появился с ростом публичных API: Twitter ввёл лимиты в 2007 году (150 req/час), GitHub — в 2010-м (60 req/час для неаутентифицированных). Сегодня rate limiting — обязательная часть любого API-шлюза.

Настройка в nginx

# Определяем зону: 10m хранит ~160 000 IP-адресов
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

server {
    location /api/ {
        # burst=20: допускаем накопление 20 запросов
        # nodelay: обрабатываем пики немедленно, не ставим в очередь
        limit_req zone=api burst=20 nodelay;
    }
}

При превышении nginx вернёт 503 (по умолчанию) или 429 (через limit_req_status 429). Для авторизационных эндпоинтов стандартно выставляют 5-10 req/min на IP. Fail2ban может автоматически банить IP, превысивших лимит, через iptables.

HTTP-заголовки rate limiting

Стандартные заголовки, которые API возвращает клиенту:

• X-RateLimit-Limit — максимальный лимит (например, 1000).
• X-RateLimit-Remaining — осталось запросов в текущем окне.
• X-RateLimit-Reset — Unix-timestamp сброса счётчика.
• Retry-After — секунды до следующего допустимого запроса (при 429).