Com provar la velocitat d'una VPN perquè les xifres signifiquin alguna cosa
Fixeu el servidor de prova, manteniu la capa inferior quieta i llegiu el retard separat del cabal. El túnel canvia el camí abans de mesurar res de res.
Una prova de velocitat mai no mesura la VPN. Mesura un camí, i engegar el túnel substitueix part d'aquest camí abans que es mogui el primer byte. Per això un portàtil mostra una xifra sana contra un lloc i una de pobra contra un altre sense que res hagi canviat a cap dels dos costats. Llegiu el resultat com a evidència sobre una ruta, no com a puntuació d'un producte.
Tres coses decideixen si la comparació val alguna cosa: si les dues execucions han tocat el mateix objectiu, si la xarxa d'accés ha quedat quieta i si heu enregistrat el retard al costat del volum.
Què reescriu el túnel abans del primer byte
El client embolcalla cada paquet en una altra capçalera, així que la càrrega útil per paquet minva. El cost és per paquet i no per transferència, cosa que vol dir que un fitxer gran necessita més paquets que el mateix fitxer enviat sense túnel. Aquest sobrecost es veu com a nombre de paquets, no com un paràmetre visible.
Se'n deriven dues conseqüències. Una prova feta de blocs grans nota el cost per paquet, mentre que una prova feta de moltes peticions petites nota en canvi els viatges d'anada i tornada. I si el descobriment de l'MTU del camí està bloquejat en algun punt, el túnel s'estableix en una mida de paquet més petita i el cabal cau per un motiu que no té res a veure amb els xifrats.
Podeu observar el sostre directament. A Linux, demaneu la càrrega més gran que sobreviu sense fragmentació i repetiu-ho amb el túnel engegat:
ping -M do -s 1472 -c 3 203.0.113.10
Si això falla, baixeu a 1,400 i torneu-ho a provar. Un túnel que només porta 1,380 bytes us diu que alguna cosa estreny més avall del camí, i cap ajust al client no ho aixecarà.
Per què es mou el servidor de prova quan s'engega el túnel
La majoria d'eines trien un servidor proper a partir de l'adreça pública que veuen. Amb el túnel engegat, aquesta adreça pertany al node de sortida, així que l'eina pot triar un amfitrió en una altra ciutat o país. Llavors compareu dues destinacions, i el buit entre elles inclou la distància de la sortida fins a l'amfitrió de prova.
Fixeu el servidor per nom o ID abans de la primera execució i manteniu-lo a cada execució posterior. Si l'eina no el reté, trieu un objectiu que controleu i conduïu-lo vosaltres: iperf3 -c test.example.net -R -t 20 manté la destinació fixa i us dona un número que podeu comparar amb el d'ahir.
Canvieu una variable, i la capa inferior no és una de sola
El sense fil és el canvi ocult habitual. La potència del senyal es mou quan es mou el portàtil i l'ocupació del canal es mou quan un veí comença una trucada, així que dues execucions amb deu minuts de diferència per Wi-Fi no són repeticions de la mateixa prova. Cable, o una posició fixa amb el nivell de senyal anotat, elimina la major part d'aquest soroll. Anotar el nivell de senyal a l'inici i al final de cada execució sol ser suficient per mostrar si dues execucions van juntes.
La càrrega del dispositiu va al mateix cistell. Un client que xifra en un sol nucli arriba al seu propi sostre molt abans que l'enllaç, i una sincronització en segon pla hi arriba abans. Mireu la CPU durant l'execució i anoteu què més estava obert. Els paràmetres d'energia també poden mossegar aquí, perquè un portàtil amb bateria pot limitar el processador molt abans que l'enllaç sigui a prop d'estar ocupat.
| Measurement | What it answers | What it misses |
|---|---|---|
| Download | Bulk capacity along the path | Any question about responsiveness |
| Upload | Capacity from client to exit | Download health |
| RTT to a fixed target | Distance plus queueing | Whether capacity is available |
| Jitter or loss | Stability under load | How much the link can carry |
Manteniu la capa inferior quieta en lloc de fer-ne una mitjana. Tres execucions que coincideixen diuen més que deu fetes en sales diferents.
Retard, pèrdua i ICMP responen preguntes diferents
El ping envia una sonda petita a una adreça fixa, i moltes xarxes responen a l'ICMP amb baixa prioritat o l'ignoren del tot. Les respostes absents descriuen la sonda, no els paquets de l'aplicació. Un temps d'anada i tornada que puja sota càrrega sol voler dir que s'omple una cua, no que la ruta s'hagi allargat.
Per saber si el túnel afegeix retard, compareu un objectiu amb i sense ell, o compareu dues sortides abastables des de la mateixa xarxa d'accés. Executeu la sonda repetidament i mireu la dispersió, perquè la mitjana amaga justament la variació que fa inservible una trucada.
Torneu a la tasca que anava lenta
Una mesura que millora mentre la trucada encara s'entretalla ha respost una altra cosa. Torneu a executar la tasca que va iniciar la investigació, fos una reunió, un recurs compartit o una sessió d'escriptori remot. Si la xifra ha millorat i la tasca no, el coll d'ampolla era en un lloc on la prova no va arribar, com el servidor darrere del túnel o l'enllaç de pujada del vostre costat.
Registreu cada execució amb dispositiu, xarxa d'accés, punt final, protocol, objectiu i hora. Una execució que no es va connectar mai és un resultat d'abastabilitat i no un cabal de zero, així que arxiveu-la sota aquesta etiqueta en lloc d'esborrar-la.
Una llista curta abans de la propera comparació
Fixeu l'objectiu i escriviu per què l'heu triat. Enregistreu la mida de paquet que el camí permet, perquè una caiguda posterior tingui explicació. Manteniu la xarxa d'accés idèntica, anoteu la càrrega de CPU i feu tres execucions abans de creure una diferència.
Després canvieu exactament una cosa i repetiu. La comparació que podeu explicar val més que la que té el número més gran.