Por qué dos pruebas de velocidad VPN en el mismo túnel no coinciden

Dos ejecuciones, un túnel, y los números difieren en un factor de tres. El túnel no cambió entre ellas. Lo que cambió es la medición: un sitio de pruebas que elige un servidor según tu ubicación aparente, un número de flujos que decide si un inicio lento o seis llenan la tubería, y una duración lo bastante corta para terminar antes de que la ruta empiece a usarse correctamente. Las pruebas de velocidad no son erróneas, pero responden a una pregunta más estrecha que la que la gente les hace.

Una dirección de salida nueva cambia el destino de la prueba

La mayoría de los sitios de pruebas eligen un servidor de medición automáticamente, y lo eligen en parte mirando de dónde parece venir tu conexión. Activa el túnel y tu país aparente cambia, así que el servidor elegido cambia, y la comparación ahora abarca dos rutas distintas hacia dos hosts distintos.

El resultado no es en absoluto una medición de la VPN. Es una medición de tu ruta hacia un servidor que no elegiste, y la diferencia entre las dos ejecuciones puede estar dominada por el peering de ese servidor y no por nada que hiciera el túnel.

Fija el destino antes de cambiar cualquier otra cosa. Toda herramienta creíble te permite elegir un servidor de forma explícita, y cuando no lo hace, la página de resultados suele nombrar el que usó, lo que basta para notar que las dos ejecuciones no son comparables. Confirma qué vio el sitio antes de confiar en la elección que hizo:

curl -sS https://ipinfo.io/json | grep -E '"ip"|"org"|"country"'

Si el país cambió entre ejecuciones, todo lo que la prueba eligió después también cambió. Anota la salida observada junto a cada resultado y la confusión desaparece en su mayor parte.

El inicio lento termina después de que acaben la mayoría de las pruebas cortas

Una conexión TCP no empieza a la velocidad del enlace. Empieza con una ventana de congestión pequeña, la duplica más o menos en cada viaje de ida y vuelta, y solo alcanza la capacidad de la ruta tras varios viajes. Una prueba de diez segundos en una ruta con latencia alta puede pasar una parte sustancial de su vida en ese ascenso.

Por eso un túnel con más latencia puntúa peor en una prueba corta de lo que merece, y por eso una ejecución más larga suele informar de un número más alto sin ningún cambio de configuración. El marco de rendimiento RFC 6349 lo trata de forma explícita, y por eso las mediciones serias duran lo suficiente para alcanzar un estado estable. Una ejecución de cinco segundos en una ruta por satélite mide el acelerador, no la carretera.

Mira las fases de la conexión en lugar de fiarte de un solo número. Curl informa de cada etapa por separado, así que puedes ver si el tiempo se va en el saludo, en el ascenso o en la transferencia:

curl -sS -o /dev/null -w 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} total=%{time_total} bytes/s=%{speed_download}\n' \
  https://mirror.example.net/testfile.bin

Ejecútalo dos veces seguidas hacia el mismo destino. Si la segunda ejecución es mucho más rápida, estabas midiendo el ascenso, no la ruta, y cualquier comparación que usara solo la primera es sospechosa.

Un flujo y seis flujos miden cosas distintas

Un solo flujo TCP está limitado por la ventana que puede mantener en vuelo, que es aproximadamente el tiempo de ida y vuelta multiplicado por la tasa. En una ruta larga ese producto supera lo que usará un flujo, así que una sola descarga informa por debajo de la capacidad que existe. Seis flujos en paralelo llenan el hueco y producen un número mayor.

iperf3 -c speed.example.net -t 20
iperf3 -c speed.example.net -t 20 -P 6
mtr -rwc 50 speed.example.net

Ambos números son ciertos. La cifra de un solo flujo dice qué hará una descarga, que es lo que suele obtener una pestaña del navegador. La cifra paralela dice qué puede llevar la ruta en conjunto, que es lo que puede aprovechar un torrent o una descarga por partes. Citar una como si fuera la otra es como se sustituye un túnel sano sin motivo.

Comparar un resultado paralelo con un resultado de un solo flujo es la forma más habitual en que la gente concluye que la VPN le ha reducido la velocidad a la mitad. Iguala el método y luego compara. El rastro del tercer comando añade el contexto que falta: una ruta con jitter alto dará resultados inconsistentes en ambos modos, y ningún número de flujos lo arregla.

El cifrado cuesta tiempo de procesador, la encapsulación cuesta bytes

Dos mecanismos se ejecutan en cada paquete sin importar lo rápida que sea el enlace. El cifrado consume CPU por byte, y la encapsulación añade bytes de cabecera que el enlace todavía debe transportar. Ambos aparecen como un techo, y tienen síntomas distintos.

El techo de la CPU aparece como una meseta: el rendimiento deja de subir por muchos flujos que añadas, y el procesador de la máquina está ocupado mientras el enlace no lo está. En un router pequeño o un teléfono ese suele ser el límite real, y por eso una línea rápida puede seguir dando un túnel modesto.

El coste en bytes es menor pero constante. Las cabeceras extra significan menos carga útil por paquete, y en una ruta con una unidad máxima de transmisión fija también pueden provocar fragmentación o agujero negro que se muestra como un atasco en transferencias grandes en lugar de como un promedio lento.

Estos tres se confunden a menudo porque los usuarios describen los tres como «la VPN va lenta». Solo el primero responde a una máquina más grande, solo el segundo responde a una MTU más pequeña, y solo el tercero responde a la gestión de colas.

Pon el método en el registro

Un resultado que merece conservarse nombra el dispositivo, la red de acceso, la salida, el servidor de medición, la dirección, el número de flujos y la duración. Sin eso, dos números no se pueden comparar, y un ticket que contiene un solo número es en realidad un estado de ánimo.

Guarda también las ejecuciones malas. Una serie en la que una salida produce un atasco cada vez es mucho más informativa que un promedio, y los atascos son exactamente lo que los promedios esconden.

Luego prueba lo que de verdad te importa. Si el objetivo es una descarga grande, descarga el archivo. Si el objetivo es una llamada, mide la latencia bajo carga en lugar del rendimiento en reposo, porque un túnel puede puntuar bien en una prueba de velocidad y aun así hacer que cada reunión sea inescuchable.