Porque uma transferência por VPN pode vencer a ligação direta

Ligue o túnel, inicie uma transferência grande e ela segue a cerca do dobro da velocidade que o mesmo ficheiro alcançava sem ele. Soa a publicidade, mas pode ser uma medição real numa linha doméstica. A causa habitual é um limite de velocidade ligado a uma porta: o túnel leva a transferência para onde o modelador não olha, e a capacidade real da linha aparece pela primeira vez.

O que significa que o número interessante não é a rapidez da VPN. É quanto da sua linha nunca estava a receber, e porquê.

Um limite que segue a porta, não a rota

Um fornecedor de acesso pode limitar o débito por assinante segundo o protocolo ou a porta de destino, e a porta 80 é um alvo preferido porque muita navegação comum a utiliza. Muitas vezes o limite não é aplicado desde o primeiro pacote: a transferência começa perto da velocidade da linha, consome uma franquia de rajada e depois assenta no valor limitado. Os primeiros segundos parecem saudáveis e o resto da transferência não.

Envie os mesmos bytes por outra porta e o modelador da 80 nunca os vê. O túnel parece vencer a ligação direta embora tenha acrescentado um salto, cifragem e o seu próprio custo. O que melhorou não é o caminho mas a ausência de uma regra.

É também por isso que o efeito é tão constante entre ficheiros e destinos. Se o limite está na porta, tudo o que viaja por essa porta comporta-se da mesma forma, seja qual for o tamanho do ficheiro e quem for o anfitrião. Um destino que atrai outra regra mostra outra curva, e essa diferença é diagnóstica por si.

Meça o planalto, não o pico

O pico é a parte menos informativa de uma transferência, porque toda a ligação parece boa enquanto os seus buffers enchem. Registe onde a velocidade se estabiliza e quanto tempo aí permanece.

curl -o /dev/null -w '%{speed_download} %{time_total}\n' https://<host>/test.bin
scp user@<transfer-host>:/data/test.bin /tmp/

Execute o par logo a seguir um ao outro na mesma máquina, à mesma hora, contra anfitriões em redes comparáveis. Uma amostra não prova nada; a forma da curva em duas execuções de cada um é o que distingue uma franquia de rajada de um limite estável. Anote onde a velocidade se achata e não o que mostrou o primeiro segundo, porque a rajada é precisamente o que um modelador lhe dá antes de começar a limitar. Um planalto calmo que aguenta o resto da transferência é o número a comparar.

Mantenha o ficheiro já comprimido para que a compressão de transporte não possa ser apresentada como explicação. Um PDF ou um arquivo elimina essa variável, e também impede que alguém argumente que o túnel comprimiu a carga. Se ambas as transferências usam o mesmo ficheiro, a única diferença que resta é o caminho e a porta. Registe a ferramenta e a porta ao lado de cada valor, ou a segunda execução não é comparável com a primeira.

Três comparações que isolam a causa

Percorra-as por ordem e pare assim que o padrão estiver claro, porque cada uma descarta uma história diferente.

1. Repita a mesma transferência pelo caminho web comum e por uma ferramenta de transferência noutra porta, a partir de um anfitrião com capacidade comparável.
2. Repita ambos com um ficheiro incomprimível, para que a compressão deixe de ser candidata.
3. Se administra o servidor do túnel, volte a ligá-lo à porta 80, ajuste o perfil do cliente para que as duas pontas concordem e transfira de novo. Se agora o túnel fica na velocidade web limitada, a restrição segue a porta e não a VPN.

O terceiro passo é o decisivo, e é também aquele que as pessoas saltam porque exige uma alteração de configuração. Sem ele demonstrou que duas coisas diferem, não que a porta é a razão.

O que esta medição não pode sustentar

Não mostra que o túnel seja mais rápido em geral, que comprima algo, nem que outras portas da linha estejam sem restrições. Descreve esta transferência, nesta linha, a esta hora. Os limites podem aplicar-se por sessão, por assinante ou conforme a hora do dia, e podem mudar sem aviso.

Também não prova que o caminho direto esteja roto. Um caminho limitado continua a funcionar; está limitado de propósito, e uma política deliberada não é uma avaria à espera de reparação.

E decerto não justifica encaminhar tudo pelo túnel. Cada aplicação na porta 80 continua limitada, enquanto tudo o que desviar depende agora de um salto extra e de um modo de falha extra.

Transforme a descoberta em algo acionável

Escreva a observação como medição e não como veredicto: as transferências grandes pela porta 80 assentam perto de metade da velocidade que o mesmo ficheiro atinge noutra porta, a estas horas, nesta linha, com estas amostras anexadas. Isso é um pedido de apoio que alguém pode investigar.

«A VPN é mais rápida» não é. Convida a uma resposta sobre o custo da cifragem, e essa resposta é tecnicamente correta sem dizer nada de útil a ninguém. Anexe o número de amostras, a hora e a porta, para que o leitor possa reproduzir o padrão.

Se decidir continuar a usar outra porta para transferências grandes, registe a ressalva nos seus próprios registos: mover um ouvinte para a porta 80 colide com qualquer servidor web já ligado aí, e a falha resultante parece um túnel roto mais do que um conflito de portas.