Качество обслуживания сетевого трафика становится заметным именно тогда, когда его нет. Видеозвонок рассыпается на квадраты, голос собеседника превращается в роботизированное бульканье, а игральная сессия зависает в самый неподходящий момент, хотя тариф обещает сотни мегабит в секунду. Причина почти всегда одна и та же: канал загружен, пакеты выстраиваются в очередь, и чувствительный к задержке трафик ждёт за тяжёлыми потоками скачиваний. Механизмы QoS позволяют маршрутизатору решать, какие пакеты отправить немедленно, какие подождать, а какие отбросить заранее, и тем самым превратить хаос перегруженного канала в предсказуемую работу. Эта статья разбирает, как устроена классификация трафика, чем строгий приоритет отличается от взвешенного справедливого распределения, зачем нужно активное управление очередями, почему возникает буферблоат и как ограничение полосы до девяноста пяти процентов от договорной скорости возвращает контроль над задержками.
Классификация трафика по меткам DSCP и номерам портов
Любая политика качества обслуживания начинается с вопроса, какой пакет перед устройством. Маршрутизатор не умеет угадывать намерения пользователя, поэтому опирается на формальные признаки. Самый аккуратный признак - поле DSCP в заголовке IP, шесть бит, задающих класс обслуживания. Значения вроде EF для голоса или AF41 для видео стандартизированы и позволяют устройствам на всём пути принимать согласованные решения, не разбирая содержимое пакета.
Второй подход - классификация по транспортным признакам: протоколу, номерам портов источника и назначения, адресам. Правило вида "трафик на пятисотый порт UDP считать телефонией" просто и работает даже там, где заголовки IP остаются нетронутыми. Однако портовая классификация груба: современные приложения прячутся за стандартными веб-портами, номера портов легко подделать, а шифрование усложняет глубокий анализ. На практике методы комбинируют: в доверенном сегменте сети администратор сам проставляет метки DSCP на граничном устройстве по правилам с портами и адресами, а дальше по маршруту оборудование доверяет уже расставленным меткам. Такая двухступенчатая схема снижает нагрузку на транзитные узлы и делает поведение сети воспроизводимым.
Строгий приоритет и взвешенное справедливое распределение
После классификации пакеты попадают в очереди, и здесь начинается главный компромисс QoS. Строгий приоритет означает, что пока в очереди высшего класса есть хотя бы один пакет, остальные очереди не обслуживаются вообще. Для голоса это идеально: задержка и джиттер минимальны, потому что голосовые пакеты идут впереди всех. Обратная сторона - риск голодания низших классов. Если приоритетный поток вдруг раздуется из-за ошибки конфигурации или злонамеренного источника, весь остальной трафик остановится. Поэтому приоритетные очереди почти всегда снабжают ограничителем скорости: голосу выделяют, скажем, не более двадцати процентов канала, а излишек отбрасывают.
Взвешенное справедливое распределение действует иначе. Каждому классу назначается вес, и планировщик поочерёдно обслуживает очереди пропорционально весам. Класс с весом восемь получает вдвое больше полосы, чем класс с весом четыре, но никто не остаётся без обслуживания. Современные варианты применяют справедливость на уровне отдельных потоков, так что один агрессивный скачивающий клиент не может вытеснить десятки веб-сессий соседей. Разумная практика для типичного шлюза выглядит так:
- Голос и сетевые вызовы помещаются в приоритетную очередь с жёстким ограничением скорости.
- Интерактивный трафик вроде игр и терминальных сессий получает отдельный класс с повышенным весом.
- Обычный веб-трафик обслуживается справедливым планировщиком с весом по умолчанию.
- Массовые скачивания и фоновые задачи отводятся в класс с минимальным весом.
- Все классы сверху ограничиваются общим шейпером, чтобы суммарная скорость не превышала реальную ёмкость канала.
Такая иерархия гарантирует и отзывчивость чувствительных приложений, и защиту массовых потоков от полного вытеснения.
Активное управление очередями и алгоритм RED
Даже правильно расставленные приоритеты не спасают, если очереди бесконечно растут. Классическая очередь с отбрасыванием хвоста ведёт себя плохо: она принимает пакеты, пока буфер не заполнится целиком, а затем начинает сбрасывать всё подряд. Причём ссылка на страницу-пример здесь не нужна - поведение известно десятилетиями. В этот момент все TCP-сессии одновременно теряют пакеты, синхронно снижают скорость, затем синхронно разгоняются и снова переполняют буфер. Получается пилообразная загрузка канала с периодами простоя и всплесками задержки.
Алгоритм RED решает проблему упреждающим отбрасыванием. Он отслеживает среднюю длину очереди и, когда она проходит нижний порог, начинает сбрасывать или маркировать отдельные пакеты с нарастающей вероятностью, ещё до переполнения. Передатчики TCP получают ранний сигнал перегрузки и плавно снижают скорость, не доводя очередь до лавины потерь. Потери распределяются по потокам пропорционально их активности, поэтому глобальной синхронизации не возникает. Более современные алгоритмы вроде CoDel и CAKE пошли дальше: вместо длины очереди в пакетах они измеряют время пребывания пакета в буфере и сбрасывают пакеты, как только это время превышает целевой порог в несколько миллисекунд. Для сетевого администратора вывод практический: включение активного управления очередями иногда важнее тонкой настройки приоритетов, потому что именно оно удерживает задержку в разумных рамках под нагрузкой.
Буферблоат и ловушка больших буферов
Буферблоат - болезнь избытка памяти. Производители оборудования долго считали, что большой буфер защищает от потерь, и ставили буферы на секунды трафика. Формально потери действительно снижаются, но цена оказывается неприемлемой: во время перегрузки каждый пакет простаивает в очереди сотни миллисекунд, а иногда и секунды. Для скачивания файла это безразлично, файл придёт целиком в любом случае. Для голосового разговора задержка в полсекунды превращает диалог в поочерёдный обмен репликами, а для игры означает, что действия игрока доходят до сервера с опозданием, при котором конкурентное преимущество теряется полностью.
Диагностика буферблоата проста. Достаточно измерить задержку на холостом канале и затем во время полной загрузки скачиванием. Если первая составляет двадцать миллисекунд, а вторая взлетает до трёхсот и выше, буферы где-то на пути слишком велики и никем не управляются. Разница между этими измерениями показывает, сколько накопленной очереди стоит между пользователем и сетью. Лечение состоит из двух частей: активное управление очередями, описанное выше, и осознанное ограничение полосы, о котором речь ниже. Важно понимать, что проблема живёт на самом узком месте пути, поэтому управлять очередями нужно именно там, где канал сужается, обычно на границе между домашней или офисной сетью и линией провайдера.
Голос и игры против больших скачиваний
Конфликт лёгкого чувствительного трафика с тяжёлыми потоками - центральный сюжет QoS. Голосовой разговор едва ли превышает сотню килобит в секунду, но требует регулярной доставки мелких пакетов каждые двадцать миллисекунд с минимальным разбросом. Игровой клиент потребляет ещё меньше, однако каждое обновление состояния должно доходить за десятки миллисекунд. Большое скачивание, напротив, съедает всю доступную полосу, нечувствительно к задержкам и устойчиво к потерям, потому что TCP просто запросит повторную передачу.
На неуправляемом канале тяжёлый поток заполняет буфер, и лёгкие пакеты застревают позади мегабайтов чужих данных. Правильная политика разводит эти категории по разным очередям. Голос и игры получают приоритет или высокий вес, а скачивания ограничиваются либо весом, либо явным потолком скорости. Показательный приём - признание, что скачиванию всё равно, займёт оно девять минут или десять, поэтому его можно смело зажимать до остаточной полосы. Дополнительно помогает управление подтверждениями TCP в исходящем направлении: на асимметричных каналах узкое восходящее плечо, забитое пакетами подтверждения от большого скачивания, способно затормозить и весь остальной трафик, поэтому мелким служебным пакетам тоже дают приоритет. Результат для пользователя ощутим: разговор остаётся чистым, игра отзывчивой, а файл всё равно докачивается до конца, лишь чуть позже.
Ограничение исходящей полосы до девяноста пяти процентов
Ключевой и часто недооценённый приём - намеренно замедлить собственный шейпер ниже договорной скорости линии. Если тариф обещает сто мегабит, а маршрутизатор выпускает трафик ровно со ста мегабитами, то узким местом становится оборудование провайдера, чьи буферы находятся вне досягаемости и часто страдают именно буферблоатом. Очередь копится там, где администратор не может её контролировать, и вся политика QoS на домашнем устройстве теряет смысл, потому что устройство никогда не видит перегрузки.
Когда же шейпер настроен на девяносто пять мегабит вместо ста, очередь начинает расти на собственном маршрутизаторе раньше, чем на оборудовании провайдера. Узкое место переносится под контроль администратора, и именно на нём начинают работать приоритеты, веса и активное управление очередями. Жертва невелика: пять процентов полосы неощутимы для скачиваний, зато выигрыш в задержке огромен. Точное значение стоит подбирать измерением: шейпер снижают шагами, пока задержка под полной нагрузкой не перестанет расти заметно выше холостой. На линиях с плавающей фактической скоростью, например на радиоканалах, запас делают большим, иногда до десяти процентов, чтобы колебания линии не выносили перегрузку обратно на чужой буфер.
Почему клиентская маркировка не работает без политики сети
Частое заблуждение состоит в том, что приложение или операционная система могут решить проблему качества самостоятельно, проставив в своих пакетах высокий класс обслуживания. На практике метка сама по себе ничего не делает. DSCP - это лишь надпись на конверте; обращение с конвертом определяет тот, кто его обрабатывает. Если маршрутизатор не настроен различать классы, он одинаково обслужит и пакет с меткой высшего приоритета, и пакет без метки. Вдобавок операторы пограничных устройств обычно обнуляют чужие метки, потому что доверять произвольным клиентам нельзя: иначе любое приложение объявило бы себя голосовым трафиком и захватило приоритетную очередь.
Поэтому первый шаг внедрения QoS - определить границу доверия. Внутри неё, например на порту, куда подключена телефонная система, меткам доверяют и передают дальше. Снаружи метки перезаписывают по собственным правилам классификации. Только после этого приобретает смысл настройка очередей и планировщиков, которые смотрят на метки и принимают решения. Та же логика действует в масштабе провайдера: чужая маркировка на входе в магистраль стирается, потому что обслуживать трафик за деньги другого клиента по его собственным записям никто не собирается. Клиентские метки полезны лишь как подсказка для первого доверенного устройства, которое по правилам решает, сохранить их, изменить или сбросить.
Измерение качества обслуживания на практике
Политика QoS без измерений - догадка. Оценивать её следует по метрикам, которые реально чувствуют приложения: задержке в обе стороны, джиттеру как разбросу задержки, доле потерянных пакетов и достигнутой пропускной способности по каждому классу. Методика несложна. Сначала фиксируют базовую линию на пустом канале: обычная серия эхо-запросов даёт минимальную задержку звена. Затем канал искусственно насыщают эталонной нагрузкой и повторяют замеры. Разница и есть плата за перегрузку, которую политика обязана минимизировать.
Для оценки по классам маршрутизаторы предоставляют счётчики очередей: число пакетов, прошедших каждый класс, число отброшенных, текущую длину очереди и распределение скоростей. Рост отбрасываний в приоритетной очереди говорит, что либо в неё попал лишний трафик, либо её ограничитель слишком тесен. Пустая очередь массовых скачиваний при жалобах на медленную загрузку указывает на неправильную классификацию. Полезны и непрерывные измерения: периодические пробы из нескольких точек сети показывают деградацию задолго до обращений пользователей. Отдельного внимания заслуживает проверка под реальным сценарием: во время большого скачивания запускают тестовый голосовой поток и смотрят джиттер. Если он остаётся в пределах пары десятков миллисекунд, конфигурация справляется. Если нет, последовательно проверяют цепочку: правильно ли классифицируются пакеты, верны ли веса, не слишком ли велик шейпер, активно ли управление очередями. Только замкнутый цикл из настройки, измерения и корректировки превращает QoS из списка команд в работающий инструмент, который держит сеть предсказуемой в самые загруженные часы.