Назад | Перейти на главную страницу

Какие существуют решения для регулирования исходящего HTTP-трафика?

Я ищу способ гибкого управления исходящим HTTP / HTTPS-трафиком с соблюдением политик сайта и возможность развертывания на «границе» нашей сети центра обработки данных.

Например, мы используем несколько веб-API, которые имеют скорость регулирования, например «не более 4 запросов в секунду» или «не более 50 000 запросов в день» и т. Д. У нас есть много людей в компании, которые используют различные подобные услуги, поэтому я не могу централизованно управляйте всеми запросами в программном обеспечении. Люди запускают эти вещи по разному графику и с разной интенсивностью. Нас это устраивает (это отвечает внутренним потребностям), но мы понимаем, что в совокупности мы можем попасть в ситуации, когда мы генерируем так много одновременного трафика, что нас блокирует сайт. (хотя это непреднамеренно)

Я ожидаю / надеюсь, что мы сможем использовать решения для управления полосой пропускания / формирования трафика, которые уже существуют в мире сетевого оборудования, и что впоследствии мы сможем развернуть такую ​​вещь на границе нашей сети центра обработки данных.

В идеале я мог бы написать правила маршрутизации L4 или L7, которые позволят нам гарантировать, что исходящий трафик не более, например, 4 запросов в секунду генерируется нашим центром обработки данных. Остальные запросы, опять же, в идеале, должны быть поставлены в очередь на оборудование в течение некоторого разумного периода времени, при этом избыточная емкость очереди просто отклоняется. Я понимаю, что бесплатного обеда нет и что регулирование не решит фундаментальную проблему спроса (запросов) и предложения (политики сайта). Однако регулирование позволит нам «сгладить» запросы в течение некоторого окна, скажем, дня, чтобы мы могли использовать внешнюю службу должным образом ограниченным образом, но при этом максимально использовать возможности.

Кто-нибудь знает такое решение для управления полосой пропускания на уровне сети? Если да, будет ли он также поддерживать правила, основанные не только на чем-то вроде URL-адреса в HTTP-запросе, но и на некоторых дополнительных заголовках HTTP?

Возможности сетевой фильтр практически безграничны. На этом я бы использовал модуль ограничения в iptables. Имейте в виду: нет способа ограничить скорость TCP / IP без отбрасывания пакетов. Вы можете поставить пакеты в очередь, но в конечном итоге, когда очередь заполнится, пакеты будут отброшены. Итак, мы собираемся отбросить пакеты SYN. Я пока не пробовал этого, вероятно, из-за очень длинных таймаутов повтора никто этого не делает, т.е. браузер может заблокироваться.

предел

Этот модуль соответствует с ограниченной частотой с использованием фильтра корзины токенов. Правило, использующее это расширение, будет соответствовать, пока не будет достигнут этот предел (если не используется флаг «!»). Его можно использовать в сочетании с целью LOG, например, для ограниченного ведения журнала.

--limit rate Максимальная средняя скорость сопоставления: указывается в виде числа с дополнительным суффиксом «/ секунда», «/ минута», «/ час» или «/ день»; по умолчанию 3 / час.

--limit-burst number Максимальное начальное число совпадающих пакетов: это число перезаряжается на один каждый раз, когда не достигается указанный выше предел, вплоть до этого числа; по умолчанию - 5.

  1. Мы настраиваем новую цепочку, которая ограничивает количество подключений. Через 4 секунды он вернется в цепочку вызывающих абонентов, остальные будут сброшены.
  2. В эту новую цепочку отправляются новые соединения с портом 80.
iptables -N CONNRATELIMIT
iptables -A CONNRATELIMIT -m limit --limit 4/sec -j RETURN
iptables -A CONNRATELIMIT -j DROP

iptables -A INPUT -p tcp --dport 80 -m state --state NEW -j CONNRATELIMIT

Я использовал вторичную цепь, чтобы показать концепцию. Вы также можете сделать это на маршрутизаторе, тогда вам нужно будет создать цепочку для каждого сервера или объекта, который вы хотите ограничить. И используйте FORWARD вместо INPUT.

Очередь

В этом решении нет «длительных» очередей. Вы можете играть с предел и предельный всплеск параметры. Также можно было бы отправлять SYN-пакеты в дисциплину очередей: настройка намного сложнее, и я не вижу, как она улучшит ситуацию с отбрасыванием SYN-пакетов.

Соответствие URL

Также возможно сопоставление URL-адресов, в этом случае вы сбросите этот пакет и задержите соединение, ожидая повторной передачи, я сделал такие вещи с модулем недавний, НО я использовал его для предотвращения атак методом перебора и сканирования портов. Так что меня не волнуют связи, которые я ограничиваю. Правильное обращение с соединениями будет затруднено!