Computer configuration windows settings policy based qos

В этой статье мы рассмотрим способы ограничения скорости передачи данных по сети с/на Windows Server 2016 и Windows 10 с помощью встроенных и сторонних средств. Как известно, что по умолчанию, приложения Windows используют сетевой интерфейс по максимуму. Это может вызвать проблемы, когда определенная задача (чаще всего это общие сетевые папки) используют всю доступную пропускную способность сетевой карты. В это случае вы можете ограничить максимальную скорость копирования файлов из сетевой папки, и предоставить пользователям других приложения гарантированные ресурсы сетевой карты.

Для управления классами и приоритетами трафика в сетях TCP/IP используется технология QoS (quality of service).

Настройка групповой политики QoS в Windows

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

Групповые политики QoS поддерживается в:

• Windows Server 2008 и выше
• Windows Vista и выше

В первую очередь настройки параметры сетевой карты и убедитесь, что у вас включена опция Qos Packet Scheduler.

1. Запустите оснастку локального редактора GPO (gpedit.msc) и перейдите в раздел Computer Configuration -> Windows Settings -> Policy-based QoS и нажмите Create new policy;
   

   Картинка с сайта: winitpro.ru

2. Укажите имя политики, включите опцию Specify Outbound Throttle Rate и задайте ограничение скорости Throttle Rate. Это скорость в MBps/KBps (мегабайтах/килобайтах) до которой вы хотите ограничить исходящий трафик.

   Заметка. Также есть возможность выставить DSCP значение. DSCP (Differenciated Services Code Point) может использоваться на продвинутых маршрутизаторах типа Cisco/Mikrotik. В зависимости от значения DSCP у пакета, маршрутизаторы будут выставлять этому пакету приоритет. Не используйте этот параметр, если вы не уверены в настройках QoS DSCP на ваших маршрутизаторах.

   

   Картинка с сайта: winitpro.ru

3. Далее можете выбрать конкретный процесс/приложение (исполняемый .ехе файл) или определенный http(s) сайт IIS, к которому будет применяться политика. В моём случае я оставлю опцию All application;
   

   Картинка с сайта: winitpro.ru

4. Вы можете указать к какому IP на вашем компьютере будет применяться политика. Это может понадобиться, если у вас есть несколько сетевых карт или IP алиасов;
5. Также вы можете указать целевой IP, с которым вы хотите ограничить скорость передачи;
   

   Картинка с сайта: winitpro.ru

6. Далее указывается протокол, к которому будет применяется политика (TCP, UDP или TCP and UDP). А также можете выбрать исходящий и целевой порт. Если вы не уверены по какому протоколу работает ваше приложение, которое вы хотите ограничить, выбирайте TCP and UDP. Если вы хотите ограничить скорость доступа к общим файлам в сетевой папке, укажите протокол TCP и 445 порт;
   

   Картинка с сайта: winitpro.ru

Настройка QoS политики в Windows завершена. Перезагружаться не надо, сразу после применения изменений скорость передачи по сети начнёт шейпиться. Обратите внимание, что Throttle Rate отображается редакторе политик в КилоБайтах, даже если вы выбрали значение 3 МБ.

Картинка с сайта: winitpro.ru

Так как я выбрал все приложения и все порты, данная политика будет ограничивать максимальную скорость передачи файлов по сети до 3 Мб (в том числе при копировании файлов через File Explorer — explorer.exe).

Картинка с сайта: winitpro.ru

Еще существуют Advanced QoS политики, которые доступны только в разделе конфигурации политик компьютера. Вы можете ограничить входящий TCP трафик на вкладке Inbound TCP Traffic. (Вкладка DSCP Marking Override относится к настройкам DSCP, её рассматривать мы не будем)

Картинка с сайта: winitpro.ru

Как вы видите, имеются 4 уровня ограничения трафика. В следующей таблице указаны уровни и их скорости.

Управление политиками QoS Windows средствами PowerShell

Для создания и управления политиками QoS можно использовать PowerShell. Например, чтобы создать политику QoS, ограничивающую пропускную способность для SMB (файлового) трафика, используйте команду:

New-NetQosPolicy -Name "SMBRestrictFileCopySpeed" -SMB -ThrottleRateActionBitsPerSecond 10MB

Name : SMBRestrictFileCopySpeed
Owner : Group Policy (Machine)
 NetworkProfile : All
