Как реализовать ограничение скорости API в ядре asp. net в зависимости от типа пользователя - PullRequest
Новая
       157

Как реализовать ограничение скорости API в ядре asp. net в зависимости от типа пользователя

2 голосов
/ 07 августа 2020

В настоящее время я работаю над предоставлением ограничения скорости API на основе IP-адреса зарегистрированного / незарегистрированного пользователя или типа пользователя в ASP. NET Core Web api. (т.е. без входа или входа в клиентское приложение). Я пытался использовать пакет AspNETCoreRateLimit , но мне не удалось динамически обновить идентификатор клиента из клиентского приложения. Если мы используем метод обновления Dynami c, он обновляет существующие правила идентификатора клиента, поэтому мы не можем создать новые правила идентификатора клиента для нового зарегистрированного пользователя. Может ли кто-нибудь предложить решение этой проблемы или альтернативный способ обработки ratelimit в ASP. NET Core веб-API.

Примечание. Приложение будет размещено в кластере Kubernetes. пожалуйста, дайте мне знать, можем ли мы справиться с этим ограничением скорости на уровне Ingress-контроллера?

1 Ответ

0 голосов
/ 10 августа 2020

Я не знаю, как это сделать с ASP. NET Core, но, как указано в документах ниже, вы сможете сделать это на уровне входа.

Kubernetes ingress

Есть документация об этом в kubernetes ingress .

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

Эти аннотации определяют ограничения на соединения и скорости передачи. Их можно использовать для смягчения DDoS-атак .

nginx .ingress.kubernetes.io / limit-connections: количество одновременных подключений, разрешенных с одного IP-адреса. При превышении этого лимита возвращается ошибка 503.

nginx .ingress.kubernetes.io / limit-rps: количество запросов, принимаемых с данного IP-адреса каждую секунду. Предел пакетной передачи установлен в 5 раз больше предела. Когда клиенты превышают этот лимит, возвращается limit-req-status-code default: 503.

nginx .ingress.kubernetes.io / limit-rpm: количество запросов, принятых от заданный IP каждую минуту. Предел пакетной передачи установлен в 5 раз больше предела. Когда клиенты превышают этот лимит, возвращается limit-req-status-code default: 503.

nginx .ingress.kubernetes.io / limit-rate-after: начальное количество килобайт, после чего дальнейшая передача ответа на данное соединение будет ограничена по скорости. Эта функция должна использоваться с включенной буферизацией прокси .

nginx .ingress.kubernetes.io / limit-rate: количество килобайт в секунду, разрешенное для отправки на данное соединение. Нулевое значение отключает ограничение скорости. Эта функция должна использоваться с включенной буферизацией прокси .

nginx .ingress.kubernetes.io / limit-whitelist: диапазоны источников IP-адресов клиентов, которые необходимо исключить из ограничения скорости. Значение представляет собой список CIDR, разделенных запятыми. Если вы укажете несколько аннотаций в одном правиле Ingress, ограничения применяются в следующем порядке: limit-connections, limit-rpm, limit-rps.

Чтобы настроить глобальные настройки для всех правил Ingress, limit-rate-after и значения предельной скорости могут быть установлены в NGINX ConfigMap . Значение, установленное в аннотации Ingress, переопределит глобальную настройку.

IP-адрес клиента будет установлен на основе использования протокола PROXY или из значения заголовка X-Forwarded-For, когда use-forwarded-headers включен.

Существует средний учебник об ограничении скорости для ваших приложений Kubernetes с входом Kubernetes.

Nginx вход

Есть документация об этом nginx вход .

Если вы не понимаете, почему я упомянул как kubernetes, так и nginx ingress, посмотрите здесь

Есть два популярных контроллера Kubernetes Ingress, которые используют NGINX - оба с открытым исходным кодом и размещен на GitHub. Один поддерживается сообществом открытого исходного кода Kubernetes (kubernetes / ingress- nginx на GitHub), а другой поддерживается NGINX, In c. (nginxinc / kubernetes-ingress на GitHub)

Надеюсь, вы найдете это полезным.

...