Poate un VPN să fie mai rapid decât conexiunea directă?

Un transfer care se târăște pe conexiunea biroului se termină uneori repede prin tunel, iar încapsularea suplimentară face ca acest lucru să pară imposibil. Paradoxul aparent vine din compararea lucrurilor greșite. Tunelul adaugă muncă și schimbă și pe ce cale de rețea merge traficul, ce adresă vede destinația și uneori ce server răspunde. Decizia între cele două rute cere separarea acestor trei efecte înainte de orice concluzie despre viteză.

Trei lucruri pe care tunelul le poate schimba

Primul este tranzitul. Rutarea pe internet urmează politica operatorului și relațiile comerciale, nu latența măsurată, așa că drumul prin furnizorul de VPN poate traversa alte rețele decât ruta directă. Poate ocoli un punct de schimb aglomerat sau poate ajunge pe unul mai bine conectat, și la fel de ușor poate fi mai rău.

Al doilea este destinația. O schimbare a adresei de ieșire modifică adesea răspunsul DNS, iar o rețea de conținut vă poate da alt cache sau altă regiune. Atunci o parte din îmbunătățire aparține noului server, nu tunelului. Același nume de gazdă poate ajunge pe un server mai apropiat sau mai puțin încărcat fără ca nimic să se schimbe la client.

Al treilea este comportamentul transportului. Încapsularea schimbă dimensiunea efectivă a pachetelor, iar un tunel care ocolește un segment intermediar cu pierderi poate lăsa un flux TCP să își mărească fereastra în loc să dea înapoi repetat. Niciunul dintre acestea nu este un mecanism universal de accelerare; fiecare este o condiție care trebuie observată. Separarea lor este ceea ce transformă o curiozitate într-un fapt.

Ce nu poate schimba

Nimic din tunel nu adaugă capacitate legăturii dintre dispozitiv și rețea. Un canal Wi-Fi saturat, o ultimă milă aglomerată sau un abonament mobil limitat restricționează ambele rute la fel, iar un test de viteză prin tunel nu poate depăși acel plafon. Aceeași legătură transportă pachetele încapsulate, deci încapsularea poate consuma capacitate, dar nu o poate crea niciodată. Ce se schimbă este unde merg pachetele după ce părăsesc acea legătură. De aceea un rezultat rapid prin tunel are întotdeauna o explicație deasupra primului salt.

Limitele de pe partea serverului sunt la fel de indiferente. Dacă gazda îndepărtată servește încet, o cale mai bună doar livrează răspunsul lent mai eficient, iar utilizatorul încă așteaptă. O origine partajată sub sarcină pare lentă pe ambele căi în același moment.

Comparați căile corect

Păstrați identice aplicația, direcția, durata și concurența și schimbați doar calea. Rulați fiecare test mai mult de o dată, la aceeași oră din zi, și notați adresa de ieșire și răspunsul resolverului lângă debit. O singură rulare este o mostră, nu o măsurătoare, iar o singură descărcare rapidă poate fi o lovitură în cache care nu spune nimic despre rută. Scrieți condițiile înaintea rezultatelor, pentru că numerele sunt greu de interpretat după aceea.

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

Răspunsul resolverului este detaliul pe care majoritatea comparațiilor îl omit și explică „îmbunătățirile” care dispar când se forțează același server. Dacă adresa diferă între rulări, testul a comparat două destinații și nu două căi. Raportați latența și pierderile lângă debit, pentru că o cale mai rapidă în ansamblu dar care adaugă întârziere fiecărei cereri interactive nu este mai bună pentru sarcina de lucru care s-a plâns. Timpul dus-întors contează mai mult decât viteza în masă pentru tot ce întreabă și așteaptă.

Când diferența merită păstrată

Dacă un tunel aprobat îmbunătățește în mod fiabil o anumită sarcină de lucru, este o alegere operațională legitimă: documentați sarcina, măsurătoarea și ieșirea folosită. O înregistrare utilă numește o singură gazdă, adresa de ieșire produsă de tunel, răspunsul resolverului și aceleași cifre de pe calea directă în aceeași zi. Este suficient pentru ca următorul inginer să repete comparația în loc să o discute din nou. Încă nu este dovada că furnizorul limitează ceva și nu se transferă la alte aplicații sau alte ore.

Păstrați înregistrarea măsurătorii împreună cu configurația. Răspunde la următoarea întrebare dacă îmbunătățirea mai există, iar aceasta este singura modalitate de a ști dacă s-a schimbat calea sau sarcina de lucru. O înregistrare fără dată nu poate răspunde deloc la această întrebare.