Perché due test di velocità VPN sullo stesso tunnel non coincidono

Due esecuzioni, un solo tunnel, e i numeri differiscono di un fattore tre. Il tunnel non è cambiato tra le due. Quello che è cambiato è la misura: un sito di test che sceglie un server in base alla tua posizione apparente, un numero di flussi che decide se un avvio lento o sei riempiono il tubo, e una durata abbastanza breve da finire prima che il percorso venga usato davvero. I test di velocità non sono sbagliati, ma rispondono a una domanda più stretta di quella che la gente pone loro.

Un nuovo indirizzo di uscita cambia la destinazione del test

La maggior parte dei siti di test sceglie automaticamente un server di misura, e lo sceglie in parte guardando da dove sembra arrivare la tua connessione. Attiva il tunnel e il tuo paese apparente cambia, quindi il server scelto cambia, e il confronto ora copre due percorsi diversi verso due host diversi.

Il risultato non è affatto una misura della VPN. È una misura del tuo percorso verso un server che non hai scelto, e la differenza tra le due esecuzioni può essere dominata dal peering di quel server più che da qualsiasi cosa abbia fatto il tunnel.

Fissa la destinazione prima di cambiare qualsiasi altra cosa. Ogni strumento credibile ti lascia scegliere un server in modo esplicito, e quando non lo fa, la pagina dei risultati di solito nomina quello usato, il che basta per notare che le due esecuzioni non sono confrontabili. Verifica cosa ha visto il sito prima di fidarti della sua scelta:

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

Se il paese è cambiato tra le esecuzioni, è cambiato anche tutto ciò che il test ha scelto dopo. Annota l'uscita osservata accanto a ogni risultato e la confusione in gran parte scompare.

L'avvio lento termina dopo la fine della maggior parte dei test brevi

Una connessione TCP non parte alla velocità del collegamento. Parte con una piccola finestra di congestione, la raddoppia più o meno a ogni andata e ritorno, e raggiunge la capacità del percorso solo dopo diversi giri. Un test di dieci secondi su un percorso ad alta latenza può passare una parte sostanziale della sua vita in quella salita.

Per questo un tunnel con più latenza segna peggio in un test breve di quanto meriti, e per questo un'esecuzione più lunga riporta spesso un numero più alto senza alcun cambio di configurazione. Il quadro di throughput RFC 6349 lo tratta esplicitamente, ed è per questo che le misure serie durano abbastanza da raggiungere uno stato stazionario. Un'esecuzione di cinque secondi su un percorso satellitare misura l'acceleratore, non la strada.

Guarda le fasi della connessione invece di fidarti di un solo numero. Curl riporta ogni fase separatamente, così puoi vedere se il tempo va nell'handshake, nella salita o nel trasferimento:

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

Eseguilo due volte di seguito verso la stessa destinazione. Se la seconda esecuzione è molto più veloce, stavi misurando la salita, non il percorso, e qualsiasi confronto che abbia usato solo la prima è sospetto.

Un flusso e sei flussi misurano cose diverse

Un singolo flusso TCP è limitato dalla finestra che riesce a tenere in volo, cioè all'incirca il tempo di andata e ritorno moltiplicato per la velocità. Su un percorso lungo quel prodotto supera ciò che userà un flusso, quindi un singolo download sottostima la capacità che esiste. Sei flussi paralleli colmano il divario e producono un numero più grande.

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

Entrambi i numeri sono veri. Il numero del singolo flusso dice cosa farà un download, che è ciò che di solito ottiene una scheda del browser. Il numero parallelo dice cosa può portare il percorso nel complesso, che è ciò che può sfruttare un torrent o un download in più parti. Citare l'uno come se fosse l'altro è il modo in cui un tunnel sano viene sostituito senza motivo.

Confrontare un risultato parallelo con un risultato a flusso singolo è il modo più comune in cui la gente conclude che una VPN ha dimezzato la velocità. Allinea il metodo, poi confronta. La traccia del terzo comando aggiunge il contesto mancante: un percorso con jitter alto darà risultati incoerenti in entrambe le modalità, e nessun numero di flussi lo risolve.

La cifratura costa tempo di CPU, l'incapsulamento costa byte

Due meccanismi agiscono su ogni pacchetto, indipendentemente da quanto è veloce il collegamento. La cifratura consuma CPU per byte, e l'incapsulamento aggiunge byte di intestazione che il collegamento deve comunque trasportare. Entrambi si presentano come un tetto, e hanno sintomi diversi.

Il tetto della CPU appare come un altopiano: il throughput smette di salire per quanti flussi aggiungi, e il processore della macchina è occupato mentre il collegamento non lo è. Su un piccolo router o un telefono è spesso il limite reale, ed è per questo che una linea veloce può comunque dare un tunnel modesto.

Il costo in byte è minore ma costante. Intestazioni extra significano meno carico utile per pacchetto, e su un percorso con unità massima di trasmissione fissa possono anche innescare frammentazione o buco nero che si manifesta come uno stallo sui trasferimenti grandi anziché come una media lenta.

Questi tre vengono spesso confusi perché gli utenti li descrivono tutti come «la VPN è lenta». Solo il primo reagisce a una macchina più grande, solo il secondo reagisce a una MTU più piccola, e solo il terzo reagisce alla gestione delle code.

Metti il metodo nel verbale

Un risultato che vale la pena conservare nomina il dispositivo, la rete di accesso, l'uscita, il server di misura, la direzione, il numero di flussi e la durata. Senza questi, due numeri non si possono confrontare, e un ticket che contiene un solo numero è in realtà un umore.

Conserva anche le esecuzioni cattive. Una serie in cui un'uscita provoca uno stallo ogni volta è molto più informativa di una media, e gli stalli sono esattamente ciò che le medie nascondono.

Poi prova ciò che ti interessa davvero. Se l'obiettivo è un download grande, scarica il file. Se l'obiettivo è una chiamata, misura la latenza sotto carico invece del throughput a riposo, perché un tunnel può segnare bene in un test di velocità e rendere comunque ogni riunione inascoltabile.