Для чего нужен планировщик пакетов qos
Что такое QoS: а так ли он нам нужен?
Всем привет! QoS (Quality of Service) – распространенная технология приоритизации трафика, сосредоточенная вокруг предоставления трафика находящимся в сети обслуживаемым классам. В IT-среде термин описывает соответствие телекоммуникационной связи заданному соглашению (с провайдером или оператором) и помогает определить скорость и способ прохождения IP-пакетов между источником и адресатом.
Модели обеспечения и механизмы работы QoS
Литературное определение QoS выглядит так: «способность построенной сети передавать заданный трафик за предсказуемый (или ограниченный) промежуток времени, без потерь и задержек».
Часто идею технологии трактуют некорректно, представляя QoS в качестве средства по расширению полосы или канала. На деле же «Quality of Service» помогает правильно распределять нагрузку и управлять ограниченными ресурсами. И оценить результаты проделанной работы помогут метрики, описывающие качество сети:
Если рассматривать QoS на наглядном, но далеком от IT примере, то канал связи, подвластный потерям, задержкам и колебаниям, можно представить в качестве водопроводной трубы, а пропускную способность – описать параметрами «длина» и «диаметр».
Но в момент передачи данных (сетевых IP-пакетов), кроме «физических» особенностей на ту же скорость «доставки» влияет и перегруженность «трубы» (канала), приводящая к эффекту «бутылочного горлышка». Пакеты банально не достигают цели, так как находятся в очереди, растягиваются или выдаются частями.
На маршрутизаторах и роутерах проблема решается с помощью метода FIFO – пакеты, выпущенные первыми, достигнут цели без очереди. Но чем интенсивнее трафик, тем больше недостатков у метода: заторы и выгружаемые из памяти пакеты игнорируются, теряются или пропускаются. На помощь в подобных ситуациях и приходит «качество обслуживания QoS», способное выстроить логичную очередь и раздать необходимые команды. В домашних условиях QoS применяется для выдачи приоритетов пакетам VoIP и снижения необходимости в FTP или SMTP.
Часто при построении «умной» очереди приходится отталкиваться от показателя «тип сервиса» ToS (Type Of Service). Привычно выделяют три модели:
Настройка приоритизация
Технология QoS необходима во многих сетевых службах и сервисах: потоковое мультимедиа, VoIP и настроенные видеоконференции, новостные порталы, где важен определенный уровень безопасности с минимальными значениями джиттера и задержки.
И, если раньше подбирать параметры и выдавать приоритеты приходилось вручную, обращаясь к командной строке, то в новых маршрутизаторах уже появились отдельные шаблоны под каждую из задач. И даже обращаться в поддержку к диспетчеру уже не требуется, все контролируется вручную.
Выбираются шаблоны в настройках маршрутизатора (адрес 192.168.1.1 или 192.168.0.1), в разделе с NAT / QoS. Перед доступом к параметрам приоритизации придется активировать параметр «качества обслуживания». Если шаблоны не предусмотрены, подбирать значения для служб и сетей придется вручную.
Управление QoS на платформе Windows
QoS – целая пачка технологий, без которых современная сеть работает крайне плохо, а ряд задач не может выполнить вообще. Это и логики классификации трафика, и схема marking’а, когда данные помечаются путём помещения в заголовок канального или сетевого уровня соответствующих пометок, и управление логикой работы очередей, когда надо отправить несколько потоков данных через ограниченный по пропускной способности интерфейс, и шейпинг, и многие другие дисциплины, без которых целостная картина просто не получится. Фундаментально это изучается разве что на курсе Cisco QOS 2.5, да и то – в пять дней не всегда влезаем, материала там много.
Однако, сетевые настройки Windows в плане “глубже, чем просто айпишник назначить”, обычно являют собой что-то мистическое для администратора (да и для большинства тренеров Microsoft тоже, т.к. сетевые вопросы в авторизованных курсах Microsoft рассказываются крайне минималистично). Хотя ничего ужасного в сетевых технологиях нет, скорее, наоборот – зачастую бытует мнение, что “в Windows этого нет”, базирующееся на глубоком выводе о том, что говорящий это не нашёл за 10 секунд.
Предположим, что Вы уже знаете сетевые технологии на базовом уровне, хотя бы слышали про ethernet, 802.1Q и формат IP-пакета. Если не слышали – имеет смысл послушать наш курс Cisco ICND1 3.0, это бесплатно. Конечно, лучше изучить QoS основательно, но это, в принципе, не строго необходимо для восприятия данного материала.
QoS в Windows Server 2012 и других версиях ОС
Включаем поддержку QoS в сетевой подсистеме Windows
Для того, чтобы маркировать и CoS и ToS, у Windows есть специальный сетевой компонент, который так и называется – QoS Packet Scheduler. Установите его и включите на всех сетевых интерфейсах, на которых планируется управление QoS.
QoS для старых версий Windows – Windows XP и Windows Server 2003
Для поддержки QoS в NT 5.1 / NT 5.2 Вам также необходимо в явном виде включить поддержку маркировки ToS – по умолчанию там она выключена. Это делается путём изменения DWORD32 значения DisableUserTOSSetting у ключа реестра HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters на нуль. Если такого значения нет – создайте его и обнулите в явном виде, а после перезапустите систему – без этого параметр не применится и ОС будет продолжать игнорировать заданную приложениями через Winsock опцию IP_TOS.
Теперь продолжим про настройки, общие для разных версий Windows.
Если посмотреть внимательно, то этот компонент по сути и есть NDIS-драйвер:
Далее. Для того, чтобы мы могли указывать не только L3-параметры QoS (которые в IP-заголовке в поле ToS), а ещё и L2-параметры (которые в 802.1Q заголовке, в части, называемой 802.1p), нам надо включить на сетевом адаптере поддержку 802.1Q. Это будет выглядеть по разному в разных сетевых адаптерах – но примерно так:
Если такого пункта нет, то ставить метки CoS в кадре 802.3 некуда. Это уменьшит практическую пользу от настроек QoS, но, в общем-то, не уберёт её. Суть в том, что обычный хост не добавляет этот заголовок в 802.3-кадр, и эта настройка, в зависимости от сетевого адаптера, может обозначать разное – или “принимать кадры с 802.1Q-заголовком и анализировать его, в том числе и 802.1p”, или “делать это только в случае, когда мы отправляем кадр с меткой 802.1Q”. Смотрите детальнее специфику своего сетевого адаптера, общий совет тут выдать можно только один – если заголовка 802.1Q нет, то данные о качестве обслуживания можно добавить лишь в L3-заголовок.
Если Вы проделали всё вышеуказанное – система готова к тому, чтобы реализовывать заданные Вами параметры QoS. Теперь надо их задать.
Глобальные настройки QoS в Windows
Глобальные настройки QoS коснутся двух моментов – того, как будет обрабатываться входящий TCP-трафик, и того, как будут взаимодействовать политики QoS и установки QoS на уровне отдельных приложений. Находятся они в объекте групповой политики, точнее – в Computer Configuration / Windows Settings / Policy-based QoS, в контекстном меню Advanced QoS Settings…, вызываемом нажатием правой кнопки мыши. Рассмотрим их по отдельности.
Настройки Inbound TCP Traffic
Выглядеть они будут примерно так:
Это, по сути, никакой не QoS, а управление окном TCP для трафика в сторону данного хоста. Идея в том, что данная настройка напрямую влияет на то, какое максимальное значение receive window будет предлагаться при работе TCP-соединений. Начиная с NT 6.0, в Windows появилась человеческая поддержка окна TCP размером более 64К, вот данная политика и позволяет задать это максимальное значение окна централизованно. При задании уровня 0 окно будет ограничено 64КБ, при 1 – 256КБ, при 2 – 1МБ, а при 3 – 16МБ.
Учтите, что чем больше окно, тем реже TCP отправляет подтверждения о приёме, и тем менее “динамично” он реагирует на форс-мажорные ситуации, когда сегмент TCP задерживается или теряется. Чем меньше – тем быстрее реакция, но больше служебного трафика. В общем и целом в надёжных сетях при передаче больших объёмов данных (например, файл-сервер в локальной сети офиса) целесообразно устанавливать значение выше, а при сценарии “По tcp-сессии идёт не очень много данных, но у канала варьируется латентность и качество” – меньшее значение.
Настройки DSCP Marking Override
Выглядеть данные настройки будут так:
Это достаточно простая настройка, некий аналог mls qos trust cos в Cisco IOS. Суть – разрешать или нет приложениям, которые умеют метить трафик, делать это. Если выберете, что в явном виде можно – то когда приложение будет устанавливать поле ToS, то политики QoS будут игнорироваться, если нет – то наоборот; приложения на данном хосте будут безрезультатно вызывать функции API по маркировке трафика, а вся маркировка будет идти по явно указанной в политиках логике.
Давайте теперь посмотрим, как эти политики формируются.
Настраиваем политики QoS
Находятся они там же – Computer Configuration / Windows Settings / Policy-based QoS. Рассмотрим создание политики.
Первое, что надо учесть – ограничения политик. Под них может подпадать только трафик TCP и UDP. Другие IP-протоколы ограничить не получится. Плюс есть дополнительные настройки для HTTP-сессий, что улучшает ситуацию. Поэтому штатное решение по управлению качеством обслуживания затрагивает не весь возможный трафик, но в подавляющем большинстве случаев является достаточным. Приоритет исходящего IPSec или PPTP-трафика, например, задать не получится.
При создании политики первым делом надо будет указать её название (произвольное, технического назначения не имеет), значение DSCP и ограничение на полосу. Давайте чуток вспомним, что это и зачем.
QoS – это большая пачка технологий. Это и то, как помечать пакеты и кадры (Marking), и то, как формировать очереди для отправки нескольких потоков с разными метками через один интерфейс (Queuing), и то, как сбрасывать из этих очередей лишний трафик (Shaping). Когда речь идёт о сегменте сети, в котором эта логика единообразна и продумана (трафик X помечается на всех устройствах однотипно и однотипно же добавляется в очереди), говорят о том, что это – домен QoS. Мы будем рассчитывать на то, что установки, которые мы сейчас делаем через групповую политику, будут аналогично восприниматься сетевыми устройствами – это уже out of scope для этой статьи, но для полноценной поддержки QoS в организации это сделать нужно. Иначе нет никакого особого смысла тщательно классифицировать трафик, потом помечать, а потом на первом же коммутаторе в процессе отправки в uplink валить всё в одну кучу с логикой FIFO.
Когда деревья были большими – 31 год назад, в 1981 году – в заголовке IP-пакета тоже, как и сейчас, было одинокое поле размером с байт и с названием ToS – Type of Service. То, что делать с этим полем, написали в RFC 791 и назвали IP Precedence. Делать предлагалось многое – помечать каждый пакет “уровнем важности” от 0 до 7, используя 3 бита этого поля, и добавлять пожелания вида “если есть возможность, отправь трафик по каналу с меньшей латентностью / большей надёжностью / большей номинальной полосой пропускания”, используя ещё 3 бита. Два бита отложили до лучших времён. Как-то так:
[ Бит приоритета N0 | Бит приоритета N1 | Бит приоритета N2 | Бит задержки | Бит толщины | Бит надёжности | Unused | Unused ]
Потом ещё чуток подумали и задействовали дополнительный бит, добавив 4е пожелание – “чтобы через тот канал, который подешевле в плане денег” – RFC 1349. Итого остался один незадействованный бит, получилось 8 уровней приоритета трафика плюс 4 бита и их комбинации влияли на выбор “при прочих равных условиях”.
Предполагалось, что этого хватит. Стало так:
[ Бит приоритета N0 Бит приоритета N1 Бит приоритета N2 Бит нежелательной задержки Бит толщины (канала) Бит надёжности По любви или за деньги Unused ]
Хорошо заметно, что логическую модель пожеланий разрабатывала женщина.
Но 14 лет назад, в 1998 году, парни из EMC и Cisco решили, что не хватит, и придумали ощутимо более гибкую систему, притом сразу и для ToS в IPv4, и для его потомка – Traffic Class в IPv6. Назвали её Differentiated Services. Система задействовала уже все 8 бит поля ToS – 6 на идентификатор класса (DSCP), и 2 на сигнализацию в случае заторов в сети (ECN). Как раз этот, более современный способ, и используется в политиках Windows. Метки, заданные по DSCP, более многочисленные, поэтому разбиваются на несколько групп.
DSCP-метки группы CS – Class Selector’ы
DSCP-метки группы AF – Assured Forwarding
Эти метки, логика которых есть в RFC 2597, уже интереснее – они содержат по 2 значения, x и y, поэтому записываются в читаемом варианте как AFxy.
Первое значение – x – будет обозначать класс трафика. Классов определено 4 – от единицы до четвёрки. Их иногда называют словами – единица = бронзовый, двойка = серебряный, тройка = золотой, четвёрка = платиновый. Это значение будет записано в первые 3 бита. Во вторые будет записан y – он будет обозначать приоритет при необходимости сброса трафика. Будет определено три значения – единица будет обозначать low drop priority, двойка – medium, тройка – high. Это будет обозначать, что трафик одного и того же класса, но с разными приоритетами, будет при возникновении ситуации удаляться исходя из этого приоритета – вначале low, потом medium, потом high. Не запутайтесь – пакет с high drop priority сбрасывается последним, а с low – первым.
Если сеть не поддерживает 3 приоритета, то она должна поддерживать хотя бы 2 – тогда они выглядят как AFx1 в роли “менее важного” и AFx2-AFx3 в роли “более важного”.
DSCP-метка EF – Expedited Forwarding
Это – высший, “premium” класс обслуживания. Значение этой метки – 46, она обозначает трафик, который надо отправить самым лучшим по всем параметрам способом.
Вкратце всё. Как понятно, значение DSCP равное нулю будет обозначать Best-Effort доставку.
Специфика 802.11-сетей
Соответственно, если Ваш WiFi-адаптер поддерживает WMM, то Вы можете включить это на уровне драйвера WiFi-адаптера, и он будет классифицировать свой исходящий трафик по 4м очередям в соответствии с “VO самый главный, VI второй, BE обычный, а BK – фоновый”. Если в Вашей сети политики QoS будут действовать на хосты с WiFi-адаптерами – учитывайте эти моменты при планировании политик.
Создаём политику
При создании политики мы можем указать нужный DSCP-класс и ограничение на полосу пропускания исходящего трафика, подпадающего под нужный критерий. Как оба этих значения, так и одно из них.
Применение политики на указанные приложения
Здесь есть три варианта – политика будет действовать на трафик от любого приложения, от указанного (указывается исполняемый модуль), или только на HTTP-ответы от наших приложений, подпадающих под нужные критерии. Третий вариант будет интересен, когда надо будет через политику ограничить полосу отдаваемого трафика для указанных HTTP-ресурсов – допустим, если мы хотим ограничить “отдаваемые с нас” видеофайлы, подпадающие под критерий вида “https://www.atraining.ru/video/*”.
Применение политики на указанные source/destination IPv4/IPv6-адреса
Достаточно тривиальные настройки – можно дополнительно ограничить применение политик QoS на трафик по L3-критерию. Замечу, что если в предыдущей настройке было выбрано “ограничить отдаваемый от нас в ответ на специфичный HTTP-запрос трафик”, то будет доступна только фильтрафия по destination, т.к. откуда исходит трафик и так понятно – от нас.
Применение политики на указанные source/destination TCP/UDP порты
Это просто – разве что не забудьте, что диапазон портов указывается через двоеточие (вида 1024:65535, а не 1024-65535).
В общем-то всё, политика создана. Можно создать и ещё. Как они будут взаимодействовать в случае пересечения?
Взаимодействие политик QoS
Зафиксируйте также интересную штуку – на серверных ОС Microsoft настройки QoS применяются всегда, а на клиентских – только в случае, когда сетевой интерфейс для исходящего трафика распознан как Domain Network. Это сделано специально, чтобы ограничения, действующие на ноутбук сотрудника при работе в корп.сети, не ограничивали бы по скорости и качеству его работу во внешних сетях. Это не влияет на безопасность, поэтому не является ослаблением оной; это лишь ограничения исходящего трафика.
Теперь – о глобальных настройках “движка QoS” – сетевого компонента QoS Packet Scheduler.
Настройки QoS Packet Scheduler
Данные параметры будут указывать общесистемные (не относящиеся к конкретному типу трафика и сетевому интерфейсу) настройки этого механизма. Располагаться они будут в соответствующей ветке групповых политик:
Параметр QoS Packet Scheduler – Limit Outstanding Packets
Данная настройка указывает максимальный размер системной очереди исходящих пакетов. Т.е. если пакет назначен для отправки через конкретный интерфейс (найден next-hop и назначен egress interface), он считается “отправляемым” по данному критерию, и увеличивает этот счётчик на единицу. Как только пакет будет успешно отправлен (заметьте – именно пакет, этот счётчик работает только для L3-пакетов), счётчик уменьшится. Технически в Windows L3-очереди для конкретного интерфейса нет, есть только L2 (т.е. из кадров), поэтому если суммарное количество таких вот “ожидающих” пакетов будет больше указанного числа, то новый пакет не будет отправлен вообще, пока очередь не будет разгружена. От размера пакета это не зависит, считаются “головы” ожидающих пакетов. Пакеты всех сетевых протоколов (и IPv4, и IPv6) считаются вместе, т.е. при значении по умолчанию – 65536 – поставить “в очередь” по, допустим, 35 тысяч пакетов IPv4 и IPv6 не получится – 65537й пакет любого протокола будет отброшен по логике tail drop (т.е. не помещён в очередь).
Я бы рекомендовал помнить, что исходящий пакет лимитируется кадровым MTU, которое в случае включения поддержки Jumbo Frames на сетевых интерфейсах будет 9КБ, поэтому даже дефолтная настройка, по сути, выделяет буфер для ожидающих пакетов суммарным размером до 589.824.000 байт, т.е. более полугигабайта (в случае обычного сетевого интерфейса 10/100Мбит – поменьше, 98.304.000 байт). Этого более чем достаточно на все случаи жизни (просто подумайте, что это за приложение такое, которое будет пытаться впихнуть в исходящую очередь интерфейса столько пакетов), поэтому зачастую целесообразно это значение уменьшать – уменьшается объём RAM, занимаемый служебными структурами драйвера QoS Packet Scheduler. Я ставлю на хосты, у которых виртуальные сетевые интерфейсы и не-интенсивная нагрузка (например, DC/GC) значение в 4096, и footprint драйвера QoS проседает.
Для узлов, к которым подключается много внешних сессий, плюс настроен QoS, плюс отдаваемые данные состоят из мелких пакетов (голос, торренты) это значение может быть увеличено. Общая логика, думается, понятна – есть память и потребность отдавать очень много мелких пакетов – вполне можно и в ограничение в 65536 упереться.
Параметр QoS Packet Scheduler – Set Timer Resolution
В случае, когда настроено ограничение какого-либо типа исходящего трафика по полосе (“шейпинг”), данный параметр указывает то, какой минимальный квант времени используется для расчётов.
Логика проста – допустим, используется стандартное значение в 10ms. Это значит, что секунда делится на 100 равных частей. Допустим, есть правило, которое ограничивает сервис X по отправке до 5МБайт в секунду. Следовательно, 100 раз в секунду будет запускаться счётчик, который будет измерять трафик, фактически отправленный подпадающим под правило сервисом. Если этот трафик за учётный период в 10ms наберёт 50КБ, то больше он отправляться не будет и начнёт уходить в “ожидающую” очередь, про которую рассказано в предыдущем пункте. Ну а когда начнётся новый период в 10ms, опять сможет быть отправлено 50КБ.
Соответственно, чем это число больше, тем шейпинг будет “грубее”, но меньше будет тратиться процессорных ресурсов. А чем число меньше, тем более “гладко” будет уходить трафик – заметьте, это всё относится только к трафику, подпадающему под правила QoS, трафик без маркировки это затрагивать не будет. Имеет смысл увеличить разрешение таймера (до 2ms например) в случае, когда есть правило по отправке голосового трафика – это положительно повлияет на качество исходящего потока.
Параметр QoS Packet Scheduler – Limit Reservable Bandwidth
Самая страшная настройка – сколько про неё сказок рассказывается уже лет 10, просто ппц. Легенды о том, что “венда по дефолту 20% сетевой полосы пропускания просто так зажимает”, я слышал в десятках вариантов – от безобидного “потому что они тупые там и не могут нормально сетевуху полностью нагрузить” до шизоидного “это чтобы данные с винта пользователя в Пентагон отправлять”.
На самом деле всё просто. Это – суммарное количество резервируемой всеми правилами QoS, работающими на данной системе, полосы пропускания. Т.е. если оно 20%, а у Вас сетевой интерфейс в 100 Мбит, то как бы Вы не старались, и не создавали, например, 3 правила, каждое из которых резервирует под приложение по 15 мегабит (3*15=45), то Вы никак больше 20 мегабит не займёте в результате своим приоритезированным трафиком.
Грубо говоря, это значение показывает, сколько “QoS’овского классифицированного” трафика в процентах от номинальной полосы пропускания интерфейса может быть. Целесообразно, если Вы пишете политики QoS, увеличить это число например до 90%. Почему не до 100? Потому что в случае, когда по каким-то причинам весь трафик некоего приложения станет супер-приоритетным, и полоса резервирования будет 100%, другой трафик будет вечно проигрывать соревнование за очерёдность отправки, и система не сможет делать свои задачи – грубо говоря, например, отвалятся всякие служебные протоколы типа IKE, который ходит по 500му порту UDP, NTP, DNS, и прочие. Вот от этого идёт страховка, когда делают не 100, а не от того, что “винда просто так берёт и часть сети не использует”.
Quality Windows Audio Video Experience (qWave) – что такое и нужен ли
Напомню – “просто так” установить этот компонент можно, но нужен софт, который будет уметь запросить у него функционал. По умолчанию qWave не работает, т.к. если бы он работал, то он тратил бы ресурсы сети на тестовые измерения качества канала.
Вместо заключения
Надеюсь, что эта краткая экскурсия в достаточно интересный мир управления трафиком была интересна и будет Вам полезна на практике.
QoS Пакеты в Роутере — Пропускная Способность Сети WiFi и Настройка Приоритетов Трафика
Пропускная способность локальной сети и фильтрация приоритета трафика (QoS) — тема, которая становится с распространением скоростного интернета все более актуальной. С каждым разом мы пытаемся подключить к роутеру все больше устройств, а программное обеспечение по умолчанию не всегда может с ними со всеми справиться. В этом случае на помощь приходит настройка приоритетов пакетов QoS для оптимизации пропускной способности локальной сети на маршрутизаторе. Она назначает приоритет на выполнение тех или иных самых важных на данный момент задач и доступна не только на топовых маршрутизаторах Mikrotik или Cisco, но и на любой недорогой модели TP-Link, Asus, Zyxel Keenetic, D-Link.
Функция QoS в роутере — что это такое?
Планировщик пакетов QoS (Quality of Service) — это функция распределения трафика согласно заданному в роутере приоритету обслуживания для настройки пропускной способности и распределения нагрузки внутри локальной сети.
Большинство современных роутеров имеет встроенную возможность управлять потоками интернет трафика внутри локальной сети и назначать с ее помощью приоритет при работе того или иного приложения. Например, вы играете в онлайн игру или просматриваете страницы любимых сайтов. И параллельно качаете интересный фильм по торренту. При этом и игра начинает тормозить, и файл качается еле-еле. Что делать?
Нужно выбрать, какое действие для вас в данный момент является более важным. Наверное, это все-таки онлайн игра. Поэтому с помощью настройки планировщика пакетов трафика QoS мы можем установить приоритет на выполнение игровых задач перед загрузкой файлов.
Но пропускная способность локальной сети обусловлена возможностями роутера. Также есть ограничение на канал трафика в интернете согласно тарифному плану от провайдера. Каким же образом при этом разделяется приоритет на выполнение нескольких одновременных задач?
Как правило, по умолчанию наивысший приоритет отдается веб-серфингу, то есть работе вашего браузера. Но если в данный момент вы открыли и читаете статью и при этом вам хочется поскорее закачать фильм, то логичнее было бы отдать приоритет именно программе загрузчику файлов, а не браузеру.
Диспетчер трафика QoS на роутере Asus
В разных моделях эта настройка может скрываться под различными названиями в пункте меню. У меня сейчас работает роутер Asus в новой прошивке — показываю на RT-N10U версии B1. И здесь настройка планировщика QoS осуществляется в разделе «Диспетчер трафика».
Для начала надо сменить активированный по умолчанию автоматический режим на один из двух. «Определяемые пользователем правила QoS» или «Определяемый пользователем приоритет»
Правила планировщика пакетов трафика
Данная настройка позволяет задать приоритет для уже предустановленных вшитых в программное обеспечение маршрутизатора программ из разных «весовых категорий». При этом заморачиваться с различными формулами и производить расчет пропускной способности сети не понадобится. Все уже придумано до нас. Без скриншота немного не понятно, поэтому привожу его:
Итак, сейчас на «Web Serf», то есть на подключения через браузер через используемый для этого 80 порт, стоит «Наивысший» приоритет. Кликнув по выпадающему списку, мы можем выбрать другой из предложенного списка. В то же время на «File Transfer», то есть для программ-загрузчиков файлов — наименьший. Поменяв эти параметры местами мы получим эффект, что при одновременной загрузке файла с какого-либо сайта и просмотре html-страницы, бОльшая скорость будет отдаваться первому процессу.
Но это еще не все. Для программ для передачи файлов посредством P2P (например, BitTorrent), или он-лайн игр, а также множества других приложений можно задать свои значения приоритета. Это делается добавлением нового правила к уже существующим.
Для его создания кликаем по пункту «Выберите» и из выпадающего списка выбираем интересующий нас тип передачи данных или предустановленные настройки для конкретного приложения. Например, можно задать в пропускной способности сети приоритет для почтовых приложений типа Outlook или TheBat (пункт SMTP, POP3…) или для ftp-клиентов (FTP, SFTP, WLM…). Также есть большой список популярных игр, например Counter Strike, и программ для обмена файлами — BitTorrent, eDonkey и т.д.
Выберем качалку торрентов. Автоматически проставятся используемые данной программой по умолчанию порты.
Но лучше на слово роутеру не верить и перепроверить их самостоятельно. Откроем программу (у меня uTorrent) и зайдем в «Настройки > Настройки программы > Соединения». Посмотрим, какой порт задан для работы этой проги.
Если он отличается от тех, которые были по дефолту прописаны в настройках роутера, то поменяйте. Либо там, либо тут, главное, чтобы они были одинаковыми. Сохраняем настройки в программе и, вернувшись в админку роутера, применяем параметры. Они активируются после перезагрузки аппарата.
Приоритет пакетов QoS в локальной сети
Это вторая настройка ручного управления пропускной способностью сети, которая позволяет настроить задаваемые в предыдущем разделе параметры. А именно определить, какая именно скорость в процентном соотношении будет назначены для каждого из параметров приоритета.
Например, для исходящего трафика на «Наивысший» в данный момент по умолчанию у меня задано 80% — минимальное значение и 100% — максимальное. Это означает, что те, у которых наивысший приоритет, будут получать не менее 80% ширины пропускаемости канала. Независимо от того, сколько бы одновременных процессов не производили исходящие соединения с интернетом. Те же, у кого приоритет «Высокий» — не менее 10%. И так далее — думаю, суть вы поняли. Отредактировав эти значения, можно детально управлять скоростью загрузки и выгрузки для разных категорий работающих программ.
Ниже для вашего удобства приведу несколько скриншотов администраторских разделов для управления пропускной способностью с моделей других фирм.
Настройка планировщика пакетов QoS на роутере TP-Link
На роутерах TP-Link планировщик пакетов QoS находится в разделе меню «Контроль пропускной способности». Для его активации ставим галочку на «Включить контроль полосы пропускания» и задаем максимальную скорость для входящего и исходящего трафика.