Por que o Tor parece mais lento que uma VPN: cliques contra downloads

Páginas que parecem travadas enquanto os downloads correm a ritmo normal descrevem viagens de ida e volta, não largura de banda. Uma VPN acrescenta um salto cifrado e um circuito Tor acrescenta vários, e cada salto extra custa um handshake antes de qualquer byte útil se mover. Esse custo aparece numa página que abre muitas conexões curtas e quase desaparece numa única transferência grande. Quando o padrão fica visível, a discussão deixa de ser sobre qual ferramenta é mais rápida.

O sintoma aponta para o custo de configuração, não para a capacidade

Carregar uma página é uma cadeia de trocas dependentes: uma busca de nome, um handshake de transporte, um handshake TLS e depois o primeiro pedido. Cada salto do caminho insere a sua própria viagem de ida e volta nessa cadeia antes de algo ser desenhado. Um download grande paga o mesmo custo de configuração uma vez e depois flui, e é exatamente por isso que as duas cargas de trabalho discordam.

Leia no painel de rede o tempo de espera antes do primeiro byte, não o total. Espera longa com download curto de conteúdo aponta para viagens de ida e volta, enquanto download longo com espera curta aponta para a taxa de transferência. Repita contra um segundo destino, porque um único host atrás de um relé ocupado não prova nada. Quando a transferência está boa e o clique lento, desconfie do custo de configuração muito antes da largura de banda.

Latência e capacidade falham de formas diferentes

Faça duas leituras e a maior parte da confusão resolve-se sozinha. A latência é um custo fixo por troca e a capacidade é uma taxa ao longo do tempo, por isso um caminho pode ser bom na primeira e mau na segunda. Um ponto final distante com um processador inativo responde depressa a um pedido pequeno e ainda limita uma transferência sustentada ao que a sua ligação ascendente permite. Os utilizadores vivem essa separação como um clique rápido seguido de uma barra de progresso que quase não se mexe.

Teste a capacidade com uma transferência sustentada e veja se a taxa se mantém estável ou em dentes de serra. Teste a latência com um pedido pequeno repetido muitas vezes e leia a dispersão em vez da melhor amostra, porque uma dispersão ampla sente-se pior do que a sua média sugere. Anote os dois números antes e depois de cada alteração, ou mais tarde atribuirá o mérito à variável errada.

Tratar as duas como um único número produz correções que nunca mexem na medição que lhe importa. É a forma mais comum de uma queixa de latência receber como resposta uma melhoria de largura de banda.

O encaminhamento em cebola acrescenta saltos que não escolheu

Um circuito Tor usa normalmente três relés — um guarda, um nó intermédio e uma saída — e o cliente escolhe-os de um consenso, não de um mapa. Por isso o caminho pode ser muito mais longo do que a linha direta até ao destino. Cada relé transporta também o tráfego de outros, pelo que o seu fluxo partilha a capacidade que restar nesse relé.

Reutilizar o circuito suaviza o custo, porque um novo fluxo pode viajar sobre um circuito existente em vez de pagar outra construção. Um cliente que constrói um circuito novo por pedido paga a configuração repetidamente e sente-se muito pior do que um que reutiliza. A escolha da saída também conta, porque algumas saídas carregam mais carga e nada na interface lhe diz em qual aterrou. Essa partilha é o sentido do desenho e a razão pela qual a latência não pode ser afinada para um valor fixo, por isso uma saída lenta é uma má razão para abandonar o arranjo.

Mudar a ordem da cadeia muda a experiência

VPN primeiro e Tor depois é uma experiência diferente de Tor primeiro e VPN depois. No primeiro arranjo o ponto final da VPN transporta todo o circuito, por isso a sua rede de acesso só conhece o endereço da VPN. No segundo, a ligação VPN é ela própria transportada dentro do caminho em cebola, e a saída vê o tráfego VPN. Ambos são desenhos legítimos, e comparar qualquer deles com uma VPN nua mede outra coisa, razão pela qual a página do projeto Tor sobre combinar as duas o apresenta como uma pergunta sobre o que tenta esconder antes de ser uma pergunta sobre tempos.

Mantenha o dispositivo, a rede de acesso e o destino fixos, e mude exatamente um elemento entre execuções. Mover servidores, circuitos e hosts de teste ao mesmo tempo produz uma diferença que ninguém consegue atribuir. Anote o que cada arranjo esconde e de quem antes de o otimizar, porque uma cadeia rápida que expõe o que queria esconder não é uma melhoria.

Uma comparação que sobrevive a uma segunda execução

Escolha dois ou três destinos que realmente usa e cronometre a mesma interação em cada um, incluindo uma página que puxa muitos recursos pequenos e uma transferência grande. Repita todo o conjunto a outra hora do dia.

Relate a mediana e o pior caso em vez da amostra mais rápida, porque o trabalho interativo julga-se pelos seus maus momentos. Anote o cliente, o ponto final ou a saída, e se o circuito ou o túnel foi reutilizado nessa execução. Se uma alteração melhora a mediana mas piora a cauda, é uma troca e não uma vitória, e decidir se os utilizadores o vão notar é a decisão real.