Una transferencia que se arrastra por la conexión de la oficina a veces termina rápido a través del túnel, y la encapsulación extra hace que eso parezca imposible. La aparente paradoja viene de comparar las cosas equivocadas. El túnel añade trabajo y también cambia qué ruta de red sigue el tráfico, qué dirección ve el destino y a veces qué servidor responde siquiera. Elegir entre las dos rutas exige separar esos tres efectos antes de cualquier conclusión sobre la velocidad.

Tres cosas que el túnel puede cambiar

La primera es el tránsito. El enrutamiento de Internet sigue la política del operador y las relaciones comerciales, no la latencia medida, así que el camino a través de un proveedor de VPN puede cruzar redes distintas de la ruta directa. Puede evitar un intercambio congestionado o aterrizar en uno mejor conectado, y con la misma facilidad puede ser peor.

La segunda es el destino. Un cambio de dirección de salida a menudo cambia la respuesta DNS, y una red de contenido puede darte otra caché u otra región. Entonces parte de la mejora pertenece al servidor nuevo y no al túnel. El mismo nombre de host puede aterrizar en un servidor más cercano o menos cargado sin que cambie nada en el cliente.

La tercera es el comportamiento del transporte. La encapsulación cambia el tamaño efectivo del paquete, y un túnel que evita un segmento intermedio con pérdidas puede dejar que un flujo TCP agrande su ventana en lugar de retroceder una y otra vez. Nada de esto es un mecanismo universal de aceleración; cada uno es una condición que debe observarse. Separarlos es lo que convierte una curiosidad en un hecho.

Qué no puede cambiar

Nada en el túnel añade capacidad al enlace entre el dispositivo y la red. Un canal Wi-Fi saturado, una última milla congestionada o un plan móvil limitado limitan ambas rutas por igual, y una prueba de velocidad a través del túnel no puede superar ese techo. El mismo enlace transporta los paquetes encapsulados, así que la encapsulación puede gastar capacidad pero nunca crearla. Lo que cambia es adónde van los paquetes después de salir de ese enlace. Por eso un resultado rápido del túnel siempre tiene una explicación aguas arriba del primer salto.

Los límites del lado del servidor son igual de indiferentes. Si el host remoto sirve despacio, una ruta mejor solo entrega la respuesta lenta con más eficiencia, y el usuario sigue esperando. Un origen compartido bajo carga se ve lento en ambas rutas en el mismo momento.

Compare las rutas correctamente

Mantenga idénticos la aplicación, la dirección, la duración y la concurrencia, y cambie solo la ruta. Ejecute cada prueba más de una vez, a la misma hora del día, y anote la dirección de salida y la respuesta del resolutor junto al rendimiento. Una ejecución es una muestra y no una medición, y una sola descarga rápida puede ser un acierto de caché que no dice nada sobre la ruta. Escriba las condiciones antes de los resultados, porque los números son difíciles de interpretar después.

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

La respuesta del resolutor es el detalle que la mayoría de las comparaciones omite, y explica las «mejoras» que desaparecen cuando se fuerza el mismo servidor. Si la dirección difiere entre ejecuciones, la prueba comparó dos destinos en lugar de dos rutas. Informe de la latencia y la pérdida junto al rendimiento, porque una ruta más rápida en conjunto pero que añade retardo a cada petición interactiva no es mejor para la carga de trabajo que se quejó. El tiempo de ida y vuelta importa más que la velocidad masiva para cualquier cosa que pregunta y espera.

Cuándo merece conservarse la diferencia

Si un túnel aprobado mejora de forma fiable una carga de trabajo concreta, es una elección operativa legítima: documente la carga, la medición y la salida utilizada. Un registro útil nombra un solo host, la dirección de salida que produjo el túnel, la respuesta del resolutor y las mismas cifras de la ruta directa el mismo día. Eso basta para que el siguiente ingeniero repita la comparación en lugar de volver a discutirla. Sigue sin ser prueba de que el proveedor limite algo, y no se traslada a otras aplicaciones ni a otras horas.

Guarde el registro de la medición con la configuración. Responde a la siguiente pregunta sobre si la mejora sigue existiendo, que es la única forma de saber si cambió la ruta o la carga de trabajo. Un registro sin fecha no puede responder esa pregunta en absoluto.

Artículos relacionados