[ivan999]

Приоритетнее тот трафик, который должен идти реалтайм - это скайп, видео, онланй игры. Серфинг - менее приоритетный. И самый низкий приоритет - даунлоад файлов по любому протоколу.

 

 

То, что веб-серфинг можно отличить от веб-тв по connection-bytes - это ясно. Но как отличить с помощью connection-bytes веб-тв от даунлоада больших файлов через веб. Хотя я бы хотел даунлоуду через http и видео через http - дать разные приоритеты (диаметрально).

 

Я понимаю, что QoS корректно работает при относительно не большом оверхеде.

 

___

Я понял - без анализа пакетов на L7 - пометить типы трафика не представляется возможным.

 

Буду уяснять теперь 2 вещи - на сколько реально действуют сигнатуры по приведнным ссылкам, как часто они обновляются.

 

И насколько анализ содержимого пакета напрягают систему (как бы не произошел отрицательный эффект).

 

Или все это фигня - и просто надо расширять аплинк и не париться. Если нет денег и/или возможностей на апгрейд/добавление бордеров - продаться конкурентам или закрыть деятельность?

 

P.S. Все же вызывает сомнения в успехе анализа шифрованного трафа торрентов и скайп.

Но я попробую.

Изменено 20 февраля, 2011 пользователем ivan999

[disappointed]

Серфинг - менее приоритетный.

Шутка? "Странички тормозят" - первое что замечают даже домохозяйки.

[NiTr0]

я не совсем понял вас - вы понимаете о том что в тике QoS работает только когда канал забит на 100 и выше

процентов? то есть если у вас канал забит на 95% то можете ни чего не выделять, приоритета не будет

все будет идти согласно шейпера и на полную катушку...

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

Собссно - то, что резаться траффик начинает только тогда, когда он превышает некоторый заданный порог - не открытие.

 

И если в микротике для каждого класса траффика не предусмотрены пороги - это проблема микротика. Я "прочему траффику" отвел где-то 80% от ширины канала в максимуме, гарантированных - что-то порядка пары десятков мбит. ХТТП - наоборот, максимум 90%, гарантированных - 40-50%. Собссно сoотношение гарантированных полос и определяет приоритет при оверкоммите.

Изменено 20 февраля, 2011 пользователем NiTr0

[ivan999]

Шутка? "Странички тормозят" - первое что замечают даже домохозяйки.

Они тормозят, но открываются. А тормозящий голос или видео или игра - это совсем приводит к разбиванию клавиатруы, как минимум : ))

 

А вовсем виноваты качки?

 

Я и не призываю вам браузинг в самый низ определить. Но он однозначно стоит на ступеньки ниже - чем реалтайм трафик. Ну и главное торренты в конец списка определить.

 

Кстати, почитал я по ссылкам, которые давали на layer7 сигнатуры.

И там черным по белому на чистом английском написано (перевожу):

 

Skype использует как TCP и UDP. UDP датаграммы не (совсем) зашифрованны / запутанны, так что можно их обнаружить. TCP соединения, с другой стороны полностью зашифрованы (очень хорошо запутанны, на самом деле), поэтому они будут довольно трудно опознаны с заказного программного обеспечения и практически невозможно с L7-фильтр. Блокировка UDP также не достаточно, чтобы заблокировать Skype.

 

(сорри за перевод - все вопросы к гугл транслейт : )

 

Я так понял - смысл в том, что просто поиском в пакете сигнатур - малоэффективно и часто может затронуть полезный трафик. Вопрос решается более сложными алгоритмами. Т.е.

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

 

Тоже самое касается и торрента.

Для мелких "не очень богатых" провайдеров покупать DPI - дороговато?

 

Идем дальше - там про битторент одна сигнатруа, и написано что протокол работает через TCP. И последняя модификация этой странички - 2007 год.

Сейчас 2011 год. И торрент вовсю юзает UDP.

