Ваш speed-тест бреше. Міряйте responsiveness.

Брехня великого числа

Кожен сайт speed-тесту відкривається зі шкалою. Вона розкручується, зупиняється на якомусь вражаючому числі (480, 510, 940 Мбіт/с, якщо у вас оптика) і це число стає історією. Історія майже завжди помилкова. Не нечесна, просто неточне питання, на яке дано точну відповідь.

Пропускна здатність це вимір ємності: скільки води може пропустити труба, коли більше нічого не відбувається. Проблема в тому, що реальні мережі майже ніколи не виглядають як «більше нічого не відбувається». Реальні мережі виглядають як сімейний відеодзвінок, хмарний бекап, синхронізація Slack, оновлення софту й дитина, яка дивиться мультики, усе одночасно. У цій сцені вам важливо не те, скільки літрів на хвилину проходить сумарно. Вам важливо, чи зможе ваш голосовий пакет прорватися крізь чергу й прийти вчасно.

Це друге питання, responsiveness, і двадцять років у нас фактично не було способу виміряти його в браузері. Тепер є. Він вбудований у macOS. Вам просто не розповідали.

Що таке bufferbloat одним абзацом

Кожен роутер і модем між вашим ноутбуком і інтернетом має буфер: невеличку пам’ять, де пакети чекають своєї черги. Коли канал перед буфером повільніший за канал за ним (скажімо, ваш 40 Мбіт/с uplink за гігабітною LAN) буфер починає наповнюватися. Виробники зробили ці буфери нереально великими, бо втрата пакетів сприймається як баг. Але завеликий буфер тримає ваш голосовий Zoom-пакет позаду кожного іншого пакета, який прийшов на мілісекунду раніше. Труба рухає вдосталь байтів. Просто важливі байти стоять у черзі. Ця затримка (у сотнях мілісекунд під навантаженням) і є bufferbloat. Саме через неї ваш speed-тест проходить, а дзвінок розсипається.

Знайомтеся, RPM: Round-trips Per Minute

У 2021 році мережева команда Apple запропонувала зрозумілий показник: RPM, або Round-trips Per Minute. Ідея майже сором’язливо проста. Поки труба насичена (ви завантажуєте й віддаєте на повну) рахуємо, скільки повних пар «запит/відповідь» вдається завершити за хвилину. Responsive-мережа встигає тисячі. Bloated-мережа падає до кількох сотень. Труба в обох випадках та сама 500-Мбіт.

Apple випустила інструмент для цього у macOS Monterey. Він називається networkQuality, лежить у /usr/bin/networkQuality, і якщо ви відкриєте Terminal та запустите його, побачите приблизно таке:

$ networkQuality
==== SUMMARY ====
Uplink capacity:   38.412 Mbps
Downlink capacity: 476.185 Mbps
Responsiveness:    Medium (540 RPM)
Idle Latency:      18 ms

Уважно прочитайте цей вивід. Труба широка, майже півгігабіта на завантаженні. Responsiveness medium. 540 раундів за хвилину це приблизно дев’ять на секунду: ваш голосовий пакет чекає близько 111 мс на завантаженій мережі проти 18 мс у простої. Ця різниця точна причина, чому дзвінок звучить чисто, коли ви вдома самі, і розсипається, коли вся сім’я стримить одночасно.

High, Medium, Low, що це означає?

Apple розкладає RPM на три зрозумілі категорії:

High, 2000 RPM і вище. Мережа responsive. Дзвінки, ігри, спільне редагування будуть відчуватися чітко незалежно від того, що ще працює.
Medium, приблизно 600–2000 RPM. Мережа ще придатна для роботи, але інтерактивні застосунки лагатимуть під навантаженням. Саме тут сидить більшість домашніх мереж у прайм-тайм, і саме звідти надходять скарги.
Low, менше 600 RPM. Буфери забиті. Голосові дзвінки будуть зриватися, відео застрягатиме, натискання клавіш у SSH прилітатимуть пакетами. Жоден обсяг додаткової пропускної здатності цього не виправить, доки буфери не спорожніють.

Чому speed-тест цього не бачить

Speed-тест міряє тільки легку половину задачі: idle throughput, зазвичай коротким сплеском, зазвичай по з’єднанню, якому ваш провайдер навчився давати пріоритет. Він каже, що ваша труба може, коли вона слабо завантажена, і ніколи не ставить наступного питання про затримку під навантаженням. Bufferbloat за визначенням невидимий цьому тесту, тому що тест сам і є навантаженням, іншого трафіку, щоб стати в чергу позаду, не існує.

Симптом, знайомий кінцевому користувачеві: технік провайдера приїжджає, запускає speed-тест, той проходить, і вам кажуть, що з’єднання в нормі. Наступний відеодзвінок все одно заїкається. Технік не збрехав. Він виміряв не те.

