Může být VPN rychlejší než přímé připojení?

Přenos, který se na kancelářském připojení plazí, někdy tunelem skončí rychle, a dodatečná enkapsulace to nechává vypadat nemožně. Zdánlivý paradox vzniká srovnáváním nesprávných věcí. Tunel přidává práci a zároveň mění kterou síťovou cestou provoz jde, jakou adresu vidí cíl a někdy i který server vůbec odpovídá. Rozhodnutí mezi oběma trasami vyžaduje tyto tři efekty oddělit dřív, než padne jakýkoli závěr o rychlosti.

Tři věci, které tunel může změnit

První je tranzit. Směrování na internetu se řídí politikou operátora a obchodními vztahy, ne naměřenou latencí, takže cesta přes poskytovatele VPN může procházet jinými sítěmi než přímá trasa. Může se vyhnout přetížené výměnné stanici nebo skončit na takové s lepším peeringem, a stejně snadno může být horší.

Druhý je cíl. Změna výstupní adresy často mění odpověď DNS a obsahová síť vám může dát jinou mezipaměť nebo jiný region. Část zlepšení pak patří novému serveru, ne tunelu. Stejné jméno hostitele může skončit na bližším nebo méně zatíženém serveru, aniž by se na klientu něco změnilo.

Třetí je chování transportu. Enkapsulace mění efektivní velikost paketu a tunel, který se vyhýbá ztrátovému střednímu úseku, může nechat TCP tok zvětšovat okno místo opakovaného couvání. Nic z toho není univerzální mechanismus zrychlení; každý je podmínka, kterou je třeba pozorovat. Právě jejich oddělení mění zajímavost ve fakt.

Co změnit nemůže

Nic v tunelu nepřidává kapacitu spoji mezi zařízením a sítí. Nasycený kanál Wi-Fi, přetížená poslední míle nebo omezený mobilní tarif omezují obě cesty stejně a test rychlosti tunelem nemůže ten strop překročit. Stejný spoj nese zapouzdřené pakety, takže enkapsulace může kapacitu spotřebovávat, ale nikdy ji nevytváří. Mění se to, kam pakety jdou poté, co tento spoj opustí. Proto má rychlý výsledek tunelem vždy vysvětlení výš než za prvním skokem.

Omezení na straně serveru jsou stejně lhostejná. Pokud vzdálený hostitel obsluhuje pomalu, lepší cesta jen doručí pomalou odpověď efektivněji a uživatel stále čeká. Sdílený zdroj pod zátěží vypadá v obou cestách pomalu ve stejný okamžik.

Porovnávejte cesty správně

Udržujte aplikaci, směr, trvání a souběžnost shodné a měňte jen cestu. Spusťte každý test více než jednou, ve stejnou denní dobu, a zapište výstupní adresu a odpověď resolveru vedle propustnosti. Jedno spuštění je vzorek, ne měření, a jedno rychlé stažení může být zásah do mezipaměti, který o trase nic neříká. Zapište podmínky před výsledky, protože čísla se pak těžko vykládají.

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

Odpověď resolveru je detail, který většina srovnání vynechává, a vysvětluje „zlepšení“, která zmizí, když se vynutí stejný server. Pokud se adresa mezi spuštěními liší, test porovnal dvě destinace, ne dvě cesty. Uvádějte latenci a ztrátovost vedle propustnosti, protože cesta, která je celkově rychlejší, ale každému interaktivnímu požadavku přidává zpoždění, není pro zátěž, která si stěžovala, lepší. Doba obratu je pro všechno, co se ptá a čeká, důležitější než hromadná rychlost.

Kdy má smysl rozdíl zachovat

Pokud schválený tunel spolehlivě zlepšuje konkrétní zátěž, je to legitimní provozní volba: zdokumentujte zátěž, měření a použitý výstup. Použitelný záznam jmenuje jeden hostitel, výstupní adresu, kterou tunel dal, odpověď resolveru a stejná čísla z přímé cesty ve stejný den. To stačí, aby další inženýr srovnání zopakoval, místo aby je znovu řešil. Stále to není důkaz, že poskytovatel něco omezuje, a nepřenáší se na jiné aplikace ani jiné hodiny.

Uchovávejte záznam měření s konfigurací. Odpovídá na další otázku, zda zlepšení stále existuje, a to je jediný způsob, jak zjistit, zda se změnila cesta nebo zátěž. Záznam bez data na takovou otázku neodpoví vůbec.