классификация трафика на основе потока для формирования трафика

Question

Мне интересно, есть ли способы добиться потокового формирования трафика с помощью Linux. Традиционные подходы к формированию трафика, похоже, основаны на создании классов для определенных протоколов или типов пакетов (таких как ssh, http, SYN или ACK), которые требуют высокой пропускной способности.

Здесь я хочу видеть каждое TCP-соединение как поток, характеризуемый определенной скоростью передачи данных. Там будет

• быстрые потоки, такие как интерактивный ssh ​​или IRC чат и
• медленные потоки (объемные данные), такие как передача файлов scp или http

Теперь я ищу способ охарактеризовать / классифицировать входящий пакет для одного из этих классов, чтобы я мог запустить формирователь трафика на основе tc. Есть намеки?

Answer 1

Поскольку вы упоминаете выделенную машину, я предполагаю, что вы управляете с сетевого моста и, таким образом, имеете доступ ко всему пакету в течение всего срока его службы в вашей системе.

Сначалаи самое главное: регулирование на принимающей стороне соединения не имеет смысла, когда вы говорите о насыщении канала.К тому времени, когда вы видите пакет, он уже уже использовал ресурсы .Это правда, даже если вы мост;Вы можете только реально сделать что-нибудь умное на выходном интерфейсе.

Я не думаю, что вы найдете готовый продукт, который будет делать именно то, что вы хотите.Вам нужно будет изменить что-то вроде dummynet , чтобы оно было динамическим в соответствии с правилами, которые вы получаете во время выполнения, или вам придется программировать динамический программный маршрутизатор, используя некоторую существующую инфраструктуру.Я знаком с модульным маршрутизатором Click , но есть и другие.Я действительно не знаю, как такие вещи, как tc и ipfw будут реагировать на то, что их конфигурируют / реконфигурируют с высокой частотой - я подозреваю, что это плохо.

Однако есть вещи, которые вы должны решить заранее.Вещи, которые сделают эту задачу трудной независимо от реализации.Например,

1. Как вы планируете проводить различие между объемами scp и интерактивным поведением ssh?Будете ли вы отслеживать исходное поведение и применять правила, основанные на этом?
2. Вы упомянули специфичное для HTTP регулирование;это подразумевает DPI.Сможете ли вы поддерживать это на этом мосту / маршрутизаторе?Сколько классов трафика приложений вы будете поддерживать?
3. Как вы планируете обрабатывать конфликты?(вы выделяете «массовые» потоки, чтобы каждый получал 30% емкости, но 10 «массовых» потоков пытался использовать)
4. Будете ли вы жестко задавать емкость канала или измерять ее?Это исправлено или будет изменяться?

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

Если бы у вас была более конкретная цель, некоторые из этих пунктов могли бы стать спорными.