← Документация WAF / rate-limiting-rules

Расчёт частоты запросов

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

Например, рассмотрим правило со следующими характеристиками:

• IP-адрес
• HTTP-заголовок x-api-key

Если два запроса имеют одинаковое значение x-api-key, но приходят с разных IP-адресов, Cloudflare считает их отдельно, поскольку комбинации их характеристик различаются.

Счётчики не разделяются между дата-центрами, за исключением дата-центров, связанных с одной географической локацией.

По умолчанию частота запросов рассчитывается по количеству входящих запросов. Клиенты Enterprise с Advanced Rate Limiting может также рассчитывать частоту на основе стоимости обслуживания каждого запроса. См. Rate limiting на основе сложности для получения дополнительной информации.

Рассмотрим следующую конфигурацию правила rate limiting:

На следующей схеме показано, как Cloudflare обрабатывает четыре входящих запроса в контексте приведённого выше правила rate limiting.

Поскольку запрос 1 соответствует выражению правила, правило rate limiting вычисляется. Cloudflare заводит счётчик запросов для значений характеристик в контексте правила rate limiting и устанавливает счётчик в 1. Поскольку значение счётчика в пределах лимитов, установленных в Запросы, запрос пропускается.

Запрос 2 соответствует выражению правила, поэтому Cloudflare оценивает правило rate limiting. Значения характеристик не совпадают ни с одним существующим счётчиком (значение X-API-Key заголовок отличается). Поэтому Cloudflare заводит отдельный счётчик в контексте этого правила и устанавливает его равным 1. Значение счётчика в пределах лимита запросов, установленного в Запросы, поэтому этот запрос пропускается.

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

Запрос 4 не соответствует выражению правила, поскольку значение Content-Type не совпадает со значением в выражении. Поэтому Cloudflare не создаёт новый счётчик правила для этого запроса. Запрос 4 не вычисляется в контексте этого правила rate limiting и передаётся последующим правилам в процессе обработки запроса.

Рассмотрим следующую конфигурацию правила rate limiting. Выражение подсчёта правила определяет, что счётчик увеличивается на единицу, когда код состояния HTTP-ответа равен 400:

Следующая диаграмма показывает, как Cloudflare обрабатывает эти четыре входящих запроса, полученных за 10-секундный период, в контексте приведённого выше правила rate limiting.

Поскольку запрос 1 соответствует выражению правила, правило rate limiting вычисляется. Запрос отправляется на источник в обход кэшированного содержимого, потому что правило rate limiting включает поле ответа (http.response.code) в выражении подсчёта. Исходный сервер отвечает 400. Поскольку есть совпадение с выражением подсчёта, Cloudflare создаёт счётчик запросов для значений характеристик в контексте правила rate limiting и устанавливает этот счётчик в 1.

Запрос 2 соответствует выражению правила, поэтому Cloudflare оценивает правило rate limiting. Счётчик запросов для значений характеристик всё ещё в пределах максимального числа запросов, заданного в Запросы. Исходный сервер отвечает 200 (код состояния). Поскольку ответ не соответствует выражению подсчёта, счётчик не увеличивается и сохраняет значение (1).

Запрос 3 соответствует выражению правила, поэтому Cloudflare вычисляет правило rate limiting. Запрос всё ещё в пределах максимального количества запросов, заданного в Запросы. Исходный сервер отвечает 400. Есть совпадение с выражением подсчёта, и счётчик устанавливается в 2.

Запрос 4 соответствует выражению правила, поэтому Cloudflare оценивает правило rate limiting. Запрос уже не укладывается в максимальное число запросов, заданное в Запросы (счётчик имеет значение 2, а максимальное число запросов — 1). Cloudflare применяет действие, заданное в конфигурации правила rate limiting, блокируя запрос 4 и все последующие запросы, соответствующие правилу rate limiting, на десять минут.

Не все запросы одинаково дороги в обслуживании. Простое чтение через API может расходовать минимум ресурсов, а сложный запрос к базе данных или экспорт файла — значительно больше. Rate limiting по числу запросов считает их одинаковыми: 100 лёгких и 100 дорогих запросов увеличивают один и тот же счётчик.

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

Чтобы использовать rate limiting на основе сложности, ваш исходный сервер должен возвращать HTTP-заголовок ответа с числовой оценкой для каждого запроса. Эта оценка представляет сложность или стоимость обслуживания запроса. Значение должно быть от 1 до 1 000 000. Имя заголовка, которое читает правило, настраиваете вы.

Правила rate limiting на основе сложности должны содержать следующие свойства:

• Оценка за период: Максимальная суммарная оценка, допустимая за период. Когда сумма превышает это значение, выполняется действие правила.
• Period: Временное окно для оценки суммарной оценки.
• Response header name: HTTP-заголовок ответа, устанавливаемый вашим исходным сервером и содержащий оценку для каждого запроса.

Cloudflare ведёт счётчики с суммарной оценкой всех запросов с одинаковыми значениями характеристик правила, совпадающих с выражением правила. Оценка увеличивается на значение, предоставленное исходным сервером в ответе, при совпадении выражения подсчёта (по умолчанию оно совпадает с выражением правила). Когда суммарная оценка превышает настроенную максимальную оценку за период, применяется действие правила.

Если исходный сервер не предоставляет HTTP-заголовок ответа со значением оценки или значение оценки выходит за допустимый диапазон, соответствующий счётчик rate limiting не обновляется.

Рассмотрим следующую конфигурацию правила rate limiting. При совпадении правила счётчик оценки сложности будет увеличиваться на основе значения в x-score заголовка ответа, переданного исходным (origin) сервером.

На следующей схеме показано, как Cloudflare обрабатывает четыре входящих запроса, полученных за одну минуту, в контексте приведённого выше правила rate limiting.

Поскольку запрос 1 соответствует выражению правила, правило rate limiting вычисляется. Источник отвечает кодом 200 код состояния и оценку сложности 100 в x-score — HTTP-заголовок ответа. Cloudflare создаёт счётчик запросов для значений характеристик в контексте правила rate limiting и устанавливает этот счётчик равным 100.

Запрос 2 соответствует выражению правила, поэтому Cloudflare оценивает правило rate limiting. Счётчик для значений характеристик всё ещё в пределах максимальной оценки за период. Исходный сервер отвечает кодом 200 кодом состояния, и счётчик запросов увеличивается на 200. Текущая оценка сложности для запроса теперь равна 300.

Запрос 3 соответствует выражению правила, поэтому Cloudflare вычисляет правило rate limiting. Счётчик запросов для данных значений характеристик всё ещё в пределах максимальной оценки за период. Исходный сервер отвечает кодом 200 кодом состояния, и счётчик запросов увеличивается на 150. Текущая оценка сложности для запроса теперь равна 450.

Запрос 4 соответствует выражению правила, поэтому Cloudflare оценивает правило rate limiting. Запрос уже не укладывается в максимальную оценку за период, заданную в правиле (счётчик имеет значение 450, а максимальная оценка — 400). Cloudflare применяет действие, заданное в конфигурации правила rate limiting, блокируя запрос 4 и все последующие запросы, соответствующие правилу rate limiting, на десять минут.