Uma VPN pode ser mais rápida que a ligação direta?
A encapsulação acrescenta custo, mas a saída pode mudar o trânsito, o destino e as condições do transporte. Decida com três comparações, não com um só teste de velocidade.
Uma transferência que se arrasta na ligação do escritório às vezes termina depressa através do túnel, e a encapsulação extra faz isso parecer impossível. O paradoxo aparente vem de comparar as coisas erradas. O túnel acrescenta trabalho e também muda que caminho de rede o tráfego segue, que endereço o destino vê e às vezes que servidor responde. Decidir entre as duas rotas exige separar esses três efeitos antes de qualquer conclusão sobre a velocidade.
Três coisas que o túnel pode mudar
A primeira é o trânsito. O encaminhamento na Internet segue a política do operador e as relações comerciais, não a latência medida, portanto o caminho através de um fornecedor de VPN pode atravessar redes diferentes da rota direta. Pode evitar um ponto de troca congestionado ou aterrar num melhor ligado, e com a mesma facilidade pode ser pior.
A segunda é o destino. Uma mudança de endereço de saída altera muitas vezes a resposta DNS, e uma rede de conteúdos pode dar-lhe outra cache ou outra região. Parte da melhoria pertence então ao novo servidor e não ao túnel. O mesmo nome de anfitrião pode aterrar num servidor mais próximo ou menos carregado sem que nada mude no cliente.
A terceira é o comportamento do transporte. A encapsulação altera o tamanho efetivo dos pacotes, e um túnel que evita um segmento intermédio com perdas pode deixar um fluxo TCP aumentar a sua janela em vez de recuar repetidamente. Nada disto é um mecanismo universal de aceleração; cada um é uma condição que tem de ser observada. Separá-los é o que transforma uma curiosidade num facto.
O que não pode mudar
Nada no túnel acrescenta capacidade à ligação entre o dispositivo e a rede. Um canal Wi-Fi saturado, uma última milha congestionada ou um plano móvel limitado limitam ambas as rotas da mesma forma, e um teste de velocidade através do túnel não pode ultrapassar esse teto. A mesma ligação transporta os pacotes encapsulados, portanto a encapsulação pode gastar capacidade mas nunca criá-la. O que muda é para onde vão os pacotes depois de saírem dessa ligação. É por isso que um resultado rápido do túnel tem sempre uma explicação a montante do primeiro salto.
Os limites do lado do servidor são igualmente indiferentes. Se o anfitrião remoto serve devagar, um caminho melhor apenas entrega a resposta lenta com mais eficiência, e o utilizador continua à espera. Uma origem partilhada sob carga parece lenta nos dois caminhos no mesmo momento.
Compare os caminhos corretamente
Mantenha idênticos a aplicação, o sentido, a duração e a concorrência, e mude apenas o caminho. Execute cada teste mais de uma vez, à mesma hora do dia, e registe o endereço de saída e a resposta do resolvedor ao lado do débito. Uma execução é uma amostra e não uma medição, e uma única descarga rápida pode ser um acerto de cache que nada diz sobre a rota. Escreva as condições antes dos resultados, porque os números são difíceis de interpretar depois.
mtr -rwc 50 -T -P 443 203.0.113.20
curl -o /dev/null -s -w '%{speed_download} %{time_connect}\n' https://example.com/file
dig +short cdn.example.com
traceroute -n -T -p 443 cdn.example.com
A resposta do resolvedor é o pormenor que a maioria das comparações omite, e explica as «melhorias» que desaparecem quando se força o mesmo servidor. Se o endereço diferir entre execuções, o teste comparou dois destinos e não dois caminhos. Comunique a latência e a perda ao lado do débito, porque um caminho mais rápido no conjunto mas que acrescenta atraso a cada pedido interativo não é melhor para a carga de trabalho que se queixou. O tempo de ida e volta importa mais do que a velocidade maciça para tudo o que pergunta e espera.
Quando a diferença merece ser mantida
Se um túnel aprovado melhora de forma fiável uma carga de trabalho concreta, é uma escolha operativa legítima: documente a carga, a medição e a saída utilizada. Um registo útil nomeia um só anfitrião, o endereço de saída que o túnel produziu, a resposta do resolvedor e os mesmos números do caminho direto no mesmo dia. Isso basta para o próximo engenheiro repetir a comparação em vez de a discutir outra vez. Continua a não ser prova de que o fornecedor limite algo, e não se transfere para outras aplicações ou outras horas.
Guarde o registo da medição com a configuração. Responde à pergunta seguinte, se a melhoria ainda existe, e é a única forma de saber se mudou o caminho ou a carga de trabalho. Um registo sem data não pode responder a essa pergunta de todo.