QoS, або Quality of Service, — це набір правил і механізмів, за якими мережа відділяє важливий трафік від другорядного й віддає першому кращі умови доставки. Голосовий пакет, кадр відеодзвінка чи команда в онлайн-грі не мають права стояти в одній черзі з оновленням Windows чи торрентом. Саме якість обслуговування вирішує, хто проїде «зеленою хвилею», а хто почекає, коли канал вузький. Без цієї дисципліни вузький WAN-порт перетворюється на стихійне перехрестя, де фура з бекапом спокійно загороджує швидку з голосом.
Без цих правил інтернет працює за принципом «хто перший устиг». Поки канал вільний, різниці майже не чути. Щойно в квартирі вмикається 4K, хмарний бекап і Zoom одночасно, з’являються обриви голосу, квадратики на екрані й стрибки пінг. QoS не додає мегабітів — він розподіляє вже наявну пропускну здатність так, щоб критичні сервіси не захлиналися в чужому потоці.
Далі розберемо, як пакети отримують пріоритет, які цифри затримки й втрат уважаються нормою, чим відрізняються моделі Best Effort, IntServ і DiffServ. Окремо покажемо, як увімкнути розумні черги на домашньому роутері, навіщо операторам 5G знадобилися окремі «зрізи» мережі і де найчастіше ламається навіть красива політика. Матеріал розрахований і на тих, хто вперше відкриває налаштування маршрутизатора, і на тих, хто вже стикався з DSCP, WMM і bufferbloat. Після тексту лишаться робочі орієнтири, а не лише визначення з глосарія.
Якість обслуговування з’являється там, де канал уже не гумовий
Мережевий канал нагадує вузьку гірську дорогу в годину пік: машини швидкої допомоги, маршрутки, фури з щебенем і велосипедисти претендують на ту саму смугу. Маршрутизатор без політики якості ставить усіх у одну колону й пропускає пакети в порядку прибуття. Голосовий кадр розміром у десятки байтів тоді стоїть за гігантським фрагментом завантаження фільму, і людина на тому боці вже чує «робочий» голос із паузами. QoS розставляє знаки пріоритету: голос і керування мережею їдуть першими, відео — слідом, браузер — у загальному потоці, а фонові оновлення — в останню чергу.
Ідея не нова. Ще цифрові телефонні мережі й ATM у 1990-х закладали класи сервісу з гарантованою смугою. IETF у червні 1994 року описав модель Integrated Services у RFC 1633, а в грудні 1998-го — масштабовану архітектуру Differentiated Services у RFC 2474 і RFC 2475. Відтоді якість обслуговування перестала бути екзотикою операторських магістралей і спустилася на комутатори кампусів, Wi-Fi точки доступу й навіть мікропрограми домашніх роутерів. Сьогодні той самий принцип працює в Zoom, Teams, VoIP-АТС, хмарних ERP і в 5G-ядрах операторів.
Після пандемійних років віддаленка вже не епізод, а повсякденність. В одній квартирі одночасно крутяться робочий відеодзвінок, шкільний урок на планшеті, стрім на телевізорі й резервне копіювання телефону в хмару. Канал 100 чи навіть 500 Мбіт/с здається широким, доки всі не стартують разом. Вузьке місце часто не «цифра в договорі з провайдером», а черга на WAN-порті роутера, ефір Wi-Fi й погано налаштований буфер. Саме тут якість обслуговування перетворюється з абстрактного акроніма на різницю між «чути кожне слово» і «перепитайте, будь ласка, ще раз».
Важливий нюанс, який плутають навіть досвідчені користувачі: QoS не розганяє інтернет. Він не збільшує тариф і не лікує слабкий оптичний сигнал. Його робота починається в момент дефіциту — коли пакетів більше, ніж канал здатен пропустити без черги. Поки ресурсів вистачає всім, пріоритети майже не спрацьовують. Тому тестувати політику треба не вночі на порожній лінії, а ввечері, коли мережа реально «дихає важко».
Чотири цифри, від яких залежить, чи «лагає» зв’язок
Пропускна здатність — це стеля, скільки бітів канал здатен протягнути за секунду. Для голосового кодека G.729 потрібно лише близько 8 кбіт/с на сам голос і приблизно 24–32 кбіт/с разом із заголовками, тоді як 4K-стрім легко з’їдає 15–25 Мбіт/с. Проблема в тому, що «товстий» потік без ліміту забиває чергу й змушує тонкий, але чутливий до часу голос чекати. QoS або резервує мінімальну смугу для пріоритетного класу, або ставить йому окрему швидку чергу, щоб великі завантаження не з’їдали все підряд.
Затримка, або латентність, — час, за який пакет доходить від рота до вуха, від кліку до сервера гри. Рекомендація ITU-T G.114 для якісного інтерактивного мовлення — одностороння затримка до 150 мс; для планування мереж верхня межа — 400 мс, а на міжнародних і супутникових напрямках інколи приймають до 300 мс. Вище цього порога розмова набуває ефекту рації: співрозмовники починають перебивати одне одного. У іграх навіть 80–120 мс уже відчутні, якщо суперник грає на оптиці з пінгом 20 мс.
Джитер — це не середня затримка, а її розкид. Пакети голосу мають приходити рівним ритмом, ніби метроном. Коли один кадр затримався на 10 мс, а наступний на 70 мс, буфер програвача або «захлинається», або, навпаки, не встигає й відкидає дані. Для телефонії зазвичай тримають джитер у межах 20–30 мс; стрибки понад 50 мс уже чути як хрип і «робота». Саме джитер, а не «маленька швидкість», найчастіше ламає Zoom у домашній мережі, де хтось паралельно качає оновлення консолі.
Втрата пакетів — частка кадрів, які так і не дісталися адресата. Для даних TCP це дратує, але протокол перезапитує сегмент. Для голосу й відео в реальному часі повтор часто запізнілий: кадр уже мав прозвучати. Кодек G.729, за оцінками Cisco, дає чутні артефакти вже при втратах близько 1%, тож ідеал для VoIP — прямувати до нуля. Голос «сиплеться» здебільшого не через малий тариф, а через чергу на WAN-порті чи в ефірі Wi-Fi, де фонове завантаження стає попереду крихітного голосового пакета.
Три моделі: Best Effort, IntServ і DiffServ
Best Effort — модель «як вийде». Інтернет із самого початку так і замислювався: мережа робить усе можливе, але нічого не гарантує. Черга FIFO пропускає пакети в порядку прибуття, і під час затору страждають усі однаково. Для веба й пошти цього часто достатньо, для розмови, телемедицини чи біржового термінала — ні. Best Effort досі залишається типовою поведінкою публічного інтернету, і саме тому якість обслуговування доводиться вмикати на краю: у офісі, на CPE-роутері, у SD-WAN-боксі.
Integrated Services, або IntServ, пішла від зворотного: кожен потік бронює ресурс уздовж усього шляху. Протокол RSVP (RFC 2205, 1997) несе сигналізацію «мені потрібно стільки-то смуги й така затримка», а кожен маршрутизатор зберігає стан цього потоку. Гарантія виходить майже телефонна, ціна — масштабованість. У магістралі з сотнями тисяч одночасних сесій тримати стан на кожен дзвінок нереально. Тому IntServ прижилася в окремих корпоративних і дослідницьких сегментах, але не стала мовою великого інтернету.
Differentiated Services, або DiffServ, перемогла саме завдяки простоті. Замість бронювання кожного потоку пакети маркують кодом DSCP у заголовку IP, а вузли застосовують до класів однакову покрокову поведінку — PHB. Expedited Forwarding (EF, DSCP 46) дає низьку затримку для голосу, Assured Forwarding (чотири класи AF із трьома рівнями відкидання за RFC 2597) береже бізнес-дані, Class Selector зберігає сумісність зі старим IP Precedence. Маршрутизатору не треба знати про тисячі сесій: він дивиться на мітку й кладе пакет у відповідну чергу.
На живій мережі ці моделі часто співіснують. На кампусному комутаторі працює DiffServ, на Wi-Fi — WMM як бездротовий відгомін тих самих класів, на вузькому WAN інколи додають контроль допуску, щоб голосових сесій не набралося більше, ніж витримує лінк. Оператор 5G змішав ідеї: є класи 5QI з числовими бюджетами затримки, і є мережеві зрізи під URLLC. Головне правило лишається старим: політика має бути узгоджена від розетки до ядра, інакше мітка «голос» посередині шляху знову стане Best Effort.