Precedence : 127
Template : SMB
JobObject :
ThrottleRate : 10.486 MBits/sec

Чтобы вывести список примененных политик QoS на компьютере, выполните команду:
Get-NetQosPolicy


Картинка с сайта: winitpro.ru

Чтобы изменить, или удалить политику QoS, используются соответственно командлеты
Set-NetQosPolicy
и
Remove-NetQosPolicy
.

Remove-NetQosPolicy -Name SMBRestrictFileCopySpeed

Set-SmbBandwidthLimit: управление пропускной способностью для SMB трафика из PowerShell

Командлет Set-SmbBandwidthLimit позволяет ограничить скорость передачи данных по SMB протоколу. Сначала нужно установить компонент Windows Server SMB Bandwidth Limit с помощью PowerShell:

Add-WindowsFeature -Name FS-SMBBW

Или можно установить его из графического Server Manager (Add Windows Feature -> SMB Bandwidth Limit).

Обычно данный модуль применяется для ограничения скорости для Hyper-V Live Migration. Например, следующая команда ограничить скорость миграции виртуальных машин до 100 Мбайт/сек.

Set-SmbBandwidthLimit -Category LiveMigration -BytesPerSecond 100MB

Картинка с сайта: winitpro.ru

Вы также можете указать -Category Default для ограничения обычного трафика для передачи файлов по протоколу SMB.

Set-SmbBandwidthLimit -Category Default -BytesPerSecond 10MB

Компонент FS-SMBBW доступен начиная с Windows Server 2012 R2.

Ограничение скорости передачи файлов в Robocopy – ключ /IPG

При использовании robocopy вы также можете использовать специальный ключ, позволяющий ограничения скорости копирования/перемещения файлов по сети. Для этого используется ключ /ipg (Inter packet Gap). Этот ключ выставляет интервал между пакетами в миллисекундах и используется для снижения нагрузки на сеть при копировании по низкоскоростным каналам. Robocopy передает данные по сети блоками по 64 КБ, и таким образом, зная пропускную способность вашего канала, можно рассчитать нужное значение для
/ipg
, исходя из требований к ограничению скорости передачи.

Если вы не хотите углубляться в формулы, то можете использовать уже готовый калькулятор Robocopy IPG Calclator: http://www.zeda.nl/index.php/en/robocopyipgcalculator-en-2

Для копирования данных по медленным и нестабильным каналам также можно использовать протокол BITS (см. пример в статье Копирование больших файлов с помощью BITS и PowerShell). Этот протокол позволят динамически управлять скоростью передачи данных между двумя узлами в зависимости от занятости канала и поддерживает докачку.

Управление шейпингом трафика с помощью сторонних утилит

Из платных вариантов самым популярным решением для ограничения пропускной способности в Windows в зависимости от порта, приложения, назначения является программы NetLimiter, а из бесплатных TMeter Free.

Также можно отменить:

• Glasswire – также включается в себя файервол и сетевой мониторинг;
• NetBalancer – сетевой мониторинг и возможность настраивать правила для трафика;
• cFosSpeed – может задать приоритет трафика для определенных приложений;
• Net Peeker – как и Glasswire имеет функцию файервола и возможность задавать приоритеты для трафика.

С задачей ограничения скорости передачи данных по сети отлично справляются QoS политики Windows, поэтому если перед вами стоит такая задача, то политики QoS должны быть рассмотрены в первую очередь. К тому же как и любые политики, они могут быть настроены на уровне всего домена через консоль gpmc.msc.

Стороннее ПО более функционально и имеет графический интерфейс, но в большинстве случаев это платные программы.

Привет.

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
• Глобальные настройки QoS
• Настраиваем политики QoS
• IP Precedence, DSCP – что и как
• WMM_AC и специфика 802.11-сетей
• Взаимодействие политик QoS
• Настройки QoS Packet Scheduler
• Quality Windows Audio Video Experience (qWave) – что такое и нужен ли

Начнём.

Включаем поддержку 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
]

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

