Wêrom twa VPN-snelheidstests op deselde tunnel ferskille

Twa rinnen, ien tunnel, en de sifers ferskille in faktor trije. De tunnel feroare net tusken har. Wat feroare is de mjitting: in testsite dy't in server kiest op basis fan jo skynbere lokaasje, in oantal streams dat beslút oft ien stadige start of seis de piip follet, en in doer dy't koart genôch is om te einigjen foardat it paad goed brûkt wurdt. Snelheidstests binne net ferkeard, mar se beantwurdzje in nauwere fraach as dy't minsken har stelle.

In nij útgongadres feroaret de testbestimming

De measte testsites kieze automatysk in mjitserver, en se kieze him foar in part troch te sjen wêr't jo ferbining wei liket te kommen. Sette de tunnel oan en jo skynbere lân feroaret, dus de keazen server feroaret, en de ferliking omfettet no twa ferskillende rûtes nei twa ferskillende hosts.

It resultaat is hielendal gjin VPN-mjitting. It is in mjitting fan jo paad nei in server dy't jo net keazen hawwe, en it ferskil tusken de twa rinnen kin behearske wurde troch it peering fan dy server ynstee fan troch wat de tunnel die.

Fêstigje de bestimming foardat jo eat oars feroarje. Elk betrouber helpmiddel lit jo in server eksplisyt kieze, en wannear't it dat net docht, neamt de resultaat side meastentiids de brûkte, wat genôch is om te merken dat de twa rinnen net ferlykber binne. Befêstigje wat de side seach foardat jo syn kar fertrouwe:

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

As it lân tusken de rinnen feroare, feroare alles wat de test dêrnei keas ek. Skriuw de waarnommen útgong njonken elk resultaat en de betizing ferdwynt foar it grutste part.

Stadige start einiget nei't de measte koarte tests dien binne

In TCP-ferbining begjint net op 'e snelheid fan 'e ferbining. It begjint mei in lyts oerbelestingsfinster, ferdûbelet dat sa'n by elke rûnreis, en berikt pas nei ferskate rûnreizen de kapasiteit fan it paad. In test fan tsien sekonden op in paad mei hege latinsje kin in flink part fan syn libben yn dy klim trochbringe.

Dêrom skoart in tunnel mei hegere latinsje yn in koarte test minner as er fertsjinnet, en dêrom rapportearret in langere rin faak in heger sifer sûnder inkele konfiguraasjefoarining. It RFC 6349-trochfiertrochset behannelet dit eksplisyt, en dêrom rinne serieuze mjittingen lang genôch om in stabile tastân te berikken. In rin fan fiif sekonden op in satellytpaad mjit de fersneller, net de wei.

Sjoch nei de fazen fan 'e ferbining ynstee fan ien sifer te fertrouwen. Curl rapportearret elke faze apart, sadat jo sjen kinne oft tiid yn 'e hânskodding, de klim of de oerdracht giet:

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

Rin it twa kear efterinoar nei deselde bestimming. As de twadde rin folle flugger is, metten jo de klim, net it paad, en elke ferliking dy't allinnich de earste rin brûkte is fertocht.

Ien stream en seis streams mjitte ferskillende dingen

In inkele TCP-stream wurdt beheind troch it finster dat er yn 'e loft hâlde kin, dat sawat de rûnreistiid fermannichfâldige mei de snelheid is. Op in lang paad oertreft dat produkt wat ien stream brûke sil, dat ien download ûnderrapportearret de kapasiteit dy't bestiet. Seis parallelle streams folje de gat en jouwe in grutter sifer.

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

Beide sifers binne wier. It sifer fan ien stream fertelt wat ien download docht, wat in browser-tab meastentiids krijt. It parallelle sifer fertelt wat it paad yn totaal drage kin, wat in torrent of in download yn dielen brûke kin. Ien sitearje as wie it de oare is hoe't in sûne tunnel sûnder reden ferfongen wurdt.

In parallel resultaat ferlykje mei in resultaat fan ien stream is de meast foarkommende manier wêrop minsken konkludearje dat in VPN har snelheid halvearre hat. Lykje de metoade, fergelykje dan. It spoar yn it tredde kommando foeget de ûntbrekkende kontekst ta: in paad mei hege jitter sil yn beide modi ynkonsistinte resultaten jouwe, en gjin oantal streams reparearret dat.

Fersifering kostet prosessortiid, ynkapseling kostet bytes

Twa meganismen rinne op elk pakket, hoe fluch de ferbining ek is. Fersifering brûkt prosessor per byte, en ynkapseling foeget header-bytes ta dy't de ferbining noch altyd drage moat. Beide wurde sjoen as in plafond, en se hawwe ferskillende symptomen.

It prosessorplafond ferskynt as in plato: trochfier hâldt op te stiigjen, hoefolle streams jo ek tafoegje, en de prosessor fan 'e masine is dwaande wylst de ferbining dat net is. Op in lytse router of in telefoan is dat faak de echte grins, en dêrom kin in flugge line noch in beskieden tunnel leverje.

De byte-kosten binne lytser mar konstant. Ekstra headers betsjutte minder nuttige lading per pakket, en op in paad mei in fêste maksimale oerdrachtienheid kinne se ek fragmintaasje of in swart gat feroarsaakje dat him sjen lit as in stop by grutte oerdrachten ynstee fan as in stadich gemiddelde.

Dizze trije wurde faak ferwiksele, om't brûkers se allegear beskriuwe as «de VPN is stadich». Allinnich de earste reagearret op in gruttere masine, allinnich de twadde reagearret op in lytsere MTU, en allinnich de tredde reagearret op wachtrigerbehear.

Set de metoade yn it record

In resultaat dat wurdich is te bewarjen neamt it apparaat, it tagongsnettwurk, de útgong, de mjitserver, de rjochting, it oantal streams en de doer. Sûnder dy kinne twa sifers net ferlike wurde, en in ticket mei ien sifer is eins in stimming.

Bewarje ek de minne rinnen. In searje wêrby't ien útgong elke kear in stop feroarsaket is folle ynformativear as in gemiddelde, en de stoppen binne krekt wat gemiddelden ferbergje.

Test dan it ding dêr't jo jo wier om jouwe. As in grutte download it doel is, download it bestân. As in oprop it doel is, mjit latinsje ûnder belesting ynstee fan trochfier by stilte, want in tunnel kin goed skoare yn in snelheidstest en dochs elk oerlis ûnheartber meitsje.