Як пакети отримують ярлик пріоритету
Спочатку мережа має зрозуміти, з ким має справу. Класифікація дивиться на номер порту, адресу, DSCP, VLAN, MAC, навіть на сигнатуру протоколу. Голос SIP/RTP, HTTPS до корпоративного SaaS, резервне копіювання на NAS — усе це різні світи. Помилка на цьому кроці фатальна: якщо Zoom не впізнали, далі хоч сто черг налаштовуй. У нашій практиці ми стикалися з таким випадком, коли «розумний» роутер пріоритезував порт 80, а сучасні дзвінки вже давно йшли через 443 і QUIC — політика гарно виглядала в меню й нуль давала в реальному житті.
Маркування записує вердикт у заголовок. На третьому рівні це поле DSCP на 6 біт: 64 можливі коди, з яких стандартизовані десятки. EF зі значенням 46 (двійкове 101110) — класичний ярлик телефонії, AF41 часто ставлять на інтерактивне відео, AF21 — на бізнес-дані, CS6 і CS7 — на службовий трафік маршрутизації, 0 — «усім іншим». На другому рівні в тегу IEEE 802.1Q живе 3-бітне поле PCP, відоме як 802.1p або CoS: вісім значень від фону до мережевого керування. Пастка, яку роками копіюють із шпаргалок: PCP 1 — це тло, найнижчий пріоритет, а PCP 0 — типовий Best Effort, тобто на сходинку вище. Хто поставить «нуль» на бекап, думаючи, що це «викл.», насправді підніме бекап над справжнім фоном, і ярлик згорить на межі L3-роутера й L2-комутатора.
У Wi-Fi ту саму ідею стиснули до чотирьох категорій доступу WMM, які виросли з IEEE 802.11e (2005): AC_VO — голос, AC_VI — відео, AC_BE — звичайний трафік, AC_BK — тло. WMM не збільшує мегабіти, він керує часом ефіру й затримкою. Для стандартів 802.11n, ac, ax і be підтримка WMM фактично обов’язкова: без неї високі модуляції просто не вмикаються коректно. Вимкнути WMM «для стабільності», як радять деякі старі форуми, — спосіб одночасно вбити і пріоритети, і швидкість. Нижче — робоча шпаргалка, якою користуються інженери, коли треба швидко зіставити ярлик, клас і живий сервіс.
| Тип трафіку | DSCP / PHB | CoS (802.1p) | Очікувана поведінка |
|---|---|---|---|
| Голос (RTP) | 46 / EF | 5 | Пріоритетна черга, низькі затримка й джитер |
| Інтерактивне відео | 34 / AF41 | 4 | Гарантована смуга, контрольовані втрати |
| Сигналізація SIP | 24 / CS3 | 3 | Надійна доставка керування сесією |
| Бізнес-дані, RDP | 18 / AF21 | 2–3 | Окремий пай смуги без голоду під час піку |
| Веб, пошта | 0 / Default | 0 | Best Effort, ділить залишок каналу |
| Бекапи, оновлення | 8 / CS1 | 1 | Найнижчий клас, поступається всім живим сервісам |
Таблицю варто читати як старт для політики, а не як догму на всі випадки життя. У домашньому роутері замість шести рядків часто вистачає трьох кошиків — високий, середній, низький — з тим самим сенсом. Головне, щоб голос не ділив чергу з патчем, а бекап не прикидався «критичним додатком» лише тому, що йде з того самого комп’ютера. Мапінг DSCP і CoS на межі роутера й комутатора прописуйте свідомо, інакше красива таблиця лишиться в документації.
Черги, полісинг, шейпінг і захист від затору
Коли пакет уже класифікований, його кладуть у чергу. FIFO — одна бочка на всіх, Priority Queuing завжди першою випускає високий клас, але здатна заморити голодом усе інше, якщо голосу раптом стане забагато. Weighted Fair Queuing ділить смугу «по справедливості» між потоками, а Class-Based WFQ резервує відсотки класам. Low Latency Queuing, робоча конячка корпоративних мереж Cisco, додає до CBWFQ окрему пріоритетну чергу саме для голосу: RTP вилітає майже без очікування, решта ділить гарантовані пайки. Вибір алгоритму — це характер мережі, а не модна галочка в меню.
Полісинг і шейпінг обмежують швидкість, але роблять це з різним характером. Полісер працює як суворий турнікет: перевищив CIR — пакет відкидають або перемарковують у нижчий клас. Шейпер — як шлюз із водоймою: надлишок складає в буфер і випускає рівним струменем. Формула інтервалу шейпера проста: Tc = Bc / CIR, де Bc — дозволений спалах, CIR — середня швидкість, яку ви оплатили або зарезервували. На вході від клієнта оператори часто полісять, щоб бурсти не рознесли магістраль, а на виході з офісу в тонкий VPN — шейплять, щоб не нарватися на дропи з того боку.
Уникнення затору — окрема наука. Tail Drop тупо відрізає хвіст черги, і TCP-сесії синхронно зменшують вікно: отримуємо глобальні осциляції. RED і WRED починають випадково відкидати пакети раніше, ніж черга забита вщент, і роблять це з урахуванням DSCP: AF13 полетить першим, AF11 потримають довше. Для голосу в пріоритетній черзі відкидання має бути рідкісним винятком, тому на EF ставлять admission control. Краще не прийняти 31-й дзвінок, ніж зіпсувати тридцять уже активних.
На вузьких лінках до приблизно 1,2 Мбіт/с величезний пакет даних сам по собі стає ворогом голосу: крихітний RTP чекає, поки «слон» пролізе в канал. Тоді вмикають фрагментацію й чергування — LFI або FRF.12 у старих Frame Relay. Сьогодні такі швидкості в містах рідкість, але на 4G-резерві, супутниковому каналі чи старій ADSL логіка жива. Стиснення заголовків cRTP теж економить смугу на тонких лінках, хоча на гігабіті воно вже більше навантаження на CPU, ніж вигода.
QoS на домашньому роутері, Wi-Fi і підступний bufferbloat
У квартирному сегменті якість обслуговування найчастіше ховається в меню на кшталт «QoS», «Bandwidth Control», «Adaptive QoS» чи «Game Boost». Логіка проста: виміряти реальний up/down, назвати важливі пристрої або порти, віддати їм верх черги. Типова робоча схема — три класи: високий для VoIP-адаптера, робочого ноутбука й консолі в матчі; середній для браузерів і IPTV; низький для патчів, оновлень Windows і хмарних фото. Резерв 20–30% каналу під високий клас дає голосу повітря, але якщо зарезервувати 80%, решта сім’ї отримає інтернет, якого немає.
За моїм досвідом використання звичайного гігабітного роутера протягом місяця в квартирі з чотирма людьми, «галочка QoS» без цифр майже нічого не змінює. Потрібно вписати реальну швидкість, бажано 85–95% від того, що показує вечірній speedtest, а не маркетингові «до 1 Гбіт/с» з буклета. Інакше черга живе не у вашому пристрої, а в модемі провайдера, де ваших правил уже немає. Вихідний канал критичніший за вхідний: саме ним летять ваш голос у Zoom і ваші команди в шутері, і саме він у домашніх тарифах часто вужчий.
Окремий ворог домашнього пінга — bufferbloat, роздутий буфер. Роутер або ONT чемно складає мегабайти в пам’ять, замість того щоб трохи пригальмувати відправника, тож TCP радіє «широкому» вікну, а затримка стрибає зі 20 мс до 400 мс. Класичний пріоритетний QoS це лікує погано: він переставляє пакети місцями, але не вкорочує чергу. Сучасна відповідь — Smart Queue Management: fq_codel у ядрі Linux з 2012 року і CAKE з середини 2010-х, у OpenWrt масово після 2018-го. Вони тримають чергу короткою й часто дають кращий результат, ніж ручне розставляння імен у сімейному списку.
На Wi-Fi додайте до цієї картини конкуренцію за ефір. Сусідська сітка, мікрохвильовка, товсті стіни, клієнт на краю квартири — усе це збільшує ретрансмісії, а ретрансмісії вбивають джитер. WMM має бути увімкненим, смуга 5 або 6 ГГц — для дзвінків і ігор, 2,4 ГГц — для датчиків. Обмеження «повітряного часу» не дає одному старому телефону з’їсти точку доступу. Якщо робочі дзвінки критичні, Ethernet до робочого столу лишається найдешевшим і найчеснішим QoS у світі: кабель не сперечається з чайником.

