====== Оптимизируем использование Uplink канала ====== {{indexmenu_n>1}} Как СКАТ поможет уменьшить затраты на аплинк на 25% и при этом повысить QoE? ====Начальные условия:==== Если посмотреть на недельный график утилизации канала типичного домового оператора, то можно заметить, что максимум обычно приходится на часы наибольшей нагрузки (ЧНН), когда все отдыхают после рабочего дня и многие проводят свой досуг в интернет: скачивают и смотрят фильмы, музыку, посещают развлекательные порталы и т.п. Пик утилизации канала происходит около 23 часов и обычно длится меньше часа, превышая обычные показатели на 30%. При этом торрент-трафик в это время может занимать до 30% канала, еще около 50% - просмотр online видео, на все остальное приходится лишь 20%. ====Что хотим получить:==== Отложить расширение канала путем оптимизации полосы под разные типы трафика. Велик соблазн не платить за “лишнюю” полосу, которая нужна всего лишь в течении часа и остальное время все равно не используется. Но если просто не заплатить, то в час пик пользователи заметят проблемы : начнутся лаги при просмотре видео, перестанут открываться сайты, будут тормозить онлайн игры и не проходить IP-звонки. На это оператор не пойдет: ведь это, можно сказать, прайм тайм и пользователям нужен качественный интернет именно в это время. Как же быть? Хочется и сэкономить, и в то же время чтобы пользователь ничего не почувствовал, да еще и спасибо сказал. ====Инструменты:==== Опции СКАТ DPI, которые будем использовать: * [[dpi:dpi_options:opt_statistics|Сбор и анализ статистики по протоколам и направлениям]] * [[dpi:dpi_options:opt_shaping|Оптимизация использования внешних каналов доступа]] Дополнительные Модули: * Для приема, обработки и хранения NetFlow [[dpi:dpi_components:qoestor|программный продукт для сбора статистики QoE Store]].\\ * Для визуализации и построения отчетов [[dpi:dpi_components:dpiui|графический интерфейс DPIUI2]].\\ ====Настройка:==== Разделим трафик на классы в зависимости от используемого протокола. Всего может быть назначено до 8 классов, которые СКАТ может использовать для маркировки пакетов как в поле DSCP/TOS IP-заголовков, так и поле приоритет VLAN/MPLS, и далее QOS может управлять внешняя платформа. Но мы рассмотрим случай, когда это делает сам СКАТ. В класс самого низкого приоритета поместим сервисы, которые мы согласны ограничить в часы пик. Обычно это сервисы, скорость которых и так зависит от внешних факторов, пользователь работает с ними не в режиме интерактивности, обычно в фоне. Это закачка файлов через торрент трекеры, сервисы обновления ПО и возможно что-то еще, специфичное для вашего случая. В класс с более высоким приоритетом поместим сервисы online-трансляций, которые обычно имеют возможность адаптироваться к доступной полосе пропускания и выбирать качество, и в класс с самым высоким приоритетом поместим интерактивные сервисы, работу которых пользователь контролирует в онлайн режиме и проблемы с которыми станут сразу заметны: это web браузинг, online игры, IP-телефония (SIP, Skype), в общем для простоты поместим в этот класс все остальное. Для каждого класса ограничим максимальную полосу пропускания, которую может занять трафик данного класса, или положимся на механизм заимствования полосы с автоматическим регулированием, заложенный в СКАТ. В последнем случае СКАТ начнет ограничивать трафик по классам только при приближении утилизации полосы входящего трафика к пороговому значению. Также ограничим полосу снизу, чтобы во время пиков трафик данного класса пострадал лишь в контролируемых пределах. При превышении верхнего ограничения полосы для класса исходящий трафик данного класса ограничивается СКАТ, при этом уменьшение полосы распределяется между абонентами равномерно. В силу двустороннего режима работы большинства протоколов (запрос-ответ, передача-подтверждение) ограничение исходящего трафика приводит к ограничению входящего. В автоматическом режиме регулирования степень этого влияния определяется СКАТ через механизм обратной связи и сначала ограничению подвергается трафик минимального приоритета вплоть до достижения установленного минимального порога. Если такого ограничения не достаточно, то ограничение распространяется на трафик следующего приоритета и т.п. Оба режима позволяют задействовать механизм заимствования, когда неиспользуемая полоса распределяется между классами в соответствии с текущими потребностями и подвергается перераспределению, когда ее начинает не хватать. ==== Пример конфигурации для приведенного выше описания ==== Создаем файл protocols.txt: default cs0 mpeg cs1 bittorrent cs7 Конвертируем protocols.txt в protocols.dscp cat protocols.txt|lst2dscp /etc/dpi/protocols.dscp Добавляем жесткие ограничения по классам в файл конфигурации /etc/dpi/fastdpi.conf, ориентируясь на график со статистикой (простое решение, но далеко не оптимальное) #Limit outbound torrent tbf_class7=rate 50mbit #Limit inbound torrent tbf_inbound_class7=rate 50mbit Или позволим DPI выполнять приоритезацию протоколов по иерархии классов самостоятельно в пределах всей доступной полосы (требует подбора параметров верхних границ для учета всплесков трафика, чтобы ограничение происходило по приоритетам dpi, а не полкой, связанной с физическими возможностями канала, за отправную точку возьмем ширину канала минус 10%, для торрентов - минус 50%) htb_inbound_root=rate 180mbit htb_inbound_class0=rate 100mbit ceil 180mbit htb_inbound_class1=rate 50mbit ceil 180mbit htb_inbound_class2=rate 8bit ceil 180mbit htb_inbound_class3=rate 8bit ceil 180mbit htb_inbound_class4=rate 8bit ceil 180mbit htb_inbound_class5=rate 8bit ceil 180mbit htb_inbound_class6=rate 8bit ceil 180mbit htb_inbound_class7=rate 10mbit ceil 100mbit htb_root=rate 180mbit htb_class0=rate 100mbit ceil 180mbit htb_class1=rate 50mbit ceil 180mbit htb_class2=rate 8bit ceil 180mbit htb_class3=rate 8bit ceil 180mbit htb_class4=rate 8bit ceil 180mbit htb_class5=rate 8bit ceil 180mbit htb_class6=rate 8bit ceil 180mbit htb_class7=rate 10mbit ceil 100mbit Рестартуем DPI service fastdpi restart ====Результат:==== Теперь во время пиков пострадает только трафик, менее критичный и заметный для пользователей, а работа важных для пользователя онлайн сервисов, проблемы в которых сразу видны, будет осуществляться, благодаря приоритезации, быстрее и с минимальными задержками. Нам удалось снизить требования к ширине канала, а работа с интернет, с точки зрения пользователей, стала шустрее. Бонус: Во время пиков трафика большая нагрузка ложится и на другое используемое оператором оборудование и оно может начать под нагрузкой вносить свои дополнительные проблемы – терять пакеты, увеличивать время отклика и т.п. Внедрение шейпинга СКАТ позволит предотвратить превышение критической нагрузки для оборудования, после которой возникают проблемы, и отложить необходимость его апгрейда на более поздний срок. Хотите сэкономить на канале еще больше, тогда смотрите описание опции [[dpi:dpi_options:opt_cache|“Кэширование”]].