Стандарты qos. Защищаемся маршрутизатором: QoS. какие устройства и в какой мере поддерживают QoS

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

Политики QoS

Тип трафика	QoS	Безопасность	Когда?
Голос	Задержка меньше 150 мс в одну сторону	Шифрование на уровне передаче голоса	Понедельник - Пятница
Система планирования ресурсов предприятия	Обеспечение доступной полосы пропускания минимум 512 кб/с	Зашифрован	24 часа в сутки, 7 дней в неделю, 365 дней в году
Трафик, создаваемый программным обеспечением станков и оборудования	Обеспечение доступной полосы пропускания минимум 256 кб/с	В открытом виде	Понедельник - Пятница
Трафик от использования интернет ресурсов HTTP/HTTPS	Негарантированная доставка по принципу Best Effort	HTTP прокси сервер	Понедельник – Пятница, с 8 утра до 9 вечера.

Осуществление QoS в сетях унифицированных коммуникаций

Условно, процесс осуществления QoS в сетях Unified Communications (унифицированных коммуникаций), можно разделить на 3 этапа:

Определение типа трафика в сети и его требований. На данном этапе необходимо научить сеть определять типы трафика чтобы применять к ним те или иные QoS алгоритмы;
с одинаковыми требованиями QoS. Например, можно определить 4 типа трафика: голос, высоко – приоритетный трафик, низко – приоритетный трафик и трафик от пользования браузером для просмотра WEB страниц;
Назначить политики QoS , применяемые к классам, определенным в п.2.

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

Согласно указанным принципам, можно условно выделить три QoS политики:

Без задержки: Присваивается в голосовому трафику;
Лучшее обслуживание: Присваивается к трафику с наивысшим приоритетом;
Остальное: Присваивается к низко – приоритетному и трафику web – браузеров;

Шаг 1: Определение типа трафика

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

Далее, необходимо определить проблемы пользователей при работе с теми или иными сетевыми приложениями: например, приложение медленно работает из-за чего имеет плохую производительности работы. Необходимо измерить сетевой трафик в часы наибольшей нагрузки, используя специальные утилиты. Для понимания процессов в сети, необходимым шагом является измерение загрузки процессора каждого из единиц активного сетевого оборудования в период наибольшей загруженности, чтобы четко знать, где потенциально могут возникать проблемы.

После этого, необходимо определить бизнес цели и модели работы и составить список бизнес – требований. По итогам этих действий, каждый из пунктов списка можно сопоставить с тем или иным классом трафика.

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

Шаг 2: Сгруппировать трафик в классы

После идентификации сетевого трафика, необходимо использовать список бизнес требований, составленный на первом этапе, чтобы определить классы трафика.

Голосовой трафик всегда определяется отдельным классом. Компания Cisco имеет разработанные механизмы QoS для голосового трафика, например, Low latency queuing (LLQ) , цель которого заключается в контроле за тем, чтобы голос получал преимущество в обслуживании. После того как определены наиболее критичные приложения, необходимо определить классы трафика использую список бизнес требований.

Не каждое приложение имеет свой собственный класс обслуживания. Довольно много приложений с похожими требованиями к QoS группируются вместе в единый класс.

Пример классификации трафика

Типичный корпоративный ландшафт определяет 5 классов трафика:

Голос: Наивысший приоритет для трафика VoIP;
Критически важные: Небольшой набор критически важных для бизнеса приложений;
Транзакции: В данном классе присутствуют сервисы баз данных, интерактивный трафик и привилегированный сетевой трафик;
Негарантированная доставка: Работает по принципу Best Effort, что дословно переводится как «лучшее усилие». В данный класс можно отнести интернет трафик и e-mail.

Шаг 3: Сгруппировать трафик в классы

Третьим шагом необходимо описать политики QoS для каждого из классов трафика, которые включают следующие действия:

Назначить минимальный размер гарантированной полосы пропускания;
Назначить максимальный размер полосы пропускания;
Назначить приоритеты для каждого из классов;
Использовать QoS технологии, такие как алгоритмы контроля очередей для управления перегрузками.

