Prečo sa dva testy rýchlosti VPN v tom istom tuneli nezhodujú
Nový výstup mení testovací server a pomalý štart mení skóre. Zafixujte cieľ, vyrovnajte počet tokov a oddeľte náklady procesora od kapacity spoja.
Dva behy, jeden tunel a čísla sa líšia trojnásobne. Tunel sa medzi nimi nezmenil. Zmenilo sa meranie: testovacia stránka, ktorá vyberá server podľa vašej zdanlivej polohy, počet tokov, ktorý rozhoduje, či potrubie plní jeden pomalý štart alebo šesť, a trvanie také krátke, že sa skončí skôr, než sa cesta vôbec začne správne používať. Testy rýchlosti nie sú nesprávne, ale odpovedajú na užšiu otázku, než akú im ľudia kladú.
Nová adresa výstupu mení cieľ testu
Väčšina testovacích stránok vyberá merací server automaticky a vyberá ho čiastočne podľa toho, odkiaľ vaše pripojenie vyzerá, že prichádza. Zapnite tunel a vaša zdanlivá krajina sa zmení, takže sa zmení zvolený server a porovnanie teraz zahŕňa dve rôzne trasy k dvom rôznym hostiteľom.
Výsledok rozhodne nie je meranie VPN. Je to meranie vašej cesty k serveru, ktorý ste si nevybrali, a rozdielu medzi oboma behmi môže dominovať peering tohto servera, nie to, čo urobil tunel.
Zafixujte cieľ skôr, než zmeníte čokoľvek iné. Každý dôveryhodný nástroj vám umožní vybrať server výslovne, a keď nie, stránka s výsledkami zvyčajne uvedie použitý, čo stačí na to, aby ste si všimli, že oba behy nie sú porovnateľné. Overte, čo stránka videla, než jej výberu uveríte:
curl -sS https://ipinfo.io/json | grep -E '"ip"|"org"|"country"'
Ak sa krajina medzi behmi zmenila, zmenilo sa aj všetko, čo test potom zvolil. Zapíšte pozorovaný výstup vedľa každého výsledku a zmätok väčšinou zmizne.
Pomalý štart končí až po konci väčšiny krátkych testov
TCP spojenie nezačína na rýchlosti spoja. Začína s malým oknom zahltenia, približne každý kruh ho zdvojnásobí a kapacitu cesty dosiahne až po niekoľkých kruhoch. Desaťsekundový test na ceste s vysokou latenciou môže stráviť značnú časť života v tom rozbehu.
Preto tunel s vyššou latenciou dopadne v krátkom teste horšie, než si zaslúži, a preto dlhší beh často hlási vyššie číslo bez akejkoľvek zmeny konfigurácie. Rámec priepustnosti RFC 6349 to rieši výslovne, a preto seriózne merania trvajú dosť dlho, aby dosiahli ustálený stav. Päťsekundový beh na satelitnej ceste meria akcelerátor, nie cestu.
Sledujte fázy spojenia, namiesto toho, aby ste verili jedinému číslu. Curl hlási každú fázu zvlášť, takže vidíte, či čas ide do handshake, do rozbehu alebo do prenosu:
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
Spustite ho dvakrát za sebou na ten istý cieľ. Ak je druhý beh oveľa rýchlejší, merali ste rozbeh, nie cestu, a každé porovnanie, ktoré použilo len prvý beh, je podozrivé.
Jeden tok a šesť tokov merajú rôzne veci
Jeden TCP tok je obmedzený oknom, ktoré udrží v lete, čo je približne čas kruhu vynásobený rýchlosťou. Na dlhej ceste tento súčin prevyšuje to, čo jeden tok využije, takže jedno sťahovanie podhodnocuje existujúcu kapacitu. Šesť paralelných tokov medzeru vyplní a dá väčšie číslo.
iperf3 -c speed.example.net -t 20
iperf3 -c speed.example.net -t 20 -P 6
mtr -rwc 50 speed.example.net
Obe čísla sú pravdivé. Číslo jedného toku hovorí, čo urobí jedno sťahovanie, čo zvyčajne dostane karta prehliadača. Paralelné číslo hovorí, čo cesta unesie celkovo, čo môže využiť torrent alebo sťahovanie po častiach. Citovať jedno, akoby bolo tým druhým, je spôsob, akým sa zdravý tunel vymení bez dôvodu.
Porovnanie paralelného výsledku s výsledkom jedného toku je najčastejší spôsob, akým ľudia dospejú k záveru, že im VPN znížil rýchlosť na polovicu. Vyrovnajte metódu a potom porovnávajte. Stopa v treťom príkaze dodáva chýbajúci kontext: cesta s veľkým jitterom bude dávať nekonzistentné výsledky v oboch režimoch a žiadny počet tokov to nespraví.
Šifrovanie stojí čas procesora, zapuzdrenie stojí bajty
Na každom pakete pracujú dva mechanizmy bez ohľadu na rýchlosť spoja. Šifrovanie spotrebúva procesor na bajt a zapuzdrenie pridáva bajty hlavičky, ktoré spoj aj tak musí preniesť. Obe sa prejavia ako strop a majú rôzne príznaky.
Strop procesora vyzerá ako plošina: priepustnosť prestane rásť, akokoľvek veľa tokov pridáte, a procesor stroja je zaneprázdnený, kým spoj nie. Na malom routeri alebo telefóne je to často skutočný limit, a preto rýchla linka môže stále dať skromný tunel.
Náklad v bajtoch je menší, ale stály. Hlavičky navyše znamenajú menej užitočného nákladu na paket a na ceste s pevnou maximálnou prenosovou jednotkou môžu tiež vyvolať fragmentáciu alebo čiernu dieru, ktorá sa prejaví ako zaseknutie pri veľkých prenosoch, nie ako pomalý priemer.
| Observation | Likely mechanism | What to measure |
|---|---|---|
| Throughput flat as streams increase | CPU per packet on one core | Per-core utilisation during the test |
| Fast small transfers, stalled large ones | MTU and fragmentation | Payload size at which it breaks |
| Good average, unusable calls | Queueing delay behind a full buffer | Latency under load |
Tieto tri sa často pletú, pretože používatelia ich všetky opisujú ako pomalý VPN. Iba prvý reaguje na väčší stroj, iba druhý reaguje na menšie MTU a iba tretí reaguje na správu frontov.
Zapíšte metódu do záznamu
Výsledok, ktorý stojí za uchovanie, uvádza zariadenie, prístupovú sieť, výstup, merací server, smer, počet tokov a trvanie. Bez toho sa dve čísla nedajú porovnať a tiket s jediným číslom je vlastne nálada.
Uchovávajte aj zlé behy. Séria, kde jeden výstup zakaždým vyvolá zaseknutie, je oveľa informatívnejšia než priemer, a zaseknutia sú presne to, čo priemery skrývajú.
Potom testujte to, na čom vám naozaj záleží. Ak je cieľom veľké sťahovanie, stiahnite súbor. Ak je cieľom hovor, merajte latenciu pod záťažou, nie nečinnú priepustnosť, pretože tunel môže v teste rýchlosti skórovať dobre a napriek tomu urobiť každé stretnutie nepočúvateľným.