MikroTik QoS — развенчание мифов

Перед тем, как настраивать роутер — важно понимать, как пакеты двигаются по цепочкам (изучить в онлайн документации Диаграммы движения пакетов — Packet Flow Diagrams).

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

Вся реализация управления пропускной способностью в RouterOS основана на иерархии — Hierarchical Token Bucket (HTB).

HTB позволяет вам создавать иерархические (древовидные) структуры очередей и определять отношения между ними.

RouterOS 5.x поддерживает 3 виртуальных HTBs (global-in, global-total, global-out) и еще один прямо перед каждым выходным интерфейсом:

Важно понимать, что через роутер проходит несколько потоков.
Например, в самом простом случае имеем один физический интерфейс роутера — Public,
и второй физический интерфейс — Local.
Итого — имеем два потока пакетов, проходящих через роутер — назовем условно Download и Upload потоки.

Для Download трафика входным интерфейсом будет Public, выходным интерфейсом будет Local.
И, наоборот, для Upload трафика входным интерфейсом будет Local, выходным интерфейсом будет Public.
При этом диаграмма движения пакетов и логика обработки потоков будет будет абсолютно одинаковой для обоих потоков.
Другими словами — для роутера не имеет значения роль интерфейса — т.е. разделение на Public и Local — условно.

Постоянно возникают споры про то, что не работает шейпинг + NAT.
Работает.

Я указываю Global-out в качестве родителя дерева Queue Tree (а не физические выходные интерфейсы) как для всего Upload, так и для всего Download трафика и маркирую пакеты в Mangle Forward отдельно для Upload и Download, и использую PCQ тип очереди, где указываются ограничения скорости. Этот план работает в любом случае — вне зависимости от наличия/отсутствия NAT, pppoe/l2tp/pptp, IpoE, HOTSPOT.

Simple Queue:
Не используйте Simple Queue в версиях ROS до 5-ой включительно, если у Вас большое к-во пользователей — сильно падает производительность.

Простые очереди идут по порядку — как правила фаервола.
Пакеты 999-ой очереди будут проверены на соответствие с каждой из 998-и предыдущих очередей.

Каждая простая очередь может стоять в 3 раздельных очередях:
One in Global-in (“direct” part)
One in Global-out (“reverse” part)
One in Global-total (“total” part)

Используйте Дерево очередей queue tree.

Когда пакеты проходят сквозь роутер, они проходят все 4 HTB дерева.

Когда пакеты приходят на роутер, они проходят только global-in и global-total HTB.

Когда пакеты уходят с роутера, они проходят только global-out, global-total и inerface HTB.

Если очередь имеет по крайней мере одного потомка – она является родительской очередью.

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

Потомки создают реальное потребление трафика, родители отвечают только за распределение трафика.

Потомки получат сначала предел трафика limit-at, а остальной трафик будет распределен родителями.

HTB имеет два предела cкорости:
— CIR (гарантированная скорость передачи данных) — (limit-at в RouterOS): при худшем сценарии поток получит это количество трафика, несмотря ни на что (при условии, что мы можем на самом деле отправить так много данных).

— MIR (максимальная скорость передачи данных) — (max-limit в RouterOS): при лучшем сценарии, скорость потока может быть повышена, если родительская очередь имеет запас полосы пропускания.

Первым делом HTB будет стараться удовлетворить каждого потомка скоростью limit-at — и только затем будет пытаться достичь max-limit.

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

MIR (родитель) ≥ CIR(потомок_1) +...+ CIR(потомок_N).

Максимальная скорость любого потомка должна меньше или равна максимальной скорости родителя.

MIR (родитель) ≥ MIR(потомок_1)
MIR (родитель) ≥ MIR(потомок_2)
MIR (родитель) ≥ MIR(потомок_N)

Приоритет работает только для потомков (нет смысла менять приоритет у родителей)
1 – высший приоритет
8 – низший приоритет

