QoS у роутері: як надати пріоритет відеодзвінкам, іграм і роботі
Коротка відповідь: домашній QoS допомагає тоді, коли дзвінок або гра псуються через чергу на вашому керованому bottleneck під паралельним upload чи download. Найнадійніший старт — не ставити «найвищий пріоритет» усьому важливому, а виміряти стабільну пропускну здатність, перенести чергу на роутер за допомогою shaping і AQM/fair queueing, а потім повторити той самий навантажувальний тест. Якщо проблема виникає у Wi‑Fi ефірі або за межами домашнього WAN, правило пріоритету може не змінити результат.
QoS — парасольковий термін. Під ним виробник може мати простий пріоритет пристрою, класи трафіку, bandwidth control, fair queueing або повноцінний SQM. Ці механізми виконують різні роботи: scheduler вирішує, який пакет піде наступним, AQM контролює накопичення черги, а shaper навмисно тримає швидкість трохи нижче реальної межі, щоб саме роутер керував bottleneck. Назва функції в меню ще не доводить її поведінку.
QoS керує конкуренцією, але не створює канал
Коли великий upload заповнює чергу на виході, маленькі пакети голосу, керування грою або віддаленого робочого столу чекають разом із масивним потоком. Пропускна здатність може залишатися високою, а responsiveness погіршується. AQM намагається не тримати чергу постійно переповненою, а flow queueing розділяє потоки, щоб один transfer не монополізував обслуговування. Саме комбінація часто корисніша за одну статичну priority queue.
Якщо тариф має 100 Мбіт/с, QoS не перетворить його на 200. Shaping навіть зменшує доступний peak, щоб черга формувалася у пристрої, де нею можна керувати. Компроміс свідомий: кілька відсотків максимальної швидкості обмінюються на передбачуванішу затримку під конкуренцією. Оптимальний запас залежить від стабільності лінії, link-layer overhead і точності вимірювання; універсального відсотка для всіх доступів немає.
Перед QoS визначте місце проблеми. Ping до LAN-адреси роутера перевіряє локальний сегмент, тест до зовнішньої контрольної цілі додає WAN і маршрут провайдера. Ethernet-клієнт прибирає Wi‑Fi airtime із рівняння. Якщо навіть локальний ping скаче без WAN-навантаження, спершу розберіть причини нестабільності Wi‑Fi, канал, сигнал і драйвер, а не маскуйте радіопроблему пріоритетом.
Контрольний тест до будь-якого правила
Запишіть чотири величини окремо для Ethernet-клієнта: стабільний download, стабільний upload, latency без навантаження і latency під контрольним потоком у кожному напрямку. Не використовуйте один випадковий запуск. Повторіть процедуру кілька разів у близький час і оберіть не найвищий пік, а значення, яке лінія реально утримує. Загальну підготовку розкриває інструкція, як правильно перевірити швидкість інтернету.
Тест upload особливо важливий для відеодзвінка: камера, демонстрація екрана, резервна копія і синхронізація хмари конкурують за вихід. Download може бути проблемою під час оновлення і streaming, але керування ingress складніше, бо пакети вже прийшли через операторську лінію. Домашній SQM часто створює керовану віртуальну ingress-чергу, проте конкретна реалізація залежить від платформи.
Паралельно відкрийте статистику інтерфейсу, якщо прошивка її надає: negotiated WAN rate, packet drops, CPU load і фактичний traffic graph. Високе завантаження CPU після ввімкнення SQM може саме стати новим bottleneck, особливо на швидкому тарифі. Офіційна документація OpenWrt прямо попереджає, що SQM виконується на CPU та може бути несумісним із hardware flow offloading; для іншого виробника звіряйте його власну довідку.
Вечірнє погіршення не завжди означає домашню чергу. Якщо Ethernet без локального фонового трафіку теж сповільнюється лише в години навантаження, перевірте сценарії з матеріалу про те, чому інтернет гальмує ввечері. QoS на вашому роутері не керує агрегацією провайдера, віддаленим сервером або peering.
Чотири різні інструменти під написом QoS
Shaping і rate limiting
Shaper задає контрольовану швидкість, нижчу за доступну межу, і формує пакети у часі. Це дозволяє утримувати чергу на домашньому роутері замість модема або операторського вузла. Rate limit окремого клієнта має іншу мету: не дати одному пристрою забрати всю місткість. Коли потрібно саме обмеження споживача, скористайтеся окремою інструкцією про ліміт швидкості для пристрою; вона не замінює AQM для загальної черги.
Active Queue Management
AQM реагує до повного переповнення буфера: може відкинути або ECN-mark пакет, щоб transport побачив congestion. RFC 7567 рекомендує AQM для керування queue length і затримкою, але підкреслює взаємодію з congestion control. Це не означає «нуль втрат за будь-яких умов»: drop інколи є сигналом, а ECN працює лише за підтримки шляху й endpoints.
Fair queueing
FQ‑CoDel створює flow queues та планує їх обслуговування разом із CoDel. Великий download перестає автоматично стояти в тій самій черзі перед кожним коротким interactive packet. Fairness тут стосується flows, а не моральної рівності пристроїв: застосунок може створити кілька flows, NAT ускладнює host fairness, а конкретні режими CAKE додають власні політики. Тому назву qdisc та її параметри треба читати в документації.
Класи, DSCP і priority
DiffServ використовує DSCP, щоб усередині адміністративного домену обрати per-hop behavior. Домашній роутер може довіряти міткам, перепризначати їх або ігнорувати. Інтернет не зобов’язаний зберігати ваш локальний DSCP end to end, а сліпе позначення всього EF знищує сенс класифікації. Вищий клас доречний для вузького адаптивного real-time потоку, але bulk traffic має залишатися у звичайній або lower-effort черзі.
Конструктор правила пріоритету трафіку
Введіть стабільну, а не рекламну швидкість. Відсоток запасу ви обираєте самі: 90% є лише поширеним стартовим прикладом у документації OpenWrt. Формула однакова для обох напрямків: candidate rate дорівнює виміряній швидкості, помноженій на частку запасу. Результат округлюється до 0,1 Мбіт/с; після застосування його треба перевірити тим самим навантаженням.
Побудуйте стартову конфігурацію
Контрольний приклад: стабільні 100/20 Мбіт/с і вибрані 90% дають 90,0/18,0 Мбіт/с. Це не «правильна швидкість» для всіх ліній. Якщо доступ коливається нижче candidate rate, черга знову може формуватися upstream; зменшуйте тільки проблемний напрямок невеликими кроками й щоразу повторюйте тест. Якщо CPU не витримує shaping, поверніть попередню конфігурацію або використайте продуктивніший router.
Як перенести результат у будь-яку прошивку
1. Знайдіть семантику, а не схожу назву. У довідці моделі з’ясуйте, чи поле задає global WAN rate, ліміт клієнта, вагу класу або просто ручний priority. Якщо документації немає, не припускайте, що «Adaptive QoS» виконує CAKE. Для входу в локальний інтерфейс скористайтеся окремими кроками, як зайти в налаштування роутера, але назви наступних пунктів звіряйте з виробником.
2. Збережіть стан. Запишіть firmware version, WAN interface, початкові rate, offloading, IPv4/IPv6 та активні правила. Змініть один механізм за раз. Це важливо, бо одночасне ввімкнення bandwidth limiter, старого QoS і нового SQM може створити кілька shaper у різних місцях.
3. Виберіть правильний інтерфейс. Shaper має бачити трафік, що проходить через bottleneck. Після переходу на PPPoE, VLAN, VPN або інший WAN логічний інтерфейс може відрізнятися від фізичного порту. Неправильний вибір часто дає красиве активне меню без впливу на потрібний flow.
4. Почніть із fair queue/AQM. Якщо платформа пропонує SQM з CAKE або FQ‑CoDel, спершу перевірте просту конфігурацію без десятків ручних класів. Класовий пріоритет додавайте тільки для конкретного, вузького й перевіреного сценарію. Велика кількість rules ускладнює діагностику та створює ризик помилкової класифікації.
5. Перевірте обидва IP-протоколи. Правило, яке matches лише IPv4 або певні ports, може обходитися IPv6 чи QUIC. Не радимо ловити застосунок лише за одним портом: сучасні сервіси змінюють endpoints і transports. Краще використовувати підтримувану класифікацію платформи або host/flow fairness, чітко розуміючи її межі.
6. Повторіть baseline. Той самий Ethernet-клієнт, сервер, часова близькість і паралельний workload роблять порівняння корисним. Запишіть не лише peak throughput, а й latency increase, jitter і packet loss. Для cloud gaming важливіший стабільний інтерактивний шлях, тому корисно окремо зрозуміти вимоги хмарного геймінгу, не змішуючи їх із завантаженням великих файлів.
Готові політики для трьох домашніх сценаріїв
Відеодзвінок і хмарна синхронізація
Відтворіть upload у хмару під час контрольного дзвінка. Якщо latency до зовнішньої цілі зростає, а LAN до роутера залишається стабільним, почніть з upload shaping і fair queue/AQM. Не піднімайте весь ноутбук у найвищий клас: на ньому ж може працювати backup, який тоді отримає той самий priority. Application-aware classifier доречний лише за документованої точності.
Гра і велике завантаження
Завантаження може створити ingress-чергу або зайняти Wi‑Fi airtime. Спершу перевірте Ethernet. Якщо проблема зникає на кабелі, змінюйте channel plan, placement або airtime policy. Якщо Ethernet також має loaded latency, налаштовуйте download shaper/AQM. Priority gaming device може допомогти проти іншого host лише в реалізації, яка справді розділяє flows; назва режиму не є доказом.
Робота кількох людей одночасно
Для двох дзвінків, VPN і кількох bulk transfers просте «перший пристрій — highest» створює нового фаворита. Host fairness або per-flow scheduler краще розділяють конкуренцію, а загальний shaper тримає bottleneck локально. Оцініть не рекламну кількість clients, а активні flows; пояснення, скільки пристроїв витримує роутер, допомагає відокремити associations від реального навантаження.
Що робити, якщо QoS стало гірше
Throughput впав сильніше, ніж очікувалося. Перевірте одиниці: деякі системи приймають кбіт/с, інші Мбіт/с, а десятковий і двійковий prefixes не слід змішувати. Переконайтеся, що старий limiter вимкнений і немає подвійного shaping. Якщо CPU завантажений, протестуйте простішу discipline або поверніть попередній стан, не послаблюючи firewall.
Download покращився, upload ні. Можливо, правило застосоване тільки до ingress або обрано не той WAN interface. Повторіть односторонні тести й подивіться counters rule/qdisc, якщо вони доступні. На асиметричному тарифі вихідний канал часто насичується раніше, тому download rate не пояснює поведінку acknowledgements і upstream media.
Дзвінок усе одно заїкається без фонового трафіку. Такий симптом не відповідає початковій моделі congestion queue. Перевірте packet loss, signal, roaming, VPN, endpoint CPU та маршрут до сервісу. QoS не ремонтує радіоперешкоди й не скорочує propagation delay. Поверніться до baseline, щоб не накопичувати rules, які не пов’язані з причиною.
Після priority інші застосунки майже зупинилися. Ймовірно, клас занадто широкий або strict-priority queue не має policer/admission control. Звузьте match, залиште достатню місткість default traffic або перейдіть на fair queue. Не позначайте EF весь host чи всю мережу: тоді пріоритет перестає відрізняти real-time packets.
Результат різний щовечора. Змінна доступна швидкість означає, що фіксований shaper іноді перестає бути найвужчим місцем. Виберіть rate, який лінія стабільно утримує у потрібний період, або використайте документований adaptive mechanism. Якщо bottleneck переміщується в мережу оператора, домашня черга не має повного контролю.
Чого не робити з DSCP і «ігровим режимом»
Не копіюйте таблицю DSCP без розуміння trust boundary. Позначки можуть бути правильними у вашій LAN і переписуватися на WAN. Не встановлюйте найвищий клас для speed test, backup або всього UDP: протокол не визначає цінність трафіку. Не створюйте десятки port rules для сервісу, який використовує CDN, QUIC та змінні endpoints; вони швидко стають неповними.
Не вимикайте AQM заради максимального benchmark, якщо ваша ціль — responsiveness під навантаженням. Водночас не залишайте shaper, який router не здатен обробити на швидкості тарифу. Правильна конфігурація — та, що показує відтворюване поліпшення потрібного workload без неприйнятного падіння корисного throughput.
Не плутайте локальний QoS із гарантованим SLA. Домашнє правило діє у вузлах, які ви контролюєте; кожен наступний домен має власну policy. DSCP може допомагати всередині керованої мережі, але не резервує маршрут через публічний інтернет. Для критичної роботи потрібні також надійний access, резервний канал і контроль застосунку.
Фінальний порядок дій
- Відтворіть проблему окремо під upload і download на Ethernet.
- Підтвердьте, що latency росте саме коли насичується домашній WAN.
- Виміряйте стабільну швидкість і виберіть явний запас shaping.
- Увімкніть один SQM/AQM/fair-queue механізм на правильному interface.
- Додайте вузький клас лише якщо базове fair queue не закриває конкретний real-time сценарій.
- Повторіть той самий тест, перевірте CPU, throughput, latency, jitter і loss.
- Збережіть робочу конфігурацію або відкотіть зміну, якщо доказу користі немає.
QoS корисний не кількістю перемикачів, а контролем черги у правильному місці. Починайте з shaper та сучасного AQM/fair scheduler, класифікуйте лише те, що справді потребує іншої обробки, і залишайте собі вимірюваний критерій успіху. Так відеодзвінок або гра отримує низьке очікування без обіцянки швидкості, якої фізично немає.
Окремі черги для кількох вузьких місць
Якщо після WAN-роутера стоїть ще один маршрутизатор із NAT, керована черга на першому пристрої не гарантує порядок у другому. Намалюйте фактичний шлях пакетів і визначте, де саме швидкість нижча за сусідній сегмент. Подвійне shaping на однакових rates марнує ресурс і ускладнює діагностику; натомість одна правильно розміщена черга перед реальною межею дає зрозумілий контроль.
Для мобільного або змінного радіодоступу baseline може швидко коливатися. Статичний limit, вищий за поточну швидкість, перестає перехоплювати чергу, а надто низький постійно відрізає корисну місткість. Перевіряйте кілька часових вікон, обирайте консервативне значення для важливого робочого сеансу та не видавайте один вимір за сталу характеристику оператора.
Після перезавантаження переконайтеся, що правило справді відновилося і прив’язане до чинного WAN-інтерфейсу. PPPoE, VLAN або тунель можуть створювати логічний інтерфейс поверх фізичного порту; shaping не на тому рівні не бачить потрібної черги. Цю відповідність треба підтвердити документацією прошивки та повторним навантажувальним тестом.