Рассмотрим на текущем примере определение политик QoS для каждого из классов:

Голос: Доступна полоса пропускания – 1мбит/с. Использовать метку Differentiated Services Code Poin (DSCP) со значением EF . Метка EF (Expedited Forwarding) означает то, что пакеты с таким маркером получают приоритет в очереди согласно принципу наименьшей задержки. Дополнительно используется алгорит LLQ;
Критически важные: Минимальная полоса пропускания – 1мбит/с. Использовать метку Differentiated Services Code Poin (DSCP) со значением AF31 (метка в поле DSCP 011010), что обеспечивает наименьшую вероятность отбрасывания пакета. Параллельное использование алгоритма CBWFQ гарантирует необходимую полосу пропускания для маркированного трафика;
Негарантированная доставка: Максимальная полоса пропускания – 500кбит/с. Использовать метку Differentiated Services Code Poin (DSCP) со значением Default (метка в поле DSCP 000000), что обеспечивает обслуживание по умолчанию. Алгоритм CBWFQ обеспечивает «доставку по возможности», которая ниже по приоритету классов «Голос» и «Критически важные».

Полезна ли Вам эта статья?

Пожалуйста, расскажите почему?

Нам жаль, что статья не была полезна для вас:(Пожалуйста, если не затруднит, укажите по какой причине? Мы будем очень благодарны за подробный ответ. Спасибо, что помогаете нам стать лучше!

Нет ни одного человека, который бы хоть раз не прочитал какой-нибудь FAQ по Windows XP. А раз так, то каждый знает, что есть такая вредная служба Quality of Service — сокращенно QoS. При настройке системы ее настоятельно рекомендуется отключать, потому что она по умолчанию ограничивает сетевую пропускную способность на 20%, и как будто бы эта проблема существует и в Windows 2000.

Вот эти строки:

Q: Как полностью отключить службу QoS (Quality of Service)? Как ее настроить? Правда ли, что она ограничивает скорость сети?
A: Действительно, по умолчанию Quality of Service резервирует для своих нужд 20% от пропускной способности канала (любого - хоть модем на 14400, хоть гигабитный Ethernet). Причем даже если удалить службу QoS Packet Scheduler из Properties-соединения, этот канал не освобождается. Освободить канал или просто настроить QoS можно здесь. Запускаем апплет Group Policy (gpedit.msc). В Group Policy находим Local computer policy и нажимаем на Administrative templates. Выбираем пункт Network - QoS Packet Sheduler. Включаем Limit reservable bandwidth. Теперь снижаем Bandwidth limit 20% до 0% или просто отключаем его. При желании здесь же можно настроить и другие параметры QoS. Для активации произведенных изменений остается только перезагрузиться.

20% - это, конечно, очень много. Воистину Microsoft - "маздай". Утверждения подобного рода кочуют из FAQ в FAQ, из форума в форум, из СМИ в СМИ, используются во всевозможного рода "твикалках" - программах по "настройке" Windows XP (кстати говоря, откройте "Групповые политики" и "Локальные политики безопасности", и ни одна "твикалка" не сравнится с ними по богатству вариантов настройки). Разоблачать голословные утверждения такого рода нужно осторожно, что мы сейчас и сделаем, применив системный подход. То есть основательно изучим проблемный вопрос, опираясь на официальные первоисточники.

Что такое сеть с качественным сервисом?

Давайте примем следующее упрощенное определение сетевой системы. Приложения запускаются и работают на хостах и обмениваются данными между собой. Приложения отправляют данные операционной системе для передачи по сети. Как только данные переданы операционной системе, они становятся сетевым трафиком.

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

Функциональные возможности QoS призваны удовлетворить двух субъектов сети: сетевые приложения и сетевых администраторов. Они часто имеют разногласия. Администратор сети ограничивает ресурсы, используемые специфическим приложением, в то же время приложение пытается захватить как можно больше сетевых ресурсов. Их интересы могут быть согласованы, принимая во внимание тот факт, что сетевой администратор играет главенствующую роль по отношению ко всем приложениям и пользователям.

Основные параметры QoS

Различные приложения имеют различные требования по обработке их сетевого трафика. Приложения в большей или меньшей степени терпимы к задержкам и потерям трафика. Эти требования нашли применение в следующих параметрах, связанных с QoS:

Bandwidth (полоса пропускания) - скорость, с которой трафик, генерируемый приложением, должен быть передан по сети;
Latency (задержка) - задержка, которую приложение может допустить в доставке пакета данных;
Jitter - изменение времени задержки;
Loss (потеря) - процент потерянных данных.

Если бы были доступны бесконечные сетевые ресурсы, то весь трафик приложения можно было бы передать с требуемой скоростью, с нулевым временем задержки, нулевым изменением времени задержки и нулевыми потерями. Однако сетевые ресурсы не безграничны.

Механизм QoS контролирует распределение сетевых ресурсов для трафика приложения, чтобы выполнить требования по его передаче.

Фундаментальные ресурсы QoS и механизмы обработки трафика

Сети, которые связывают хосты, используют разнообразные сетевые устройства включая сетевые адаптеры хостов, маршрутизаторы, свичи и хабы. Каждый из них имеет сетевые интерфейсы. Каждый сетевой интерфейс может принять и передать трафик с конечной скоростью. Если скорость, с которой трафик направлен на интерфейс, выше, чем скорость, с которой интерфейс передает трафик дальше, то возникает перегрузка.

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

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

Распределение ресурсов QoS по сетевым устройствам

Устройства, поддерживающие QoS, разумно используют ресурсы сети для передачи трафика. То есть трафик приложений, более терпимых к задержкам, становится в очередь (сохраняется в буфере в памяти), а трафик приложений, критичных к задержкам, передается далее.

Для выполнения этой задачи сетевое устройство должно идентифицировать трафик путем классификации пакетов, а также иметь очереди и механизмы их обслуживания.

Механизм обработки трафика

Механизм обработки трафика включает в себя:

802.1p;
Дифференцированные услуги per-hop-behaviors (diffserv PHB);
Интегрированные услуги (intserv);
ATM и др.

Большинство локальных сетей основано на технологии IEEE 802 включая Ethernet, token-ring и др. 802.1p - это механизм обработки трафика для поддержки QoS в таких сетях.

802.1p определяет поле (уровень 2 в сетевой модели OSI) в заголовке пакета 802, которое может нести одно из восьми значений приоритета. Как правило, хосты или маршрутизаторы, посылая трафик в локальную сеть, маркируют каждый посланный пакет, присваивая ему определенное значение приоритета. Предполагается, что сетевые устройства, такие, как свичи, мосты и хабы, обработают пакеты соответствующим образом, используя механизмы организации очередей. Область применения 802.1p ограничена локальной сетью (LAN). Как только пакет пересекает локальную сеть (через уровень 3 OSI), приоритет 802.1p удаляется.

Diffserv - это механизм уровня 3. Он определяет поле в уровне 3 заголовка пакетов IP, названных diffserv codepoint (DSCP).

Intserv - это целый комплекс услуг, определяющий гарантированный сервис и сервис, управляющий загрузкой. Гарантированный сервис обещает нести некоторый объем трафика с измеримой и ограниченной задержкой. Сервис, управляющий загрузкой, соглашается нести некоторый объем трафика с "появлением легкой загруженности сети". Это - измеримые услуги в том смысле, что они определены, чтобы обеспечить измеримый QoS к определенному количеству трафика.

Поскольку технология ATM фрагментирует пакеты в относительно маленькие ячейки, то она может предложить очень низкое время задержки. Если необходимо передать пакет срочно, интерфейс ATM может всегда освобождаться для передачи на время, которое требуется, чтобы передать одну ячейку.

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

QoS – целая пачка технологий, без которых современная сеть работает крайне плохо, а ряд задач не может выполнить вообще. Это и логики классификации трафика, и схема marking’а, когда данные помечаются путём помещения в заголовок канального или сетевого уровня соответствующих пометок, и управление логикой работы очередей, когда надо отправить несколько потоков данных через ограниченный по пропускной способности интерфейс, и шейпинг, и многие другие дисциплины, без которых целостная картина просто не получится. Фундаментально это изучается разве что на курсе , да и то – в пять дней не всегда влезаем, материала там много.

Однако, сетевые настройки Windows в плане “глубже, чем просто айпишник назначить”, обычно являют собой что-то мистическое для администратора (да и для большинства тренеров Microsoft тоже, т.к. сетевые вопросы в авторизованных курсах Microsoft рассказываются крайне минималистично). Хотя ничего ужасного в сетевых технологиях нет, скорее, наоборот – зачастую бытует мнение, что “в Windows этого нет”, базирующееся на глубоком выводе о том, что говорящий это не нашёл за 10 секунд.

Попробуем разобраться.

Предположим, что Вы уже знаете сетевые технологии на базовом уровне, хотя бы слышали про ethernet, 802.1Q и формат IP-пакета. Если не слышали – имеет смысл послушать наш курс , это бесплатно. Конечно, лучше изучить QoS основательно , но это, в принципе, не строго необходимо для восприятия данного материала.

QoS в Windows Server 2012 и других версиях ОС

Глобальные настройки QoS
Настраиваем политики QoS
IP Precedence, DSCP – что и как
WMM_AC и специфика 802.11-сетей
Взаимодействие политик QoS

Включаем поддержку 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 на уровне отдельных приложений. Находятся они в объекте групповой политики, точнее – в , в контекстном меню 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) и будет достаточно несложной.

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

