Como testar a velocidade de uma VPN para que os números signifiquem algo

Um teste de velocidade nunca mede a VPN. Mede um caminho, e ligar o túnel substitui parte desse caminho antes de o primeiro byte se mover. É por isso que um portátil mostra um número saudável contra um site e um mau contra outro sem que nada tenha mudado de qualquer dos lados. Leia o resultado como prova sobre uma rota, não como pontuação de um produto.

Três coisas decidem se a comparação vale alguma coisa: se as duas execuções atingiram o mesmo alvo, se a rede de acesso ficou imóvel e se registou o atraso junto ao volume.

O que o túnel reescreve antes do primeiro byte

O cliente envolve cada pacote noutro cabeçalho, pelo que a carga útil por pacote encolhe. O custo é por pacote e não por transferência, o que significa que um ficheiro grande precisa de mais pacotes do que o mesmo ficheiro enviado sem túnel. Esse excedente vê-se como número de pacotes, não como uma definição visível.

Daí decorrem duas consequências. Um teste feito de blocos grandes sente o custo por pacote, enquanto um teste de muitos pedidos pequenos sente, em vez disso, as idas e voltas. E se a descoberta da MTU do caminho estiver bloqueada em algum ponto, o túnel fica num tamanho de pacote menor e o caudal cai por um motivo que nada tem a ver com as cifras.

Pode observar o teto diretamente. No Linux, peça a maior carga útil que passa sem fragmentação e repita depois com o túnel ligado:

ping -M do -s 1472 -c 3 203.0.113.10

Se isso falhar, desça para 1,400 e tente de novo. Um túnel que só transporta 1,380 bytes está a dizer-lhe que algo aperta mais abaixo no caminho, e nenhum ajuste no cliente o levantará.

Porque é que o servidor de teste se desloca quando o túnel liga

A maioria das ferramentas escolhe um servidor próximo com base no endereço público que vê. Com o túnel ligado, esse endereço pertence ao nó de saída, por isso a ferramenta pode escolher um anfitrião noutra cidade ou país. Passa então a comparar dois destinos, e a diferença entre eles inclui a distância da saída até ao anfitrião de teste.

Fixe o servidor por nome ou ID antes da primeira execução e mantenha-o em cada execução seguinte. Se a ferramenta não o retiver, escolha um alvo que controle e conduza-o você mesmo: iperf3 -c test.example.net -R -t 20 mantém o destino fixo e dá-lhe um número que pode comparar com o de ontem.

Mude uma variável, e a camada inferior não é uma só

O sem fios é a alteração escondida habitual. A potência do sinal desloca-se quando o portátil se move e a ocupação do canal desloca-se quando um vizinho inicia uma chamada, por isso duas execuções com dez minutos de diferença em Wi-Fi não são repetições do mesmo teste. Cabo, ou uma posição fixa com o nível de sinal anotado, elimina a maior parte desse ruído. Uma nota do nível de sinal no início e no fim de cada execução costuma bastar para mostrar se duas execuções andam juntas.

A carga do dispositivo pertence ao mesmo cesto. Um cliente que cifra num só núcleo atinge o seu próprio teto muito antes da ligação, e uma sincronização em segundo plano atinge-o mais cedo. Vigie a CPU durante a execução e anote o que mais estava aberto. As definições de energia também podem morder aqui, porque um portátil a bateria pode limitar o processador muito antes de a ligação estar perto de estar ocupada.

Mantenha a camada inferior imóvel em vez de fazer uma média sobre ela. Três execuções que concordam dizem mais do que dez feitas em salas diferentes.

Atraso, perda e ICMP respondem a perguntas diferentes

O ping envia uma sonda pequena para um endereço fixo, e muitas redes respondem ao ICMP com baixa prioridade ou ignoram-no por completo. As respostas ausentes descrevem a sonda, não os pacotes da aplicação. Um tempo de ida e volta que sobe sob carga costuma significar que uma fila está a encher, não que a rota ficou mais longa.

Para saber se o túnel acrescenta atraso, compare um alvo com e sem ele, ou compare duas saídas alcançáveis a partir da mesma rede de acesso. Execute a sonda repetidamente e olhe para a dispersão, porque a média esconde exatamente a variação que torna uma chamada inutilizável.

Volte à tarefa que pareceu lenta

Uma medida que melhora enquanto a chamada ainda se corta respondeu a outra coisa. Volte a executar a tarefa que iniciou a investigação, fosse uma reunião, uma partilha de ficheiros ou uma sessão de ambiente de trabalho remoto. Se o número melhorou e a tarefa não, o estrangulamento estava num sítio onde o teste nunca chegou, como o servidor atrás do túnel ou a sua ligação de subida.

Registe cada execução com dispositivo, rede de acesso, extremo, protocolo, alvo e hora. Uma execução que nunca se ligou é um resultado de alcançabilidade e não um caudal de zero, por isso arquive-a sob esse rótulo em vez de a apagar.

Uma lista curta antes da próxima comparação

Fixe o alvo e escreva porque o escolheu. Registe o tamanho de pacote que o caminho permite, para que uma queda posterior tenha explicação. Mantenha a rede de acesso idêntica, anote a carga de CPU e faça três execuções antes de acreditar numa diferença.

Depois mude exatamente uma coisa e repita. A comparação que consegue explicar vale mais do que a que tem o número maior.