Один ошибочный скрипт вызывает ваш API в тесном цикле. Без ограничений это может замедлить работу службы для любого другого пользователя или привести к увеличению счета за облако. Ограничение скорости API — это ограждение, которое удерживает одного клиента от получения большего, чем его справедливая доля.

Чтобы показать, как ведут себя общие алгоритмы, мы написали небольшие версии Python и передали им моделируемое время выполнения запросов. Результаты, приведенные ниже, получены в результате этого прогона. Они обучают моделям, а не производственному коду, а настоящие шлюзы имеют больше возможностей.

Что такое ограничение скорости?

Ограничение скорости учитывает количество запросов на каждого клиента и отклоняет или задерживает запросы, превышающие согласованный лимит, например 100 запросов в минуту. Связанная с этим идея, регулирование, часто означает замедление запросов, а не их отклонение. Квота обычно представляет собой большую норму на более длительный период, например 10 000 вызовов в месяц по тарифному плану.

Зачем это нужно API

• Стабильность: скачки трафика не могут перегрузить базы данных или нижестоящие службы.
• Справедливость: один тяжелый клиент не может морить голодом остальных.
• Безопасность: ограничения замедляют попытки грубого входа в систему и парсинг.
• Контроль затрат: дорогостоящие операции, такие как вызовы моделей ИИ, остаются в рамках бюджета.

Ограничение скорости — это основной элемент управления в топ-10 безопасности API OWASP при неограниченном потреблении ресурсов. В нашем руководстве по тестированию API с помощью Postman показано, как отправлять повторяющиеся запросы, необходимые для его проверки.

Корзина токенов

Представьте себе ведро, вмещающее до 5 жетонов. Каждый запрос принимает токен. Токены пополняются со скоростью 1 в секунду, а в ведре никогда не бывает больше 5. Если ведро пусто, запрос отклоняется.

class TokenBucket:
    def __init__(self, capacity, refill_per_sec):
        self.capacity = capacity
        self.rate = refill_per_sec
        self.tokens = capacity
        self.last = 0.0

    def allow(self, now):
        elapsed = now - self.last
        self.tokens = min(self.capacity, self.tokens + elapsed * self.rate)
        self.last = now
        if self.tokens >= 1:
            self.tokens -= 1
            return True
        return False

Мы отправили сразу 7 запросов, потом еще:

burst of 7 at t=0:  [True, True, True, True, True, False, False]
t=2.0:              [True, True, False]
t=10:               5 allowed of 10

Первые 5 прошли как взрыв, затем ведро опустело. Через две секунды 2 токена были пополнены, поэтому прошло еще 2 запроса. После долгой паузы корзина снова была заполнена, но ограничена значением 5. Такое периодическое, а затем стабильное поведение соответствует реальному трафику, поэтому корзины токенов часто встречаются в шлюзах API. Дырявое ведро — это близкий родственник, который обрабатывает запросы с фиксированной скоростью, сглаживая выходные данные, а не допуская всплески.

Фиксированное окно против раздвижного окна

Счетчик фиксированного окна — это самый простой подход: разрешайте 10 запросов в минуту и сбрасывайте счетчик при изменении минуты. У него есть известный дефект на границе. Мы отправили 10 запросов за 59,9 секунды и еще 10 за 60,0 секунды с ограничением 10 на 60-секундное окно:

fixed window allowed around boundary: 20 of 20
sliding log allowed around boundary:  10 of 20

Фиксированное окно позволяло обрабатывать все 20 запросов за десятую долю секунды, что вдвое превышает запланированную скорость, поскольку они попадали в два разных окна. скользящий журнал запоминает время каждого недавнего запроса и подсчитывает запросы за последние 60 секунд, поэтому правильно разрешено только 10.

Компромисс — память. В скользящем журнале хранится временная метка каждого запроса. Счетчик с раздвижным окном — популярный компромиссный вариант. Он оценивает скорость путем смешивания текущего и предыдущего счетчиков окон, используя небольшой объем памяти с хорошей точностью.

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

Что ограничить

• Ключ API или идентификатор пользователя: самый справедливый вариант для аутентифицированных API.
• IP-адрес: полезен для общедоступных конечных точек, но многие пользователи могут использовать один IP-адрес, и злоумышленники могут менять их.
• Конечная точка: дорогостоящие операции, такие как поиск, экспорт или вход в систему, заслуживают более жестких ограничений.
• Уровень плана: бесплатные и платные клиенты часто получают разные лимиты.

Конечные точки входа требуют особого внимания. Ограничьте как учетную запись, так и IP-адрес, чтобы злоумышленники не могли просто распространять предположения по множеству IP-адресов или множеству учетных записей.

Ответ 429

