Može li VPN biti brži od direktne veze?

Prenos koji na uredskoj vezi jedva mili ponekad se kroz tunel završi brzo, a dodatna enkapsulacija čini to nemogućim. Prividni paradoks dolazi iz poređenja pogrešnih stvari. Tunel dodaje posao, a mijenja i kojim mrežnim putem saobraćaj ide, koju adresu vidi odredište i ponekad koji server uopće odgovara. Odluka između dvije rute traži razdvajanje ta tri efekta prije bilo kakvog zaključka o brzini.

Tri stvari koje tunel može promijeniti

Prvo je tranzit. Internet rutiranje slijedi politiku operatera i poslovne odnose, a ne izmjereno kašnjenje, pa put kroz dobavljača VPN-a može preći druge mreže od direktne rute. To može izbjeći zagušeno mjesto razmjene ili stići na ono s boljim peeringom, i jednako lako može biti gore.

Drugo je odredište. Promjena izlazne adrese često mijenja DNS odgovor, a mreža sadržaja vam može dati drugi keš ili regiju. Tada dio poboljšanja pripada novom serveru, a ne tunelu. Isti naziv hosta može stići na bliži ili manje opterećen server, a da se na klijentu ništa ne promijeni.

Treće je ponašanje prenosa. Enkapsulacija mijenja efektivnu veličinu paketa, a tunel koji zaobilazi gubitni srednji segment može pustiti TCP tok da poveća svoj prozor umjesto da se iznova povlači. Ništa od ovoga nije univerzalni mehanizam ubrzanja; svako je uslov koji treba posmatrati. Razdvajanje jeste ono što radoznalost pretvara u činjenicu.

Šta ne može promijeniti

Ništa u tunelu ne dodaje kapacitet vezi između uređaja i mreže. Zasićen Wi-Fi kanal, zagušena zadnja milja ili ograničen mobilni plan jednako ograničavaju oba puta, a test brzine kroz tunel ne može preći taj plafon. Ista veza nosi enkapsulirane pakete, pa enkapsulacija može trošiti kapacitet, ali ga nikada ne stvara. Mijenja se to gdje paketi idu nakon što napuste tu vezu. Zato brz rezultat kroz tunel uvijek ima objašnjenje uzvodno od prvog skoka.

Ograničenja na strani servera jednako su ravnodušna. Ako udaljeni host poslužuje sporo, bolji put samo dostavlja spori odgovor efikasnije, a korisnik i dalje čeka. Zajednički izvor pod opterećenjem izgleda sporo na oba puta u istom trenutku.

Poredite puteve kako treba

Držite aplikaciju, smjer, trajanje i paralelnost istim, a mijenjajte samo put. Pokrenite svaki test više od jednom, u isto doba dana, i zapišite izlaznu adresu i odgovor resolvera uz propusnost. Jedno pokretanje je uzorak, a ne mjerenje, i jedno brzo preuzimanje može biti pogodak keša koji ništa ne govori o ruti. Zapišite uslove prije rezultata, jer brojeve je poslije teško tumačiti.

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

Odgovor resolvera je detalj koji većina poređenja izostavlja, i on objašnjava „poboljšanja“ koja nestanu kad se isti server forsira. Ako se adresa razlikuje između pokretanja, test je uporedio dva odredišta, a ne dva puta. Prijavite kašnjenje i gubitak uz propusnost, jer put koji je ukupno brži ali dodaje odgodu svakom interaktivnom zahtjevu nije bolji za opterećenje koje se žalilo. Vrijeme povratnog puta važnije je od masovne brzine za sve što pita i čeka.

Kada razliku vrijedi zadržati

Ako odobreni tunel pouzdano poboljšava određeno opterećenje, to je legitiman operativni izbor: dokumentujte opterećenje, mjerenje i korišteni izlaz. Upotrebljiv zapis imenuje jedan host, izlaznu adresu koju je tunel dao, odgovor resolvera i iste brojke s direktnog puta istog dana. To je dovoljno sljedećem inženjeru da ponovi poređenje umjesto da ga ponovo raspravlja. To još nije dokaz da dobavljač nešto ograničava, i ne prenosi se na druge aplikacije ili druge sate.

Čuvajte zapis mjerenja uz konfiguraciju. On odgovara na sljedeće pitanje postoji li poboljšanje još, a to je jedini način da se zna je li se promijenio put ili opterećenje. Zapis bez datuma ne može odgovoriti na to pitanje uopšte.