Може ли 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

Одговор резолвера је детаљ који већина поређења изоставља, и он објашњава „побољшања“ која нестану кад се исти сервер форсира. Ако се адреса разликује између покретања, тест је упоредио два одредишта, а не два пута. Пријавите кашњење и губитак уз пропусност, јер пут који је укупно бржи али додаје одгоду сваком интерактивном захтеву није бољи за оптерећење које се жалило. Време повратног пута важније је од масовне брзине за све што пита и чека.

Када разлику вреди задржати

Ако одобрени тунел поуздано побољшава одређено оптерећење, то је легитиман оперативни избор: документујте оптерећење, мерење и коришћени излаз. Употребљив запис именује један хост, излазну адресу коју је тунел дао, одговор резолвера и исте бројеве с директног пута истог дана. То је довољно следећем инжењеру да понови поређење уместо да га поново расправља. То још није доказ да добављач нешто ограничава, и не преноси се на друге апликације или друге сате.

Чувајте запис мерења уз конфигурацију. Он одговара на следеће питање постоји ли побољшање још, а то је једини начин да се зна је ли се променио пут или оптерећење. Запис без датума не може одговорити на то питање уопште.