Я понимаю, что естькуча других мест , где можно найти свежие сигнатуры (хотя бы здесь на наге), но в целом ссылка

http://l7-filter.sourceforge.net/protocols

явно сильно не поможет в реальной работе.

 

P.S. Пока читаю дальше - OpenDPI.org - что нам это даст....

Изменено 20 февраля, 2011 пользователем ivan999

[ivan999]

я не совсем понял вас - вы понимаете о том что в тике QoS работает только когда канал забит на 100 и выше

процентов? то есть если у вас канал забит на 95% то можете ни чего не выделять, приоритета не будет

все будет идти согласно шейпера и на полную катушку...

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

Собссно - то, что резаться траффик начинает только тогда, когда он превышает некоторый заданный порог - не открытие.

 

И если в микротике для каждого класса траффика не предусмотрены пороги - это проблема микротика. Я "прочему траффику" отвел где-то 80% от ширины канала в максимуме, гарантированных - что-то порядка пары десятков мбит. ХТТП - наоборот, максимум 90%, гарантированных - 40-50%. Собссно сoотношение гарантированных полос и определяет приоритет при оверкоммите.

Стоп. Давайте не переходить в холивар. Не важно - бсд у вас, линуха или основанные на них другие продукты типа микротика (кстати - Нормально на Тике - кос работает и настраивается, в том числе и пороги)

Наша дискуссия в другом -

 

1. составить план - типы трафика и сервисов и их приоритеты.

2. Самое сложное - как пометить трафик , в том смысле - что это сложно - найти признаки протоколов L7 - например шифрованный скайп и торрент с рандомными портами , и периодически изменяющимися сигнатурами.

Изменено 20 февраля, 2011 пользователем ivan999

[disappointed]

Я делал так на ingress апстримов.

 

1. Отфильтровать uTP чтобы не мешался (почему - см. далее)

2. Сети корпоративных клиентов в максимально возможный приоритет (давят всех и вся при дефиците полосы).

2. Высокий приоритет - весь UDP, пакеты с портами источников 1-1024, 5190, 8080.. (список позиций на 30, пополнять по жалобам).

Сетки игр вроде WoW, Linage итд (длинный список). Весь ICMP.

3. Весь остальной трафик в остататочный класс. В нём большей частью tcp битторрент.

 

[ivan999]

Короче, всякие там DPI - тоже не панацея, а временная небольшая победа.

 

В итоге, если все массово будут скупать и внедрять разные DPI , типа Cisco SCE - это только ускорит массовый переход к шифрованию трафика юзерами. (например торрент клиенты будут сразу из коробочки с включенным шифрованием - чтобы домохозяйкам было лучше обходить наши DPI : ))

 

Я тут как раз на зимней сессии сдавал основы теории информации. Так там как-раз одно из важнейших требований к криптоалгоритмам - при использованиии одного и того же ключа - один и тот же блок исходных даных после зашифровывания должен каждый раз давать разный зашифрованный код. (и таки так и есть).

Так что сигнатуры искать не получиться. Добавим сюда длинные ключи и их частую смену - и все. Привет сетевая нейтральность.

И еще одно важное замечание - описание стандарта криптоалгоритма никак не должно влиять на криптостойкость. С точки зрения математики - даже если вы знаете функцию зашифровывания (а она такая же как и расшифровывания) - не зная приватного ключа - можно только брутфорсом, а в случае достаточного длинного ключа - на это уйдет много-много времени и вычислительных ресурсов.

 

 

 

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

 

Господа - на данном этапе развития своей сети, с учетом всех нюансов, в том числе той ниши и масштабов, которые я занимаю на рынке (а это скромные 10 000 физиков) - я пока не буду трогать и дальше юзерский трафик - не дропаю , того, чего не знаю (а то можно и полезный траф подропать - ибо каждый день следить за все новыми протоколами L7. игрушками, софтинами - это жесть), не трогаю pps, не трогаю connection byte. Только минимум основных стандартных правил - типа дропать заведомо инвалидные конекшены, также можно подрезать количество конекшенов с одного IP в разумных пределах, и заведомо потенциально проблемные порты дропнуь, типа виндовские шары, RPC и т.д.. Может еще акуратно глянуть - что сделать с входящими коннектами на белые юзерские IP. Может только разрешать по требыванию, или на некоторых известных полезных портах, или на тарифах - где это точно надо. Хотя это тоже все спорно.

 