Соответственно, если Ваш WiFi-адаптер поддерживает WMM, то Вы можете включить это на уровне драйвера WiFi-адаптера, и он будет классифицировать свой исходящий трафик по 4м очередям в соответствии с “VO самый главный, VI второй, BE обычный, а BK – фоновый”. Если в Вашей сети политики QoS будут действовать на хосты с WiFi-адаптерами – учитывайте эти моменты при планировании политик.

Создаём политику

При создании политики мы можем указать нужный DSCP-класс и ограничение на полосу пропускания исходящего трафика, подпадающего под нужный критерий. Как оба этих значения, так и одно из них.

Применение политики на указанные приложения

Здесь есть три варианта – политика будет действовать на трафик от любого приложения, от указанного (указывается исполняемый модуль), или только на HTTP-ответы от наших приложений, подпадающих под нужные критерии. Третий вариант будет интересен, когда надо будет через политику ограничить полосу отдаваемого трафика для указанных HTTP-ресурсов – допустим, если мы хотим ограничить “отдаваемые с нас” видеофайлы, подпадающие под критерий вида “http://www..

Применение политики на указанные 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 вида http://host/video/* лучше, чем http://host/*”

Зафиксируйте также интересную штуку – на серверных ОС Microsoft настройки QoS применяются всегда, а на клиентских – только в случае, когда сетевой интерфейс для исходящего трафика распознан как Domain Network. Это сделано специально, чтобы ограничения, действующие на ноутбук сотрудника при работе в корп.сети, не ограничивали бы по скорости и качеству его работу во внешних сетях. Это не влияет на безопасность, поэтому не является ослаблением оной; это лишь ограничения исходящего трафика.

