Перед тем, как настраивать роутер (не важно — офисный аппаратный роутер за 50 долларов или программный роутер на базе сервера с двумя 4-х ядерными процессорами) — важно понимать, как пакеты двигаются по цепочкам (изучить в онлайн документации Диаграммы движения пакетов — Packet Flow Diagrams).
Невозможно должным образом управлять и поддерживать сложные конфигурации без понимания того — что, где, когда и почему происходит.
В случае бриджинга трафика (Layer 2 (MAC)) — роутинг представлен ввидечерного серого «ящика» Layer3,
…
в случае роутинга трафика (Layer 3 (IP)) — бриджинг представлен ввиде серого «ящика» bridging,
Сокращенная диаграмма:
Здесь и далее под QoS в MikroTik ROS — подразумевается шейпинг.
Shaping — «изменять форму».
Т.е. изменяем форму графиков загрузки интерфейсов — управляем пропускной способностью, устанавливая ограничения (limit) либо по типу трафика, либо по «юзерам» или «сервисам» (по их IP адресам, портам и прочим критериям).
В разных контекстах для различного оборудования или ПО такие понятия как QoS (качество обслуживания), шейпинг, полисинг, приоритезация — может иметь другой «оттенок смысла». Существует множество концепций, реализаций, алгоритмов.
Вся реализация управления пропускной способностью в RouterOS основана на иерархии — Hierarchical Token Bucket (HTB).
HTB позволяет вам создавать иерархические (древовидные) структуры очередей и определять отношения между ними.
RouterOS 5.x поддерживает 3 виртуальных HTBs (global-in, global-total, global-out) и еще один прямо перед каждым выходным интерфейсом:
Важно понимать, что через роутер проходит несколько потоков.
Здесь не имеется ввиду сессии TCP/UDP.
Например, в самом простом случае имеем один физический интерфейс роутера — Public,
и второй физический интерфейс — Local.
Итого — имеем два потока пакетов, проходящих через роутер — назовем условно Download и Upload потоки.
Для Download трафика входным интерфейсом будет Public, выходным интерфейсом будет Local.
И, наоборот, для Upload трафика входным интерфейсом будет Local, выходным интерфейсом будет Public.
При этом диаграмма движения пакетов и логика обработки потоков будет будет абсолютно одинаковой для обоих потоков.
Другими словами — для роутера не имеет значения роль интерфейса — т.е. разделение на Public и Local — условно.
Download поток
Upload поток
_______________________________________________________________________________
Существует заблуждение, что в ROS не работает шейпинг + NAT + PCQ тип очереди.
Таки работает замечательно.
Я гарантирую это.
Указывайте 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 и фактической истории скорости передачи данных.
Использовать Burst имеет смысл либо только дома или в маленьком офисе. Либо у относительно небольшого провайдера с «маленькими» тарифами — например 256k, 512k, 1024k. Т.к. тарифы от 2 мегабит и выше уже в любом случае достаточно комфортны для веб серфинга — поэтому эффект от бёрст будет малозаметен.
При большом количестве юзеров и современных тарифах использовать burst может быть нецелесообразно с точки зрения производительности программного роутера (но решать Вам).
Размер очереди:
Размер очереди оказывает непосредственное влияние на производительность очереди — это выбор между потерей пакетов и увеличением латентности (задержки).
В RoutesOS размер очереди является общим для одного типа очереди (т.е. очередей одного типа может быть много — но размер очереди будет одинаковый — и поэтому задается в Queue Types).
Разрушение легенд:
Вот как всё на самом деле РАБОТАЕТ:
‣ HTB приоритезация не меняет последовательность пакетов — не переставляет одни пакеты раньше других;
‣ В HTB — приоритезация является инструментом, который помогает решить — какие пакеты будут проходить дальше, а какие будут отброшены.
‣ Решение дропать пакет основывается на лимитах — таким образом, если пределы скоростей не установлены, то приоритеты не имеют никакого эффекта.
‣ Приоритет также никак не влияет на трафик пакетов, двигающихся со скоростью меньше или равной гарантированной (CIR). Пакеты просто проходят сквозь алгоритм QoS (даже если родители реально не могут обеспечить такую пропускную способность).
‣ QoS не может контролировать количество приходящего трафика, который вы видите на любом из интерфейсах роутера.
‣ На диаграмме движения пакетов видно, что HTB global-in находится после входного интерфейса, где регистрируется к-во пришедшего на роутер трафика.
‣ При этом эффект снижения трафика, скорее всего, является эффектом поведения протокола TCP.
‣ Единственный способ увидеть QoS в действии является мониторинг передачи данных (TX) противоположного интерфейса.
Другими словами — Вы никак не можете повлиять с помощью своего QoS на тот реальный входящий трафик, что уже фактически пришел на любой из интерфейсов роутера – ведь ни ваши юзеры, ни “мир” — ничего не знают про ваш QoS.
!!! Но это не значит – что QoS не работает.
Вы же можете манипулировать трафиком всех потоков (как Download так и Upload) внутри роутера — решая — как, сколько и какой трафик уйдет с роутера (пройдет сквозь роутер далее).
‣ QoS не может знать, какова фактическая пропускная способность доступна.
‣ Драйвер выходного интерфейса является первым, кто может знать, какую пропускную способность вы фактически имеете. Но в диаграмме движения пакетов видно, что выходной интерфейс находится уже после всех HTB.
‣ Драйвер интерфейса знает лишь максимальное аппаратное ограничение интерфейса, но если фактическое ограничение меньше — единственный способ обеспечить алгоритм QoS информацией о реальной пропускной способности — указать вручную явно все пределы.
(Причем некоторые администраторы сети рекомендуют указать 80-90% от максимальной суммарной пропускной способности канала — чтобы гарантировать создание очереди у себя, т.е. создать запас пропускной способности, а иначе «лишний» трафик зря дропнется у вашего вышестоящего провайдера, который тоже режет скорость вам — согласнокупленных билетов оплаченной полосы.
Конечно — речь идет о гарантированном канале со стороны вышестоящего провайдера, либо негарантированном, но стабильном — по факту — большую часть суток.
Я лично не практикую это, т.к. выполняю следующее правило — «вовремя расширять внешний канал с небольшим запасом фактической утилизации в ЧНН». Благо — нет технических/экономических ограничений (но не у всех такая же ситуация).
Много споров о том, возможен ли двойной QoS (Double QoS) в Mikrotik Router OS.
Ответ — возможен.
Под двойным QoS подразумевается — одновременно шейпить по типу трафика (например, поджать суммарный p2p и дать приоритет web трафику в часы наивысшей нагрузки (ЧНН), и при этом нарезать скорость отдельно каждому юзеру (по тарифу).
Например вот так:
1. шейпинг по типу трафика:
— маркировка трафика в мангл прероутинг — шейпинг в глобал-ин
2. нарезка полосы по юзерам:
— маркировка трафика в мангл форвард — шейпинг в глобал-аут
Идентифицировать трафик по его типу — это творческая работа, имеющая множество решений, и это выходит за рамки этой статьи.
Шейпить по типу трафика можно или нужно — когда у вас есть проблемы с доступностью необходимой полосы (технические/финансовые) и когда у Вас относительно немного юзеров — (дом/офис/небольшая сеть) — когда вы знаете — какие протоколы/сервисы/приложения используются в сети и у вас есть обратная связь с юзерами. потому что легко зарезать полезный трафик, особенно когда протоколы/сервисы/приложения бурно меняются.
Т.е. постоянно нужно держать руку на пульсе и обновлять сигнатуры :)
Я не практикую шейпинг по типу трафика — по следующим причинам:
— нет проблем с расширением канала
— не имею право решать за пользователей — какой тип трафика хуже или лучше другого (например — с какого перепугу я имею право торренты подрезать)
— количество пользователей, а значит сервисов, протоколов и типов трафика столько много — что постоянно следить за этим не представляется возможным.
— именно из-за большого количества юзеров (тысячи их) — идентификация трафика по его типам — займет очень много ресурсов программного роутера. Эту работу должна делать специализированная железка операторского уровня (такие штуки, например, ставят операторы сотовой связи — тобишь ОПСОСы — иначе вы убъете торрентами весьма ограниченный частотный ресурс)
Я просто нарезаю клиентам скорости по тарифам и забываю про существования серверов/роутеров/коммутаторов на очень долго.
Важное замечание — когда мы говорим о шейпинге по типу трафика — то речь идет о суммарном трафике всего роутера, а не о приоритезации по типу трафика внутри полосы каждого пользователя. Хотя это тоже возможно — но требует огромной вычеслительной мощности (будет очень много прафил Firewall для каждого юзера), и если речь идет о сотнях/тысячах пользователей, то не следует этого делать — это работа для аппаратных железок, которые стоят порядка сотни тысяч долларов.
Если речь идет о доме или маленьком офисе — тогда это вполне реально сделать, чтобы ваш брат, качая торренты, не ухудшал себе веб серфинг, и совсем никак не мешал сестре и маме. Для этого папа должен настроить QoS и сжечь пароль от роутера. А если старший брат скинул роутер в дефолтные настройки — чтобы обнулить/сменить пароль — то онполучает п***ей лишается карманных денег и получает домашний арест на неделю и должен прочитать и перерассказать роман «Война и мир».
Еще одно важное замечание — некоторые вещи, сказанные выше — относятся только для версий MikroTik ROS 4 и 5.
6-ая версия имеет существенные отличия. Например — там полностью переработаны Simple Queue и изменена диаграмма движения пакетов.
Об этом в переводе презентации:
Что нового в 6-ой версии MikroTik RouterOS
Очень подробно с примерами разных тарифов про настройку шейпера можно найти в моей статье на xgu.ru:
xgu.ru/wiki/Биллинг_Ideco_АСР_%2B_MikroTik_ROS.
Вся эта информация и даже более и плюс картинки можно найти в моих переводах официальных презентаций там:
wiki.mikrotik.com/wiki/Russian/QoS
и
wiki.mikrotik.com/wiki/Russian/QoS2011
P.S. Итог:
!!! QoS работает.
Просто надо понимать как и для каких задач использовать механизмы управления трафиком и уметь это «готовить»
(иметь мозг).
Невозможно должным образом управлять и поддерживать сложные конфигурации без понимания того — что, где, когда и почему происходит.
В случае бриджинга трафика (Layer 2 (MAC)) — роутинг представлен ввиде
…
в случае роутинга трафика (Layer 3 (IP)) — бриджинг представлен ввиде серого «ящика» bridging,
Сокращенная диаграмма:
Здесь и далее под QoS в MikroTik ROS — подразумевается шейпинг.
Shaping — «изменять форму».
Т.е. изменяем форму графиков загрузки интерфейсов — управляем пропускной способностью, устанавливая ограничения (limit) либо по типу трафика, либо по «юзерам» или «сервисам» (по их IP адресам, портам и прочим критериям).
В разных контекстах для различного оборудования или ПО такие понятия как QoS (качество обслуживания), шейпинг, полисинг, приоритезация — может иметь другой «оттенок смысла». Существует множество концепций, реализаций, алгоритмов.
Вся реализация управления пропускной способностью в RouterOS основана на иерархии — Hierarchical Token Bucket (HTB).
HTB позволяет вам создавать иерархические (древовидные) структуры очередей и определять отношения между ними.
RouterOS 5.x поддерживает 3 виртуальных HTBs (global-in, global-total, global-out) и еще один прямо перед каждым выходным интерфейсом:
Важно понимать, что через роутер проходит несколько потоков.
Здесь не имеется ввиду сессии TCP/UDP.
Например, в самом простом случае имеем один физический интерфейс роутера — Public,
и второй физический интерфейс — Local.
Итого — имеем два потока пакетов, проходящих через роутер — назовем условно Download и Upload потоки.
Для Download трафика входным интерфейсом будет Public, выходным интерфейсом будет Local.
И, наоборот, для Upload трафика входным интерфейсом будет Local, выходным интерфейсом будет Public.
При этом диаграмма движения пакетов и логика обработки потоков будет будет абсолютно одинаковой для обоих потоков.
Другими словами — для роутера не имеет значения роль интерфейса — т.е. разделение на Public и Local — условно.
Download поток
Upload поток
_______________________________________________________________________________
Существует заблуждение, что в ROS не работает шейпинг + NAT + PCQ тип очереди.
Таки работает замечательно.
Я гарантирую это.
Указывайте 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 и фактической истории скорости передачи данных.
Использовать Burst имеет смысл либо только дома или в маленьком офисе. Либо у относительно небольшого провайдера с «маленькими» тарифами — например 256k, 512k, 1024k. Т.к. тарифы от 2 мегабит и выше уже в любом случае достаточно комфортны для веб серфинга — поэтому эффект от бёрст будет малозаметен.
При большом количестве юзеров и современных тарифах использовать burst может быть нецелесообразно с точки зрения производительности программного роутера (но решать Вам).
Размер очереди:
Размер очереди оказывает непосредственное влияние на производительность очереди — это выбор между потерей пакетов и увеличением латентности (задержки).
В RoutesOS размер очереди является общим для одного типа очереди (т.е. очередей одного типа может быть много — но размер очереди будет одинаковый — и поэтому задается в Queue Types).
Разрушение легенд:
Вот как всё на самом деле РАБОТАЕТ:
‣ HTB приоритезация не меняет последовательность пакетов — не переставляет одни пакеты раньше других;
‣ В HTB — приоритезация является инструментом, который помогает решить — какие пакеты будут проходить дальше, а какие будут отброшены.
‣ Решение дропать пакет основывается на лимитах — таким образом, если пределы скоростей не установлены, то приоритеты не имеют никакого эффекта.
‣ Приоритет также никак не влияет на трафик пакетов, двигающихся со скоростью меньше или равной гарантированной (CIR). Пакеты просто проходят сквозь алгоритм QoS (даже если родители реально не могут обеспечить такую пропускную способность).
‣ QoS не может контролировать количество приходящего трафика, который вы видите на любом из интерфейсах роутера.
‣ На диаграмме движения пакетов видно, что HTB global-in находится после входного интерфейса, где регистрируется к-во пришедшего на роутер трафика.
‣ При этом эффект снижения трафика, скорее всего, является эффектом поведения протокола TCP.
‣ Единственный способ увидеть QoS в действии является мониторинг передачи данных (TX) противоположного интерфейса.
Другими словами — Вы никак не можете повлиять с помощью своего QoS на тот реальный входящий трафик, что уже фактически пришел на любой из интерфейсов роутера – ведь ни ваши юзеры, ни “мир” — ничего не знают про ваш QoS.
!!! Но это не значит – что QoS не работает.
Вы же можете манипулировать трафиком всех потоков (как Download так и Upload) внутри роутера — решая — как, сколько и какой трафик уйдет с роутера (пройдет сквозь роутер далее).
‣ QoS не может знать, какова фактическая пропускная способность доступна.
‣ Драйвер выходного интерфейса является первым, кто может знать, какую пропускную способность вы фактически имеете. Но в диаграмме движения пакетов видно, что выходной интерфейс находится уже после всех HTB.
‣ Драйвер интерфейса знает лишь максимальное аппаратное ограничение интерфейса, но если фактическое ограничение меньше — единственный способ обеспечить алгоритм QoS информацией о реальной пропускной способности — указать вручную явно все пределы.
(Причем некоторые администраторы сети рекомендуют указать 80-90% от максимальной суммарной пропускной способности канала — чтобы гарантировать создание очереди у себя, т.е. создать запас пропускной способности, а иначе «лишний» трафик зря дропнется у вашего вышестоящего провайдера, который тоже режет скорость вам — согласно
Конечно — речь идет о гарантированном канале со стороны вышестоящего провайдера, либо негарантированном, но стабильном — по факту — большую часть суток.
Я лично не практикую это, т.к. выполняю следующее правило — «вовремя расширять внешний канал с небольшим запасом фактической утилизации в ЧНН». Благо — нет технических/экономических ограничений (но не у всех такая же ситуация).
Много споров о том, возможен ли двойной QoS (Double QoS) в Mikrotik Router OS.
Ответ — возможен.
Под двойным QoS подразумевается — одновременно шейпить по типу трафика (например, поджать суммарный p2p и дать приоритет web трафику в часы наивысшей нагрузки (ЧНН), и при этом нарезать скорость отдельно каждому юзеру (по тарифу).
Например вот так:
1. шейпинг по типу трафика:
— маркировка трафика в мангл прероутинг — шейпинг в глобал-ин
2. нарезка полосы по юзерам:
— маркировка трафика в мангл форвард — шейпинг в глобал-аут
Идентифицировать трафик по его типу — это творческая работа, имеющая множество решений, и это выходит за рамки этой статьи.
Шейпить по типу трафика можно или нужно — когда у вас есть проблемы с доступностью необходимой полосы (технические/финансовые) и когда у Вас относительно немного юзеров — (дом/офис/небольшая сеть) — когда вы знаете — какие протоколы/сервисы/приложения используются в сети и у вас есть обратная связь с юзерами. потому что легко зарезать полезный трафик, особенно когда протоколы/сервисы/приложения бурно меняются.
Т.е. постоянно нужно держать руку на пульсе и обновлять сигнатуры :)
Я не практикую шейпинг по типу трафика — по следующим причинам:
— нет проблем с расширением канала
— не имею право решать за пользователей — какой тип трафика хуже или лучше другого (например — с какого перепугу я имею право торренты подрезать)
— количество пользователей, а значит сервисов, протоколов и типов трафика столько много — что постоянно следить за этим не представляется возможным.
— именно из-за большого количества юзеров (тысячи их) — идентификация трафика по его типам — займет очень много ресурсов программного роутера. Эту работу должна делать специализированная железка операторского уровня (такие штуки, например, ставят операторы сотовой связи — тобишь ОПСОСы — иначе вы убъете торрентами весьма ограниченный частотный ресурс)
Я просто нарезаю клиентам скорости по тарифам и забываю про существования серверов/роутеров/коммутаторов на очень долго.
Важное замечание — когда мы говорим о шейпинге по типу трафика — то речь идет о суммарном трафике всего роутера, а не о приоритезации по типу трафика внутри полосы каждого пользователя. Хотя это тоже возможно — но требует огромной вычеслительной мощности (будет очень много прафил Firewall для каждого юзера), и если речь идет о сотнях/тысячах пользователей, то не следует этого делать — это работа для аппаратных железок, которые стоят порядка сотни тысяч долларов.
Если речь идет о доме или маленьком офисе — тогда это вполне реально сделать, чтобы ваш брат, качая торренты, не ухудшал себе веб серфинг, и совсем никак не мешал сестре и маме. Для этого папа должен настроить QoS и сжечь пароль от роутера. А если старший брат скинул роутер в дефолтные настройки — чтобы обнулить/сменить пароль — то он
Еще одно важное замечание — некоторые вещи, сказанные выше — относятся только для версий MikroTik ROS 4 и 5.
6-ая версия имеет существенные отличия. Например — там полностью переработаны Simple Queue и изменена диаграмма движения пакетов.
Об этом в переводе презентации:
Что нового в 6-ой версии MikroTik RouterOS
Очень подробно с примерами разных тарифов про настройку шейпера можно найти в моей статье на xgu.ru:
xgu.ru/wiki/Биллинг_Ideco_АСР_%2B_MikroTik_ROS.
Вся эта информация и даже более и плюс картинки можно найти в моих переводах официальных презентаций там:
wiki.mikrotik.com/wiki/Russian/QoS
и
wiki.mikrotik.com/wiki/Russian/QoS2011
P.S. Итог:
!!! QoS работает.
Просто надо понимать как и для каких задач использовать механизмы управления трафиком и уметь это «готовить»
(иметь мозг).
