O desempenho de um onion service se decide no servidor: para onde vão os milissegundos e o que o operador pode mesmo ajustar
Quando um site onion parece lento, o reflexo é culpar a rede Tor. Isso vale só até certo ponto. Um serviço oculto nunca conversa diretamente com os visitantes, e cada conexão é montada com retransmissores escolhidos pelos dois lados, mas uma fatia real da espera é fabricada na própria máquina do serviço, na forma como o Tor cuida dos encanamentos à frente do backend web. Saber qual metade é qual decide se o ajuste ajuda ou só empurra a culpa.
Para onde vão os milissegundos
A visão geral do protocolo do Projeto Tor conta uma conexão onion completa em seis retransmissores: três escolhidos pelo cliente, três pelo serviço, emendados num ponto de rendezvous que depois "apenas retransmite mensagens criptografadas de ponta a ponta do cliente para o serviço e vice-versa" (Projeto Tor, protocolo de serviços onion). Antes desse circuito existir, várias viagens de ida e volta já se foram: o cliente busca o descritor assinado do serviço numa tabela de espalhamento distribuída, constrói uma rota até um dos pontos de introdução e negocia o rendezvous. Nada disso é tempo de backend, mas tudo cai no cronômetro do visitante. O lado do serviço carrega ainda um custo permanente que nenhum cliente paga. Os pontos de introdução mantêm circuitos anônimos de longa duração vindos do serviço, e o manual do Tor fixa o pool padrão em três pontos de introdução, expansível a vinte num serviço v3. Como esses retransmissores são o único endereço do serviço, não podem sumir em silêncio: se um falha, o serviço precisa construir outro circuito de três saltos e republicar seu descritor assinado - trabalho que aparece em primeiras cargas mais frias e lentas.O que um operador realmente controla
O Tor expõe uma lista curta de ajustes, mais estreita do que o folclore de desempenho admite:- Folga criptográfica. Os handshakes que introduções e rendezvous geram são decifrados por um grupo de workers de criptografia; o manual descreve o NumCPUs como "quantos processos usar ao mesmo tempo para decifrar onionskins e outras operações paralelizáveis". Um serviço faminto por CPU fica lento exatamente onde o operador pode consertar.
- Tamanho do pool de introdução. O HiddenServiceNumIntroductionPoints vem com três por padrão; mais pontos de introdução distribuem as introduções por mais retransmissores, ao preço de mais circuitos permanentes.
- Frescor dos circuitos. O MaxCircuitDirtiness tem dez minutos por padrão, e o manual nota que, em serviços ocultos, a idade conta desde a última vez que o circuito carregou tráfego. Subir o valor reduz reconstruções; baixar troca mais builds por rotas mais novas.
- Software em dia. O controle de congestão chegou no Tor 0.4.7 em 2022, e o Projeto Tor foi direto: "usuários de Tor 0.4.7 ou superior terão desempenho melhor ao usar saídas ou onion services atualizados para 0.4.7" - um serviço numa versão mais velha prende todos os visitantes no controle de fluxo antigo (blog do Projeto Tor).
A tentação do salto único
O debate de desempenho mais antigo deste canto do Tor é se o serviço precisa mesmo de três saltos de proteção. A Proposal 260, redigida em 2015 por um grupo que inclui Roger Dingledine e Paul Syverson e implementada no Tor 0.2.9.3-alpha, descreve "rendezvous single onion services" que "trocam a privacidade de localização do lado do serviço por melhor desempenho, confiabilidade e escalabilidade", com circuitos de um salto até os pontos de introdução e rendezvous e uma rota cortada para "4 em vez de 6" retransmissores. A chave continua existindo: o HiddenServiceSingleHopMode é documentado como experimental e não anônimo; deixa o servidor "facilmente localizável" enquanto "os clientes seguem anônimos". A troca é sem rodeios. Um single onion mantém o endereço .onion e o anonimato dos visitantes, mas entrega o esconderijo do próprio operador - e os autores da proposal avisaram que cada sabor adicional de onion service "divide o conjunto de anonimato". Por isso o design padrão sobrevive: o salto único fica como ferramenta opcional para operadores que aceitam exposição, um julgamento que o Tor deixa deliberadamente fora do protocolo.Por que serviços grandes rodam backends afinados
Propriedades onion de longa vida - buscadores, espelhos, diretórios - convergem para a mesma forma: frontends Tor finos, backends de propósito estáticos ou em cache, e carga espalhada entre instâncias. A Proposal 260 observa até que um rendezvous single onion service "pode balancear carga entre múltiplos rendezvous backends". Nada disso encurta a rota; minimiza o único segmento que o operador possui, para que a viagem de seis retransmissores seja a única espera relevante. O Tor Metrics mede o tráfego onion extrapolando de estatísticas de retransmissores que atuam como pontos de rendezvous - essa camada é literalmente onde vive a carga visível (Tor Metrics).O que dá para consertar e o que não dá
"Como os caminhos dos serviços onion são mais que o dobro do comprimento dos caminhos de saída (e portanto mais que o dobro da latência de circuito), o rendimento de um onion service sempre será menor que metade do rendimento de uma saída" (Proposal 324).O operador pode consertar folga criptográfica, tamanho do pool, versão do software e peso do backend. Não pode consertar o comprimento da rota, os tempos de construção de circuito do dia, a congestão dos retransmissores nem a rotação de guards do cliente. A leitura honesta: uma primeira carga sem cache que leva segundos não é um site quebrado - é descritor, introdução e rendezvous pagos à vista - enquanto pedidos num circuito quente devem ficar perto do próprio tempo de resposta do backend mais o trânsito. Se um serviço continua lento depois da primeira página, o operador provavelmente tem espaço para agir. Se só parece lento nos picos da meia-noite, o turno é da rede, não do backend - o padrão documentado nas nossas notas de campo sobre variância de latência onion. Do lado do servidor os ganhos são reais, porém limitados: ajuste o que o torrc controla, mantenha a origem leve e pare de esperar uma rota mais curta do que o protocolo permite.