Модель IP Precedence была простой и предполагала, что весь трафик можно разбить на 8 классов, между которыми будет простое логическое соотношение вида “5 всегда важнее, чем 4”, плюс добавить некоторые пожелания. Все задачи по реализации этой схемы (чтобы одинаковый трафик метили одинаковыми IP Precedence, и обрабатывали схожим способом, плюс учитывали пожелания в виде 4х дополнительных бит) ложились на администратора. Впоследствии 4 бита “пожеланий” практически перестали использовать, и схема IP Precedence превратилась в минималистичную “8 глобальных типов трафика, выстроеных по важности”. Их можно трактовать и называть по-разному, логики работы это не поменяет, например так:

• 0 – То, что называется Best Effort – трафик, который будет доставляться по остаточному принципу, когда будет возможность. Best Effort – это не “наилучшим способом”, это “хотели, как лучше, а как получится – посмотрим”. Обычно 0 – это весь неклассифицированный трафик.
• 1 – Распознаный трафик. Например, HTTP, SMB, FTP. Это не значит, что этот трафик какой-то особенный. Он хотя бы “понятно какой”.
• 2 – Приоритетный трафик. Например, RDP – при перекачке файла будет не очень хорошо, если начнёт тормозить работа с терминальным сервером.

Но 14 лет назад, в 1998 году, парни из EMC и Cisco решили, что не хватит, и придумали ощутимо более гибкую систему, притом сразу и для ToS в IPv4, и для его потомка – Traffic Class в IPv6. Назвали её Differentiated Services. Система задействовала уже все 8 бит поля ToS – 6 на идентификатор класса (DSCP), и 2 на сигнализацию в случае заторов в сети (ECN). Как раз этот, более современный способ, и используется в политиках Windows. Метки, заданные по DSCP, более многочисленные, поэтому разбиваются на несколько групп.

DSCP-метки группы CS – Class Selector’ы

Этот механизм, который описан в RFC 2474, нужен для совместимости с предыдущей реализацией. В этом случае используется только 3 первые бита из 6, остальные устанавливаются в нули, поэтому с точки зрения расположения данных внутри байта ToS, CS’ы задают те же самые биты, что и IP Precedence. Соответственно, CS’ов будет 8 штук – от CS0 до CS7, и выглядеть они будут предсказуемо:

• CS0 = 000 000
• CS1 = 001 000
• CS2 = 010 000
• CS3 = 011 000
• CS4 = 100 000
• CS5 = 101 000
• CS6 = 110 000
• CS7 = 111 000

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 в роли “более важного”.

Определены следующие значения:
 

• AF11 = 001 010 (в десятичном варианте DSCP = 10)
• AF12 = 001 100 (в десятичном варианте DSCP = 12)
• AF13 = 001 110 (в десятичном варианте DSCP = 14)
• AF21 = 010 010 (в десятичном варианте DSCP = 18)
• AF22 = 010 100 (в десятичном варианте DSCP = 20)
• AF23 = 010 110 (в десятичном варианте DSCP = 22)
• AF31 = 011 010 (в десятичном варианте DSCP = 26)
• AF32 = 011 100 (в десятичном варианте DSCP = 28)
• AF33 = 011 110 (в десятичном варианте DSCP = 30)
• AF41 = 100 010 (в десятичном варианте DSCP = 34)
• AF42 = 100 100 (в десятичном варианте DSCP = 36)
• AF43 = 100 110 (в десятичном варианте DSCP = 38)

DSCP-метка EF – Expedited Forwarding

Это – высший, “premium” класс обслуживания. Значение этой метки – 46, она обозначает трафик, который надо отправить самым лучшим по всем параметрам способом.

Вкратце всё. Как понятно, значение DSCP равное нулю будет обозначать Best-Effort доставку.

Специфика 802.11-сетей

У WiFi будет своя классификация типов трафика. Она будет называться WMM_AC (Wireless MultiMedia Access Categories) и будет достаточно несложной.

1. Весь трафик с DSCP от 48 и выше относится к Voice-классу (обозначается как VO)
2. Весь трафик с DSCP от 32 до 47 относится к Video-классу (обозначается как VI)
3. Весь трафик с DSCP от 24 до 31 относится к BestEffort-классу (обозначается как BE)
4. Весь трафик с DSCP от 8 до 23 относится к Background-классу (обозначается как BK)
5. Весь трафик с DSCP от 0 до 7 относится (опять, да?) к BestEffort-классу (обозначается тоже как BE)

Соответственно, если Ваш 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

