День 1779. #ЗаметкиНаПолях
Сравниваем Алгоритмы Ограничения Обработки Запросов. Начало
Всегда следует устанавливать ограничение на количество входящих запросов. Иначе система может оказаться уязвимой для злоумышленников. Рассмотрим 4 основных алгоритма ограничения обработки запросов.

Ограничение обработки запросов (Rate Limiting) — это способ запретить клиентам слишком часто обращаться к системе.

Преимущества:
1. Защищает систему от DoS атак
Если злоумышленник попытается повлиять на систему, вызывая API так часто, что вся система выйдет из строя, ограничение поможет уменьшить количество выполняемых операций.
2. Добавляет уровень безопасности, предотвращающий атаки грубой силой.
Если злоумышленник попытается получить доступ к системе, перепробовав все возможные пароли, политика ограничения обработки запросов не позволит ему выполнить слишком много попыток.
3. Защищает медленно работающую часть системы.
Если часть системы не может быстро обработать запрос, клиент может добавить политику повтора запроса. Так он может перегрузить и без того плохо работающий компонент, что сделает его совершенно неспособным обрабатывать любые запросы.

Чтобы клиенты знали, что их запросы не обрабатываются из-за слишком частых попыток, нужно использовать код ответа HTTP: 429 Too Many Requests. Так клиенты могут реализовать логику повторных попыток, учитывая это. Ответ также должен включать HTTP-заголовок Retry-After, чтобы сообщить клиенту, как долго ждать перед выполнением следующего запроса.

Теперь рассмотрим стратегии ограничения количества запросов.

1. Фиксированное окно
Ограничивает количество запросов, разрешённых в течение данного временного окна. Временные рамки определяются сервером и одинаковы для всех клиентов.

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

Алгоритм прост в реализации, но имеет некоторые недостатки:
1) Может допускать всплески запросов в начале или в конце каждого окна, что может перегрузить систему.
2) Предположим, что многие запросы переводятся на следующую минуту. В этом случае вы в итоге добавляете всё больше запросов в начало следующей минуты, вызывая всплеск запросов, которые система может быть не в состоянии обработать.

2. Скользящее окно
Делит время на фиксированные интервалы, и каждый интервал начинается с первого запроса клиента. Если окно составляет 100 запросов в минуту, то:
- Клиент А делает первый запрос в 09:00:05 и может обратиться к системе 100 раз до 09:01:05.
- Клиент B - первый запрос в 09:00:38 - 100 запросов до 09:01:38.
Так оба клиента могут обращаться к системе по 100 раз в минуту, но их временные окна не зависят друг от друга и могут пересекаться.

Этот алгоритм более справедлив, чем алгоритм фиксированного окна, поскольку рассматривает историю запросов каждого клиента независимо. Однако теперь необходимо хранить информацию о количестве запросов и времени окна для каждого клиента, что более сложно и ресурсоемко.

Окончание следует…

Источник: https://www.code4it.dev/architecture-notes/rate-limiting-algorithms/