Una VPN può essere più veloce della connessione diretta?

Un trasferimento che striscia sulla connessione dell'ufficio a volte termina in fretta attraverso il tunnel, e l'incapsulamento extra fa sembrare impossibile tutto ciò. L'apparente paradosso nasce dal confronto delle cose sbagliate. Il tunnel aggiunge lavoro, e cambia anche quale percorso di rete segue il traffico, quale indirizzo vede la destinazione e talvolta quale server risponde. Scegliere tra le due rotte richiede di separare questi tre effetti prima di qualsiasi conclusione sulla velocità.

Tre cose che il tunnel può cambiare

La prima è il transito. L'instradamento di Internet segue la politica dell'operatore e i rapporti commerciali, non la latenza misurata, quindi il percorso attraverso un fornitore VPN può attraversare reti diverse dalla rotta diretta. Può evitare uno scambio congestionato o atterrare su uno meglio collegato, e con la stessa facilità può essere peggiore.

La seconda è la destinazione. Un cambio di indirizzo di uscita spesso cambia la risposta DNS, e una rete di contenuti può darti un'altra cache o un'altra regione. Allora parte del miglioramento appartiene al nuovo server e non al tunnel. Lo stesso nome host può atterrare su un server più vicino o meno carico senza che nulla cambi sul client.

La terza è il comportamento del trasporto. L'incapsulamento cambia la dimensione effettiva dei pacchetti, e un tunnel che evita un segmento intermedio con perdite può lasciare che un flusso TCP aumenti la sua finestra invece di arretrare ripetutamente. Nessuno di questi è un meccanismo universale di accelerazione; ciascuno è una condizione da osservare. Separarli è ciò che trasforma una curiosità in un fatto.

Ciò che non può cambiare

Nulla nel tunnel aggiunge capacità al collegamento tra il dispositivo e la rete. Un canale Wi-Fi saturo, un ultimo miglio congestionato o un piano mobile limitato limitano entrambi i percorsi allo stesso modo, e un test di velocità attraverso il tunnel non può superare quel tetto. Lo stesso collegamento trasporta i pacchetti incapsulati, quindi l'incapsulamento può consumare capacità ma mai crearla. Ciò che cambia è dove vanno i pacchetti dopo aver lasciato quel collegamento. Per questo un risultato veloce del tunnel ha sempre una spiegazione a monte del primo salto.

I limiti lato server sono altrettanto indifferenti. Se l'host remoto serve lentamente, un percorso migliore consegna solo la risposta lenta in modo più efficiente, e l'utente aspetta ancora. Un'origine condivisa sotto carico appare lenta su entrambi i percorsi nello stesso momento.

Confrontate i percorsi correttamente

Mantenete identici applicazione, direzione, durata e concorrenza, e cambiate solo il percorso. Eseguite ogni test più di una volta, alla stessa ora del giorno, e annotate l'indirizzo di uscita e la risposta del resolver accanto al throughput. Una singola esecuzione è un campione e non una misura, e un singolo download veloce può essere un successo di cache che non dice nulla sulla rotta. Scrivete le condizioni prima dei risultati, perché i numeri sono difficili da interpretare dopo.

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 risposta del resolver è il dettaglio che la maggior parte dei confronti omette, e spiega i «miglioramenti» che svaniscono quando si forza lo stesso server. Se l'indirizzo differisce tra le esecuzioni, il test ha confrontato due destinazioni e non due percorsi. Riportate latenza e perdita accanto al throughput, perché un percorso più veloce nel complesso ma che aggiunge ritardo a ogni richiesta interattiva non è migliore per il carico di lavoro che si è lamentato. Il tempo di andata e ritorno conta più della velocità in massa per tutto ciò che chiede e attende.

Quando la differenza vale la pena di essere conservata

Se un tunnel approvato migliora in modo affidabile un carico di lavoro specifico, è una scelta operativa legittima: documentate il carico, la misurazione e l'uscita usata. Un record utilizzabile nomina un solo host, l'indirizzo di uscita prodotto dal tunnel, la risposta del resolver e le stesse cifre del percorso diretto lo stesso giorno. Questo basta al prossimo ingegnere per ripetere il confronto invece di ridiscuterlo. Non è ancora prova che il fornitore limiti qualcosa, e non si trasferisce ad altre applicazioni o ad altre ore.

Conservate il record della misurazione con la configurazione. Risponde alla domanda successiva, se il miglioramento esiste ancora, ed è l'unico modo per sapere se è cambiato il percorso o il carico di lavoro. Un record senza data non può rispondere affatto a quella domanda.