Hvers vegna tvö VPN-hraðapróf á sama göngunni stemma ekki

Tvær keyrslur, ein göng, og tölurnar eru þrefalt frábrugðnar. Göngin breyttust ekki á milli þeirra. Það sem breyttist er mælingin: prófunarsíða sem velur þjón út frá sýnilegri staðsetningu þinni, fjöldi strauma sem ræður því hvort ein hæg byrjun eða sex fylli rörin, og tímalengd sem er nógu stutt til að enda áður en farvegurinn er rétt notaður. Hraðapróf eru ekki röng, en þau svara þrengri spurningu en sú sem fólk leggur fyrir þau.

Ný útgönguleið breytir prófunaráfangastaðnum

Flestar prófunarsíður velja mæliþjón sjálfkrafa, og þær velja hann að hluta með því að skoða hvaðan tengingin þín virðist koma. Kveiktu á göngunum og sýnilegt land þitt breytist, svo valinn þjónn breytist, og samanburðurinn nær nú yfir tvær ólíkar leiðir að tveimur ólíkum hýslum.

Niðurstaðan er alls ekki VPN-mæling. Hún er mæling á leið þinni að þjóni sem þú valdir ekki, og munurinn á milli keyrslnanna getur ráðist af peering þess þjóns frekar en nokkru sem göngin gerðu.

Festu áfangastaðinn áður en þú breytir einhverju öðru. Hvert trúverðugt tól leyfir þér að velja þjón skýrt, og þegar það gerir það ekki nefnir niðurstöðusíðan yfirleitt þann sem var notaður, sem er nóg til að taka eftir að keyrslurnar tvær eru ekki samanburðarhæfar. Staðfestu hvað síðan sá áður en þú treystir vali hennar:

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

Ef landið breyttist á milli keyrslna breyttist líka allt sem prófið valdi eftir það. Skrifaðu séðu útgönguna við hverja niðurstöðu og ruglingurinn hverfur að mestu.

Hæg byrjun lýkur eftir að flest stutt próf eru búin

TCP-tenging byrjar ekki á hraða tengingarinnar. Hún byrjar með litlum þrengingarglugga, tvöfaldar hann um það bil á hverri ferð fram og til baka, og nær aðeins getu farvegsins eftir nokkrar ferðir. Tíu sekúndna próf á farveg með háum biðtíma getur eytt verulegum hluta ævi sinnar í þeirri hækkun.

Þess vegna skorar göng með meiri biðtíma verr í stuttu prófi en þau eiga skilið, og þess vegna tilkynnir lengri keyrsla oft hærri tölu án nokkurrar stillingabreytingar. RFC 6349 afkastarammi fjallar um þetta skýrt, og þess vegna standa alvarlegar mælingar nógu lengi til að ná stöðugu ástandi. Fimm sekúndna keyrsla á gervihnattarleið mælir hraðarann, ekki veginn.

Skoðaðu fasa tengingarinnar í stað þess að treysta einni tölu. Curl tilkynnir hvert stig sérstaklega, svo þú sérð hvort tíminn fer í handabandið, hækkunina eða flutninginn:

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

Keyrðu það tvisvar í röð á sama áfangastað. Ef seinni keyrslan er miklu hraðari varstu að mæla hækkunina, ekki farveginn, og allur samanburður sem notaði aðeins fyrstu keyrsluna er grunsamlegur.

Einn straumur og sex straumar mæla ólíka hluti

Einn TCP-straumur takmarkast af glugganum sem hann getur haldið á lofti, sem er um það bil ferðatíminn sinnum hraðinn. Á langri leið fer sú margfeldi yfir það sem einn straumur mun nota, svo ein niðurhal dregur úr getunni sem er til staðar. Sex samhliða straumar fylla skarðið og gefa hærri tölu.

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

Báðar tölurnar eru sannar. Tala eins straums segir hvað eitt niðurhal gerir, sem vafraflipi fær venjulega. Samhliða talan segir hvað leiðin getur borið samtals, sem torrent eða niðurhal í hlutum getur nýtt. Að vitna í aðra eins og hún væri hin er leiðin sem heilbrigð göng eru skipt út án ástæðu.

Að bera saman samhliða niðurstöðu við niðurstöðu eins straums er algengasta leiðin sem fólk kemst að þeirri niðurstöðu að VPN hafi helmingað hraðann hjá sér. Jafnaðu aðferðina og berðu svo saman. Slóðin í þriðju skipuninni bætir við samhenginu sem vantar: leið með miklum jitter gefur ósamkvæmar niðurstöður í báðum stillingum, og enginn straumafjöldi lagar það.

Dulkóðun kostar örgjörvatíma, umgjör kostar bæti

Tvær aðferðir vinna á hverri pakkningu sama hversu hröð tengingin er. Dulkóðun eyðir örgjörva á hvert bæti, og umgjör bætir við hausbætum sem tengingin verður samt að bera. Bæði birtast sem þak, og einkenni þeirra eru ólík.

Örgjörvaþakið birtist sem háslétta: afköst hætta að hækka sama hversu mörgum straumum þú bætir við, og örgjörvi vélarinnar er upptekinn á meðan tengingin er það ekki. Á litlum beini eða síma er það oft raunverulegu takmörkin, og þess vegna getur hröð lína samt veitt hóflegt göng.

Bætakostnaðurinn er minni en stöðugur. Aukahausar þýða minni gagnlega byrði á pakkningu, og á leið með föstu hámarksflutningsstaðli geta þeir einnig valdið sundrungu eða svartholi sem birtist sem stöðvun á stórum flutningum frekar en sem hægum meðaltali.

Þessi þrjú ruglast oft því notendur lýsa þeim öllum sem því að VPN-ið sé hægt. Aðeins hið fyrsta bregst við stærri vél, aðeins annað við minni MTU, og aðeins þriðja við stýringu biðraða.

Settu aðferðina í færsluna

Niðurstaða sem er þess virði að varðveita nefnir tækið, aðgangsnetið, útgönguna, mæliþjóninn, stefnuna, fjölda strauma og tímalengdina. Án þeirra er ekki hægt að bera tvær tölur saman, og miði sem inniheldur eina tölu er í raun skap.

Geymdu líka slæmu keyrslurnar. Röð þar sem ein útganga veldur stöðvun í hvert sinn er miklu upplýsandi en meðaltal, og stöðvanirnar eru einmitt það sem meðaltöl fela.

Prófaðu svo það sem þér er raunverulega annt um. Ef markmiðið er stórt niðurhal skaltu sækja skrána. Ef markmiðið er símtal skaltu mæla biðtíma undir álagi frekar en afköst í hvíld, því göng geta skorað vel í hraðaprófi og samt gert hvern fund óheyrnilegan.