El rendimiento de un onion service se decide en el servidor: a dónde van los milisegundos y qué puede ajustar un operador
Cuando un sitio onion parece lento, el reflejo es culpar a la red Tor. Eso es justo solo hasta cierto punto. Un servicio oculto nunca habla directamente con los visitantes, y cada conexión se ensambla con relés elegidos por ambas partes, pero una parte real de la espera se fabrica en la propia máquina del servicio, en cómo Tor mantiene las tuberías frente al backend web. Saber qué mitad es cuál decide si el ajuste ayuda o solo traslada la culpa.
A dónde van los milisegundos
La descripción del protocolo del Proyecto Tor cuenta una conexión onion completa en seis relés: tres elegidos por el cliente, tres por el servicio, empalmados en un punto de rendezvous que luego "simplemente retransmite mensajes cifrados de extremo a extremo del cliente al servicio y viceversa" (Tor Project, protocolo de servicios onion). Antes de que exista ese circuito ya se han gastado varios viajes de ida y vuelta: el cliente descarga el descriptor firmado del servicio desde una tabla hash distribuida, construye una ruta hacia uno de sus puntos de introducción y negocia el rendezvous. Nada de eso es tiempo del backend, pero todo aparece en el cronómetro del visitante. El lado del servicio también carga un coste permanente que ningún cliente paga. Los puntos de introducción mantienen circuitos anónimos de larga duración desde el servicio, y el manual de Tor fija el grupo por defecto en tres puntos de introducción, ampliable a veinte en un servicio v3. Como esos relés son la única dirección del servicio, no pueden desaparecer en silencio: si uno falla, el servicio debe construir otro circuito de tres saltos y volver a publicar su descriptor firmado, un trabajo que se nota en primeras cargas más frías y lentas.Qué controla realmente un operador
Tor ofrece una lista corta de ajustes, más estrecha de lo que admite el folclore del rendimiento:- Margen criptográfico. Los handshakes que generan las introducciones y el rendezvous los descifra un grupo de trabajadores criptográficos; el manual describe NumCPUs como "cuántos procesos usar a la vez para descifrar onionskins y otras operaciones paralelizables". Un servicio con la CPU ahogada se siente lento exactamente donde un operador puede arreglarlo.
- Tamaño del grupo de introducción. HiddenServiceNumIntroductionPoints viene con tres por defecto; más puntos de introducción reparten las introducciones entre más relés, al precio de más circuitos permanentes.
- Frescura de circuitos. MaxCircuitDirtiness es de diez minutos por defecto, y el manual apunta que en los servicios ocultos la edad cuenta desde la última vez que el circuito llevó tráfico. Subirla reduce reconstrucciones; bajarla cambia más builds por rutas más frescas.
- Software al día. El control de congestión llegó con Tor 0.4.7 en 2022, y el Proyecto Tor fue tajante: "los usuarios de Tor 0.4.7 o superior notarán más rapidez al usar salidas u onion services que se hayan actualizado a 0.4.7" - un servicio en una versión anterior limita a todos sus visitantes al control de flujo heredado (blog del Proyecto Tor).
La tentación del salto único
El debate de rendimiento más antiguo de esta esquina de Tor es si el servicio necesita tres saltos de protección. La Propuesta 260, redactada en 2015 por un grupo que incluye a Roger Dingledine y Paul Syverson e implementada en Tor 0.2.9.3-alpha, describe "rendezvous single onion services" que "canjean la privacidad de localización del lado del servicio por mejor rendimiento, fiabilidad y escalabilidad", con circuitos de un salto hacia los puntos de introducción y rendezvous y una ruta recortada a "4 en lugar de 6" relés. El interruptor sigue existiendo: HiddenServiceSingleHopMode figura como experimental y no anónimo; deja al servidor "fácilmente localizable" mientras "los clientes conservan el anonimato". El intercambio es sin adjetivos. Un single onion conserva su dirección .onion y el anonimato de sus visitantes, pero renuncia a ocultar la localización del operador - y los autores de la propuesta advirtieron de que cada sabor adicional de onion service "divide el conjunto de anonimato". Por eso sobrevive el diseño por defecto: el salto único queda como herramienta opcional para operadores que pueden aceptar exposición, un juicio que Tor deja deliberadamente fuera del protocolo.Por qué las grandes propiedades usan backends afinados
Las propiedades onion de larga vida - buscadores, espejos, directorios - convergen en la misma forma: frontales Tor delgados, backends estáticos o cacheados a propósito, y carga repartida entre instancias. La Propuesta 260 incluso señala que un servicio rendezvous single onion "puede balancear carga entre múltiples rendezvous backends". Nada de eso acorta la ruta; minimiza el único segmento que el operador posee para que el viaje de seis relés sea la única espera relevante. Tor Metrics mide el tráfico onion extrapolando de estadísticas de relés que actúan como puntos de rendezvous - ese nivel es literalmente donde vive la carga visible (Tor Metrics).Qué se puede arreglar y qué no
"Como las rutas de los servicios onion son más del doble de largas que las rutas de salida (y por tanto más del doble de latencia de circuito), el rendimiento de un onion service siempre será menor de la mitad del de una salida" (Propuesta 324).Un operador puede arreglar el margen criptográfico, el tamaño del grupo, el software y el peso del backend. No puede arreglar la longitud de la ruta, los tiempos de construcción del circuito de ese día, la congestión de los relés ni la rotación de guards del cliente. La lectura honesta: una primera carga sin caché que tarda segundos no es un sitio roto - es descriptor, introducción y rendezvous pagados a tope - mientras que las peticiones sobre un circuito caliente deberían acercarse al tiempo de respuesta del propio backend más el tránsito. Si un servicio sigue lento tras la primera página, el operador casi seguro tiene margen de actuación. Si solo se siente lento en los picos de medianoche, el turno es de la red, no del backend - el patrón que documentaron nuestras notas de campo sobre la varianza de latencia onion. En el lado del servidor las ganancias son reales pero acotadas: ajusta lo que la torrc controla, mantén el origen ligero y deja de esperar una ruta más corta de lo que el protocolo permite.