Como probar a velocidade dunha VPN para que as cifras signifiquen algo
Fixe o servidor de proba, manteña a capa inferior quieta e lea o atraso por separado do caudal. O túnel cambia a ruta antes de medir nada de nada.
Unha proba de velocidade nunca mide a VPN. Mide unha ruta, e acender o túnel substitúe parte desa ruta antes de que se mova o primeiro byte. Por iso un portátil mostra unha cifra san contra un sitio e unha mala contra outro sen que cambiase nada en ningún dos dous lados. Lea o resultado como evidencia sobre unha ruta, non como unha puntuación dun produto.
Tres cousas deciden se a comparación vale algo: se as dúas execucións deron co mesmo obxectivo, se a rede de acceso quedou quieta e se rexistrou o atraso xunto ao volume.
Que reescribe o túnel antes do primeiro byte
O cliente envolve cada paquete noutra cabeceira, así que a carga útil por paquete redúcese. O custo é por paquete e non por transferencia, o que significa que un ficheiro grande necesita máis paquetes que o mesmo ficheiro enviado sen túnel. Ese sobrecusto vese como número de paquetes, non como un axuste visible.
Dedúcense dúas consecuencias. Unha proba feita de bloques grandes nota o custo por paquete, mentres que unha proba de moitas peticións pequenas nota en cambio as viaxes de ida e volta. E se o descubrimento da MTU da ruta está bloqueado nalgún punto, o túnel queda nun tamaño de paquete menor e o caudal cae por un motivo que non ten nada que ver cos cifrados.
Pode observar o teito directamente. En Linux, pida a carga útil máis grande que sobrevive sen fragmentación e repita despois co túnel acendido:
ping -M do -s 1472 -c 3 203.0.113.10
Se iso falla, baixe a 1,400 e volva tentar. Un túnel que só transporta 1,380 bytes está a dicirlle que algo aperta máis abaixo na ruta, e ningún axuste no cliente o levantará.
Por que se move o servidor de proba cando se acende o túnel
A maioría das ferramentas elixen un servidor próximo a partir do enderezo público que ven. Co túnel acendido, ese enderezo pertence ao nodo de saída, así que a ferramenta pode escoller un equipo noutra cidade ou país. Entón compara dous destinos, e a diferenza entre eles inclúe a distancia desde a saída ata o equipo de proba.
Fixe o servidor por nome ou ID antes da primeira execución e mantéñao en cada execución posterior. Se a ferramenta non o retén, escolla un obxectivo que controle e condúzao vostede mesmo: iperf3 -c test.example.net -R -t 20 mantén fixo o destino e dálle un número que pode comparar co de onte.
Cambie unha variable, e a capa inferior non é unha soa
O sen fíos é o cambio oculto habitual. A potencia do sinal desprázase cando se move o portátil e a ocupación da canle desprázase cando un veciño comeza unha chamada, así que dúas execucións con dez minutos de diferenza por Wi-Fi non son repeticións da mesma proba. Cable, ou unha posición fixa co nivel de sinal anotado, elimina a maior parte dese ruído. Anotar o nivel de sinal ao comezo e ao final de cada execución adoita abondar para mostrar se dúas execucións van xuntas.
A carga do dispositivo vai na mesma cesta. Un cliente que cifra nun só núcleo chega ao seu propio teito moito antes que a ligazón, e unha sincronización en segundo plano chega antes. Vixíe a CPU durante a execución e anote que máis estaba aberto. Os axustes de enerxía tamén poden morder aquí, porque un portátil con batería pode limitar o procesador moito antes de que a ligazón estea sequera preto de estar ocupada.
| 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 |
Manteña a capa inferior quieta en lugar de facerlle unha media. Tres execucións que coinciden din máis que dez tomadas en cuartos distintos.
Atraso, perda e ICMP responden preguntas distintas
Ping envía unha sonda pequena a un enderezo fixo, e moitas redes responden ao ICMP con baixa prioridade ou ignórano por completo. As respostas ausentes describen a sonda, non os paquetes da aplicación. Un tempo de ida e volta que sobe baixo carga adoita significar que se está a encher unha cola, non que a ruta se alongase.
Para saber se o túnel engade atraso, compare un obxectivo con e sen el, ou compare dúas saídas alcanzables desde a mesma rede de acceso. Execute a sonda repetidamente e mire a dispersión, porque a media esconde xustamente a variación que fai inservible unha chamada.
Volva á tarefa que se sentiu lenta
Unha medida que mellora mentres a chamada aínda entrecórtase respondeu a outra cousa. Volva executar a tarefa que iniciou a investigación, fose unha reunión, un recurso compartido ou unha sesión de escritorio remoto. Se a cifra mellorou e a tarefa non, o pescozo de botella estaba nalgún sitio ao que a proba nunca chegou, como o servidor detrás do túnel ou a ligazón de subida da súa beira.
Rexiste cada execución con dispositivo, rede de acceso, extremo, protocolo, obxectivo e hora. Unha execución que nunca se conectou é un resultado de alcanzabilidade e non un caudal de cero, así que arquívea baixo esa etiqueta en lugar de borrala.
Unha lista curta antes da próxima comparación
Fixe o obxectivo e escriba por que o escolleu. Rexiste o tamaño de paquete que permite a ruta, para que unha caída posterior teña explicación. Manteña a rede de acceso idéntica, anote a carga de CPU e faga tres execucións antes de crer unha diferenza.
Despois cambie exactamente unha cousa e repita. A comparación que pode explicar vale máis que a que ten o número máis grande.