Por que dúas probas de velocidade VPN no mesmo túnel non coinciden

Dúas execucións, un túnel, e os números difiren nun factor de tres. O túnel non cambiou entre elas. O que cambiou é a medición: un sitio de probas que escolle un servidor segundo a túa localización aparente, un número de fluxos que decide se un inicio lento ou seis enchen a tubaxe, e unha duración o bastante curta para rematar antes de que a ruta comece a usarse correctamente. As probas de velocidade non son erróneas, pero responden a unha pregunta máis estreita que a que a xente lles fai.

Un enderezo de saída novo cambia o destino da proba

A maioría dos sitios de probas escollen un servidor de medición automaticamente, e escolléneo en parte mirando de onde parece vir a túa conexión. Activa o túnel e o teu país aparente cambia, así que o servidor escollido cambia, e a comparación agora abrangue dúas rutas distintas cara a dous hosts distintos.

O resultado non é en absoluto unha medición da VPN. É unha medición da túa ruta cara a un servidor que non escolliches, e a diferenza entre as dúas execucións pode estar dominada polo peering dese servidor e non por nada que fixese o túnel.

Fixa o destino antes de cambiar calquera outra cousa. Toda ferramenta crible permíteche escoller un servidor de forma explícita, e cando non o fai, a páxina de resultados adoita nomear o que usou, o que abonda para notar que as dúas execucións non son comparables. Confirma que viu o sitio antes de confiar na escolla que fixo:

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

Se o país cambiou entre execucións, todo o que a proba escolleu despois tamén cambiou. Anota a saída observada xunto a cada resultado e a confusión desaparece na súa maior parte.

O inicio lento remata despois de que rematen a maioría das probas curtas

Unha conexión TCP non comeza á velocidade da ligazón. Comeza cunha xanela de conxestión pequena, duplícaa máis ou menos en cada viaxe de ida e volta, e só alcanza a capacidade da ruta tras varios viaxes. Unha proba de dez segundos nunha ruta con latencia alta pode pasar unha parte substancial da súa vida nese ascenso.

Por iso un túnel con máis latencia puntúa peor nunha proba curta do que merece, e por iso unha execución máis longa adoita informar dun número máis alto sen ningún cambio de configuración. O marco de rendemento RFC 6349 trátao de forma explícita, e por iso as medicións serias duran o suficiente para alcanzar un estado estable. Unha execución de cinco segundos nunha ruta por satélite mide o acelerador, non a estrada.

Mira as fases da conexión en lugar de confiar nun só número. Curl informa de cada etapa por separado, así que podes ver se o tempo vai no saúdo, no ascenso ou na 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

Execútao dúas veces seguidas cara ao mesmo destino. Se a segunda execución é moito máis rápida, estabas medindo o ascenso, non a ruta, e calquera comparación que usase só a primeira é sospeitosa.

Un fluxo e seis fluxos miden cousas distintas

Un só fluxo TCP está limitado pola xanela que pode manter en voo, que é aproximadamente o tempo de ida e volta multiplicado pola taxa. Nunha ruta longa ese produto supera o que usará un fluxo, así que unha soa descarga informa por baixo da capacidade que existe. Seis fluxos en paralelo enchen o oco e producen un número maior.

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 certos. A cifra dun só fluxo di que fará unha descarga, que é o que adoita obter unha lapela do navegador. A cifra paralela di que pode levar a ruta en conxunto, que é o que pode aproveitar un torrent ou unha descarga por partes. Citar unha como se fose a outra é como se substitúe un túnel san sen motivo.

Comparar un resultado paralelo cun resultado dun só fluxo é a forma máis habitual en que a xente conclúe que a VPN lle reduciu a velocidade á metade. Iguala o método e logo compara. O rastro do terceiro comando engade o contexto que falta: unha ruta con jitter alto dará resultados inconsistentes en ambos modos, e ningún número de fluxos o arranxa.

O cifrado custa tempo de procesador, a encapsulación custa bytes

Dous mecanismos execútanse en cada paquete independentemente do rápido que sexa a ligazón. O cifrado consome CPU por byte, e a encapsulación engade bytes de cabeceira que a ligazón aínda debe transportar. Ambos aparecen como un teito, e teñen síntomas distintos.

O teito da CPU aparece como unha meseta: o rendemento deixa de subir por moitos fluxos que engadas, e o procesador da máquina está ocupado mentres a ligazón non o está. Nun router pequeno ou un teléfono ese adoita ser o límite real, e por iso unha liña rápida pode seguir dando un túnel modesto.

O custo en bytes é menor pero constante. As cabeceiras extra significan menos carga útil por paquete, e nunha ruta cunha unidade máxima de transmisión fixa tamén poden provocar fragmentación ou burato negro que se mostra como un atasco en transferencias grandes en lugar de como unha media lenta.

Estes tres confúndense a miúdo porque os usuarios describen os tres como «a VPN vai lenta». Só o primeiro responde a unha máquina máis grande, só o segundo responde a unha MTU máis pequena, e só o terceiro responde á xestión de colas.

Pon o método no rexistro

Un resultado que merece conservarse nomea o dispositivo, a rede de acceso, a saída, o servidor de medición, a dirección, o número de fluxos e a duración. Sen iso, dous números non se poden comparar, e un ticket que contén un só número é en realidade un estado de ánimo.

Garda tamén as execucións malas. Unha serie na que unha saída produce un atasco cada vez é moito máis informativa ca unha media, e os atascos son exactamente o que as medias agochan.

Despois proba o que de verdade che importa. Se o obxectivo é unha descarga grande, descarga o ficheiro. Se o obxectivo é unha chamada, mide a latencia baixo carga en lugar do rendemento en repouso, porque un túnel pode puntuar ben nunha proba de velocidade e aínda así facer que cada reunión sexa inescoitable.