Я хотел бы обнаружить 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% от моего максимального снижения, предотвратило переполнение соединения и позволило устанавливать новые соединения гораздо проще, чем раньше.)