Теперь – о глобальных настройках “движка QoS” – сетевого компонента 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 не работает, т.к. если бы он работал, то он тратил бы ресурсы сети на тестовые измерения качества канала.

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

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

Нет ни одного человека, который бы хоть раз не прочитал какой-нибудь FAQ по Windows XP. А раз так, то каждый знает, что есть такая вредная служба Quality of Service - сокращенно QoS. При настройке системы ее настоятельно рекомендуется отключать, потому что она по умолчанию ограничивает сетевую пропускную способность на 20%, и как будто бы эта проблема существует и в Windows 2000.

Вот эти строки:

"Q: Как полностью отключить службу QoS (Quality of Service)? Как ее настроить? Правда ли, что она ограничивает скорость сети? A: Действительно, по умолчанию Quality of Service резервирует для своих нужд 20% от пропускной способности канала (любого - хоть модем на 14400, хоть гигабитный Ethernet). Причем даже если удалить службу QoS Packet Scheduler из Properties-соединения, этот канал не освобождается. Освободить канал или просто настроить QoS можно здесь. Запускаем апплет Group Policy (gpedit.msc). В Group Policy находим Local computer policy и нажимаем на Administrative templates. Выбираем пункт Network - QoS Packet Sheduler. Включаем Limit reservable bandwidth. Теперь снижаем Bandwidth limit 20% до 0% или просто отключаем его. При желании здесь же можно настроить и другие параметры QoS. Для активации произведенных изменений остается только перезагрузиться ".