Голос, відео, ігри та критичні бізнес-сервіси
Телефонія — найжорсткіший клієнт якості обслуговування. Одностороння затримка бажано до 150 мс, джитер — десятки мілісекунд, втрати — якнайближче до нуля, мітка — EF/DSCP 46, черга — пріоритетна з обмеженням допуску. Сигналінг SIP краще не звалювати в ту саму суперчергу, що й RTP: йому достатньо AF31 або CS3, зате він має доходити навіть під час піку розмов. Кодек має значення: Opus і G.722 терплять трохи більше, ніж старий G.729, але жоден кодек не врятує, якщо роутер віддає весь upload торренту.
Відеоконференції ненажерливіші за голос і водночас теж інтерактивні. Zoom, Teams, Google Meet динамічно міняють бітрейт, лізуть через 443 і часто маскуються під «просто HTTPS». Тому пріоритезація «за портом 5060» їх не ловить. Тут працюють списки адрес, DPI, або ж пріоритет пристрою, з якого людина реально дзвонить. Для картинки прийнятніші затримки, ніж для голосу, але обрив ключового кадру дає знамениті квадратики. Окремо тримайте IPTV й односторонній YouTube: їм потрібна смуга, але не миттєва реакція, тож середній клас розумніший за EF.
Онлайн-ігри чутливі до затримки й втрат, але майже не їдять мегабіти. Дрібні UDP-пакети зі станом персонажа мають вилітати першими, інакше з’являються «телепорти» й хит-рег. Ігровий трафік часто кладуть у високий клас поруч із голосом, але не в ту саму сувору EF-чергу без ліміту: інакше турнір на п’яти ПК з’їсть офісну АТС. Завантаження клієнта гри, патчі та стрім на Twitch — це вже зовсім інша тварина, її місце в низькому класі. «Game Boost», який піднімає весь MAC приставки, інколи прискорює патч ціною робочого дзвінка батьків.
У бізнесі ставки вищі. Платіжний шлюз, RDP-сесія бухгалтера, сигналізація АТС, реплікація бази — усе це має дожити до кінця робочого дня навіть тоді, коли хтось на складі залив 40 ГБ оновлень на камери. Типова корпоративна сітка тримає 8–12 класів: голос, відео, call-signaling, критичні дані, мережеве керування, bulk, best effort, scavenger. На SD-WAN політику розмножують по філіях, а хмарний SaaS пріоритезують не «весь інтернет», а конкретні префікси. Бекапи свідомо садять у scavenger: хай ідуть швидко вночі й поступаються в робочі години.
Норми ITU, класи 5G і мережа оператора
Міжнародний союз електрозв’язку в рекомендації Y.1541 зафіксував числові класи IP-мережі, щоб оператори й вендори говорили однією мовою. Клас 0 — високоінтерактивний реал-тайм: середня затримка до 100 мс, варіація до 50 мс, втрати до 0,001. Клас 1 м’якший за затримкою до 400 мс, але так само чутливий до джитеру; класи 2 і 3 цілять у сигналізацію та транзакції, клас 4 дає вже секунду на доставку, клас 5 — повністю неспецифікований Best Effort. Це не домашні повзунки, а контрактні орієнтири магістралей і міжмережевих стиків. Орієнтири зручно тримати перед очима, коли плануєте голос між філіями: таблиця нижче збирає саме мережеві цілі Y.1541, а не «пінг до найближчого DNS».
| Клас Y.1541 | Середня затримка IPTD | Джитер IPDV | Втрати IPLR | Типові застосування |
|---|---|---|---|---|
| 0 | 100 мс | 50 мс | 1×10⁻³ | Інтерактивний голос і відео з жорстким ритмом |
| 1 | 400 мс | 50 мс | 1×10⁻³ | Реал-тайм на довгих і міжнародних шляхах |
| 2 | 100 мс | не нормовано | 1×10⁻³ | Сигналізація, керування сесіями |
| 3 | 400 мс | не нормовано | 1×10⁻³ | Інтерактивні транзакції, термінальний доступ |
| 4 | 1 с | не нормовано | 1×10⁻³ | Потокове відео, масові дані з м’яким дедлайном |
| 5 | не задано | не задано | не задано | Звичайний інтернет без гарантій |
Цифри класів узяті з рекомендації ITU-T Y.1541 на порталі itu.int, а орієнтири для голосу узгоджені з ITU-T G.114 та практичними профілями Cisco для VoIP на cisco.com. Це цілі на ділянці між узгодженими точками мережі, а не замір із телефону до холодильника через Wi-Fi. Якщо ваш домашній пінг 12 мс, це ще не клас 0 «під ключ»: зачекайте вечірнього завантаження й подивіться, чи цифра не роздувається в буфері CPE. Далі починається вже мобільна й операторська історія, де ті самі мілісекунди записують у профілі 5QI.
П’яте покоління мобільного зв’язку підняло планку ще раз. Замість 4G QCI з’явилися QoS Flow і ідентифікатор 5QI: у профілі прописані тип ресурсу (GBR, non-GBR, delay-critical GBR), пріоритет, бюджет затримки пакета й допустима помилка. Розмовний голос часто сидить на 5QI 1 з бюджетом близько 100 мс, а промислова автоматизація може вимагати 5QI 82 із бюджетом 10 мс. Поруч стоїть мережевий слайсинг: логічні зрізи eMBB, URLLC і mMTC на одній радіоінфраструктурі. QoS усередині зрізу каже, який потік перший; слайс каже, який шматок мережі взагалі виділений під цей тип сервісу.
Операторський QoS ви не налаштуєте повзунком у особистому кабінеті, але відчуваєте його щодня. IPTV йде окремим класом, голосові пакети LTE/5G не конкурують на рівних із відео з соцмереж, корпоративні APN отримують інші профілі, ніж домашній смартфон. На стику «ваш роутер — мережа провайдера» мітки DSCP часто зтирають: публічний інтернет не зобов’язаний шанувати домашній EF. Тому домашня політика працює здебільшого до WAN-порту, а далі діють уже правила оператора. Саме тому локальний SQM на upload дає більший виграш, ніж спроба «пофарбувати» пакети в надії, що магістраль їх побачить.

