Proč se dva testy rychlosti VPN na stejném tunelu rozcházejí

Dva běhy, jeden tunel a čísla se liší trojnásobně. Tunel se mezi nimi nezměnil. Změnilo se měření: testovací web, který vybírá server podle vaší zdánlivé polohy, počet toků, který rozhoduje, zda trubku plní jeden pomalý start, nebo šest, a doba natolik krátká, že skončí dřív, než se cesta vůbec začne správně využívat. Testy rychlosti nejsou špatné, ale odpovídají na užší otázku, než jakou jim lidé kladou.

Nová adresa výstupu mění cíl testu

Většina testovacích webů vybírá měřicí server automaticky a vybírá ho částečně podle toho, odkud vaše připojení vypadá, že přichází. Zapněte tunel a vaše zdánlivá země se změní, takže se změní zvolený server a srovnání teď zahrnuje dvě různé trasy ke dvěma různým hostitelům.

Výsledek rozhodně není měření VPN. Je to měření vaší cesty k serveru, který jste si nevybrali, a rozdílu mezi oběma běhy může dominovat peering onoho serveru, ne to, co udělal tunel.

Zafixujte cíl dřív, než změníte cokoli jiného. Každý důvěryhodný nástroj vám umožní vybrat server výslovně, a když ne, stránka s výsledky obvykle uvede ten použitý, což stačí k tomu, abyste si všimli, že oba běhy nejsou srovnatelné. Ověřte, co web viděl, než jeho volbě uvěříte:

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

Pokud se země mezi běhy změnila, změnilo se i všechno, co test potom zvolil. Zapište pozorovaný výstup vedle každého výsledku a zmatek většinou zmizí.

Pomalý start končí až po konci většiny krátkých testů

TCP spojení nezačíná na rychlosti spoje. Začíná s malým oknem zahlcení, zhruba každý kruh ho zdvojnásobí a kapacity cesty dosáhne až po několika kruzích. Desetisekundový test na cestě s vysokou latencí může značnou část života strávit v tom náběhu.

Proto tunel s vyšší latencí dopadá v krátkém testu hůř, než si zaslouží, a proto delší běh často hlásí vyšší číslo bez jakékoli změny konfigurace. Rámec propustnosti RFC 6349 to řeší výslovně, a proto seriózní měření běží dost dlouho, aby dosáhla ustáleného stavu. Pětisekundový běh na satelitní cestě měří akcelerátor, ne silnici.

Sledujte fáze spojení, místo abyste věřili jedinému číslu. Curl hlásí každou fázi zvlášť, takže vidíte, zda čas jde do handshaku, do náběhu, nebo do přenosu:

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

Spusťte ho dvakrát za sebou na stejný cíl. Pokud je druhý běh mnohem rychlejší, měřili jste náběh, ne cestu, a každé srovnání, které použilo jen první běh, je podezřelé.

Jeden tok a šest toků měří různé věci

Jeden TCP tok je omezen oknem, které udrží v letu, což je zhruba doba kruhu vynásobená rychlostí. Na dlouhé cestě tento součin převyšuje to, co jeden tok využije, takže jedno stahování podhodnocuje existující kapacitu. Šest paralelních toků mezeru vyplní a dá větší číslo.

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

Obě čísla jsou pravdivá. Číslo jednoho toku říká, co udělá jedno stahování, což je obvykle to, co dostane karta prohlížeče. Paralelní číslo říká, co cesta unese celkově, což může využít torrent nebo stahování po částech. Citovat jedno, jako by bylo tím druhým, je způsob, jak se zdravý tunel vymění bez důvodu.

Srovnání paralelního výsledku s výsledkem jednoho toku je nejčastější způsob, jak lidé dojdou k závěru, že jim VPN snížila rychlost na polovinu. Srovnejte metodu a pak porovnávejte. Stopa ve třetím příkazu dodává chybějící kontext: cesta s velkým jitterem bude dávat nekonzistentní výsledky v obou režimech a žádný počet toků to nespraví.

Šifrování stojí čas procesoru, zapouzdření stojí bajty

Na každém paketu pracují dva mechanismy bez ohledu na rychlost spoje. Šifrování spotřebovává procesor na bajt a zapouzdření přidává bajty hlavičky, které spoj stejně musí přenést. Oba se projeví jako strop a mají různé příznaky.

Strop procesoru vypadá jako plošina: propustnost přestane růst, ať přidáte jakýkoli počet toků, a procesor stroje je zaneprázdněný, zatímco spoj ne. Na malém routeru nebo telefonu je to často skutečný limit, a proto rychlá linka může stále dát skromný tunel.

Náklad v bajtech je menší, ale stálý. Hlavičky navíc znamenají méně užitečného nákladu na paket a na cestě s pevnou maximální přenosovou jednotkou mohou také vyvolat fragmentaci nebo černou díru, která se projeví jako zaseknutí u velkých přenosů, ne jako pomalý průměr.

Tyto tři se často pletou, protože je uživatelé popisují všechny jako „VPN je pomalá“. Jen první reaguje na větší stroj, jen druhý reaguje na menší MTU a jen třetí reaguje na správu front.

Zapište metodu do záznamu

Výsledek, který stojí za uchování, uvádí zařízení, přístupovou síť, výstup, měřicí server, směr, počet toků a dobu trvání. Bez toho nelze dvě čísla srovnat a tiket s jediným číslem je vlastně nálada.

Uchovávejte i špatné běhy. Série, kde jeden výstup pokaždé vyvolá zaseknutí, je mnohem informativnější než průměr, a zaseknutí jsou přesně to, co průměry skrývají.

Pak testujte to, na čem vám skutečně záleží. Pokud je cílem velké stahování, stáhněte soubor. Pokud je cílem hovor, měřte latenci pod zátěží, ne nečinnou propustnost, protože tunel může v testu rychlosti skórovat dobře a přesto udělat každou schůzku neposlouchatelnou.