Что такое сеть с качественным сервисом?

Основные параметры QoS

Bandwidth (полоса пропускания) - скорость, с которой трафик, генерируемый приложением, должен быть передан по сети
- Latency (задержка) - задержка, которую приложение может допустить в доставке пакета данных.
- Jitter - изменение времени задержки.
- Loss (потеря) - процент потерянных данных.

Фундаментальные ресурсы QoS и механизмы обработки трафика

Распределение ресурсов QoS по сетевым устройствам

Механизм обработки трафика

Механизм обработки трафика включает в себя:

802.1p
- Дифференцированные услуги per-hop-behaviors (diffserv PHB).
- Интегрированные услуги (intserv).
- ATM и др.

Diffserv - это механизм уровня 3. Он определяет поле в уровне 3 заголовка пакетов IP, названных diffserv codepoint (DSCP).

Для наглядности рассмотрим рис. 1.

Принимаем следующее:

Все маршрутизаторы участвуют в передаче нужных протоколов.
- Один QoS-сеанс, требующий 64 Kbps, инициализирован между хостом А и хостом B.
- Другой сеанс, требующий 64 Kbps, инициализирован между хостом А и хостом D.
- Для упрощения схемы полагаем, что маршрутизаторы сконфигурированы так, что могут резервировать все сетевые ресурсы.

В нашем случае один запрос о резервировании 64 Kbps достиг бы трех маршрутизаторов на пути данных между хостом А и хостом B. Другой запрос о 64 Kbps достиг бы трех маршрутизаторов между хостом А и хостом D. Маршрутизаторы выполнили бы эти запросы на резервирование ресурсов, потому что они не превышают максимума. Если вместо этого каждый из хостов B и C одновременно инициализировал бы 64 Kbps QoS-сеанс с хостом A, то маршрутизатор, обслуживающий эти хосты (B и C), запретил бы одно из соединений.

Теперь предположим, что администратор сети отключает обработку QoS в трех нижних маршрутизаторах, обслуживающих хосты B, C, D, E. В этом случае запросы о ресурсах до 128 Kbps удовлетворялись бы независимо от месторасположения участвующего в соединении хоста. При этом гарантии качества были бы низки, поскольку трафик для одного хоста подвергал бы риску трафик другого. Качество обслуживания могло бы быть сохранено, если бы верхний маршрутизатор ограничивал все запросы до 64 Kbps, однако это привело бы к неэффективному использованию сетевых ресурсов.

С другой стороны, пропускную способность всех сетевых связей можно было бы увеличить до 128 Kbps. Но увеличенная пропускная способность будет использоваться только когда хосты B и C (или D и E) одновременно затребуют ресурсы. Если это не так, то ресурсы сети опять будут использоваться неэффективно.

QoS-компоненты Microsoft

Windows 98 содержит компоненты QoS только пользовательского уровня включая:

Компоненты приложений.
- GQoS API (часть Winsock 2).
- QoS service provider.

Операционная система Windows 2000/XP/2003 содержит все описанное выше и следующие компоненты:

Resource Reservation Protocol Service Provider (Rsvpsp.dll) и службы RSVP (Rsvp.exe) и QoS ACS. В Windows XP, 2003 не используются. Управление трафиком (Traffic.dll).
- Generic Packet Classifier (Msgpc.sys). Классификатор пакетов определяет класс сервиса, которому принадлежит пакет. При этом пакет будет поставлен в соответствующую очередь. Очереди управляются Планировщиком пакетов QoS.
- Планировщик пакетов QoS (Psched.sys). Определяет параметры QoS для специфического потока данных. Трафик помечается определенным значением приоритета. Планировщик пакетов QoSпределяет график постановки в очередь каждого пакета и обрабатывает конкурирующие запросы между поставленными в очередь пакетами, которые нуждаются в одновременном доступе к сети.

Диаграмма на рис.2 иллюстрирует стек протоколов, компоненты Windows и их взаимодействие на хосте. Элементы, использовавшиеся в Windows 2000, но не использующиеся в Windows XP/2003, на диаграмме не показаны.

Приложения находятся наверху стека. Они могут знать или не знать о QoS. Чтобы использовать всю мощь QoS, Microsoft рекомендует использовать в приложениях вызовы Generic QoS API. Это особенно важно для приложений, требующих высококачественных гарантий обслуживания. Некоторые утилиты могут использоваться для вызова QoS от имени приложений, которые не знают о QoS. Они работают через API управления трафиком. Например, NetMeeting использует GQoS API. Но для таких приложений качество не гарантируется.

Последний гвоздь

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

Впрочем, дадим слово разработчикам и изложим избранные моменты из статьи "316666 - Windows XP Quality of Service (QoS) Enhancements and Behavior " литературным русским языком:

"Сто процентов сетевой полосы пропускания доступны для распределения между всеми программами, если какая-либо программа явно не запрашивает приоритетную полосу пропускания. Эта "зарезервированная" полоса пропускания доступна другим программам, если программа, которая ее затребовала, не отправляет данные.

По умолчанию программы могут резервировать до 20% основной скорости соединения на каждом интерфейсе компьютера. Если программа, которая резервировала полосу пропускания, не посылает достаточно много данных, чтобы использовать ее полностью, неиспользованная часть зарезервированной полосы пропускания доступна для других потоков данных.

Были заявления в различных технических статьях и телеконференциях, что Windows XP всегда резервирует 20% доступной полосы пропускания для QoS. Эти заявления неверны".

Если теперь у кого-то все еще "отжирается" 20% полосы пропускания, что ж, я могу посоветовать и дальше использовать побольше всевозможных "твикалок" и кривых сетевых драйверов. Еще и не столько будет "отжираться".

Начнем с определений:

Сравнение IPP и DSCP.

Per-Hop Behaviors (PHB)

1.Default PHB

3.Assured Forwarding PHB (AF)

4.Class Selector PHB (CS)

Попробуем разобраться, что такое QoS (Quality of Service), какие стандарты и определения к ней относятся. Поговорим о Best Effort Service, IntServ, DiffServ, PHB, ToS, CoS, IP Precedence (IPP), DSCP, AF, EF, Default PHB.

Давайте первым делом определимся, что же такое Quality of Service. Существует множество определений QoS, мне больше всего нравится вот это:

Под QoS (Quality of Service) следует понимать способность сети (сетевой инфраструктуры) обеспечить необходимый (требуемый) уровень сервиса заданному сетевуму трафику при использование различных технологий.

Под сервисом понимается множество параметров при передачи данных. Рассмотрим основные из них:

1. Bandwidth - ширина полосы пропускания. 2. End-to-end delay - задержка при передаче пакета. 3. Jitter - изменение задержки во времени при передаче пакетов. 4. Packet Loss – потеря (отбрасывание) пакетов при передачи данных.

Сервисные модели Quality of Service.

Существуют 3 различные сервисные моделей QoS.

1. Best Effort Service. Негарантированная доставка.

