Выделение приоритета для конкретного ПО (шейпинг (QoS), типизация трафика)

[patrius]

Имеем такую ситуацию:
1. 50Мб канал в нет
2. Среднюю загрузку в рамках 60% канала
3. Пиковую нагрузку в рамках 90-100% в произвольные интервалы с длительностью до 1часа в сутки.
4. Пинг по "чистому" каналу около 40-50мс.

С недавнего времени начали жаловаться пользователи ММОРПГ на лаги.
1*В дальнейшем, для примера, буду говорить конкретно про WoW (World of Warcraft).

Что сделано:
1. Скачал в офф сервера клиент, загерил триал. Некоторое время побегал... Действительно проблемка есть, особенно в часы пиковой загрузки.
2. Повысил приоритет всего своего потока - действительно полегчало. В т.ч. не ощущаются пиковые загрузки.
3. Просмотрел данные от iptables -j LOG и не нашел различий в TOS, от торрент клиента.

Решения, которые я знаю (вижу):
1. Повышение приоритета для трафика по портам

. TCP/UDP Ports 3724,1119, 4000, 6112, 6113, 6114, 6881-6999

2. Повышение приоритета для ACK/SYN и др маловесных пакетов.

В этих решениях меня смущает:
1. Возможность "повесить", например, торрента на указанные порты.
2. Невозможность "типизации" приложения, трафик которого проходит по правилу.

Вернемся к 1* и вспомним, что на данный момент различных ММОРПГ на данный момент более чем выше крыши. И типизация трафика для каждого из приложений становиться очень не тривиальна.

P.S.: Также хотелось бы узнать, чем можно собрать камулятивную статистику по трафику, не такую подробную как дают iptables и iptraf.

[Alex2ndr]

Вы не один мучаетесь такими проблемами Думаю часть спецов провайдеров и держателей домашних сетей заняты тем же

Решения, которые я знаю (вижу):
1. Повышение приоритета для трафика по портам

. TCP/UDP Ports 3724,1119, 4000, 6112, 6113, 6114, 6881-6999

2. Повышение приоритета для ACK/SYN и др маловесных пакетов.

Со вторым пунктом надо быть осторожнее, т к неизвестно что именно создает большее кол-во ACK/SYN пакетов. Вполне возможно что торрент превосходит в этом WoW. По ACK точно, по SYN не знаю... мерить надо.

В этих решениях меня смущает:
1. Возможность "повесить", например, торрента на указанные порты.
2. Невозможность "типизации" приложения, трафик которого проходит по правилу.

1. Да - можно. Тут нужно работать в сторону административных мер. Т е за превышение объема трафика - бан порта и тд. Или понижение приоритета этого порта, против остальных.
2. Увы и ах. Так же как невозможно составить статистику использования например цвета чернил в бумажной переписке. Т е модель OSI в действии - нижние уровни не знаю то, что делают верхние.

Вернемся к 1* и вспомним, что на данный момент различных ММОРПГ на данный момент более чем выше крыши. И типизация трафика для каждого из приложений становиться очень не тривиальна.

Поэтому возможно стоит ограничить именно торренты против всего остального. Если говорить об uTP(Micro Transport Protocol), то можно попробовать вылавливать по сигнатуре пакета. Но тоже не панацея... Как почуют - перейдут на вариант с шифрованием.

P.S.: Также хотелось бы узнать, чем можно собрать камулятивную статистику по трафику, не такую подробную как дают iptables и iptraf.

Netflow? Я не совсем понял термин "камулятивную".

[dduck]

А чем вас не устраивает распределение (деление) канала (трафика) между пользователями, а не между портами? И пусть они, в отведённом им канале, сами решают какие порты более приоритетные, а какие менее. На сколько я понял у вас сейчас трафик делится не между клиентами, а между приложениями (портами) клиентов?

[patrius]

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

Alex2ndr, на данном этапе все реализовано первым способом, т.е. повышением приоритета для трафика по портам

TCP/UDP Ports 3724,1119, 4000, 6112, 6113, 6114

для оговоренного ряда клиентов.

1. Да - можно. Тут нужно работать в сторону административных мер. Т е за превышение объема трафика - бан порта и тд. Или понижение приоритета этого порта, против остальных.

Это очень интересная мысль, т.к. трафик WoW составляет порядка 1 - 5 Мб/час, что для торрента неописуемо МИЗЕР )))

Я не совсем понял термин "камулятивную".

Камулятивной считаю статистику вида: источник-получатель-протокол-число_байт-число_пакетов
К слову, нашел соответствующую опцию в настройке фильтров iptraf.
Netflow обкатываю.

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

[rm_]

Я не совсем понял термин "камулятивную".

Камулятивной

Нету такого слова. Вот такое есть: http://yandex.ru/yandsearch?text=%EA%F3%EC...t=rad&lr=55

[Alex2ndr]

1. Да - можно. Тут нужно работать в сторону административных мер. Т е за превышение объема трафика - бан порта и тд. Или понижение приоритета этого порта, против остальных.

Это очень интересная мысль, т.к. трафик WoW составляет порядка 1 - 5 Мб/час, что для торрента неописуемо МИЗЕР )))

Увы, это тяжелая для реализации мысль. Нужно объединить работу со статистикой трафика и шейпер. Я, в свое время, долго подбирался к этой мысли, но так и не сделал...

Камулятивной считаю статистику вида: источник-получатель-протокол-число_байт-число_пакетов

Тогда точно Netflow. Я ей регулярно пользуюсь - очень удобная штука. А еще можно в какую-нить БД сливать(например в мускуль) - будет совсем хорошо. Одним запросом можно получить почти любую статистику.
Насчет "камулятивной" - знаю камулятивный снаряд, но статистика....

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

Не увлекайтесь Мой(точнее наш) составляет ~1500 строк и весьма сложен в отладке

[patrius]

Alex2ndr, согласен.

Увы, это тяжелая для реализации мысль. Нужно объединить работу со статистикой трафика и шейпер. Я, в свое время, долго подбирался к этой мысли, но так и не сделал...

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

[allez]

Насчет "камулятивной" - знаю камулятивный снаряд, но статистика....

Во-первых, таки все же "кумулятивный", а во-вторых, кумулятивная статистика еще называется накопительной.

[arkhnchul]

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

эмм... не очень хорошо знаю, как там в точности работает шейпер, но некоторое размышление: а если каждому дать некоторую гарантированную полосу, в сумме всех таковых полос общей толщины канала не превышающую, а остальное - уже сверху? Насколько помню, траффик в этой полосе можно как-то выделить и повысить приоритет... Если клиент забьет свою полосу торрентом - ну, ссзб, как говорится.