A mund të jetë VPN më i shpejtë se lidhja e drejtpërdrejtë?

Një transferim që zvarritet në lidhjen e zyrës ndonjëherë përfundon shpejt përmes tunelit, dhe inkapsulimi shtesë e bën këtë të duket e pamundur. Paradoksi i dukshëm vjen nga krahasimi i gjërave të gabuara. Tuneli shton punë dhe ndryshon gjithashtu cilën rrugë rrjeti ndjek trafiku, cilën adresë sheh destinacioni dhe ndonjëherë cili server përgjigjet fare. Vendimi midis dy rrugëve kërkon që këto tre efekte të ndahen përpara çdo përfundimi për shpejtësinë.

Tri gjëra që tuneli mund të ndryshojë

E para është transit-i. Rrugëtimi në internet ndjek politikën e operatorit dhe marrëdhëniet e biznesit, jo vonesën e matur, prandaj rruga përmes ofruesit të VPN mund të kalojë në rrjete të ndryshme nga rruga e drejtpërdrejtë. Mund të shmangë një pikë shkëmbimi të mbingarkuar ose të zbresë në një me peering më të mirë, dhe po aq lehtë mund të jetë më keq.

E dyta është destinacioni. Një ndryshim i adresës së daljes shpesh ndryshon përgjigjen DNS, dhe një rrjet përmbajtjeje mund t'ju japë një cache ose rajon tjetër. Atëherë një pjesë e përmirësimit i takon serverit të ri dhe jo tunelit. I njëjti emër hosti mund të zbresë në një server më të afërt ose më pak të ngarkuar pa ndryshuar asgjë te klienti.

E treta është sjellja e transportit. Inkapsulimi ndryshon madhësinë efektive të paketës, dhe një tunel që shmang një segment të mesëm me humbje mund të lejojë një rrjedhë TCP të rritë dritaren e saj në vend që të tërhiqet vazhdimisht. Asnjë nga këto nuk është mekanizëm universal përshpejtimi; secili është një kusht që duhet vëzhguar. Ndarja e tyre është ajo që e kthen kureshtjen në fakt.

Çfarë nuk mund të ndryshojë

Asgjë në tunel nuk i shton kapacitet lidhjes midis pajisjes dhe rrjetit. Një kanal Wi-Fi i ngopur, një milje e fundit e mbingarkuar ose një plan celular i kufizuar kufizojnë të dyja rrugët njësoj, dhe një test shpejtësie përmes tunelit nuk mund ta kalojë atë tavan. E njëjta lidhje mban paketat e inkapsuluara, prandaj inkapsulimi mund të konsumojë kapacitet, por kurrë nuk e krijon atë. Ajo që ndryshon është ku shkojnë paketat pasi largohen nga ajo lidhje. Prandaj një rezultat i shpejtë i tunelit ka gjithmonë një shpjegim mbi hop-in e parë.

Kufijtë në anën e serverit janë njësoj indiferentë. Nëse hosti i largët shërben ngadalë, një rrugë më e mirë thjesht e dorëzon përgjigjen e ngadaltë më me efikasitet, dhe përdoruesi vazhdon të presë. Një origjinë e përbashkët nën ngarkesë duket e ngadaltë në të dyja rrugët në të njëjtin moment.

Krahasoni rrugët si duhet

Mbani identike aplikacionin, drejtimin, kohëzgjatjen dhe njëkohshmërinë, dhe ndryshoni vetëm rrugën. Ekzekutoni çdo test më shumë se një herë, në të njëjtën orë të ditës, dhe shënoni adresën e daljes dhe përgjigjen e zgjidhësit pranë xhiros. Një ekzekutim është mostër dhe jo matje, dhe një shkarkim i vetëm i shpejtë mund të jetë një goditje cache që nuk thotë asgjë për rrugën. Shkruani kushtet para rezultateve, sepse numrat janë të vështirë të interpretohen më pas.

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

Përgjigja e zgjidhësit është detaji që shumica e krahasimeve e lënë jashtë, dhe shpjegon «përmirësimet» që zhduken kur detyrohet i njëjti server. Nëse adresa ndryshon midis ekzekutimeve, testi ka krahasuar dy destinacione dhe jo dy rrugë. Raportoni vonesën dhe humbjen pranë xhiros, sepse një rrugë më e shpejtë në tërësi por që shton vonesë në çdo kërkesë interaktive nuk është më e mirë për ngarkesën e punës që u ankua. Koha e shkuarjes dhe kthimit ka më shumë rëndësi se shpejtësia masive për çdo gjë që pyet dhe pret.

Kur ia vlen të ruhet diferenca

Nëse një tunel i miratuar përmirëson në mënyrë të besueshme një ngarkesë pune të caktuar, ai është një zgjedhje operative legjitime: dokumentoni ngarkesën, matjen dhe daljen e përdorur. Një regjistrim i dobishëm emërton një host, adresën e daljes që prodhoi tuneli, përgjigjen e zgjidhësit dhe të njëjtat shifra nga rruga e drejtpërdrejtë në të njëjtën ditë. Kjo mjafton që inxhinieri i radhës ta përsëritë krahasimin në vend që ta rindiskutojë. Ende nuk është provë që ofruesi kufizon diçka, dhe nuk transferohet në aplikacione të tjera ose orë të tjera.

Mbajeni regjistrimin e matjes bashkë me konfigurimin. Ai përgjigjet pyetjes së radhës nëse përmirësimi ekziston ende, dhe ky është mënyra e vetme për të ditur nëse ndryshoi rruga apo ngarkesa. Një regjistrim pa datë nuk mund t'i përgjigjet fare asaj pyetjeje.