Як перевіряти швидкість VPN, щоб цифри щось означали
Закріпіть тестовий сервер, тримайте нижній рівень нерухомим і читайте затримку окремо від пропускної здатності. Тунель змінює шлях ще до того, як щось виміряти.
Тест швидкості ніколи не вимірює сам VPN. Він вимірює шлях, а ввімкнення тунелю замінює частину цього шляху ще до того, як зрушиться перший байт. Тому один ноутбук показує здорову цифру на одному сайті й погану на іншому, хоча з жодного боку нічого не змінилося. Читайте результат як доказ про маршрут, а не як оцінку продукту.
Три речі вирішують, чи варте порівняння чогось: чи обидва прогони влучили в ту саму ціль, чи залишилася мережа доступу нерухомою і чи записали ви затримку поряд з обсягом.
Що тунель переписує до першого байта
Клієнт загортає кожен пакет у ще один заголовок, тому корисне навантаження на пакет зменшується. Витрати рахуються на пакет, а не на передачу, тобто великому файлу потрібно більше пакетів, ніж тому самому файлу без тунелю. Такі накладні витрати видно як кількість пакетів, а не як видиме налаштування.
Звідси два наслідки. Тест із великих блоків відчуває витрати на пакет, а тест із багатьох дрібних запитів відчуває натомість обходи туди й назад. І якщо виявлення MTU шляху десь заблоковане, тунель зупиняється на меншому розмірі пакета, і пропускна здатність падає з причини, що не має нічого спільного з шифрами.
Стелю можна спостерігати безпосередньо. У Linux запитайте найбільше навантаження, яке проходить без фрагментації, а потім повторіть із увімкненим тунелем:
ping -M do -s 1472 -c 3 203.0.113.10
Якщо це не вдалося, спустіться до 1,400 і спробуйте знову. Тунель, що несе лише 1,380 байтів, каже вам, що щось стискає сильніше нижче за шляхом, і жодне налаштування на клієнті цього не підніме.
Чому тестовий сервер зсувається, коли вмикається тунель
Більшість інструментів обирають близький сервер за публічною адресою, яку вони бачать. Коли тунель увімкнено, ця адреса належить вихідному вузлу, тож інструмент може вибрати хост в іншому місті чи країні. Тоді ви порівнюєте дві точки призначення, і розрив між ними включає відстань від виходу до тестового хоста.
Закріпіть сервер за іменем або ID до першого прогону й утримуйте його в кожному наступному. Якщо інструмент його не утримує, виберіть ціль, яку контролюєте, і керуйте нею самі: iperf3 -c test.example.net -R -t 20 тримає пункт призначення нерухомим і дає число, яке можна порівняти з учорашнім.
Змініть одну змінну, а нижній рівень не одна
Бездротове з'єднання — звичайна прихована зміна. Сила сигналу зсувається, коли ноутбук рухається, а зайнятість каналу зсувається, коли сусід починає розмову, тому два прогони з різницею в десять хвилин по Wi-Fi не є повтореннями того самого тесту. Кабель або нерухоме положення із записаним рівнем сигналу прибирають більшу частину цього шуму. Запис рівня сигналу на початку й наприкінці кожного прогону зазвичай достатній, щоб показати, чи належать два прогони один одному.
Навантаження пристрою належить до того самого кошика. Клієнт, що шифрує на одному ядрі, упирається у власну стелю задовго до каналу, а фонова синхронізація впирається раніше. Стежте за CPU під час прогону й записуйте, що ще було відкрито. Налаштування живлення теж можуть вкусити, бо ноутбук на батареї може обмежити процесор задовго до того, як канал узагалі наблизиться до завантаження.
| Measurement | What it answers | What it misses |
|---|---|---|
| Download | Bulk capacity along the path | Any question about responsiveness |
| Upload | Capacity from client to exit | Download health |
| RTT to a fixed target | Distance plus queueing | Whether capacity is available |
| Jitter or loss | Stability under load | How much the link can carry |
Тримайте нижній рівень нерухомим, а не усереднюйте по ньому. Три прогони, що збігаються, кажуть більше, ніж десять, зроблених у різних кімнатах.
Затримка, втрати й ICMP відповідають на різні питання
Ping надсилає маленький зонд на фіксовану адресу, і багато мереж відповідають на ICMP з низьким пріоритетом або повністю його ігнорують. Відсутні відповіді описують зонд, а не пакети застосунку. Час обходу, що зростає під навантаженням, зазвичай означає, що заповнюється черга, а не що маршрут подовшав.
Щоб дізнатися, чи додає тунель затримку, порівняйте одну ціль з ним і без нього або порівняйте два виходи, доступні з тієї самої мережі доступу. Запускайте зонд багаторазово й дивіться на розкид, бо середнє приховує саме ту мінливість, яка робить дзвінок непридатним.
Поверніться до завдання, яке здалося повільним
Метрика, що поліпшується, поки дзвінок ще уривається відповіла на щось інше. Запустіть знову те завдання, з якого почалося розслідування, чи то зустріч, спільний файл чи сеанс віддаленого робочого столу. Якщо число поліпшилося, а завдання ні, вузьке місце було там, куди тест так і не дістався, наприклад сервер за тунелем або ваша висхідна лінія.
Записуйте кожен прогін із пристроєм, мережею доступу, кінцевою точкою, протоколом, ціллю й часом. Прогін, який так і не підключився, — це результат доступності, а не нульова пропускна здатність, тому зберігайте його під цією міткою, а не видаляйте.
Короткий список перед наступним порівнянням
Закріпіть ціль і запишіть, чому ви її обрали. Позначте розмір пакета, який допускає шлях, щоб у пізнішого падіння було пояснення. Тримайте мережу доступу однаковою, позначте навантаження CPU і зробіть три прогони, перш ніж вірити розбіжності.
Потім змініть рівно одну річ і повторіть. Порівняння, яке ви можете пояснити, краще за те, де число більше.