Как я могу обнаружить долгоживущие соединения и пометить их для формирования

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