Мне бы хотелось обнаружить TCP-соединения, которые открыты более одной минуты (или более N байт или M пакетов), чтобы можно было классифицировать их как массовый трафик («загрузки») и понизить их приоритет.
Могу ли я обнаружить длительные потоки с помощью iptables/netfilter/conntrack и пометить их для формирования с помощью tc?
Я думал, что смогу использовать "порядковый номер" TCP как некоторую меру длины потока, но, к сожалению, он не начинается с нуля! Возможно, отслеживание соединения с помощью netfilter/conntrack могло бы определить правильный порядковый номер или общее количество байтов и длительность соединения, а также выбрать, следует ли маркировать пакет.
(Я также мог бы упомянуть, что я делаю это навхождениес использованием виртуального интерфейса ifb0. В настоящее время я использую очереди tbf (с sfq) для ограничения низкоприоритетных данных. Независимо от этого, любое решение также может быть применено квыход(например, для веб-сервера с ограниченным соединением, который хочет снизить приоритет загрузок, чтобы ускорить небольшие запросы.)
Обновление: Используя conntrackd, я могу видеть список подключений и как давно каждое из них было инициировано. Я начал использовать этот список для обнаружения пар IP/порт, которые я хочу ограничить (через 60 секунд). Однако есть ряд проблем:
- conntrack(d) похоже не очищает соединения из списка сразу после их закрытия! Поэтому я в итоге помечаю все соединения для ограничения, даже те, которые были завершены.
- Установка меток в conntrack, похоже, не устанавливает метки в пакетах (насколько может видеть tc). (Это происходит не только потому, что conntrack видит пакеты после ifb0: я также не вижу никаких меток на исходящих пакетах.) Поэтому я просто добавляю новые фильтры в tc для ограничения, что далеко от идеала в долгосрочной перспективе.
- conntrack(d) не сообщает мне, сколько пропускной способности использовало каждое соединение. Поэтому я не могу отличить прерывистые (например, iosocket) сеансы от тяжелых загрузок. (В любом случае, это сложная проблема: если у нас уже есть 5 загрузок и начинается новая загрузка, как мы можем определить, что он пытается зафлудить? Он не достигнет и близко максимальной скорости.)
Будем признательны за любые предложения по вышеизложенному.
(С другой стороны, даже если я не могу правильно классифицировать загрузки, простое использование tfb для ограничения входящих данных до 80% от моей максимальной скорости загрузки предотвратило переполнение соединения и позволило устанавливать новые соединения гораздо легче, чем раньше.)
решение1
Ожидаемая продолжительность жизни и фактическая долговечность соединения не имеют НИКАКОГО отношения к тому, следует ли придавать соединению особую форму или нет.
Некоторые примеры:
SSH, возможно, долгоживущий, минуты, часы, дни, недели, даже месяцы. Все еще нуждается в высоком приоритете, чтобы реагировать на взаимодействие с пользователем.
Bittorrent (или подобные протоколы), случайным образом жили, некоторые секунды, а затем отключались, другие минуты или часы, а затем отключались. Немногие из них жили больше суток за раз.
Резюме: Длина соединения НИКАК не влияет на то, является ли соединение «массовым» или нет, и следует ли его рассматривать как массовый.
Не обязательно напрямую связано, но полезно:
Ограничение трафика загрузки с помощью шейпинга трафика полезно или вредно?