Por que a penalidade do VPN parece pior no celular do que no Ethernet

O mesmo notebook, o mesmo servidor e o mesmo túnel podem perder um quinto da sua vazão no Ethernet e três quartos no celular, e nenhum dos dois números significa que o VPN está quebrado. Cada rede de acesso fornece um caminho diferente, e o túnel acrescenta um segundo caminho por cima. Comparar um número com túnel a um número sem túnel não responde nada, porque os dois números descrevem denominadores diferentes. Quatro células e uma fração de retenção por linha dirão qual pergunta fazer em seguida.

Quatro células, não uma penalidade

Meça a linha de base direta e o resultado com túnel em cada rede de acesso, e mantenha-os como uma matriz em vez de um veredicto único. A base é a mesma tarefa realizada naquela rede sem o túnel; o resultado com túnel é a mesma tarefa com ele.

Use uma carga de trabalho autorizada para os testes diretos e mantenha os controles de privacidade exigidos pelo ambiente. Um teste que viola a política produz um número que você não pode publicar e não deveria repetir.

Mantenha as variáveis paradas

Mantenha o dispositivo, o aplicativo, o destino, a direção da transferência e o endpoint do VPN fixos nas quatro células. Se um serviço trocar silenciosamente seu servidor de teste entre execuções, registre a mudança e trate o par como não controlado em vez de diluir a diferença numa média.

Repita a matriz nos dois sentidos e em horários comparáveis. As condições de um rádio celular e a carga na sua célula mudam em minutos, então uma única base excepcionalmente boa pode exagerar a penalidade aparente. Registre a dispersão dos resultados ao lado de um valor representativo, e anote se as execuções com túnel foram intercaladas com as bases ou feitas em bloco.

O intercalamento importa mais do que a maioria espera. Uma base medida antes do almoço e uma execução com túnel medida depois são duas redes diferentes com o mesmo nome.

Mantenha o denominador visível

Relate a fração de retenção e também a taxa absoluta: E1 dividido por E0, e C1 dividido por C0. Um link rápido que mantém uma parte pequena da sua vazão e um link lento que mantém a maior parte dela são achados diferentes, e só a fração mostra a diferença.

A vazão absoluta ainda decide o que um usuário pode fazer. A fração decide onde olhar. Quando o Ethernet mantém a maior parte da sua base e o celular mantém muito menos, a variável interessante está no caminho celular e não dentro da criptografia.

Os dois números pertencem ao relatório, porque cada um sozinho sustenta uma conclusão que os dados não sustentam.

Leia o padrão antes de mudar qualquer coisa

Tetos com túnel semelhantes nas duas redes apontam para algo compartilhado: o endpoint, sua CPU, um limite de taxa ou um único salto congestionado. Uma queda que aparece só no celular aponta para a rota dessa rede, a perda, a latência e o tamanho efetivo do pacote.

Estas são pistas, não diagnósticos, e a diferença importa quando você escreve o chamado. Um teto compartilhado não melhora quando você troca o modem celular, e uma queda só celular não melhora quando você redimensiona o endpoint. Diga qual dos dois padrões você viu antes de propor uma mudança. Assim a mudança carrega uma previsão, e a próxima medição pode confirmá-la ou matá-la.

As próprias orientações de desempenho do OpenVPN separam restrições de largura de banda, CPU, transporte e tamanho de pacote pelas mesmas linhas, o que é um lembrete útil de que o túnel raramente é uma só variável.

Quando o tamanho do pacote é o suspeito

O encapsulamento consome espaço do pacote, então o tamanho efetivo num caminho celular pode ser menor que o anunciado pela interface. Mantenha evidências de tamanho de pacote para o caminho que está comparando em vez de supor um valor a partir do nome da tecnologia de acesso.

Datagram packetization-layer path MTU discovery descreve como descobrir o tamanho efetivo em vez de fixá-lo. Use as observações que a implementação suporta, e não imponha um MTU baixo arbitrário a cada cliente como precaução, porque isso troca um problema por um pior em caminhos que estavam bem.

Uma hipótese de tamanho precisa das suas próprias evidências: a mesma transferência em dois tamanhos, com o padrão de perda registrado.

Adicione uma variável por vez

Compare um transporte alternativo só depois que a matriz de base estiver salva. Isso mantém uma variável deliberada em jogo e permite atribuir a mudança em vez de adivinhá-la.

Mantenha o dimensionamento da carga útil do TCP separado do comportamento dos datagramas UDP, já que os dois reagem de forma diferente à perda e ao tamanho do caminho. Uma melhoria vinda de uma mudança de transporte é evidência sobre aquele transporte, não prova de que a criptografia ou a cobertura eram a causa original.

Ordem do trabalho: preencha as quatro células, calcule as duas frações, intercale as execuções, depois escolha uma hipótese e teste-a com uma única mudança. Qualquer outra coisa é uma comparação de duas incógnitas.