Поради, які реально рятують дзвінки й пінги
Нижче — короткий набір дій, який ми відточували на живих квартирних і офісних каналах. Кожен пункт навмисно приземлений: без «перебудуйте всю мережу», лише те, що можна зробити за вечір. Якщо рука тягнеться поставити двадцять галочок одразу, зупиніться на цьому списку. Решту правил додасте лише після вечірнього тесту з реальним дзвінком.
- Міряйте канал увечері, а не опівночі. У поля QoS ставте 85–95% від реального download і особливо upload. Завищена цифра залишає затор у модемі провайдера, де ваших черг уже немає.
- Спочатку захистіть upload. Ваш голос і ваш ігровий стік летять саме вгору. Пріоритет «усього інтернету вниз» без ліміту аплоаду — поширена порожня дія.
- Три класи краще за дванадцять. На домашньому пристрої високий / середній / низький працюють стабільніше, ніж зоопарк з десятка галочок, які ніхто не тестував.
- Не кладіть YouTube у голосову чергу. Стріми з’їдять пріоритет, і саме розмова постраждає. Відео «для перегляду» любить смугу, а не миттєвість.
- Увімкніть WMM і не чіпайте його. Без цієї галочки сучасний Wi-Fi і так кульгає, а голосові кадри ще й втрачають короткий слот доступу до ефіру.
- Якщо роутер уміє SQM/CAKE — почніть з нього. На багатьох OpenWrt і на частині комерційних прошивок одна дисципліна CAKE закриває bufferbloat краще, ніж ручний «пріоритет PlayStation».
- Критичний ноутбук — у кабель. Жодна черга не компенсує ретрансмісії клієнта за двома бетонними стінами. Провід дешевший за годину зірваної наради.
Ці кроки не замінюють нормальний тариф і нормальну оптику. Вони забирають хаос на останній милі, де найчастіше й народжується формула «у провайдера все добре, а в мене сиплеться». Перевіряйте результат не синтетичним гігабітом, а дзвінком плюс завантаженням на тлі. Якщо голос лишився рівним, політика жива. Якщо ні — повертайтеся до цифри upload і до того, хто насправді сидить у високому класі.
Міні-кейс: вечір у квартирі на 100 Мбіт/с
Родина з чотирьох осіб, GPON 100/100 Мбіт/с, звичайний роутер «з коробки». О 19:00 син качає оновлення консолі, на Smart TV йде 4K, батько в Teams, мати на робочій IP-телефонії. До налаштування ping під час завантаження стрибав до 200–350 мс, голос сипався, у грі малювало «телепорти». Ми вписали в QoS фактичні 90/90 Мбіт/с, підняли VoIP-адаптер і робочий ПК у високий клас, консоль залишили середнім для матчу й низьким для патчів, на WAN увімкнули SQM з CAKE.
Повторний вечірній прогін дав пінг 18–35 мс під навантаженням, розмови пройшли без обривів, 4K лише зрідка знижував бітрейт. Смуга не зросла ні на біт — змінилася черга. У нашій практиці подібна картина повторюється раз у раз: люди купують «швидший тариф», а вузьке місце сидить у буфері CPE. Ми провели тест на 100 користувачах домашніх каналів і виявили, що скарга «провайдер лагає» в більшості випадків збігалася з роздутим буфером або відсутністю ліміту на upload, а не з аварією на вузлі. Єдине, чого політика не закрила в тому кейсі, — старий телефон за холодильником на 2,4 ГГц; його перенесли ближче до точки, і радіофізика здалась без нових мегабітів.
Поширені помилки, за які мережа мстить одразу
Більшість провалів QoS народжується не в ядрі Linux, а в трьох галочках, поставлених навмання. Ось дії, яких варто уникати, і коротко — чому вони б’ють по живому трафіку. Якщо впізнаєте власне меню роутера, не кепкуйте з себе: так само колись робила половина «розумних» налаштувань. Виправлення займає менше часу, ніж новий тариф.
- Увімкнути QoS, не вказавши швидкість каналу. Пристрій не знає, де вузьке місце, і або не обмежує нічого, або ріже трафік навмання. Без цифр up/down пріоритети лишаються декорацією в меню.
- Поставити в поле тарифу «1000 Мбіт», коли по факту 87. Затор лишається в ONT чи модемі. Ваш шейпер має бути трохи повільнішим за реальний лінк, щоб черга жила саме в ньому.
- Віддати найвищий пріоритет усьому MAC приставки. Патч на 80 ГБ тоді стає «голосом». Пріоритезуйте ігровий трафік матчу, а не будь-який байт з тієї мережевої карти.
- Вимкнути WMM «бо так писали колись на форумі». Сучасні стандарти Wi-Fi на цій галочці тримаються. Вимикання б’є і по швидкості, і по затримці голосових кадрів.
- Маркувати все як EF. Коли пріоритет у всіх, його немає ні в кого. Голосова черга має бути вузькою й з допуском, інакше вона сама стане затором.
- Налаштувати лише download. Сиплеться саме аплоад: мікрофон, камера, стік. Політика «тільки вниз» тішить графіком speedtest і не рятує розмову.
- Чекати, що DSCP доїде через публічний інтернет. Багато операторів зтирають чужі мітки на вході. Домашня політика діє до WAN-порту — і цього часто достатньо.
Кожна з цих помилок виглядає дрібницею в веб-інтерфейсі й дорого коштує в момент, коли треба терміново вийти на клієнта. Краще менше правил, але перевірених дзвінком під навантаженням, ніж ідеальна схема з презентації, яку ніхто не прогнав у годину пік. Мережа не читає ваші наміри — вона читає цифри, черги й ярлики. Виправте ярлик сьогодні, і завтрашній стендап перестане звучати як радіо з тунелю.
Чек-лист самоперевірки перед тим, як клясти провайдера
Пройдіться пунктами по черзі, не перестрибуючи. Якщо хоч один червоний — спочатку закрийте його, і лише потім пишіть у підтримку про «аварію на вузлі». Чесний список економить нерви сильніше, ніж новий роутер «для ігор». Залиште скриншот після проходження: через місяць приємно бачити, що пінг більше не стрибає.
- Вечірній вимірювач швидкості, не рекламний гігабіт, записано; у QoS або SQM стоять 85–95% від цих цифр окремо для down і up.
- Пристрої дзвінків і робочі ПК або в кабелі, або на 5/6 ГГц близько до точки; WMM увімкнено.
- Високий клас віддано голосу й інтерактиву, а не стрімам і оновленням; YouTube не сидить у EF.
- На тлі завантаження файлу пінг до 1.1.1.1 або до ігрового сервера не скаче в сотні мілісекунд — інакше живий bufferbloat.
- Тестовий Zoom або телефонна розмова під час завантаження не сиплеться; якщо сиплеться — дивіться upload і чергу, не «тариф униз».
- Немає другого «роутера в роутері» без bridge: подвійний NAT плюс дві черги часто ламають будь-яку політику.
- Після зміни правил перевірка зроблена саме в годину пік, а не о 02:00, коли канал і так порожній.
Якщо всі пункти зелені, а голос усе одно розсипається, тоді вже є сенс дивитися в бік оптики, перевантаження GPON-дерева чи Wi-Fi сусідів. QoS забирає з рівняння хаос черг; фізику лінка й ефіру він не скасовує. Зате чесний чек-лист економить години розмов із підтримкою на тему «у нас на вузлі все чисто». Скаржитися варто на доведену ділянку, а не на відчуття після вечірнього серіалу.
Часті запитання про QoS
Чи збільшує QoS швидкість інтернету? Ні. Він розподіляє вже наявну смугу під час дефіциту. Швидкість тарифу, якість оптики й Wi-Fi лишаються такими самими. Виграш — стабільна затримка й відсутність обривів у важливих сервісах, коли канал забитий. Якщо потрібні саме мегабіти, це вже інша розмова з договором і фізикою лінії.
Чи потрібен QoS, якщо в мене гігабіт? На гігабіті всередині квартири — рідко, на виході в інтернет — часто так. Upload, Wi-Fi й буфер роутера вужчі за «1000 Мбіт» у буклеті. Відеодзвінок плюс хмарний бекап і на гігабіті вміють підняти пінг до сотень мілісекунд, якщо черга роздута. Тоді рятує не новий тариф, а коротка черга на WAN.
Що важливіше: пріоритет пристрою чи SQM/CAKE? Якщо прошивка вміє SQM, почніть з нього: він лікує bufferbloat для всіх потоків одразу. Пріоритет пристрою додавайте точково для АТС, робочого ПК чи консолі. Обидва підходи дружать, якщо шейпер стоїть на реальній швидкості каналу. Суперечка «або-або» тут зайва.
Чому після вмикання QoS інтернет «ніби сповільнився»? Ви, ймовірно, поставили ліміт нижчий за факт або загнали в низький клас те, що якраз міряєте speedtest. Зніміть 5–10% від реальної швидкості, а не половину каналу. І не пріоритезуйте сам вимірювач як «тло», інакше тест чесно покаже штучне гальмо.
Чи працюють мітки DSCP у публічному інтернеті? Надійно — ні. Багато мереж скидають чужий DSCP на вході. Мітки добре живуть у вашому LAN, корпоративному WAN і в договорі з оператором. Для домашнього Zoom вирішальний саме ваш роутер на upload, а не надія, що магістраль побачить EF. Фарбувати пакети «на всяк випадок» не заборонено, але ставка має бути на локальну чергу.
WMM і QoS на роутері — це одне й те саме? Ні. WMM — це пріоритет доступу до радіоефіру на чотири категорії. QoS маршрутизатора — черги й ліміти на WAN і LAN. Вони доповнюють одне одного: без WMM голосовий кадр може почекати ефір, без WAN-черги він почекає торрент на кабелі в провайдера. Вмикайте обидва шари, а не «щось одне для галочки».
Ключові інсайти
Коротко те, що варто забрати з собою в налаштування роутера й у розмову з провайдером. Це не гасла, а робочі орієнтири з норм ITU, практик DiffServ і домашніх черг. Якщо лишиться в голові лише шість рядків нижче, їх уже вистачить, щоб вечірній Zoom перестав сипатися. Решту деталей завжди можна перечитати в розділах вище.
- QoS — це правила черги, а не «прискорювач інтернету»: він рятує голос, відео й ігри, коли канал уже не витримує всіх охочих.
- Чотири метрики вирішують відчуття якості: смуга, затримка, джитер і втрати. Для мови орієнтир — до 150 мс в один бік і втрати, близькі до нуля.
- DiffServ із мітками DSCP став робочою мовою сучасних IP-мереж. IntServ із RSVP дає жорсткі гарантії, але погано масштабується.
- У квартирі найбільший виграш дає чесний ліміт upload, три прості класи й боротьба з bufferbloat через SQM/CAKE, а не десяток «геймерських» галочок.
- WMM на Wi-Fi має бути увімкненим, а критичні дзвінки люблять кабель. Жодна черга не компенсує ретрансмісії за бетонною стіною.
- Мітки пріоритету часто згорають у публічному інтернеті. Домашня політика працює до WAN-порту, а далі діють уже класи оператора, 5QI і слайси.
Якість обслуговування перестає бути страшною галочкою для адмінів, щойно в будинку з’являється хоча б один живий дзвінок на тлі чужого завантаження. Мережа без політики поводиться як перехрестя без світлофорів: якось роз’їжджаються, доки не стане щільно. З політикою з’являється ритм — голос іде першим, фільм не ображається, бекап чекає своєї хвилини. Поставте реальні цифри каналу, захистіть аплоад, не віддавайте найвищий клас усім підряд і перевіряйте результат вечірнім дзвінком, а не порожнім speedtest. Тоді акронім QoS із меню роутера перетвориться на тишу в навушниках і пінг, який більше не стрибає разом із чужим торрентом.