Ну и постоянно расширять аплинк. В конце концов - юзеры платят нам не за то - чтобы я им дропал торрент-трафик. А дальше будет видно.

 

 

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

Провайдеры ШПД придумали анлимы, чтобы захватыать рынок, бурно развивающийся. Высококонкурентный ? : ) Но и контент был не настолько тяжел 10 лет назад. Только только в постсоветском пространсве юзеры начали юзать DVD в небольших городах в провинциях : )))))

Сейчас цены падают, ARPU паает, скорости растут, потребление трафа - растет Что дальше?

 

Сами себе могилу роем?

Я что-то не вижу, чтобы те же мобильные операторы ввели реальные анлимы даже на голосовой трафик по таким низким ценам.

Хотя у них тоже жесткая конкуренция и они сильно свой ARPU снизили за последние несколько лет.

 

(Все это с поправкой на регионы, в МСК , конечно - все не так?)

 

 

Скорее всего - решение будет больше в плоскости экономической.

Хоть и неблагодарное это дело - предсказывать будущее - камни полетят совсех сторон. Но я попробую.

Например, через 7-10 лет. Ethernet Провайдер будет предоставлять такие тарифы

 

$49,99 - скорость доступа к Сети - на уровне доступа порта (если еще бдут 100Мб порты- значит до 100, и частично много кто внедрит гигабитный порты в кваритру)

Далее идет маленькая звездочка и мелким шрифтом в договоре "При превышении объема трафика в месяц более 100Tb - скорость порта нижается до 10М/с

 

Ну и далее аналогично:

$39,99 - скорость доступа к Сети - на уровне доступа порта

Далее идет маленькая звездочка и мелким шрифтом в договоре "При превышении объема трафика в месяц более 100Tb - скорость порта снижается до 10М/с

 

$29,99 - скорость доступа к Сети - на уровне доступа порта

Далее идет маленькая звездочка и мелким шрифтом в договоре "При превышении объема трафика в месяц более 50Tb - скорость порта снижается до 5М/с

 

$19,99 - скорость доступа к Сети - на уровне доступа порта

Далее идет маленькая звездочка и мелким шрифтом в договоре "При превышении объема трафика в месяц более 25Tb - скорость порта снижается до 2М/с

 

и соц пакет : )))

и соц пакет : )))

 

$9,99 - скорость доступа к Сети - на уровне доступа порта

Далее идет маленькая звездочка и мелким шрифтом в договоре "При превышении объема трафика в месяц более 10Tb - скорость порта нижается до 1М/с

 

Это анлимы? ДА!!!!

 

Далее рассуждаем. Никто не будет шейпить и приоритезировать такие скорости, тем более в едином центре (NAS, BRAS). Будет только умный доступ и скорость будет рубиться на ближнем конце - на порту свичей доступа - с помощью SNMP.

 

Никто не будет пытаться определять тип трафика по сигнатурам : ) - с такими объемами, скоростями, с шифрованием трафика - с целью его приортезации. Полный сетевой нейтралитет.

 

Будут только железки для обнаружения DDOS атак, для аналитиков, для спецслужб - и все они будут пытаться анализировать только отзеркалированный траф.

 

Будет IPv6.

 

 

Так что я считаю в долгосрочной перспективе - проигрышной идею анализа пакетов на уровне L7.

(В сетях с коммутацией пакетов)

 

 

Фантастика?