Очередь с более высоким приоритетом получает возможность получить максимальную скорость (max-limit) раньше очередей с более низким приоритетом.

Фактическая приоритезация трафика будет работать, только если заданы лимиты. Очередь без лимитов не будет “приоритезироваться”.

Burst:
Функция QoS «Burst» является одним из лучших способов улучшить качество веб-сёрфинга для клиентов.

Burst позволяет обеспечивать более высокие скорости передачи данных на короткий период времени.

Если средняя скорость передачи данных меньше чем Burst порог (burst-threshold), burst может быть использован (фактическая скорость передачи данных может достигать лимита burst-limit).

Средняя скорость передачи данных рассчитывается от последних burst-time секунд.

Средняя скорость передачи данных вычисляется следующим образом:

— burst-time делится на 16 отрезков;

— роутер рассчитывает среднюю скорость передачи данных каждого класса на этих маленьких отрезках;

Обратите внимание, что фактический отрезок времени burst — это не тоже самое что burst-time. Он может быть в несколько раз меньше, чем burst-time, в зависимости от max-limit, burst-limit, burst-threshold и фактической истории скорости передачи данных.

Размер очереди:
Размер очереди оказывает непосредственное влияние на производительность очереди — это выбор между потерей пакетов и увеличением латентности (задержки).

В RoutesOS размер очереди является общим для одного типа очереди (т.е. очередей одного типа может быть много — но размер очереди будет одинаковый — и поэтому задается в Queue Types).

Разрушение легенд:

‣ HTB приоритезация не меняет последовательность пакетов — не переставляет одни пакеты раньше других;

‣ В HTB — приоритезация является инструментом, который помогает решить — какие пакеты будут проходить дальше, а какие будут отброшены.

‣ Решение дропать пакет основывается на лимитах — таким образом, если пределы скоростей не установлены, то приоритеты не имеют никакого эффекта.

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

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

‣ На диаграмме движения пакетов видно, что HTB global-in находится после входного интерфейса, где регистрируется к-во пришедшего на роутер трафика.

‣ При этом эффект снижения трафика, скорее всего, является эффектом поведения протокола TCP.

‣ Единственный способ увидеть QoS в действии является мониторинг передачи данных (TX) противоположного интерфейса.

Другими словами — Вы никак не можете повлиять с помощью своего QoS на тот реальный входящий трафик, что уже фактически пришел на любой из интерфейсов роутера – ведь ни ваши юзеры, ни “мир” — ничего не знают про ваш QoS.
!!! Но это не значит – что QoS не работает.

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

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

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

Много споров о том, возможен ли двойной QoS (Double QoS) в Mikrotik Router OS.

Ответ — возможно.

Под двойным QoS подразумевается — одновременно шейпить по типу трафика (например, поджать суммарный p2p и дать приоритет web трафику в часы наивысшей нагрузки (ЧНН), и при этом нарезать скорость отдельно каждому юзеру (по тарифу).

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

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

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

Еще одно важное замечание — некоторые вещи, сказанные выше — относятся только для версий MikroTik ROS 4 и 5.
6-ая версия имеет существенные отличия. Например — там полностью переработаны Simple Queue и изменена диаграмма движения пакетов.

Об этом позже…

Очень подробно с примерами разных тарифов про настройку шейпера можно найти в моей статье на xgu.ru:
xgu.ru/wiki/Биллинг_Ideco_АСР_%2B_MikroTik_ROS.

Вся эта информация и даже более и плюс картинки можно найти в моих переводах официальных презентаций там:
wiki.mikrotik.com/wiki/Russian/QoS
и
wiki.mikrotik.com/wiki/Russian/QoS2011

P.S. Итог:
!!! QoS работает.

Просто надо понимать как и для каких задач использовать механизмы управления трафиком и уметь это «готовить»
(иметь мозг).

Автор: white_crow

Источник