Управление 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
• Глобальные настройки 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 не работает, т.к. если бы он работал, то он тратил бы ресурсы сети на тестовые измерения качества канала.

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

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

Удач!