Тогда нужно придумать что-то с технологией коммутациеи пакетов для осуществления стабильности и рпедсказуемости выдиления гарантированной полосы для сервиса, для клиента. DSCP и другие метки - не предлагать. Проблема таже - как пометить тарфик, как его анализировать?

 

Предложите свое видение.

 

 

Я делал так на ingress апстримов.

 

1. Отфильтровать uTP чтобы не мешался (почему - см. далее)

2. Сети корпоративных клиентов в максимально возможный приоритет (давят всех и вся при дефиците полосы).

2. Высокий приоритет - весь UDP, пакеты с портами источников 1-1024, 5190, 8080.. (список позиций на 30, пополнять по жалобам).

Сетки игр вроде WoW, Linage итд (длинный список). Весь ICMP.

3. Весь остальной трафик в остататочный класс. В нём большей частью tcp битторрент.

 

 

3. А также TCP скайп, TCP Web ТВ , TCP разные ютубы, и много чего еще важного TCP, о котором вы можете не догадываться?

Да и просто даже TCP web-серфинг попадает в самый низкоприоритетный класс?

 

 

Ну, не знаю, либо я что-то не так понял - либо мне не очень подходит такой план для QoS

Изменено 21 февраля, 2011 пользователем ivan999

[NiTr0]

3. А также TCP скайп, TCP Web ТВ , TCP разные ютубы, и много чего еще важного TCP, о котором вы можете не догадываться?

Да и просто даже TCP web-серфинг попадает в самый низкоприоритетный класс?

Веб тв, ютубы и прочее идут во 2й класс. Потому как нижние порты. Скайп - туда же, ибо он UDP пользует штатно, а TCP - при невозмоджности коннекта по UDP ну и + ессно для авторизации.

Ессно, всегда держать канал в полке некошерно, но вот для сглаживания пиков - приоритезация просто необходима. Иначе - при каждом подобном пике будет шквал звонков мол "скайп не работает, странички не открываются/открываются по 5 минут, спидтест вместо заявленых XXX мбит показывает 100 кбит, за что деньги плачу". Зато качкам будет хорошо, да.

[ivan999]

сделайте приоритет для трафика на адреса популярных спидтестов и для icmp : )))

[sherwood]

ivan999

хорошо, тогда прокомментируйте мне такую вымышленную ситуацию:

например имеем канал 100Мбит\с онлайн клиентов 100 с тарифом 1Мбит\с

и грузят канал на всю свою полосу...

как бы тут все должно по вашему работать как и положено и наверное это правильно,

далее подключается еще 100 онлайн клиентов шейпер ровно раздает всем по 500Кбит\с,

так вот скайпу нужно imxo наверное 300Кбит\с что бы нормально разговаривать а у клиента

500Кбит\с так вот почему вы считаете что при таком раскладе скайп должен тормозить?

тут даже QoS не нужен, тормоза будт из-за того если например ваше оборудование не

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

"баранам" такое количество не пропускает внешний провайдер...

есть и в этом опыт два одинаковых канала, только один по ADSL а второй выделенкаи оба 15Мбит\с,

так вот ADSL загибается при полностью забитом канале и скорее всего от количества "сессий" udp,

потому что "качки" на своих 1Мбит тарифах умудряются делать свыше 400 "соединений" с одного

компьютера а их ведь не один.... тогда как канал по выделенке в таком же режиме справляется со

своей задачей...

по этому на ADSL делаем QoS и загоняем весь не нужный трафик под лавку какой только можем выловить

и работаем с клиентами по поводу выявления какой трафик им пропустить без тормозов...

и (!) это не проблема QoS и нашего оборудования, а проблема выше...

[NiTr0]

далее подключается еще 100 онлайн клиентов шейпер ровно раздает всем по 500Кбит\с,

так вот скайпу нужно imxo наверное 300Кбит\с что бы нормально разговаривать а у клиента

500Кбит\с так вот почему вы считаете что при таком раскладе скайп должен тормозить?

