Por qué Tor parece más lento que una VPN: clics frente a descargas

Las páginas que se sienten pegajosas mientras las descargas van a ritmo normal describen viajes de ida y vuelta, no ancho de banda. Una VPN añade un salto cifrado y un circuito de Tor añade varios, y cada salto extra cuesta un handshake antes de que se mueva un solo byte útil. Ese coste se nota en una página que abre muchas conexiones cortas y casi desaparece en una única transferencia grande. Una vez que el patrón es visible, la discusión deja de ser sobre qué herramienta es más rápida.

El síntoma apunta al coste de configuración, no a la capacidad

Cargar una página es una cadena de intercambios dependientes: una búsqueda de nombre, un handshake de transporte, un handshake TLS y luego la primera petición. Cada salto del camino inserta su propio viaje de ida y vuelta en esa cadena antes de que se dibuje nada. Una descarga grande paga el mismo coste de configuración una vez y luego fluye, y por eso mismo las dos cargas de trabajo no coinciden.

Lee en el panel de red el tiempo de espera antes del primer byte, no el total. Una espera larga con una descarga corta de contenido apunta a viajes de ida y vuelta, mientras que una descarga larga con una espera corta apunta al rendimiento. Repite contra un segundo destino, porque un solo host detrás de un relé ocupado no demuestra nada. Cuando la transferencia va bien y el clic es lento, sospecha del coste de configuración mucho antes que del ancho de banda.

La latencia y la capacidad fallan de formas distintas

Toma dos lecturas y la mayor parte de la confusión se resuelve sola. La latencia es un coste fijo por intercambio y la capacidad es una tasa a lo largo del tiempo, así que un camino puede ser bueno en la primera y malo en la segunda. Un punto final lejano con un procesador inactivo responde rápido a una petición pequeña y aun así limita una transferencia sostenida a lo que permite su enlace ascendente. Los usuarios viven esa separación como un clic ágil seguido de una barra de progreso que apenas se mueve.

Prueba la capacidad con una transferencia sostenida y observa si la tasa se mantiene estable o hace sierra. Prueba la latencia con una petición pequeña repetida muchas veces y lee la dispersión en lugar de la mejor muestra, porque una dispersión amplia se siente peor de lo que sugiere su media. Anota ambos números antes y después de cada cambio, o luego atribuirás el mérito a la variable equivocada.

Tratar las dos como un solo número produce correcciones que nunca mueven la medición que te importa. Es la forma más común de que una queja de latencia reciba como respuesta una mejora de ancho de banda.

El enrutamiento en cebolla añade saltos que no elegiste

Un circuito de Tor suele usar tres relés —un guardián, un nodo medio y una salida— y el cliente los elige de un consenso, no de un mapa. Por eso el camino puede ser mucho más largo que la línea directa hasta el destino. Cada relé también transporta el tráfico de otras personas, así que tu flujo comparte la capacidad que le quede a ese relé.

Reutilizar el circuito suaviza el coste, porque un flujo nuevo puede viajar sobre un circuito existente en lugar de pagar otra construcción. Un cliente que construye un circuito nuevo por petición paga la configuración una y otra vez y se siente mucho peor que uno que reutiliza. La elección de salida también importa, porque algunas salidas llevan más carga y nada en la interfaz te dice en cuál has aterrizado. Esa compartición es el sentido del diseño y la razón por la que la latencia no se puede ajustar a un valor fijo, así que una salida lenta es una mala razón para abandonar la disposición.

Cambiar el orden de la cadena cambia el experimento

VPN primero y Tor después es un experimento distinto de Tor primero y VPN después. En la primera disposición el punto final de la VPN transporta todo el circuito, así que tu red de acceso solo conoce la dirección de la VPN. En la segunda, la conexión VPN viaja dentro del camino de cebolla y la salida ve el tráfico de la VPN. Ambos son diseños legítimos, y comparar cualquiera de ellos con una VPN desnuda mide otra cosa, por eso la página del proyecto Tor sobre combinar las dos lo plantea como una pregunta sobre qué intentas ocultar antes que como una pregunta sobre tiempos.

Mantén fijos el dispositivo, la red de acceso y el destino, y cambia exactamente un elemento entre ejecuciones. Mover servidores, circuitos y hosts de prueba a la vez produce una diferencia que nadie puede atribuir. Anota qué oculta cada disposición y ante quién antes de optimizarla, porque una cadena rápida que expone lo que querías ocultar no es una mejora.

Una comparación que sobrevive a una segunda ejecución

Elige dos o tres destinos que realmente uses y cronometra la misma interacción en cada uno, incluida una página que atrae muchos recursos pequeños y una transferencia grande. Repite todo el conjunto a otra hora del día.

Informa de la mediana y del peor caso en lugar de la muestra más rápida, porque el trabajo interactivo se juzga por sus malos momentos. Anota el cliente, el punto final o la salida, y si el circuito o el túnel se reutilizaron en esa ejecución. Si un cambio mejora la mediana pero empeora la cola, es un intercambio y no una victoria, y decidir si los usuarios lo notarán es la decisión real.