В случае, когда трафик будет подпадать под несколько политик, будет определяться “выигравшая”, приоритеты будут выставляться так:

• Политики QoS уровня пользователя перекрывают политики QoS уровня компьютера
• Если определена политика, влияющая на конкретное приложение, и есть политика, под которую тот же трафик подпадает, но уже по сетевым критериям (адреса, номера портов), то выигрывает политика приложения
• Политика, действующая на настройку более конкретно, перекроет общую. Это отнесётся и к подпадению сразу под две политики сетевого плана (подпасть под 192.168.1.0/24 важнее, чем под 192.168.0.0/16), и под “указанный явно порт лучше чем диапазон портов”, и под “более конкретный URL вида https://host/video/* лучше, чем https://host/*”

Зафиксируйте также интересную штуку – на серверных ОС 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) – что такое и нужен ли

Данный компонент, появившийся со времен NT 6.0, представляет из себя клиент-серверный сервис, технически работающий по портам 2177 TCP/UDP, и нужный для того, чтобы две службы на разных хостах могли “договориться” о том, какому потоку данных какой приоритет предоставить. Сервер, инициирующий передачу данных, имеет роль initiator, принимающая сторона имеет роль sink. Суть в том, что приложение, которое сможет “заказать” у qWave уровень качества для своих данных, должно быть соответствующим способом разработано (например, использовать для установки сессии функционал .NET). qWave, по сути, будет перекрывать своими настройками, если они есть, системные. Плюсов у интегрированного подхода много – qWave автоматически определяет, поддерживается ли 802.1p не только на конечных хостах, но и на промежуточном сетевом оборудовании, позволяет гибко и на ходу переопределять резервируемую полосу для нужного трафика, а также постоянно отслеживать такие параметры, как latency канала (QoS Packet Scheduler этого делать не может), периодически отправляя тестовые пакеты и “промеряя” качество линии между двумя хостами.

Напомню – “просто так” установить этот компонент можно, но нужен софт, который будет уметь запросить у него функционал. По умолчанию qWave не работает, т.к. если бы он работал, то он тратил бы ресурсы сети на тестовые измерения качества канала.

Вместо заключения

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

Удач!

Background on QoS Settings

DSCP tags in packets are useful for letting network appliances know how to prioritize traffic. For example, it’s common that RTP traffic (audio) in a VoIP call gets a DSCP tag of 46. This allows you to set up custom traffic shaping rules that would prioritize your voice traffic and increase your overall call quality.

Prior to Windows Vista / Server 2008, Windows allowed software developers to set the Quality of Service (QoS) tags on traffic. However, if packets weren’t tagged correctly it could cause issues for network administrators that suddenly found that they were prioritizing file sharing applications instead of bandwidth sensitive applications such as VoIP.

With the release of Vista / Server 2008, Microsoft began to overwrite any DSCP values that were set by applications and set them to 0, basically it didn’t trust software to set those values. Because of this there are some settings that you need to modify so that your traffic gets tagged appropriately.

For more information, see Microsoft’s Quality of Service (QoS) Policy

Modify QoS Registry Settings

If you use a Windows PC that is not connected to a domain, you should follow the instructions in this step.

Modifying this registry setting will allow you to specify the QoS setting that will be used based on Group Policy settings that you configure.

HKEY_LOCAL_MACHINE > CurrentControlSet > Services > tcpip > QoS

The QoS Key may not exist. If it does not, then you’ll need to right click on tcpip and select “New Key“. Type in the name as “QoS“.

Once complete, select the QoS key and if it doesn’t already exist then create a new string value called “Do not use NLA“. Set the value to “1“.

It should look like the image below:

Картинка с сайта: www.voiceelements.com

Registry Editor Example for QoS Settings

Reboot Your System

After you complete the registry changes, you will need to reboot for the settings to take effect.

Set Up QoS Group Policy Rules

You control the QoS settings that are used for certain applications by designing different Group Policy rules.

To open up the Group Policy rules, go to a command line and type “gpedit.msc”

This will bring up the local group policy editor. Under Computer Configuration select “Policy Based QoS Settings“, right click and select “Create New Policy“. You will then run through a wizard interface to configure the QoS rules to use.

On the first screen you will be prompted to enter a Policy Name and specify a DSCP value.

Put “HMP Elements” as the Policy name, and specify a DSCP value of “46“, and click “Next“.