В зависимости от того как шейпер шейпит полосу внутри класса на соединение - по сессиям (как при дисциплине SFQ на классе), по ИП (как для ESFQ), или же - рандомно дропая пакеты (как при отсутствии дисциплин поверх класса). В первом случае - качок высосет всю полосу, а серфер не получит почти ничего (ибо делится по сессиям). В третьем - опять-таки качку дропы пофиг, серферу - снижение скорости, но не так критично. Во втором же случае - канал будет распределяться независимо от кол-ва сессий, но это - идеальный случай, и ESFQ в ядро ванильное не входит. Как шейпер на микротике реализован - я не знаю.

[ivan999]

 

 

Я еще раз повторю в кратце логику рассуждений (пока нет смысла обсуждать частности, и разные pps)

Cуть в том, что я про будущее, а не про вашу вымышленную ситуацию ---> контент тяжелеет очень быстро, сможем ли мы так быстро расширять аплинки? А вот если не сможем - вот тогда потенциальный трафик от клиентов в ЧНН будет больше, чем реальная пропускная способность. Вот тогда и нужен QoS (до этого момента QoS не нужен - как мы уже все уяснили). А дальше, чтобы сделать приоритезацию по типу трафа - нужно разделить трафик на типы. Вот эту проблему я и поднял. Определять трафик глубоким анализом поведения этого самого трафика и анализ содержимого по сигнатурам - насколько это рационально и перспективно? Успех в этой области будет временным - тем быстрее будут усложняться и меняться алгоритмы шифрования и запутывания разных скайпов и торрентов.

Поэтому может параллельно с расширением аплинков придем к эконмическим мерам ? - и все таки будем деньгами ограничивать юзерам объемы трафа в разумных пределах. Типа - хочешь качать миллион blu-ray образов в месяц - плати - на тебе тариф дороже. Хочешь только по 2 часа вечером ютуб сореть - плати меньше. В обоих случаях цену за трафик не считаем, т.е. это все же анлимы, но при превышении весьма и весьма приличных объемов в месяц - скорость доступа на порту абонента - снижается.

 

 

Но, возможно, все будет так - расширять аплинки вечно - никто не помешает - технологии развиваются, уплотнение в оптике, новые алгоритмы модуляции, сжатия. Да ипросто волокна рядом больше прокладывать : ))

 

