Принцип ділити все і вся існує стільки, скільки мільярдів років існує Всесвіт. Найчастіше об'єкти діляться в однакових пропорціях і нерівний отхваченний шматок ким або чим-небудь викликає невдоволення поділених. Подібні ситуації часто виникають тоді, коли об'єкт ділення має вагоме значення в системі. Перенесемося в 21 століття. Спостерігаючи процеси в суспільстві і, в першу чергу в інформаційній сфері, можна помітити, що розумно ділити все-таки навчилися. І, часом алгоритми настільки непідробні і стійкі, що не залишають жодної можливості взяти більше або менше дозволеного. Застосувавши все вищевикладене до передачі даних можна зрозуміти про що йде мова.
Сучасне суспільство і кожна людина в ньому вимагає до себе однакового ставлення у всіх сферах, що часто стає головним болем для тих, хто надає послуги. Зокрема торкаючись надання послуг доступу до Інтернету за останні кілька років стався величезний прорив, що дозволив вирішити ряд проблем, породжених появою всесвітньої павутини у нас в будинках і на роботі, перетворивши її з якогось делікатесу в фаст-фуд для сотень тисяч людей.
Для початку розглянемо кілька понять, якими ми будемо користуватися надалі.
Технологія, яка дозволяє обмежувати швидкість і якість доступу в Інтернет, називається шейпінг (від англ. Shape - форма). Образно кажучи - це технологія надання якоїсь форми графіку завантаження каналу.
Шейпер - це алгоритм, який крім управління черговістю пакетів дозволяє відкидати не відповідають умовам. До таких належать алгоритми PCQ і HTB (про них поговоримо трохи пізніше).
Під-чергу - черга, сформована з пакетів з того чи іншою ознакою.
Queuing discipline (qdisc - дисципліна черги) - алгоритм, який захоплює пакети і точно визначає в якому порядку і яким чином вони будуть рухатися.
В основі шейпінгу, використовуваного в Mikrotik, лежить дисципліна черги HTB, реалізована в багатьох Linux-системах. Її вивчення є досить складною, однак необхідним завданням для новачка, тому як без цих знань далі невдалих спроб і копіювання правил з документації мало хто заходить.
Список основних можливостей з управління трафіком в Mikrotik виглядає наступним чином:
Ключовим поняттям для HTB є клас. Приставка Hierarhical в абревіатурі HTB означає, що дисципліна дозволяє будувати ієрархію класів.
Схематично ієрархію класів (для спрощення будемо називати класи правилами) HTB можна представити у вигляді такого собі гібридного розділеного рівнями дерева, кінцевими вершинами якого є клієнти. Класи, які не мають дочірніх, будемо називати клієнтами або листям. Зазвичай вони знаходяться на нульовому рівні ієрархії і першими захоплюють відноситься до них трафік, передаючи його батькам. Два або більше класу, що мають одного прямого батька знаходяться на одному рівні і приєднані до однієї локальної вихідний черги.
Схематичне зображення структури HTB
На схемі вище зображена ієрархія класів, в яку з брандмауера (Filter) надходять пакети з даними. Залежно від пріоритету, параметрів класів і завантаження каналу вони потрапляють або в локальні черги (Self Feed), або передаються в черзі батьківських класів (Inner Feed).
Клас характеризують такі параметри:
Клас може перебувати в одному з трьох станів:
- Зелений - пропускна здатність правила не перевищує параметр limit-at. В цьому випадку пакети не рухаються вгору по ієрархії, а переміщаються відразу в вихідний потік свого рівня відповідно до пріоритетів.
- Жовтий - пропускна здатність правила більше limit-at, але менше max-limit. В цьому випадку клас відключається від вихідного потоку свого рівня і підключається до батьківського класу.
- Червоний - пропускна здатність правила більше max-limit. У цьому стані клас відключається від батьківського і підключається до локальної черзі.
Користуючись вже навіть цими даними, можна складати правила, однак на практиці деякі речі можуть виглядати дещо інакше.
У Mikrotik передбачено два типи правил, рознесені на різні закладки в графічній утиліті Winbox (з її допомогою можна конфігурувати Mikrotik з-під Windows):
Про них ми поговоримо трохи пізніше, а зараз розглянемо кілька прикладів роботи HTB
Створимо кілька правил
[Admin @ MikroTik] queue tree> add name = ClassA parent = Local max-limit = 2048000
[Admin @ MikroTik] queue tree> add name = ClassB parent = ClassA max-limit = 1024000
[Admin @ MikroTik] queue tree> add name = Leaf1 parent = ClassA max-limit = 2048000
. limit-at = 1024000 packet-mark = packet_mark1 priority = 8
[Admin @ MikroTik] queue tree> add name = Leaf2 parent = ClassB max-limit = 1024000
. limit-at = 256000 packet-mark = packet_mark2 priority = 7
[Admin @ MikroTik] queue tree> add name = Leaf3 parent = ClassB max-limit = 1024000
. limit-at = 768000 packet-mark = packet_mark3 priority = 8
[Admin @ MikroTik] queue tree> print
Flags: X - disabled, I - invalid
0 name = "ClassA" parent = Local packet-mark = "" limit-at = 0 queue = default
priority = 8 max-limit = 2048000 burst-limit = 0 burst-threshold = 0
burst-time = 0s
1 name = "ClassB" parent = ClassA packet-mark = "" limit-at = 0 queue = default
priority = 8 max-limit = 1024000 burst-limit = 0 burst-threshold = 0
burst-time = 0s
2 name = "Leaf1" parent = ClassA packet-mark = packet_mark1 limit-at = 1024000
queue = default priority = 8 max-limit = 2048000 burst-limit = 0
burst-threshold = 0 burst-time = 0s
3 name = "Leaf2" parent = ClassB packet-mark = packet_mark2 limit-at = 256000
queue = default priority = 7 max-limit = 1024000 burst-limit = 0
burst-threshold = 0 burst-time = 0s
4 name = "Leaf3" parent = ClassB packet-mark = packet_mark3 limit-at = 768000
queue = default priority = 8 max-limit = 1024000 burst-limit = 0
burst-threshold = 0 burst-time = 0s
[Admin @ MikroTik] queue tree>
1. Розглянемо перший випадок, коли клієнти 1 і 2 передають дані зі швидкістю менше, ніж зазначено в параметрі limit-at, а клієнт 3 не працює.
Як бачимо, пакети з даними від leaf1 і leaf2 (клієнти) не передаються в батьківські класи, а шикуються в локальну чергу відповідно до своїх пріоритетів
2. Зараз подивимося що буде, в разі якщо клієнт leaf2 буде передавати дані зі швидкістю більше limit-at, але менше max-limit зазначених в його параметрах і менше limit-at в параметрах ClassB, до якого він прикріплений. Одночасно з ним leaf1 буде передавати дані зі швидкістю не перевищує limit-at.
В даному випадку виходить цікава ситуація: клієнт leaf1 матиме більший пріоритет, ніж leaf2, хоча в параметрах останнього вказано більший пріоритет. Це пов'язано з тим, що передаючи дані зі швидкістю більше limit-at leaf2 підключився до батьківського класу, що має пріоритет 8. При цьому існує правило, що на нижніх рівнях пріоритет пакетів при однакових умовах більше, ніж на верхніх.
3. Розглянемо наступний приклад: швидкості передачі даних для leaf1 перевищила допустимий max-limit, клієнт leaf2 передає дані на швидкості більше limit-at і менше max-limit, клієнт leaf3 працює на швидкості менше limit-at.
Це дуже цікавий випадок. У даній ситуації видно, що ClassA перевантажений даними з Leaf1, тому ClassB не отримає дозволу на передачу.В результаті працездатним виявиться тільки клієнт leaf3, підключений до локальної чергу на нульовому рівні.
4. Тепер розглянемо приклад, коли дані будуть одночасно передавати leaf1, leaf2, leaf3, ClassB буде жовтим, а ClassA зеленим.
В результаті цього на другому рівні leaf2 потрапить в чергу першим (так як має більший пріоритет), а leaf1 і leaf3 піддадуться випадковим вибором для визначення порядку проходження.
Як бачимо алгоритм роботи HTB вельми логічна і не так уже й складний, як могло здатися відразу. Він був прийнятий багатьма виробниками програмного і апаратного забезпечення за свою гнучкість, надійність і відсутність властивих його попередникам недоліків. Завдяки величезній універсальності за допомогою нього можна будувати практично будь-які можливі ієрархії правил, в точності розмежовуючи і даючи можливість управляти потоками даних на досить низькому рівні.
Часто виникає необхідність видати так звану пікову швидкість клієнту на певний проміжок часу. Наприклад, іноді потрібно прискорити завантаження сторінок, залишивши при цьому середню швидкість на закачку файлів не вище відведеної. Або потрібно рідко посилати запити та отримувати дані, але робити це з максимальною швидкістю. Нерозумно було б в такому випадку видавати клієнту велику швидкість, так як в один прекрасний момент через необережність або злого умислу інші користувачі можуть залишитися або зовсім без Інтернету, або отримувати його не таким, яких хотілося і за скільки заплачено.
Розробники Mikrotik надали в розпорядження всі необхідні інструменти для управління описаної вище піковою швидкістю. Наступні параметри характеризують її поведінку:
- burst-limit - швидкість, яка буде доступна відразу при підключенні;
- burst-threshold - середня швидкість за останні burst-time секунд;
- burst-time - час для підрахунку burst-threshold.
Момент, коли клієнту або класу потрібно видати максимальну швидкість, визначається наступним чином. Раз в 1/16 часу burst-time обчислюється завантаження каналу на вказане число секунд. Якщо середнє завантаження не дотягувала до burst-threshold, то клієнтові або класу виділяється зазначена в burst-limit швидкість до тих пір, поки вона не перевищить burst-threshold. Після цього діє обмеження max-limit до тих пір, поки знову не станеться зниження швидкості менш burst-threshold.
Даний графік характерний для випадку із закачуванням великого файлу по протоколу http. Після першої секунди середнє завантаження каналу буде дорівнює (0 + 0 + 0 + 0 + 0 + 0 + 0 + 512) / 8 = 64 kbps, що менше встановленого нами параметра burst-threshold. Після другої секунди середня швидкість буде дорівнює (0 + 0 + 0 + 0 + 0 + 0 + 512 + 512) / 8 = 128kbps. Після третьої секунди середня швидкість перевищить показник burst-threshold. У цей момент швидкість різко впаде до значення параметра max-limit і буде триматися на цьому рівні до тих пір, поки середнє завантаження каналу не стане менше burst-threshold і знову не відбудеться видача burst швидкості.
Розглянемо алгоритми так званих Schedulers, про які згадувалося вище. Зазвичай вони застосовуються разом з Шейпера, проте деякі з них так само мають функції обмеження швидкості. Фізично Scheduler передує Шейпера і представляє йому вже підготовлені черзі пакетів, до яких слід застосовувати ограніенія.
Packet / Bytes (FIFO) алгоритм, заснований на принципі перший прийшов-перший пішов. Використовується для ethernet-інтерфейсів. Єдиний параметр, іспользуемвий для конфігурації даного алгоритму, - це pfifo-limit (bfifo-limit). Він вказує на кількість байт, які можуть зберігатися у вихідному буфері. Хто не потрапив до буфер пакети будуть руйнуватися. Графічно алгоритм можна зобразити за допомогою такої схеми. По суті справи PFIFO / BFIFO нічого особливого з себе не представляє і ніяких привілеїв не дає. Він просто є і використовується там, де його використовувати доцільно ...
SFQ (Stochastic Fairness Queuing) - цей алгоритм можна назвати "випадково-чесним". Він застосовується тоді, коли потрібно надати всім TCP / UDP-підключень однакову можливість по передачі даних. Для конфігурації SFQ використовується два параметри:
- sfq-perturb - вказує через який час потрібно міняти хешірующій алгоритм, який визначає як будуть формуватися під-чергу запитів;
- pcq-allot - визначає кількість байт в під-черзі.
SFQ працює за наступним принципом: алгоритм вилучення пакетів з підчерги одночасно випускає в вихідний інтерфейс pcq-allot кількість байт, а хешірующій алгоритм додає до кожного під-черзі pcq-allot байт, зберігаючи при цьому рівновагу і однакову довжину всіх підчерги. Схему роботи SFQ можна порівняти з м'ясорубкою, в якій через вихідну решітку одночасно з усіх дірок в однаковій кількості виходить фарш :).
Алгоритм SFQ рекомендується використовувати у випадках, коли канал сильно завантажений і необхідно надати додаткам однакову можливість по передачі даних. Єдиним його недоліком є те, що один додаток, відкривши багато потоків, може заглушити інші підключення.
RED (Random Early Detection) - алгоритм, покликаний вирівнювати пропускну здатність і згладжувати стрибки, контролюючи середній розмір черги. Коли її розмір досягає значення red-min-threshold алгоритм видаляє випадково обраний пакет. Число віддалених пакетів зростає зі збільшенням среднег розміру черги. Якщо розмір досягає значення red-max-threshold все пакети видаляються. Однак трапляються ситуації, коли реальний розмір черги (не середній) значно більше red-max-threshold. У такому випадку всі пакети, що виходять за рамки меж red-limit. видаляються.
Використання алгоритму вкрай не бажано при присутності UDP-трафіку, так як в зв'язку з нерозбірливістю алгоритму при видаленні пакетів з черги і принципом роботи UDP-протоколу, дані можуть не дійти до одержувача.
Від теорії до практики
Зараз ми знаємо все необхідне для того, щоб побудувати необхідні нам правила. Так як на практиці застосування алгоритмів SFQ і RED використовується вкрай рідко, то на прикладах їх роботи ми зупинятися не будемо.
Queue Trees - особливий тип черг, який прямо відображає пристрій Шейпера HTB. Він дозволяє будувати дерева правил (класів) і на найнижчому рівні управляти пакетами.
Коротенько пояснимо значення основних елементів управління, присутніх в Queue Trees:
- burst-limit (ціле) - максимальна burst-швидкість;
- burst-threshold (ціле) - середнє завантаження каналу, при якій дозволено видати burst-limit;
- burst-time (час) - використовується для підрахунку середнього завантаження каналу;
- flow (text) - потік, маркований в / ip firewall mangle;
- limit-at (ціле) - гарантована швидкість;
- max-limit (ціле) - максимальна швидкість;
- name (text) - ім'я черги;
- parent (text) - батько в ієрархії класів HTB;
- priority (ціле: 1..8) - пріоритет черги;
- queue (text) - тип черги. Здається в / queue type.
I. Отже, створимо правило, яке дозволить отримати клієнтам локальної або віртуальної мережі максимальну швидкість і мінімальний час відгуку при зверненні до сайту www.x-drivers.ru. проте розділить швидкість між усіма порівну.
/ Ip firewall mangle add chain = forward src-address = 192.168.11.0 / 24 dst-address = 66.148.73.54 / 32 action = mark-connection new-connection-mark = users-con-up
/ Ip firewall mangle add connection-mark = users-con-up action = mark-packet
new-packet-mark = users-up chain = forward
/ Ip firewall mangle add chain = forward src-address = 66.148.73.54 / 32
action = mark-connection new-connection-mark = users-con-down
/ Ip firewall mangle add connection-mark = users-con-down action = mark-packet
new-packet-mark = users-down chain = forward
/ Queue type add name = pcq-download kind = pcq pcq-classifier = dst-address
/ Queue type add name = pcq-upload kind = pcq pcq-classifier = src-address