RPM-тест на практиці

networkQuality від Apple елегантно-брутальний. Він відкриває кілька паралельних з’єднань до CDN-ендпоінтів, насичує їх в обох напрямках і після цього заміряє, наскільки швидко проходить невелика пара HTTP/2 запит—відповідь під час цього насичення. Це і є RPM. Виміри ємності йдуть у парі, тому інструмент одним запуском повертає всі три числа.

Тест триває близько п’ятнадцяти секунд. Він б’є ваш канал, тому не запускайте його під час дзвінка. Він також викриває речі, які провайдер радше б не показував: Wi-Fi канали, що перетинаються із сусідами; роутер із прошивковим багом, що подвоює глибину черги; VPN, який додає 200 мс затримки до кожного раунду. Ви дуже часто виявите, що слабка ланка не ваш провайдер. Вона у вас удома.

Що робити, коли RPM, Low

Єдиного чарівного рішення немає, але чекліст скінченний:

Спершу спробуйте провід. Увімкніть Ethernet у Mac і запустіть networkQuality знову. Якщо RPM стрибає на High, проблема у Wi-Fi (перевантаження, перетин каналів або відстань) а не в провайдері.
Увімкніть Smart Queue Management. Роутери з SQM, CAKE або fq_codel різко сплющують bufferbloat. Роутер за $100 із увімкненим fq_codel обжене роутер за $600 без цього.
Обмежте upload. Якщо SQM недоступний, обмежте віддачу Mac до ~90 % від виміряної ємності uplink. Тільки ця зміна не дасть вашим власним аплоадам забити буфер і заголодомирити зворотні ACK завантажень.
Замініть комбайн роутер-модем від провайдера. Багато комплектів від ISP налаштовані під бенчмарки пропускної здатності, а не під responsiveness. Переведення ISP-комплекту в bridge-режим і ваш власний роутер перед ним, найбільший одноразовий стрибок RPM, який побачить більшість людей.

Три стійкі міфи

«Більше пропускної здатності це виправить». Іноді, але здебільшого ні. Якщо ваш uplink уже насичується одним бекапом, апгрейд із 40 до 100 Мбіт/с угору допоможе. Але якщо справжній винуватець буфер, ви вдвічі швидше впретеся у ту саму стелю, і симптоми повернуться. Рішення спорожнити чергу, а не розширити трубу перед нею.

«У мене ping 12 мс, усе гаразд». Ping міряє idle-затримку: скільки йде пакет, коли ніщо не заважає. Bufferbloat виявляється тільки під навантаженням. Idle ping 12 мс на bloated-каналі регулярно перетворюється на 350 мс під навантаженням. Запустіть ping в одному терміналі, а великий upload в іншому, і ви побачите це в реальному часі.

«Провайдер уже оптимізував це». Деякі так. Багато ні. Інженерія не складна, але комерційні стимули дивляться в інший бік: мережа, налаштована під speed-тест, виграє ринок, який дивиться на шкали пропускної здатності. Responsiveness рідко з’являється на маркетинговій сторінці.

До чого тут WiFi & IP Info

Ми поклали рушій networkQuality одним кліком у рядок меню. Панель Network Quality у Pro запускає той самий Apple-тест, показує ємності uplink / downlink, звітує про категорію RPM і базовий RTT, і, що важливо, веде журнал. Ви можете тиснути «запустити ще раз» раз на годину протягом тижня й побачити патерн: High у суботу зранку, Medium за вечерею, Low коли діти повертаються зі школи. Саме цей графік змушує провайдера щось зробити, бо повторюваність, ось що перетворює скаргу на тікет.

Поєднайте з графіком Історії затримок і Журналом з’єднань, і ви надішлете провайдеру тридцятисекундний тікет: «RPM падає з 2400 до 410 між 18:00 і 21:00 за місцевим часом, корелює з тригратно вищим медіанним RTT до вашого ж шлюзу. Додаю CSV». Це вже зовсім інша розмова, ніж «у мене інтернет повільний».

Коротка версія

Ваш speed-тест міряє ємність. Ємність реальна, і зрідка саме вона, проблема. Але зазвичай проблема, це responsiveness: чи може ваш трафік вчасно потрапити всередину й назад, поки труба зайнята. RPM, це показник для цього. Apple зробила першокласний інструмент, щоб його міряти. Ми поклали цей інструмент у ваш рядок меню й тримаємо історію.

Якщо з цієї сторінки ви запам’ятаєте лише одне речення, нехай це буде ось це: пропускна здатність, це ширина дороги; responsiveness, це скільки ви стоїте на світлофорі. Важливі обидва. Лише одне з двох є на сторінці вашого speed-тесту.