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

Отговорът на резолвера е детайлът, който повечето сравнения пропускат, и той обяснява „подобренията“, които изчезват, когато се наложи същият сървър. Ако адресът се различава между пусканията, тестът е сравнил две дестинации, а не два пътя. Съобщавайте закъснението и загубите до пропускателната способност, защото път, който е по-бърз като цяло, но добавя закъснение към всяка интерактивна заявка, не е по-добър за натоварването, което се е оплакало. Времето за двупосочен обмен е по-важно от масовата скорост за всичко, което пита и чака.

Кога разликата си струва да се запази

Ако одобрен тунел надеждно подобрява конкретно натоварване, това е законен оперативен избор: документирайте натоварването, измерването и използвания изход. Полезен запис посочва един хост, изходния адрес, който тунелът е дал, отговора на резолвера и същите числа от директния път в същия ден. Това е достатъчно следващият инженер да повтори сравнението, вместо да го препира отново. Това все още не е доказателство, че доставчикът ограничава нещо, и не се пренася към други приложения или други часове.

Пазете записа от измерването заедно с конфигурацията. Той отговаря на следващия въпрос дали подобрението още съществува и това е единственият начин да се разбере дали пътят или натоварването се е променило. Запис без дата не може да отговори на този въпрос изобщо.