Чому два тести швидкості VPN в одному тунелі не збігаються

Два прогони, один тунель, а цифри різняться втричі. Тунель між ними не змінювався. Змінилося вимірювання: тестовий сайт, який вибирає сервер за вашою видимою локацією, кількість потоків, що визначає, чи заповнює трубу один повільний старт, чи шість, і тривалість, достатньо коротка, щоб закінчитися раніше, ніж маршрут почне використовуватися як слід. Тести швидкості не помиляються, але вони відповідають на вужче питання, ніж те, яке їм ставлять люди.

Нова адреса виходу змінює призначення тесту

Більшість тестових сайтів вибирають вимірювальний сервер автоматично, і частково за тим, звідки нібито надходить ваше з'єднання. Увімкніть тунель, і ваша видима країна зміниться, отже, зміниться вибраний сервер, і порівняння тепер охоплює два різні маршрути до двох різних хостів.

Результат зовсім не є вимірюванням VPN. Це вимірювання вашого шляху до сервера, який ви не вибирали, і різницею між двома прогонами може керувати піринг цього сервера, а не щось, що зробив тунель.

Зафіксуйте призначення перш ніж змінювати будь-що інше. Кожен гідний інструмент дозволяє вибрати сервер явно, а коли не дозволяє, сторінка результатів зазвичай називає використаний, і цього достатньо, щоб помітити, що прогони непорівнювані. Підтвердьте, що бачив сайт, перш ніж довіряти його вибору:

curl -sS https://ipinfo.io/json | grep -E '"ip"|"org"|"country"'

Якщо країна змінилася між прогонами, змінилося й усе, що тест вибрав після цього. Запишіть спостережуваний вихід поруч із кожним результатом, і плутанина здебільшого зникає.

Повільний старт закінчується вже після завершення більшості коротких тестів

TCP-з'єднання не починається зі швидкості каналу. Воно починається з малого вікна перевантаження, приблизно подвоює його за кожен круговий обхід і досягає пропускної здатності маршруту лише після кількох обходів. Тест на десять секунд на маршруті з високою затримкою може провести значну частину життя в цьому розгоні.

Тому тунель із більшою затримкою показує в короткому тесті гірший результат, ніж заслуговує, і тому довший прогін часто повідомляє більше число без будь-якої зміни конфігурації. рамка пропускної здатності RFC 6349 розглядає це прямо, і тому серйозні вимірювання тривають достатньо довго, щоб вийти на усталений режим. П'ятисекундний прогін на супутниковому маршруті вимірює прискорювач, а не дорогу.

Дивіться на фази з'єднання, а не довіряйте одному числу. Curl повідомляє про кожен етап окремо, тож видно, чи йде час у рукостискання, у розгін або в передавання:

curl -sS -o /dev/null -w 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} total=%{time_total} bytes/s=%{speed_download}\n' \
  https://mirror.example.net/testfile.bin

Запустіть його двічі підряд на те саме призначення. Якщо другий прогін значно швидший, ви вимірювали розгін, а не маршрут, і будь-яке порівняння, що використало лише перший, підозріле.

Один потік і шість потоків вимірюють різні речі

Один TCP-потік обмежений вікном, яке він утримує в польоті, а це приблизно час кругового обходу, помножений на швидкість. На довгому маршруті цей добуток перевищує те, що використає один потік, тому одне завантаження занижує наявну пропускну здатність. Шість паралельних потоків закривають цю прогалину і дають більше число.

iperf3 -c speed.example.net -t 20
iperf3 -c speed.example.net -t 20 -P 6
mtr -rwc 50 speed.example.net

Обидва числа правдиві. Число одного потоку каже, що зробить одне завантаження, а це зазвичай отримує вкладка браузера. Паралельне число каже, що маршрут може нести загалом, і це може використати торент або багаточастинне завантаження. Цитувати одне як інше це спосіб без причини замінити здоровий тунель.

Порівняння паралельного результату з результатом одного потоку це найчастіший шлях, яким люди доходять висновку, що VPN удвічі урізав їхню швидкість. Зрівняйте метод, потім порівнюйте. Слід у третій команді додає відсутній контекст: маршрут із великим джиттером дасть нестабільні результати в обох режимах, і жодна кількість потоків цього не виправить.

Шифрування коштує часу процесора, інкапсуляція коштує байтів

На кожному пакеті працюють два механізми незалежно від швидкості каналу. Шифрування витрачає процесор на байт, а інкапсуляція додає байти заголовка, які канал усе одно мусить нести. Обидва виявляються як стеля, і симптоми в них різні.

Стеля процесора виглядає як плато: пропускна здатність перестає зростати, скільки б потоків ви не додали, а процесор машини зайнятий, тоді як канал ні. На малому маршрутизаторі або телефоні це часто і є справжня межа, і тому швидка лінія може дати скромний тунель.

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

Ці три часто плутають, бо користувачі описують їх усі як повільний VPN. Лише перший реагує на потужнішу машину, лише другий на менший MTU, і лише третій на керування чергами.

Запишіть метод у протокол

Результат, який варто зберегти, називає пристрій, мережу доступу, вихід, вимірювальний сервер, напрямок, кількість потоків і тривалість. Без цього два числа не можна порівняти, а заявка з одним числом насправді настрій.

Зберігайте й погані прогони. Серія, де один вихід щоразу дає зависання, значно інформативніша за середнє, і зависання це саме те, що середні приховують.

Потім перевіряйте те, що справді важливо. Якщо мета велике завантаження, завантажте файл. Якщо мета дзвінок, вимірюйте затримку під навантаженням, а не пропускну здатність у простої, бо тунель може добре виступити в тесті швидкості і все одно зробити кожну зустріч нечутною.