Un test de viteză nu măsoară niciodată VPN-ul. Măsoară o rută, iar pornirea tunelului înlocuiește o parte din acea rută înainte ca primul octet să se miște. De aceea un laptop arată o cifră sănătoasă față de un site și una slabă față de altul fără ca nimic să se fi schimbat de vreo parte. Citește rezultatul ca dovadă despre o rută, nu ca punctaj pentru un produs.

Trei lucruri decid dacă comparația valorează ceva: dacă ambele rulări au lovit aceeași țintă, dacă rețeaua de acces a rămas nemișcată și dacă ai notat întârzierea alături de volum.

Ce rescrie tunelul înainte de primul octet

Clientul înfășoară fiecare pachet într-un alt antet, așa că încărcătura utilă pe pachet scade. Costul este pe pachet, nu pe transfer, ceea ce înseamnă că un fișier mare are nevoie de mai multe pachete decât același fișier trimis fără tunel. Un astfel de surplus se vede ca număr de pachete, nu ca o setare vizibilă.

Din asta rezultă două consecințe. Un test construit din blocuri mari simte costul pe pachet, în timp ce un test din multe cereri mici simte în schimb dus-întorsurile. Și dacă descoperirea MTU a traseului este blocată undeva pe drum, tunelul se așează pe o dimensiune mai mică a pachetului și debitul scade dintr-un motiv care nu are nimic de-a face cu cifrurile.

Poți observa plafonul direct. În Linux cere cea mai mare încărcătură care trece fără fragmentare, apoi repetă cu tunelul pornit:

ping -M do -s 1472 -c 3 203.0.113.10

Dacă asta eșuează, coboară la 1,400 și încearcă din nou. Un tunel care duce doar 1,380 de octeți îți spune că ceva strânge mai jos pe traseu, și nicio ajustare la client nu o va ridica.

De ce serverul de test se mută când pornește tunelul

Majoritatea instrumentelor aleg un server apropiat după adresa publică pe care o văd. Cu tunelul pornit, acea adresă aparține nodului de ieșire, așa că instrumentul poate alege o gazdă în alt oraș sau altă țară. Compari atunci două destinații, iar diferența dintre ele include distanța de la ieșire până la gazda de test.

Fixează serverul după nume sau ID înainte de prima rulare și păstrează-l la fiecare rulare următoare. Dacă instrumentul nu îl ține, alege o țintă pe care o controlezi și condu-o singur: iperf3 -c test.example.net -R -t 20 ține destinația fixă și îți dă un număr pe care îl poți compara cu cel de ieri.

Schimbă o variabilă, iar stratul de dedesubt nu e una singură

Fără fir este schimbarea ascunsă obișnuită. Puterea semnalului se mută când laptopul se mișcă, iar ocuparea canalului se mută când un vecin începe un apel, așa că două rulări la zece minute distanță în Wi-Fi nu sunt repetări ale aceluiași test. Cablu, sau o poziție fixă cu nivelul semnalului notat, elimină cea mai mare parte a acelui zgomot. O notă a nivelului semnalului la începutul și la sfârșitul fiecărei rulări este de obicei suficientă pentru a arăta dacă două rulări merg împreună.

Încărcarea dispozitivului intră în același coș. Un client care cifrează pe un singur nucleu atinge propriul plafon mult înaintea legăturii, iar o sincronizare din fundal îl atinge mai devreme. Urmărește CPU-ul în timpul rulării și notează ce altceva era deschis. Setările de energie pot mușca și aici, pentru că un laptop pe baterie poate limita procesorul mult înainte ca legătura să fie măcar aproape ocupată.

MeasurementWhat it answersWhat it misses
DownloadBulk capacity along the pathAny question about responsiveness
UploadCapacity from client to exitDownload health
RTT to a fixed targetDistance plus queueingWhether capacity is available
Jitter or lossStability under loadHow much the link can carry

Ține stratul de dedesubt nemișcat în loc să faci o medie peste el. Trei rulări care se potrivesc spun mai mult decât zece făcute în camere diferite.

Întârzierea, pierderea și ICMP răspund la întrebări diferite

Ping trimite o sondă mică la o adresă fixă, iar multe rețele răspund la ICMP cu prioritate joasă sau îl ignoră complet. Răspunsurile lipsă descriu sonda, nu pachetele aplicației. Un timp dus-întors care urcă sub încărcare înseamnă de obicei că o coadă se umple, nu că traseul s-a lungit.

Ca să afli dacă tunelul adaugă întârziere, compară o țintă cu și fără el, sau compară două ieșiri accesibile din aceeași rețea de acces. Rulează sonda în mod repetat și uită-te la împrăștiere, pentru că media ascunde exact variația care face un apel inutilizabil.

Întoarce-te la sarcina care s-a simțit lentă

O măsură care se îmbunătățește în timp ce apelul încă se rupe a răspuns la altceva. Rulează din nou sarcina care a început investigația, fie că a fost o ședință, o partajare de fișiere sau o sesiune de desktop la distanță. Dacă cifra s-a îmbunătățit, iar sarcina nu, blocajul era undeva unde testul nu a ajuns niciodată, cum ar fi serverul din spatele tunelului sau legătura ta de încărcare.

Înregistrează fiecare rulare cu dispozitiv, rețea de acces, punct final, protocol, țintă și oră. O rulare care nu s-a conectat niciodată este un rezultat de accesibilitate, nu un debit zero, așa că arhiveaz-o sub acea etichetă în loc să o ștergi.

O listă scurtă înainte de următoarea comparație

Fixează ținta și scrie de ce ai ales-o. Notează dimensiunea pachetului pe care o permite traseul, ca o scădere ulterioară să aibă o explicație. Ține rețeaua de acces identică, notează încărcarea CPU și fă trei rulări înainte de a crede o diferență.

Apoi schimbă exact un lucru și repetă. Comparația pe care o poți explica bate cea cu numărul mai mare.

Articole similare