Как СКАТ поможет уменьшить затраты на аплинк на 25% и при этом повысить QoE?
Если посмотреть на недельный график утилизации канала типичного домового оператора, то можно заметить, что максимум обычно приходится на часы наибольшей нагрузки (ЧНН), когда все отдыхают после рабочего дня и многие проводят свой досуг в интернет: скачивают и смотрят фильмы, музыку, посещают развлекательные порталы и т.п.
Велик соблазн не платить за “лишнюю” полосу, которая нужна всего лишь в течении часа и остальное время все равно не используется. Но если просто не заплатить, то в час пик пользователи заметят проблемы : начнутся лаги при просмотре видео, перестанут открываться сайты, будут тормозить онлайн игры и не проходить IP-звонки. На это оператор не пойдет: ведь это, можно сказать, прайм тайм и пользователям нужен качественный интернет именно в это время. Как же быть? Хочется и сэкономить, и в то же время чтобы пользователь ничего не почувствовал, да еще и спасибо сказал.
Опции СКАТ DPI, которые будем использовать:
Дополнительные Модули:
Разделим трафик на классы в зависимости от используемого протокола. Всего может быть назначено до 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
Теперь во время пиков пострадает только трафик, менее критичный и заметный для пользователей, а работа важных для пользователя онлайн сервисов, проблемы в которых сразу видны, будет осуществляться, благодаря приоритезации, быстрее и с минимальными задержками. Нам удалось снизить требования к ширине канала, а работа с интернет, с точки зрения пользователей, стала шустрее. Бонус: Во время пиков трафика большая нагрузка ложится и на другое используемое оператором оборудование и оно может начать под нагрузкой вносить свои дополнительные проблемы – терять пакеты, увеличивать время отклика и т.п. Внедрение шейпинга СКАТ позволит предотвратить превышение критической нагрузки для оборудования, после которой возникают проблемы, и отложить необходимость его апгрейда на более поздний срок.
Хотите сэкономить на канале еще больше, тогда смотрите описание опции “Кэширование”.