De ce două teste de viteză VPN pe același tunel nu se potrivesc

Două rulări, un singur tunel, iar cifrele diferă de trei ori. Tunelul nu s-a schimbat între ele. Ce s-a schimbat este măsurarea: un site de test care alege un server după locația aparentă, un număr de fluxuri care decide dacă umple conducta o pornire lentă sau șase, și o durată suficient de scurtă încât să se încheie înainte ca ruta să fie folosită corect. Testele de viteză nu sunt greșite, dar ele răspund la o întrebare mai îngustă decât cea pe care le-o pun oamenii.

O adresă de ieșire nouă schimbă destinația testului

Majoritatea site-urilor de test aleg automat un server de măsurare și îl aleg parțial uitându-se de unde pare că vine conexiunea. Activați tunelul și țara aparentă se schimbă, deci serverul ales se schimbă, iar comparația acoperă acum două rute diferite către două gazde diferite.

Rezultatul nu este deloc o măsurare a VPN-ului. Este o măsurare a drumului către un server pe care nu l-ați ales, iar diferența dintre cele două rulări poate fi dominată de peering-ul acelui server, nu de ceva ce a făcut tunelul.

Fixați destinația înainte de a schimba orice altceva. Fiecare instrument credibil vă lasă să alegeți explicit un server, iar când nu o face, pagina de rezultate numește de obicei serverul folosit, ceea ce e suficient ca să observați că cele două rulări nu sunt comparabile. Confirmați ce a văzut site-ul înainte de a avea încredere în alegerea lui:

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

Dacă țara s-a schimbat între rulări, s-a schimbat și tot ce a ales testul după aceea. Notați ieșirea observată lângă fiecare rezultat, iar confuzia dispare în mare parte.

Pornirea lentă se termină după ce se termină majoritatea testelor scurte

O conexiune TCP nu începe la viteza legăturii. Începe cu o fereastră de congestie mică, o dublează aproximativ la fiecare dus-întors și atinge capacitatea rutei abia după mai multe dus-întorsuri. Un test de zece secunde pe o rută cu latență mare poate petrece o parte substanțială din viață în acea urcare.

De aceea un tunel cu latență mai mare punctează mai slab într-un test scurt decât ar merita, și de aceea o rulare mai lungă raportează adesea un număr mai mare fără nicio schimbare de configurare. cadrul de debit RFC 6349 tratează explicit acest lucru, și de aceea măsurătorile serioase durează suficient pentru a atinge o stare stabilă. O rulare de cinci secunde pe o rută satelitară măsoară acceleratorul, nu drumul.

Uitați-vă la fazele conexiunii în loc să aveți încredere într-un singur număr. Curl raportează fiecare etapă separat, astfel încât vedeți dacă timpul merge în strângerea de mână, în urcare sau în transfer:

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

Rulați-l de două ori la rând către aceeași destinație. Dacă a doua rulare este mult mai rapidă, măsurați urcarea, nu ruta, iar orice comparație care a folosit doar prima este suspectă.

Un flux și șase fluxuri măsoară lucruri diferite

Un singur flux TCP este limitat de fereastra pe care o poate ține în zbor, adică aproximativ timpul dus-întors înmulțit cu rata. Pe o rută lungă acel produs depășește ce va folosi un flux, deci o singură descărcare raportează sub capacitatea care există. Șase fluxuri paralele umplu golul și produc un număr mai mare.

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

Ambele numere sunt adevărate. Numărul unui singur flux spune ce va face o descărcare, ceea ce de obicei obține o filă de browser. Numărul paralel spune ce poate duce ruta în total, ceea ce poate folosi un torrent sau o descărcare în mai multe părți. A cita unul ca și cum ar fi celălalt este felul în care un tunel sănătos este înlocuit fără motiv.

Compararea unui rezultat paralel cu un rezultat de un singur flux este cea mai obișnuită cale prin care oamenii ajung la concluzia că VPN-ul le-a înjumătățit viteza. Egalizați metoda, apoi comparați. Urma din a treia comandă adaugă contextul lipsă: o rută cu jitter mare va da rezultate inconsistente în ambele moduri, iar niciun număr de fluxuri nu repară asta.

Criptarea costă timp de procesor, încapsularea costă octeți

Două mecanisme acționează asupra fiecărui pachet indiferent cât de rapidă este legătura. Criptarea consumă procesor pe octet, iar încapsularea adaugă octeți de antet pe care legătura tot trebuie să-i ducă. Ambele apar ca un plafon și au simptome diferite.

Plafonul procesorului apare ca un platou: debitul încetează să crească oricâte fluxuri ați adăuga, iar procesorul mașinii este ocupat în timp ce legătura nu este. Pe un router mic sau un telefon acesta este adesea limita reală, și de aceea o linie rapidă poate da totuși un tunel modest.

Costul în octeți este mai mic, dar constant. Anteturile suplimentare înseamnă mai puțină încărcătură utilă pe pachet, iar pe o rută cu unitate maximă de transmisie fixă pot declanșa și fragmentare sau o gaură neagră care apare ca o blocare la transferurile mari, nu ca o medie lentă.

Aceste trei sunt adesea confundate pentru că utilizatorii le descriu pe toate ca fiind VPN-ul lent. Doar primul reacționează la o mașină mai mare, doar al doilea reacționează la un MTU mai mic, și doar al treilea reacționează la gestionarea cozilor.

Puneți metoda în registru

Un rezultat care merită păstrat numește dispozitivul, rețeaua de acces, ieșirea, serverul de măsurare, direcția, numărul de fluxuri și durata. Fără ele, două numere nu pot fi comparate, iar un tichet care conține un singur număr este de fapt o stare de spirit.

Păstrați și rulările proaste. O serie în care o ieșire produce o blocare de fiecare dată este mult mai informativă decât o medie, iar blocajele sunt exact ceea ce ascund mediile.

Apoi testați lucrul care vă interesează cu adevărat. Dacă scopul este o descărcare mare, descărcați fișierul. Dacă scopul este un apel, măsurați latența sub sarcină în loc de debitul în repaus, pentru că un tunel poate puncta bine într-un test de viteză și totuși face fiecare ședință de neascultat.