QoS Качество обслуживания: классификация, маркировка, очереди

Полоса пропускания не бесконечна, а трафик неоднороден: голосовой звонок умирает от 150 мс задержки, а большой бэкап готов ждать. QoS (Quality of Service) — это набор механизмов, который решает, чей пакет важнее, когда канал перегружен. Не «ускорить всё» (это невозможно), а осознанно распределить дефицит: кому приоритет, кого притормозить, кого выбросить первым.

🟡 Калибровка: практическая база глубоко, операторская экзотика для голоса — обзорно. Тебе важно понимать четыре кита (классификация, маркировка, управление очередями, управление перегрузкой), модель DiffServ/DSCP и разницу policing vs shaping — это спрашивают и это переносится в облако/Kubernetes. Тонкую настройку LLQ под конкретные кодеки VoIP давать наизусть не будем.

Что узнаешь

Четыре «врага» трафика: bandwidth, delay, jitter, loss
Три модели QoS: best-effort, IntServ, DiffServ — и почему победил DiffServ
Где живёт маркировка: CoS (L2), ToS/DSCP (L3) — побитно
Стандартные классы PHB: EF, AF, CS, Default
Классификация и trust boundary — кому верить
Policing против shaping — «выбросить» против «придержать»
Очереди: FIFO, WFQ, CBWFQ, LLQ — кого пропускать вперёд
AQM против перегрузки: tail drop, RED/WRED, и почему пришли CoDel/FQ-CoDel
Конфиг MQC (class-map → policy-map → service-policy)
Мост в DevOps: DSCP в облаке, tc/qdisc в Linux, QoS в Kubernetes

1. Четыре характеристики, которые портят трафик

Параметр	Что это	Кому критично
Bandwidth (полоса)	сколько бит/с проходит	загрузкам, видео
Delay (задержка)	время доставки end-to-end	голос, игры (норма для VoIP ≤150 мс)
Jitter (вариация задержки)	«дрожание» — пакеты приходят неравномерно	голос/видео (буфер сглаживает до предела)
Loss (потери)	% потерянных пакетов	всем; для VoIP >1% уже слышно

Ключевая мысль: QoS не создаёт полосу. Он перераспределяет дефицит. Если канал хронически забит на 100% — это вопрос апгрейда, а не QoS. QoS спасает в моменты всплесков и защищает чувствительный трафик от «жадного».

2. Три модели QoS

Best-effort — никакого QoS, «как получится». По умолчанию весь интернет так и работает.
IntServ (Integrated Services) — резервирование ресурсов под каждый поток через RSVP. Точно, но не масштабируется (нужно состояние на каждый поток) — почти мёртв.
DiffServ (Differentiated Services) ⭐ — трафик делится на классы, каждый помечается, и роутеры применяют политику к классу, не к потоку. Масштабируется, поэтому победил.

Дальше всё — про DiffServ: это де-факто стандарт.

3. Где живёт маркировка: CoS и DSCP

Чтобы применять политику к классу, пакет надо пометить. Метки есть на двух уровнях:

CoS (L2) — 3 бита в теге 802.1Q (помнишь VLAN-тег из модуля 3?). Значения 0–7. Живёт только внутри L2-сегмента — на маршрутизаторе тег снимается, CoS теряется.
DSCP (L3) — 6 бит в поле ToS/DS заголовка IP. Живёт end-to-end, пока кто-нибудь не перепишет. Это главный инструмент.

Поле ToS в IPv4 → переосмыслено как DSCP (6 бит) + ECN (2 бита)

DSCP едет в каждом IP-пакете и сохраняется на всём пути — если домен ему «доверяет».

Стандартные классы (PHB — Per-Hop Behavior)

Чтобы все вендоры понимали метки одинаково, RFC задают стандартные значения DSCP:

Класс	DSCP	Для чего
EF (Expedited Forwarding)	46	голос (VoIP) — минимальная задержка, строгий приоритет
AF (Assured Forwarding)	AF11–AF43	видео, важные приложения; 4 класса × 3 уровня drop
CS (Class Selector)	CS0–CS7	совместимость со старым IP Precedence; CS6/CS7 — сетевое управление
Default (BE)	0	best-effort — весь обычный трафик

Запомни главное: EF (46) = голос, Default (0) = всё остальное. Остальное — нюансы. Имя «AFxy»: x — класс очереди (1–4), y — приоритет отбрасывания (1 лучше, 3 первым дропнут).