По сути, в этой модели отсутствуют какие-либо механизмы QoS. Используются все доступные ресурсы сети. Отсуствуют механизмы управления трафиком. Для улучшения QoS используется расширение полосы пропускания в узких местах, однако это не всегда даёт нужный эффект т.к. существуют типы трафика, чувствительные к задержкам и джиттеру (например VoIP).

2. Integrated Service (IntServ). Интегрированное обслуживание.

Обеспечивает сквозное (End-to-End) качество обслуживания, т.е. происходит резервирование ресурсов на всем пути прохождения трафиика. Для резирвирования ресурсов (Resource reservation) используется протокол RSVP, гарантируя необходимую пропускную способность. Существенным недостатком является постоянное резервирование ресурса, даже в том случае, если он не используется или используется не полностью.

3. Differentiated Service (DiffServ). Дифференцированное обслуживание.

Для обеспечения QoS используется ряд специальных компонентов, таких как классификаторы и формирователи трафика на границе сети, также применяются функции распределения ресурсов в ядре сети.

DiffServ выпоняет две функции:

1. Формирование трафика на границах сети - функции классификации, маркировки пакетов и управление интенсивностью. 2. Политика пошагового обслуживания PHB (Per-Hop Behavior) включает функции распределения ресурсов и отбрасывания пакетов.

QoS Классификация и маркировка пакетов.

Начнем с определений:

Классификация пакетов (Packet Classification) - отнесение пакета к определенному классу.

Маркировка пакетов (Packet Marking) - установка требуемого приоритета.

Следует отметить, что классификация и маркировка пакетов отличаются в зависимости от уровня OSI, на котором работает устройство. Как правило, все коммутаторы работают на уровне L2, а именно с Ethernet кадрами. Маршутизаторы работают на уровне L3 и уже не с кадрами, а пакетами.

Классификация и маркировка пакетов на уровне L2

В протоколе Ethernet отсуствует возможность классификации и маркировки пакетов. Классификация возможна лишь по номеру входящего порта (что в большинстве случаев не представляет никакого интереса), а маркировка вообще невозможна.

Однако не все так плохо. Появился стандарт IEEE 802.1Q, описывающий технологию виртуальных локальных сетей VLAN, вместе с которым был разработан стандарт 802.1P для обеспечения QoS в сетях Ethernet (классификации и маркировки Ethernet кадров).

В стандарте 802.1P предусмотрено поле User Priority или второе более позднее название CoS (Class of Service), состоящее из 3-х бит в заголовке 802.1Q, т.е. CoS может принимать значения от 0 до 7.

Формат Ethernet кадра 802.1Q.

Классы трафика согласно стандарту IEEE 802.1P.

Классификация и маркировка пакетов на уровне L3

На L3 мы имеем дело с протоколом IP (Internet Protocol). При разработке протокола IP для целей QoS было специально предусмотрено поле ToS (Type of Service) размером один байт.

Поле ToS может быть заполнен классификатором IP Precedence или DSCP в зависимости от задачи.

IP precedence (IPP) имеет размерность 3 бита, может принимать значения 0-7, т.е. можно говорить о 8-ми классах обслуживания. Изначально использовался классификатор IPP, но со временем появилась необходимость разделять трафиик на большее чем 8 классов обслуживания, следствием чего явилась разработка классификатора DSCP.

DSCP состоит из 6 бит (значения 0-63). Использование дополнительных 3-х бит позволяют ввести большее количество классов. DSCP обратно совместим с IPP. Важно понимать, что оборудование должно поддерживать обработку поля ToS заполненого классификатором DSCP, на старом оборудование с этим могут возникнуть проблемы.

Сравнение IPP и DSCP.

Per-Hop Behaviors (PHB)

Разберем более подробно понятие PHB.

Per-Hop Behaviors (PHB) - это политика пошагового обслуживания, иными словами, это некий алгоритм действий по обработки пакетов, выполняемый на каждом узле. PHB определяет, к какой из очередей отнести пакет, а также сброс пакетов в очереди в случае перегрузок.

Существуют 4 стандартизованных PHB.