Чи може VPN бути швидшим за пряме підключення?

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

Три речі, які тунель може змінити

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

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

Третє — поведінка транспорту. Інкапсуляція змінює ефективний розмір пакета, і тунель, що оминає ділянку з втратами, може дозволити TCP-потоку збільшувати вікно замість повторних відступів. Ніщо з цього не є універсальним механізмом прискорення; кожне — умова, яку треба спостерігати. Саме їх розділення перетворює цікавість на факт.

Чого він змінити не може

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

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

Порівнюйте шляхи правильно

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

mtr -rwc 50 -T -P 443 203.0.113.20
curl -o /dev/null -s -w '%{speed_download} %{time_connect}\n' https://example.com/file
dig +short cdn.example.com
traceroute -n -T -p 443 cdn.example.com

Відповідь резолвера — та деталь, яку більшість порівнянь оминає, і вона пояснює «поліпшення», що зникають, коли примусово вибрати той самий сервер. Якщо адреса різниться між запусками, тест порівняв два призначення, а не два шляхи. Повідомляйте затримку та втрати поряд із пропускною здатністю, бо шлях, швидший загалом, але такий, що додає затримку кожному інтерактивному запиту, не кращий для навантаження, яке скаржилося. Час обігу важливіший за масову швидкість для всього, що питає й чекає.

Коли різницю варто зберегти

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

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