Zakaj se dva testa hitrosti VPN v istem tunelu ne ujemata

Dva zagona, en tunel, številke pa se razlikujejo za trikrat. Tunel se med njima ni spremenil. Spremenilo se je merjenje: testno mesto, ki strežnik izbere glede na vašo navidezno lokacijo, število tokov, ki odloči, ali cev polni en počasen začetek ali šest, in trajanje, ki je tako kratko, da se konča, preden se pot sploh začne pravilno uporabljati. Testi hitrosti niso napačni, vendar odgovarjajo na ožje vprašanje od tistega, ki jim ga ljudje postavljajo.

Nov naslov izhoda spremeni cilj testa

Večina testnih mest samodejno izbere merilni strežnik in ga izbere deloma tako, da pogleda, od kod izgleda, da prihaja vaša povezava. Vklopite tunel in vaša navidezna država se spremeni, zato se izbrani strežnik spremeni, primerjava pa zdaj zajema dve različni poti do dveh različnih gostiteljev.

Rezultat sploh ni merjenje VPN. To je merjenje vaše poti do strežnika, ki ga niste izbrali, in razliki med obema zagonoma lahko gospodari peering tega strežnika, ne pa kaj, kar je naredil tunel.

Pritrdite cilj, preden spremenite karkoli drugega. Vsako verodostojno orodje vam omogoča, da strežnik izberete izrecno, in kadar ne, stran z rezultati običajno navede uporabljenega, kar zadošča, da opazite, da zagona nista primerljiva. Potrdite, kaj je mesto videlo, preden zaupate njegovi izbiri:

curl -sS https://ipinfo.io/json | grep -E '"ip"|"org"|"country"'

Če se je država med zagonoma spremenila, se je spremenilo tudi vse, kar je test izbral zatem. Zapišite opaženi izhod ob vsak rezultat in zmeda večinoma izgine.

Počasen začetek se konča šele po koncu večine kratkih testov

Povezava TCP se ne začne s hitrostjo povezave. Začne se z majhnim oknom zastoja, približno vsak krog ga podvoji in zmogljivost poti doseže šele po nekaj krogih. Desetsekundni test na poti z visoko zakasnitvijo lahko preživi precejšen del svojega življenja v tem vzponu.

Zato tunel z večjo zakasnitvijo v kratkem testu doseže slabši rezultat, kot si zasluži, in zato daljši zagon pogosto poroča višje število brez kakršne koli spremembe konfiguracije. Okvir prepustnosti RFC 6349 to obravnava izrecno, zato resni meritvi trajajo dovolj dolgo, da dosežejo ustaljeno stanje. Petsekundni zagon na satelitski poti meri pospeševalnik, ne ceste.

Poglejte faze povezave, namesto da zaupate eni številki. Curl poroča o vsaki fazi ločeno, tako da vidite, ali čas gre v rokovanje, v vzpon ali v prenos:

curl -sS -o /dev/null -w 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} total=%{time_total} bytes/s=%{speed_download}\n' \
  https://mirror.example.net/testfile.bin

Zaženite ga dvakrat zapored na isti cilj. Če je drugi zagon veliko hitrejši, ste merili vzpon, ne poti, in vsaka primerjava, ki je uporabila le prvega, je sumljiva.

En tok in šest tokov merijo različne stvari

En sam tok TCP omejuje okno, ki ga lahko drži v zraku, to pa je približno čas kroga, pomnožen s hitrostjo. Na dolgi poti ta zmnožek preseže, kar bo uporabil en tok, zato en prenos podceni obstoječo zmogljivost. Šest vzporednih tokov zapolni vrzel in da večje število.

iperf3 -c speed.example.net -t 20
iperf3 -c speed.example.net -t 20 -P 6
mtr -rwc 50 speed.example.net

Obe številki sta resnični. Število enega toka pove, kaj bo naredil en prenos, kar običajno dobi zavihek brskalnika. Vzporedno število pove, kaj lahko pot nosi skupaj, kar lahko izkoristi torrent ali prenos v delih. Citirati eno, kot da je drugo, je način, kako se zdrav tunel zamenja brez razloga.

Primerjanje vzporednega rezultata z rezultatom enega toka je najpogostejši način, kako ljudje sklenejo, da jim je VPN prepolovil hitrost. Izenačite metodo, nato primerjajte. Sled v tretjem ukazu doda manjkajoči kontekst: pot z velikim jitterjem bo v obeh načinih dajala nedosledne rezultate in nobeno število tokov tega ne popravi.

Šifriranje stane procesorski čas, enkapsulacija stane bajte

Na vsakem paketu delujeta dva mehanizma ne glede na to, kako hitra je povezava. Šifriranje porabi procesor na bajt, enkapsulacija pa doda bajte glave, ki jih povezava vseeno mora nositi. Oba se pokažeta kot zgornja meja in imata različne simptome.

Zgornja meja procesorja se pokaže kot planota: prepustnost neha naraščati, kolikor tokov koli dodate, procesor stroja pa je zaseden, medtem ko povezava ni. Na majhnem usmerjevalniku ali telefonu je to pogosto resnična meja, zato lahko hitra linija še vedno da skromen tunel.

Strošek v bajtih je manjši, a stalen. Dodatne glave pomenijo manj koristnega tovora na paket, na poti s fiksno največjo prenosno enoto pa lahko sprožijo tudi razdrobljenost ali črno luknjo, ki se pokaže kot zastoj pri velikih prenosih, ne kot počasno povprečje.

Ti trije se pogosto mešajo, ker uporabniki vse opisujejo kot počasen VPN. Samo prvi se odziva na večji stroj, samo drugi na manjši MTU in samo tretji na upravljanje čakalnih vrst.

Zapišite metodo v zapis

Rezultat, ki ga je vredno ohraniti, navede napravo, dostopovno omrežje, izhod, merilni strežnik, smer, število tokov in trajanje. Brez tega dveh števil ni mogoče primerjati, vstopnica z eno številko pa je v resnici razpoloženje.

Ohranite tudi slabe zagone. Serija, v kateri en izhod vsakič povzroči zastoj, je veliko bolj informativna od povprečja, zastoji pa so natanko tisto, kar povprečja skrijejo.

Nato preizkusite tisto, kar vam je res pomembno. Če je cilj velik prenos, prenesite datoteko. Če je cilj klic, merite zakasnitev pod obremenitvijo, ne prepustnosti v mirovanju, ker je lahko tunel v testu hitrosti dober in vseeno naredi vsak sestanek neslišen.