4. Классификация и trust boundary

Классификация — определить, к какому классу относится пакет. Способы: по входному интерфейсу, по ACL (адреса/порты), по уже стоящей метке DSCP/CoS, по протоколу (NBAR на Cisco — распознавание приложений).

Trust boundary — граница доверия меткам. Принцип: метить трафик как можно ближе к источнику, но не доверять меткам, которые поставил сам пользователь. Иначе любой ПК выставит себе EF и «обгонит» голос. Обычно доверяют IP-телефонам (через CDP/LLDP) и серверам, а пользовательский трафик ре-маркируют на access-порту.

Trust boundary: где начинаем доверять меткам

Граница доверия — обычно access-свитч. Телефону верим, пользовательскому ПК — нет.

5. Policing против shaping

Два способа ограничить скорость класса — и их постоянно путают:

Policing — «выбросить лишнее»

Превышение лимита → пакет дропается (или ре-маркируется)
Не вносит задержку, не буферизует
Можно применять на вход и на выход

Резкий, рваный трафик (особенно бьёт TCP)
Потери → ретрансмиты

Shaping — «придержать в очереди»

Превышение → пакет буферизуется и выпускается ровно
Гладкий трафик, дружелюбен к TCP
Идеален к скорости провайдера/контракту

Вносит задержку (буфер)
Только на выход; нужен буфер (память)

Один и тот же всплеск: policing режет, shaping сглаживает

Правило: к скорости провайдера/контракту — shaping (свой край), злоупотребление лимитом — policing.

6. Очереди: кого пропускать вперёд

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

Механизм	Идея
FIFO	одна очередь, «кто первый пришёл». Никакого QoS.
WFQ	автоматически делит полосу «по-честному» между потоками
CBWFQ	классам выделяется гарантированная доля полосы (bandwidth)
LLQ ⭐	CBWFQ + строгая приоритетная очередь для голоса (EF) — её обслуживают первой, всегда

LLQ (Low Latency Queueing) — стандарт для голоса: EF-трафик идёт в priority-очередь и обслуживается раньше всех (минимальная задержка), но с ограничением (policer), чтобы голос не «съел» весь канал и не заморил остальных. Это лучшее из двух миров: приоритет + защита от голодания.

LLQ: голос — мимо очереди, остальные — по гарантированным долям

Это типовая «иерархия классов» enterprise: голос → видео → бизнес-данные → всё прочее.

7. Управление перегрузкой: tail drop, RED/WRED, CoDel

Что делать, когда очередь переполнилась? Самое наивное — tail drop: новые пакеты просто отбрасываются. Проблема — TCP global synchronization: множество TCP-сессий одновременно теряют пакеты, разом сбрасывают скорость, потом разом разгоняются — канал «пилит» то пусто, то перегруз.

RED / WRED (Random Early Detection) — начинает случайно подроняв пакеты заранее, до переполнения. Это «намекает» части TCP-сессий притормозить вразнобой — синхронизации нет. WRED учитывает DSCP (низкоприоритетные дропает раньше).
CoDel / FQ-CoDel — современный ответ на bufferbloat (раздутые буферы дают огромную задержку). Управляет не длиной очереди, а временем пребывания пакета в ней. Стандарт в Linux сегодня.
ECN — вместо дропа пометить пакет «впереди затор», и отправитель сам снизит темп. Без потерь.

🌉 Bufferbloat и CoDel — это уже про Linux и облако, а не про Cisco. На серверах qdisc fq_codel — дефолт во многих дистрибутивах. Понимание «большой буфер ≠ хорошо, он добавляет задержку» — зрелый сетевой взгляд, который ценят и в DevOps.

8. Как это конфигурится: MQC (Cisco)

Cisco собирает QoS из трёх кирпичей — Modular QoS CLI:

class-map — «что является этим классом» (классификация).
policy-map — «что делать с классом» (маркировать, дать полосу, приоритет, shape).
service-policy — «применить политику к интерфейсу».

# 1) классифицируем R1(config)# class-map match-any VOICE R1(config-cmap)# match dscp ef R1(config)# class-map match-any VIDEO R1(config-cmap)# match dscp af41 # 2) политика: голос — приоритет, видео — доля R1(config)# policy-map WAN-OUT R1(config-pmap)# class VOICE R1(config-pmap-c)# priority percent 20 # LLQ: строгий приоритет + лимит R1(config-pmap)# class VIDEO R1(config-pmap-c)# bandwidth percent 35 # гарантированная доля R1(config-pmap)# class class-default R1(config-pmap-c)# fair-queue R1(config-pmap-c)# random-detect # WRED для best-effort # 3) применяем на выход WAN R1(config)# interface gi0/0 R1(config-if)# service-policy output WAN-OUT

