Kāpēc divi VPN ātruma testi vienā tunelī nesakrīt

Divi palaidieni, viens tunelis, un skaitļi atšķiras trīs reizes. Tunelis starp tiem nemainījās. Mainījās mērījums: testa vietne, kas izvēlas serveri pēc jūsu šķietamās atrašanās vietas, plūsmu skaits, kas nosaka, vai cauruli piepilda viens lēns starts vai seši, un tik īsa ilgstība, ka tā beidzas, pirms maršruts vispār tiek pareizi izmantots. Ātruma testi nav nepareizi, bet tie atbild uz šaurāku jautājumu nekā to, ko cilvēki tiem uzdod.

Jauna izejas adrese maina testa galamērķi

Lielākā daļa testa vietņu mērījumu serveri izvēlas automātiski, un izvēlas to daļēji, skatoties, no kurienes šķietami nāk jūsu savienojums. Ieslēdziet tuneli, un jūsu šķietamā valsts mainās, tāpēc izvēlētais serveris mainās, un salīdzinājums tagad aptver divus dažādus maršrutus uz diviem dažādiem resursdatoriem.

Rezultāts nemaz nav VPN mērījums. Tas ir jūsu maršruta līdz serverim, kuru neizvēlējāties, mērījums, un atšķirību starp diviem palaidieniem var noteikt šī servera peering, nevis kaut kas, ko izdarīja tunelis.

Fiksējiet galamērķi, pirms maināt ko citu. Katrs uzticamais rīks ļauj skaidri izvēlēties serveri, un, kad tas to nedara, rezultātu lapa parasti nosauc izmantoto, ar ko pietiek, lai pamanītu, ka divi palaidieni nav salīdzināmi. Apstipriniet, ko vietne redzēja, pirms uzticaties tās izvēlei:

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

Ja valsts starp palaidieniem mainījās, mainījās arī viss, ko tests pēc tam izvēlējās. Pierakstiet novēroto izeju pie katra rezultāta, un apjukums lielākoties pazūd.

Lēns starts beidzas pēc tam, kad beigušies lielākā daļa īso testu

TCP savienojums nesākas ar saites ātrumu. Tas sākas ar mazu pārslodzes logu, aptuveni katrā turp-atpakaļ braucienā to dubulto, un maršruta kapacitāti sasniedz tikai pēc vairākiem braucieniem. Desmit sekunžu tests maršrutā ar augstu latentumu var pavadīt ievērojamu daļu savas dzīves šajā kāpumā.

Tāpēc tunelis ar lielāku latentumu īsā testā izskatās sliktāk, nekā pelnījis, un tāpēc garāks palaidienis bieži ziņo lielāku skaitli bez jebkādām konfigurācijas izmaiņām. RFC 6349 caurlaidspējas ietvars to aplūko tieši, un tāpēc nopietni mērījumi ilgst pietiekami ilgi, lai sasniegtu vienmērīgu stāvokli. Piecu sekunžu palaidienis satelīta maršrutā mēra paātrinātāju, nevis ceļu.

Skatiet saites fāzes, nevis uzticieties vienam skaitlim. Curl ziņo par katru posmu atsevišķi, tāpēc redzat, vai laiks aiziet rokasspiedienā, kāpumā vai pārsūtīšanā:

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

Palaidiet to divas reizes pēc kārtas uz to pašu galamērķi. Ja otrais palaidienis ir daudz ātrāks, jūs mērījāt kāpumu, nevis maršrutu, un jebkurš salīdzinājums, kas izmantoja tikai pirmo, ir aizdomīgs.

Viena plūsma un sešas plūsmas mēra dažādas lietas

Vienu TCP plūsmu ierobežo logs, ko tā var noturēt lidojumā, un tas ir aptuveni turp-atpakaļ laiks, reizināts ar ātrumu. Garā maršrutā šis reizinājums pārsniedz to, ko izmantos viena plūsma, tāpēc viena lejupielāde novērtē esošo kapacitāti par zemu. Sešas paralēlas plūsmas aizpilda starpību un dod lielāku skaitli.

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

Abi skaitļi ir patiesi. Vienas plūsmas skaitlis pasaka, ko darīs viena lejupielāde, ko parasti iegūst pārlūka cilne. Paralēlais skaitlis pasaka, ko maršruts var nest kopumā, ko var izmantot torrents vai daļēja lejupielāde. Citēt vienu tā, it kā tas būtu otrs, ir veids, kā veselu tuneli bez iemesla nomaina.

Paralēla rezultāta salīdzināšana ar vienas plūsmas rezultātu ir visizplatītākais veids, kā cilvēki nonāk pie secinājuma, ka VPN ir uz pusi samazinājis viņu ātrumu. Saskaņojiet metodi, tad salīdziniet. Trešās komandas pēda pievieno trūkstošo kontekstu: maršruts ar lielu džiteri abos režīmos dos nekonsekventus rezultātus, un neviens plūsmu skaits to nelabo.

Šifrēšana maksā procesora laiku, iekapsulēšana maksā baitus

Divi mehānismi darbojas uz katras paketes neatkarīgi no tā, cik ātra ir saite. Šifrēšana patērē procesoru uz baitu, un iekapsulēšana pievieno galvenes baitus, kas saitei tomēr jāpārnēsā. Abi parādās kā griesti, un to simptomi atšķiras.

Procesora griesti parādās kā plato: caurlaidspēja pārstāj augt, lai cik plūsmu pievienotu, un iekārtas procesors ir aizņemts, kamēr saite nav. Mazā maršrutētājā vai telefonā tas bieži ir īstā robeža, un tāpēc ātra līnija joprojām var dot pieticīgu tuneli.

Baitu izmaksas ir mazākas, bet pastāvīgas. Papildu galvenes nozīmē mazāk lietderīgās kravas uz paketi, un maršrutā ar fiksētu maksimālo pārraides vienību tās var izraisīt arī sadalīšanu vai melno caurumu, kas lielos pārraides gadījumos parādās kā iesprūšana, nevis kā lēns vidējais.

Šos trīs bieži jauc, jo lietotāji tos visus apraksta kā to, ka VPN ir lēns. Tikai pirmais reaģē uz lielāku iekārtu, tikai otrais uz mazāku MTU, un tikai trešais uz rindu pārvaldību.

Ierakstiet metodi protokolā

Rezultāts, ko vērts saglabāt, nosauc ierīci, piekļuves tīklu, izeju, mērījumu serveri, virzienu, plūsmu skaitu un ilgumu. Bez tiem divus skaitļus nevar salīdzināt, un biļete ar vienu skaitli patiesībā ir noskaņojums.

Saglabājiet arī sliktos palaidienus. Sērija, kurā viena izeja katru reizi rada iesprūšanu, ir daudz informatīvāka par vidējo, un iesprūšanas ir tieši tas, ko vidējie slēpj.

Pēc tam pārbaudiet to, kas jums patiešām svarīgi. Ja mērķis ir liela lejupielāde, lejupielādējiet failu. Ja mērķis ir zvans, mēriet latentumu zem slodzes, nevis caurlaidspēju dīkstāvē, jo tunelis var labi nopelnīt ātruma testā un tomēr padarīt katru sapulci nedzirdamu.