Miért nem egyezik két VPN-sebességteszt ugyanazon az alagúton

Két futás, egy alagút, és a számok háromszoros eltérést mutatnak. Az alagút nem változott köztük. Ami változott, az a mérés: egy tesztoldal, amely a látszólagos tartózkodási helye alapján választ szervert, a folyamok száma, amely eldönti, hogy egy lassú indulás vagy hat tölti-e a csövet, és egy olyan rövid időtartam, hogy az útvonal rendes használata előtt véget ér. A sebességtesztek nem tévesek, de szűkebb kérdésre válaszolnak, mint amit az emberek feltesznek nekik.

Az új kilépési cím megváltoztatja a teszt célját

A legtöbb tesztoldal automatikusan választ mérőszervert, és részben abból választja ki, hogy honnan tűnik jönni a kapcsolata. Kapcsolja be az alagutat, és a látszólagos országa megváltozik, így a kiválasztott szerver megváltozik, és az összehasonlítás most két különböző útvonalat ölel fel két különböző gazdagéphez.

Az eredmény egyáltalán nem VPN-mérés. Ez az ön útjának mérése egy olyan szerverhez, amelyet nem ön választott, és a két futás közötti különbséget az adott szerver peeringje uralhatja, nem az, amit az alagút tett.

Rögzítse a célt, mielőtt bármi mást megváltoztatna. Minden hiteles eszköz lehetővé teszi a szerver kifejezett kiválasztását, és amikor nem, az eredményoldal általában megnevezi a használtat, ami elég ahhoz, hogy észrevegye: a két futás nem összehasonlítható. Erősítse meg, mit látott az oldal, mielőtt megbízik a választásában:

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

Ha az ország megváltozott a futások között, minden is megváltozott, amit a teszt utána választott. Írja fel a megfigyelt kilépést minden eredmény mellé, és a zavar nagyrészt eltűnik.

A lassú indulás a legtöbb rövid teszt vége után fejeződik be

A TCP-kapcsolat nem a kapcsolat sebességével indul. Egy kis torlódási ablakkal kezd, nagyjából minden oda-vissza útra megduplázza, és csak több oda-vissza út után éri el az útvonal kapacitását. Egy tíz másodperces teszt nagy késleltetésű útvonalon élete jelentős részét töltheti ebben a felfutásban.

Ezért teljesít rosszabbul egy nagyobb késleltetésű alagút egy rövid teszten, mint amennyit érdemel, és ezért jelent gyakrabban nagyobb számot egy hosszabb futás minden konfigurációváltoztatás nélkül. A RFC 6349 átbocsátási keretrendszer ezt kifejezetten kezeli, és ezért tartanak a komoly mérések elég sokáig az állandósult állapot eléréséhez. Egy öt másodperces futás műholdas útvonalon a gyorsítót méri, nem az utat.

Nézze meg a kapcsolat fázisait, ahelyett hogy egyetlen számnak hinne. A Curl minden szakaszt külön jelent, így láthatja, hogy az idő a kézfogásba, a felfutásba vagy az átvitelbe megy-e:

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

Futtassa kétszer egymás után ugyanarra a célra. Ha a második futás sokkal gyorsabb, a felfutást mérte, nem az útvonalat, és minden összehasonlítás gyanús, amely csak az első futást használta.

Egy folyam és hat folyam különböző dolgokat mér

Egyetlen TCP-folyamot az az ablak korlátoz, amelyet repülésben tarthat, ez pedig nagyjából az oda-vissza idő szorozva a sebességgel. Hosszú útvonalon ez a szorzat meghaladja azt, amit egy folyam használni fog, ezért egyetlen letöltés alábecsüli a meglévő kapacitást. Hat párhuzamos folyam kitölti a rést, és nagyobb számot ad.

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

Mindkét szám igaz. Az egyfolyamos szám megmondja, mit tesz egyetlen letöltés, amit egy böngészőfül általában megkap. A párhuzamos szám megmondja, mit tud összesen szállítani az útvonal, amit egy torrent vagy egy többrészes letöltés kihasználhat. Az egyiket a másikként idézni az az út, amelyen egy egészséges alagutat ok nélkül kicserélnek.

A párhuzamos eredmény összehasonlítása az egyfolyamos eredménnyel a leggyakoribb módja annak, hogy az emberek arra jutnak: a VPN megfelezte a sebességüket. Egyeztesse a módszert, aztán hasonlítson. A harmadik parancs nyomvonala hozzáadja a hiányzó kontextust: a nagy jitterű útvonal mindkét módban következetlen eredményeket ad, és semmilyen folyamszám nem javítja ezt.

A titkosítás processzoridőbe, a beágyazás bájtokba kerül

Minden csomagon két mechanizmus fut, függetlenül attól, milyen gyors a kapcsolat. A titkosítás processzort fogyaszt bájtonként, a beágyazás pedig fejlécbájtokat ad hozzá, amelyeket a kapcsolatnak mégis szállítania kell. Mindkettő plafonként jelenik meg, és eltérő tüneteik vannak.

A processzorplafon fennsíkként jelenik meg: az átbocsátás nem nő tovább, akárhány folyamot ad hozzá, és a gép processzora foglalt, miközben a kapcsolat nem. Kis routeren vagy telefonon ez gyakran a valódi korlát, és ezért adhat egy gyors vonal mégis szerény alagutat.

A bájtokban mért költség kisebb, de állandó. A további fejlécek kevesebb hasznos terhet jelentenek csomagonként, és fix maximális átviteli egységű útvonalon töredezést vagy fekete lyukat is kiválthatnak, amely nagy átviteleknél akadásként jelenik meg, nem lassú átlagként.

Ezt a hármat gyakran összekeverik, mert a felhasználók mindegyiket úgy írják le, hogy lassú a VPN. Csak az első reagál nagyobb gépre, csak a második reagál kisebb MTU-ra, és csak a harmadik reagál a sorok kezelésére.

Tegye a módszert a feljegyzésbe

A megőrzésre érdemes eredmény megnevezi az eszközt, a hozzáférési hálózatot, a kilépést, a mérőszervert, az irányt, a folyamok számát és az időtartamot. Ezek nélkül két szám nem hasonlítható össze, és az egyetlen számot tartalmazó jegy valójában egy hangulat.

Tartsa meg a rossz futásokat is. Egy sorozat, amelyben egy kilépés minden alkalommal akadást okoz, sokkal informatívabb egy átlagnál, és az akadások pontosan azok, amiket az átlagok elrejtenek.

Aztán tesztelje azt, ami valóban fontos önnek. Ha a cél egy nagy letöltés, töltse le a fájlt. Ha a cél egy hívás, mérje a késleltetést terhelés alatt, ne az üresjárati átbocsátást, mert egy alagút jól szerepelhet egy sebességteszten, és mégis minden megbeszélést hallgathatatlanná tehet.