Да и возможно не все так печально будет с глубоким анализом на уровне L7 внутри пакетов - всетаки вычислительные мощности растут. Глядишь - рано или поздно смогут создать коммерческие приборы на несколько порядков более производительные чем полупроводниковые приборы (типа квантовые вычисления (вместо электрических сигналов - световые).

Лаборатории не сидят на месте - а все ближе приближают эти дни....

Изменено 21 февраля, 2011 пользователем ivan999

[sherwood]

Как шейпер на микротике реализован - я не знаю.

очереди PCQ, справляется достаточно хорошо, и качек получит свои 500Кбит\с

и серфер если сделает тест на скорость получит тоже самое и странички и скайп работает

без задержки...

почитать можно тут - PCQ

 

ivan999

думаю что да, при таких скоростях железки нужны мощные, которые способны обрабатывать трафик для приоритета

и не тормозить поток... и соответственно нужно еще по каким то признакам разобраться с идущим трафиком,

а все чаще и чаще он шифруется...например все чаще пользователи создают VPN туннели со своим рабочем

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

Изменено 21 февраля, 2011 пользователем sherwood

[Saab95]

Самое простое и действенное решение, создать что-то типа глобальных сертификатов приоритетов трафика. Которые нельзя будет подделать и все сетевое оборудование будет обязано понимать их и расставлять трафик в соответствии с приоритетами. Я не понимаю, почему такое не сделали в IPv6.

 

Будет создан классификатор программ, в котором четко указано назначение программы, генерируемый ей трафик и т.д.

 

Например скайп получит для своей программы сертификат с типом трафика с высоким приоритетом, потому что используется для связи по голосу и видео.

 

Игры получат комбинированный сертификат, для обмена данными с игровым сервером, будет высокий приоритет, для закачки обновлений - низкий.

 

Всякие там файлообменные программы получат самый низкий приоритет.

 

Все другие программы, у которых нет сертификата, будут так же идти по самому низкому приоритету.

 

А далее уже не важно, шифрует программа трафик или нет, весь ее трафик будет идти с приоритетом, указанным ее создателем/сертификатором.

[ivan999]

Самое простое и действенное решение, создать что-то типа глобальных сертификатов приоритетов трафика. Которые нельзя будет подделать и все сетевое оборудование будет обязано понимать их и расставлять трафик в соответствии с приоритетами. Я не понимаю, почему такое не сделали в IPv6.

А я понимаю. Это невозможно. Начиная от сложности технической реализации на всем оборрудовании и софте, далее - чтобы все договорились и согласились, и заканчивая - неизбежными злоупотреблениями и подделками под другой тип трафика.... А так же прощай сетевой нейтралитет, прощай свобода. Китай и прочие диктатуры будут рубить легко нежелательный траф - тот же скайп. Юзерам и скайпу - это не надо. Им надо максимально усложнить свое обнаружение.

 

Пусть уж лучше будет сетевой нейтралитет. Как нить мы уж будем гонять по каналам просто нули и единицы - не вникая в их наполнение.

Изменено 21 февраля, 2011 пользователем ivan999

[NiTr0]

Определять трафик глубоким анализом поведения этого самого трафика и анализ содержимого по сигнатурам - насколько это рационально и перспективно?

Глубокий анализ - абсолютно бесперспективен ИМХО.

А вот кое-какая приоритезация (пускай и не идеальная), позволяющая в случае оверкоммита в ЧНН хоть как-то улучшить прохождение высокоприоритетных видов траффика (пускай и не всех) - полезная. Ведь в один день в ЧНН скажем канал 500 мбит, в следующий - внезапно становится 600-650 МБит. Либо - при условии наличия толстых каналов, приход домой всего 3-4 торрентоводов с работы внезапно поднимает даунлоад эдак на 200-300 мбит, и вполне может упереть канал в полку. Хоть и на короткое время (пока они свой BDRip выкачают), но при этом неудобства при отсутствии какой-либо приоритезации будут испытывать все.

Собссно из этого и исходим в выборе методов шейпинга.

[disappointed]

Ведь в один день в ЧНН скажем канал 500 мбит, в следующий - внезапно становится 600-650 МБит.

Можно вообще научить систему мониторинга при подходе к "полке" реконфигурить шейперы на клиентов чтобы избегать этой ситуации.

Тогда и мучений с классификацией не будет, а снижения по скорости на 5-10% на 2-3 часа мало кто заметит, если не будет явных лагов.

[NiTr0]

Можно вообще научить систему мониторинга при подходе к "полке" реконфигурить шейперы на клиентов чтобы избегать этой ситуации.

Тогда и мучений с классификацией не будет, а снижения по скорости на 5-10% на 2-3 часа мало кто заметит, если не будет явных лагов.

Это справедливо для тощих каналов. Когда у юзера канал в 20-50-100 мбит - 10% ничего не сыграют.

[bekzep]

dobrii vremeni sutok. unas dve RB450G soedineni linkami ubiquit rocket m5.rostoenie mejdu roketami 2,4km. vecherom internet rabotaet ochen medlenno,ping 1500mc-4000mc. kagda otkluchau vse porti krome 80 i 53 vse ochen xorosho,no veto vremia ne rabotaet online prilojenii,naprimer online poker,slot,ruletka i nashi klienti abiavlaet voinu,podskajite pajalusta chto nado sdelat.mojet ogronichit sesii i kak nado eta sdelat,ili podskajite port dlya online prilojenii chtobi s 80 i 53 portom otkrivat i etot port.

sposibo za ranee