Ar VPN gali būti greitesnis už tiesioginį ryšį?
Inkapsuliavimas prideda sąnaudų, tačiau išėjimas gali pakeisti tranzitą, paskirties vietą ir transporto sąlygas. Spręskite trimis palyginimais, o ne vienu greičio testu.
Perdavimas, kuris biuro ryšiu vos slenka, kartais tuneliu baigiamas greitai, o papildomas inkapsuliavimas tai daro neįmanomu. Matomas paradoksas kyla lyginant netinkamus dalykus. Tunelis prideda darbo, o taip pat keičia kuriuo tinklo keliu eina srautas, kokį adresą mato paskirties vieta ir kartais kuris serveris apskritai atsako. Sprendimas tarp dviejų maršrutų reikalauja atskirti šiuos tris poveikius prieš bet kokią išvadą apie greitį.
Trys dalykai, kuriuos tunelis gali pakeisti
Pirmas – tranzitas. Interneto maršrutizavimas vadovaujasi operatoriaus politika ir verslo santykiais, o ne išmatuota latencija, todėl kelias per VPN tiekėją gali kirsti kitus tinklus nei tiesioginis maršrutas. Jis gali išvengti perkrautos mainų vietos arba atsidurti geresnio peering vietoje, ir lygiai taip pat lengvai gali būti blogesnis.
Antras – paskirties vieta. Išėjimo adreso pasikeitimas dažnai keičia DNS atsakymą, o turinio tinklas gali duoti kitą podėlį ar regioną. Tada dalis pagerėjimo priklauso naujam serveriui, o ne tuneliui. Tas pats prieglobos vardas gali atsidurti artimesniame ar mažiau apkrautame serveryje, klientui nieko nekeičiant.
Trečias – transporto elgsena. Inkapsuliavimas keičia efektyvų paketo dydį, o tunelis, apeinantis nuostolius turintį vidurinį segmentą, gali leisti TCP srautui didinti langą, o ne kartoti atsitraukimą. Nė vienas iš jų nėra universalus pagreitinimo mechanizmas; kiekvienas yra sąlyga, kurią reikia stebėti. Būtent jų atskyrimas paverčia smalsumą faktu.
Ko jis negali pakeisti
Niekas tunelyje neprideda talpos jungčiai tarp įrenginio ir tinklo. Užsėdintis Wi-Fi kanalas, perkrauta paskutinė mylia ar ribotas mobilusis planas vienodai riboja abu kelius, o greičio testas per tunelį negali viršyti šios lubos. Ta pati jungtis neša inkapsuliuotus paketus, todėl inkapsuliavimas gali eikvoti talpą, bet niekada jos nesukuria. Keičiasi tai, kur paketai eina palikę tą jungtį. Todėl greitas tunelio rezultatas visada turi paaiškinimą aukščiau pirmo šuolio.
Serverio pusės ribos yra taip pat abejingos. Jei nuotolinis mazgas aptarnauja lėtai, geresnis kelias tik efektyviau pristato lėtą atsakymą, o naudotojas vis tiek laukia. Bendra kilmė esant apkrovai atrodo lėtai abiem keliais tuo pačiu metu.
Palyginkite kelius teisingai
Laikykite programą, kryptį, trukmę ir lygiagretumą identiškus, o keiskite tik kelią. Kiekvieną testą paleiskite daugiau nei kartą, tą pačią paros valandą, ir šalia pralaidumo užrašykite išėjimo adresą bei sprendėjo atsakymą. Vienas paleidimas yra imtis, o ne matavimas, ir vienas greitas atsisiuntimas gali būti podėlio pataikymas, nieko nesakantis apie maršrutą. Užrašykite sąlygas prieš rezultatus, nes skaičius vėliau sunku interpretuoti.
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
Sprendėjo atsakymas yra detalė, kurią dauguma palyginimų praleidžia, ir ji paaiškina „pagerėjimus“, kurie išnyksta privertus tą patį serverį. Jei adresas skiriasi tarp paleidimų, testas palygino dvi paskirties vietas, o ne du kelius. Nurodykite latenciją ir nuostolius šalia pralaidumo, nes kelias, kuris apskritai greitesnis, bet kiekvienai interaktyviai užklausai prideda uždelsimą, nėra geresnis tam krūviui, kuris skundėsi. Grįžtamasis laikas svarbesnis už masinį greitį viskam, kas klausia ir laukia.
Kada skirtumą verta išsaugoti
Jei patvirtintas tunelis patikimai pagerina konkretų krūvį, tai teisėtas operacinis pasirinkimas: dokumentuokite krūvį, matavimą ir naudotą išėjimą. Naudingas įrašas įvardija vieną mazgą, tunelio sukurtą išėjimo adresą, sprendėjo atsakymą ir tuos pačius skaičius iš tiesioginio kelio tą pačią dieną. To pakanka kitam inžinieriui pakartoti palyginimą, o ne vėl jį ginčyti. Tai vis dar nėra įrodymas, kad tiekėjas ką nors riboja, ir neperkeliama į kitas programas ar kitas valandas.
Laikykite matavimo įrašą kartu su konfigūracija. Jis atsako į kitą klausimą, ar pagerėjimas dar egzistuoja, ir tai vienintelis būdas sužinoti, ar pasikeitė kelias, ar krūvis. Įrašas be datos į tą klausimą negali atsakyti visai.