Perché un download via VPN può battere la vostra connessione diretta

Collegate il tunnel, avviate un download grande e vedrete che va a circa il doppio della velocità che lo stesso file raggiungeva senza. Sembra pubblicità, ma può essere una misurazione reale su una linea domestica. La causa abituale è un limite di velocità legato a una porta: il tunnel porta il trasferimento dove il modellatore non guarda, e la capacità reale della linea si mostra per la prima volta.

Il che significa che il numero interessante non è quanto fosse veloce la VPN. È quanto della vostra linea non stavate ricevendo, e perché.

Un limite che segue la porta, non il percorso

Un fornitore di accesso può limitare la capacità per abbonato in base al protocollo o alla porta di destinazione, e la porta 80 è un bersaglio preferito perché tanta navigazione ordinaria la usa. Spesso il limite non si applica dal primo pacchetto: il trasferimento parte vicino alla velocità della linea, consuma una franchigia di raffica, poi si assesta sul valore limitato. I primi secondi sembrano sani e il resto del trasferimento no.

Inviate gli stessi byte su un’altra porta e il modellatore sulla 80 non li vede mai. Il tunnel sembra battere la connessione diretta anche se ha aggiunto un salto, la cifratura e il proprio costo. Ciò che è migliorato non è il percorso ma l’assenza di una regola.

È anche per questo che l’effetto è così costante tra file e destinazioni. Se il limite è sulla porta, tutto ciò che viaggia su quella porta si comporta allo stesso modo, qualunque sia la dimensione del file e chiunque sia l’host. Una destinazione che attira un’altra regola mostra un’altra curva, e quella differenza è diagnostica di per sé.

Misurate il plateau, non il picco

Il picco è la parte meno informativa di un trasferimento, perché ogni connessione sembra buona mentre i suoi buffer si riempiono. Annotate dove la velocità si assesta e quanto resta lì.

curl -o /dev/null -w '%{speed_download} %{time_total}\n' https://<host>/test.bin
scp user@<transfer-host>:/data/test.bin /tmp/

Eseguite la coppia uno dopo l’altro sulla stessa macchina, alla stessa ora, verso host su reti confrontabili. Un solo campione non dimostra nulla; la forma della curva su due esecuzioni di ciascuno è ciò che distingue una franchigia di raffica da un limite stabile. Annotate dove la velocità si appiattisce invece di ciò che ha mostrato il primo secondo, perché la raffica è proprio ciò che un modellatore vi dà prima di iniziare a limitare. Un plateau tranquillo che regge fino alla fine del trasferimento è il numero da confrontare.

Tenete il file già compresso perché la compressione di trasporto non possa essere offerta come spiegazione. Un PDF o un archivio elimina quella variabile e impedisce anche a chiunque di sostenere che il tunnel abbia compresso il payload. Se entrambi i trasferimenti usano lo stesso file, l’unica differenza rimasta è il percorso e la porta. Annotate lo strumento e la porta accanto a ogni cifra, altrimenti la seconda esecuzione non è confrontabile con la prima.

Tre confronti che isolano la causa

Fateli in ordine e fermatevi appena lo schema è chiaro, perché ciascuno esclude una storia diversa.

1. Ripetete lo stesso download sul percorso web ordinario e con uno strumento di trasferimento su un’altra porta, da un host con capacità confrontabile.
2. Ripetete entrambi con un file incomprimibile, perché la compressione smetta di essere candidata.
3. Se gestite voi stessi il server del tunnel, rilegatelo alla porta 80, regolate il profilo del client perché le due estremità siano d’accordo, e trasferite di nuovo. Se ora il tunnel sta alla velocità web limitata, la restrizione segue la porta e non la VPN.

Il terzo passo è quello decisivo, ed è anche quello che la gente salta perché richiede un cambio di configurazione. Senza di esso avete mostrato che due cose differiscono, non che la porta sia la ragione.

Cosa questa misurazione non può sostenere

Non dimostra che il tunnel sia più veloce in generale, che comprima qualcosa o che altre porte della linea siano senza restrizioni. Descrive questo trasferimento, su questa linea, a quest’ora. I limiti possono valere per sessione, per abbonato o secondo l’ora del giorno, e possono cambiare senza avviso.

Non dimostra nemmeno che il percorso diretto sia rotto. Un percorso limitato funziona ancora; è limitato di proposito, e una politica deliberata non è un guasto in attesa di riparazione.

E di certo non giustifica instradare tutto attraverso il tunnel. Ogni applicazione sulla porta 80 resta limitata, mentre tutto ciò che deviate ora dipende da un salto in più e da un modo di guasto in più.

Trasformate la scoperta in qualcosa di attuabile

Scrivete l’osservazione come misurazione e non come verdetto: i trasferimenti grandi sulla porta 80 si assestano intorno alla metà della velocità che lo stesso file raggiunge su un’altra porta, a queste ore, su questa linea, con questi campioni in allegato. È una richiesta di supporto che qualcuno può indagare.

«La VPN è più veloce» non lo è. Invita a una risposta sul costo della cifratura, e quella risposta è tecnicamente corretta mentre non dice niente di utile a nessuno. Allegare il numero di campioni, l’ora e la porta, così il lettore può riprodurre lo schema.

Se decidete di continuare a usare un’altra porta per i trasferimenti in blocco, annotate l’avvertenza nei vostri registri: spostare un listener sulla porta 80 va in conflitto con qualsiasi server web già legato lì, e il guasto che ne deriva sembra un tunnel rotto più che un conflitto di porte.