R1# show policy-map interface gi0/0 # счётчики по классам, дропы, соответствие

9. Мост в DevOps

DSCP в облаке: AWS/GCP в основном не гарантируют QoS внутри, но DSCP-маркировка сохраняется и важна на гибридных линках (Direct Connect, VPN к корпоративной сети с голосом/видео).
Linux tc/qdisc: ровно те же идеи — classful qdisc (HTB ≈ CBWFQ), fq_codel против bufferbloat, policing/shaping. Это и есть «QoS на сервере».
Kubernetes QoS classes (Guaranteed/Burstable/BestEffort) — это про CPU/память, другой QoS, но философия та же: при дефиците решаем, кого ужать первым. Не путай с сетевым DSCP.
Service mesh / Envoy — rate limiting и приоритеты на L7 — современный наследник идей policing/shaping.

# Linux: shaping и борьба с bufferbloat — те же концепции $ tc qdisc add dev eth0 root fq_codel # современный AQM против задержки $ tc qdisc add dev eth0 root tbf rate 100mbit burst 32kb latency 400ms # shaping

10. Вопросы с собеседования

❓ В чём разница policing и shaping?

Policing отбрасывает (или ре-маркирует) превышение — без задержки, но рвано. Shaping буферизует и выпускает ровно — гладко, но добавляет задержку. К контракту провайдера — shaping; для жёсткого лимита — policing.

❓ Какой DSCP у голоса и почему именно строгий приоритет?

EF = DSCP 46. Голос чувствителен к задержке и jitter, поэтому его кладут в priority-очередь (LLQ), обслуживаемую первой — но с лимитом, чтобы не заморить остальной трафик.

❓ Зачем WRED, если можно просто tail drop?

Tail drop вызывает TCP global synchronization (все сессии разом тормозят и разом разгоняются). WRED роняет пакеты заранее и вразнобой, сглаживая поведение TCP и держа очередь короче.

❓ Что такое trust boundary?

Граница, с которой мы доверяем меткам QoS. Пользовательскому ПК не доверяем (ре-маркируем на access-порту), IP-телефону/серверу — доверяем. Метим как можно ближе к источнику.

11. Частые ошибки джунов

ошибка 1 «QoS добавит скорость». Нет. QoS перераспределяет дефицит. Хронически забитый канал лечится апгрейдом.

ошибка 2 Доверяют меткам пользователя. Без trust boundary любой ПК выставит себе EF и обгонит голос. Ре-маркируй на крае.

ошибка 3 Маркируют CoS и ждут, что доедет до конца. CoS живёт только в L2; через роутер теряется. Для end-to-end — DSCP.

ошибка 4 QoS только на одном устройстве. QoS работает hop-by-hop: политика и доверие к DSCP должны быть согласованы по всему пути (domain-wide), иначе на любом «нечестном» хопе всё рассыпется.

ошибка 5 Гигантские буферы «чтобы не терять». Это bufferbloat: пакеты не теряются, зато задержка взлетает — для голоса хуже потерь. Управляй временем в очереди (CoDel), а не только её длиной.

Ключевое за этот урок

QoS не создаёт полосу — распределяет дефицит при перегрузке. Враги: bandwidth, delay, jitter, loss.
Победившая модель — DiffServ: классы + маркировка + политика к классу.
CoS (3 бита, L2, локально) vs DSCP (6 бит, L3, end-to-end). EF=46 — голос, Default=0 — всё прочее.
Классификация по ACL/интерфейсу/метке; trust boundary — где начинаем доверять меткам.
Policing = выбросить лишнее (без задержки, рвано); shaping = придержать в буфере (гладко, с задержкой).
Очереди: FIFO → WFQ → CBWFQ (доли) → LLQ (строгий приоритет голосу + лимит).
Против перегрузки: WRED (ранний случайный дроп вместо tail drop), CoDel/FQ-CoDel против bufferbloat, ECN без потерь.
Cisco MQC: class-map → policy-map → service-policy.
В Linux/облаке те же идеи: tc/qdisc, HTB, fq_codel; не путать с QoS-классами Kubernetes (это про CPU/RAM).