In the second screen, you are prompted to determine which applications the policy applies to.

Select “Only applications with the executable name” and enter “HmpElementsServer.exe“, and select “Next“.

In the third screen you can limit both the source and destination IP address.

You may not need to enter any settings here. Once complete click “Next“.

In the fourth and final screen, you’ll want to select the protocol that the QoS applies to.

Most users will limit this to UDP. If you aren’t certain, select “TCP and UDP”.

Additionally, you can select different port ranges on this page. This can be useful, because you could set up one DSCP rule for SIP traffic (typically DSCP 26), and another for the RTP range.

Once complete your rules should look something like this:

Картинка с сайта: www.voiceelements.com

Local Group Policy Editor QoS Settings

Please note that I created an additional rule for Chrome so that UDP packets sent by the browser were tagged with a DSCP value of 46 this is so that WebRTC packets get prioritized. You may not need to modify these settings.

Introduction

This document describes how to enable Quality of Service (QoS) tagging on Windows client machines.

Prerequisites

Requirements

This document assumes you have basic understanding and familiarity with QoS concepts.

Components used

 This article is based on Windows 10 and 11.

Background Information

You sometimes need to configure your windows machine to override or tag the traffic they send. By default, Windows OS sets DSCP tag to ‘0’ unless you have applications configured to mark traffic such as Webex for example.

Configure window 10 Machines to tag traffic

Add «Do not use NLA” parameter and configure the value to 1

 Step 1. From the start menu open “register Editor”.

 Step 2. Go to  Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\QoS

 Step 3. If «QoS» folder does not exist , Create it as demonstrated

• Right click on Tcpip folder.
• Choose New > key.
• Name it as QoS.

 Step 4. Under QoS folder add a DWORD parameter named «Do not use NLA» and assign the value to  «1» .

Картинка с сайта: www.cisco.com

Step 5. Reboot the PC.

Configure local group policy for all or specific application and add the DSCP value

Step 1. From start menu open “local group policy Editor”.

Step 2. In the Group Policy Management Editor, expand ‘Computer Configuration’, followed by ‘Windows Settings’, right-click ‘Policy-based QoS’, and then click ‘Create new policy’:

 Step 3. In ‘Policy-based QoS’, type a name for the new policy. Select Specify DSCP Value and set the value to 46 or any value you want.

 Step 4. Select the application that you want to use this policy or leave it for all applications.

 Step 5. On the third page, configure the source and destination IPs if needed.

 Step 6. On page four, choose ‘TCP and UDP’ in ‘Select the protocol this QoS policy applies to’.

 Step 7. In ‘Specify the source port number’, make sure that both ‘Any source port’ and ‘Any destination port’ are selected and then click ‘Finish’.

For example Putty can be used as application to tag traffic as 46 :

Картинка с сайта: www.cisco.com

   1. From Action tab > Advanced Qos Settings > DSCP marking Override > Allowed.

Картинка с сайта: www.cisco.com

Each time you do changes under the group policy make sure to do a Group Policy refreshment:

 1. Run CMD as administrator

 2. Run this command  :C:\Windows\system32> gpupdate.exe /force.

Note : if your PC is part of group domain , make sure you are connected to that domain before doing the refresh .

Verifications

 Step 1. Run CMD as administrator.

 Step 2. Generate Html file : C:\Windows\system32> gpresult /H «%USERPROFILE%\Desktop\gp.html»

 Step 3. Or generate .txt file :C:\Windows\system32> regedit /e «%USERPROFILE%\Desktop\gp.txt» HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\QoS

For example for the putty test, you can generate the .txt file which shows the DSCP value as 46 :

[HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\QoS\putty]

«Version»=»1.0»

«Application Name»=»putty.exe»

«Protocol»=»*»

«Local Port»=»*»

«Local IP»=»*»

«Local IP Prefix Length»=»*»

«Remote Port»=»*»

«Remote IP»=»*»

«Remote IP Prefix Length»=»*»

«DSCP Value»=»46»

«Throttle Rate»=»-1″.

• From HTML file :

Картинка с сайта: www.cisco.com

• From Wireshark :

Картинка с сайта: www.cisco.com

References

Implementing QoS on Windows Environments

How To Enable Group Policy Editor (gpedit.msc) In Windows 10 Home Edition

Ok