Когда клиент превышает лимит, возвращайте HTTP 429 Too Many Requests, а не 500 или 403. Включите заголовки, которые сообщают клиенту, что произошло и когда повторить попытку. Наше моделирование создало этот набор для клиента, у которого не осталось запросов:

HTTP/1.1 429 Too Many Requests
RateLimit-Limit: 100
RateLimit-Remaining: 0
RateLimit-Reset: 30
Retry-After: 30

Retry-After — стандартный HTTP-заголовок. Заголовки RateLimit-* взяты из проекта IETF, и многие API используют свои собственные варианты X-RateLimit-*. Что бы вы ни выбрали, задокументируйте это. Дополнительную информацию о кодах состояния см. в нашей шпаргалке по кодам состояния HTTP.

Обработка лимитов в качестве клиента

Повторная попытка сразу после ошибки 429 усугубляет ситуацию. Если тысячи клиентов делают это одновременно, они поступают на сервер синхронизированными волнами. Исправление — экспоненциальная задержка с джиттером: ждите дольше после каждого сбоя и добавьте случайность.

def backoff(attempt, base=0.5, cap=30, rng=random.Random(4)):
    return round(min(cap, base * 2 ** attempt) * rng.random(), 2)

[backoff(a) for a in range(6)]
# [0.12, 0.1, 0.79, 0.62, 0.53, 6.43]

Это «полный джиттер»: случайное ожидание между нулем и экспоненциально растущим потолком. Ожидания выглядят нерегулярными, и в этом вся суть. Клиенты расходятся вместо того, чтобы повторять попытки вместе. Мы задали генератор случайных чисел, чтобы можно было воспроизвести выходные данные.

Распределенное ограничение скорости

Благодаря нескольким серверам API за балансировщиком нагрузки каждый сервер, рассчитывающий самостоятельно, позволяет клиенту превысить лимит, распределяя запросы между ними. Команды обычно хранят счетчики в общем хранилище, таком как Redis, с атомарными операциями или коротким скриптом, чтобы два сервера не могли одновременно получить последний токен. Такие шлюзы, как Kong, NGINX, Envoy и облачные API-шлюзы, предоставляют это в качестве конфигурации. Для этой статьи мы не запускали распределенную установку.

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

• Отправьте запросы до лимита и подтвердите их успешность.
• Отправьте еще один и подтвердите код 429 с правильными заголовками.
• Подождите времени сброса и снова подтвердите успешность запросов.
• Проверьте лимиты на ключ: использование одного клиента не должно блокировать использование другого.
• Проверьте границу между окнами на предмет проблемы двойного пакета.
• Используйте инструмент загрузки, описанный в разделе нагрузочное тестирование и стресс-тестирование, чтобы проверить поведение в условиях интенсивного параллелизма.

В модульные тесты вводите текущее время, как это делает наша симуляция с now, поэтому тестам никогда не придется переходить в режим сна.

Проектирование ограничений, с которыми пользователи могут жить

Выбор чисел имеет такое же значение, как и выбор алгоритма. Начните с реального трафика: посмотрите, сколько запросов в минуту делают ваши самые активные легитимные клиенты, и установите комфортные лимиты выше этого значения. Ограничение, блокирующее нормальное использование, создает заявки в службу поддержки, а не безопасности.

• Опубликуйте ограничения в документации по API для каждой конечной точки и для каждого плана.
• Предупреждать перед блокировкой. Заголовки, показывающие оставшиеся запросы, позволяют хорошо себя замедлить работу клиентов.
• Предлагайте альтернативы интенсивному опросу, например веб-перехватчики, массовые конечные точки или страницы большего размера.
• Отслеживайте показатели 429. Внезапный рост может означать атаку, выпуск клиента с ошибками или слишком жесткие ограничения.
• Намеренно предоставляйте исключения, например повышенные ограничения для партнера, записанные в конфигурации, а не жестко закодированные.

Также решите, что произойдет с запросами, количество которых превышает лимит. Некоторые API ненадолго ставят в очередь небольшое количество дополнительных запросов вместо того, чтобы отклонять их, что сглаживает короткие всплески. Другие отдают приоритет важным конечным точкам, таким как платежи, над менее важными, такими как аналитика, чтобы важный трафик продолжал течь, когда система находится под нагрузкой.

Итоги

Хорошее ограничение скорости — это договор между API и клиентом. Сервер выбирает справедливый алгоритм, обычно сегмент токенов или скользящее окно, и четко объясняет его ограничения с помощью 429 и Retry-After. Клиент уважает эти сигналы и отступает с дрожью. Начните с щедрых ограничений на ключ API, наблюдайте за реальным использованием и увеличивайте их только там, где это необходимо.

Часто задаваемые вопросы

Продолжайте учиться