Perché un download VPN è limitato dall’upload del server

Il client mostra un collegamento in discesa veloce, il server sta su una connessione in fibra e il trasferimento striscia comunque. Il numero che le persone confrontano è di solito quello stampato nel piano del client, mentre il pacchetto attraversa prima il collegamento di accesso in uscita del server. Quel collegamento è il budget in cui il trasferimento deve rientrare. Su una piccola connessione domestica è il numero più piccolo del percorso.

Il numero che avete letto era nella direzione sbagliata

Un download verso un client remoto consuma capacità di upload all’estremità server del tunnel. Le velocità di download dichiarate del server descrivono la direzione opposta e non dicono nulla su questa. La stessa asimmetria si inverte quando il client carica, ed è per questo che una direzione può sembrare a posto mentre l’altra è inutilizzabile.

Il costo dell’incapsulamento e qualsiasi traffico concorrente spendono parte dello stesso budget. Nessuno dei due è visibile in un test di velocità che misura solo il client.

Scrivete il percorso come un budget

Elencate ogni confine che il pacchetto deve attraversare e date a ciascuno un numero nella stessa unità. La consegna dalla sorgente, l’elaborazione sul server, il collegamento in salita del server, il percorso intermedio, il collegamento in discesa del client e l’elaborazione sul client valgono tutti. La velocità utilizzabile è la più piccola di queste meno il costo, e nessuna messa a punto sopra quel tetto cambia l’esito. Scrivete l’elenco prima di misurare, perché vi dice a quale numero non credere.

Con un collegamento in salita del server da 20 Mbit/s e un collegamento in discesa del client da 100 Mbit/s, il server limita il trasferimento molto prima che il client se ne accorga. Il costo e qualsiasi trasferimento simultaneo prendono un’altra fetta, e un collegamento in salita saturo ritarda anche le conferme, il che rallenta un trasferimento TCP sotto il tetto grezzo. Nessuno dei due effetti compare in un confronto di piani.

Tenete separati megabit e megabyte e dite se ogni cifra misura il traffico del collegamento cifrato o il carico utile dell’applicazione. Mescolare i due è la ragione più comune per cui un budget sembra non tornare. Etichettate ogni cifra con la sua unità e il suo punto di misura.

Dove la scheda vi costa davvero

Una volta che il collegamento di accesso è abbastanza grande, l’hardware dell’estremità diventa visibile, e solo allora il processore conta. Identificate il modello, la disposizione delle interfacce e l’implementazione in uso. Un’osservazione sul bus condiviso di una scheda precoce non descrive ogni revisione successiva.

Confrontate percorsi di elaborazione individuali invece di una media CPU unica. Un carico complessivo moderato può nascondere un core saturo che fa tutto il lavoro per pacchetto, e la frequenza di clock non si trasferisce tra progetti di processori come un punteggio di prestazioni. La velocità dei pacchetti conta quanto la portata, perché i pacchetti piccoli costano più per byte di quelli grandi. Misurate con le dimensioni di pacchetto che il vostro carico di lavoro usa davvero.

Anche i limiti termici e di potenza decidono il comportamento sostenuto. Un breve scoppio può sembrare eccellente mentre un trasferimento di dieci minuti cala, ed è per questo che un benchmark di pochi secondi è una guida scarsa per un backup notturno.

Le indicazioni sulle prestazioni del fornitore separano larghezza di banda di accesso, CPU, elaborazione dei pacchetti, trasporto e dimensione dei pacchetti in vincoli distinti. Vale la pena leggerle prima di cambiare un cifrario, perché un cambio di cifrario raramente sposta un confine che non è mai stato il limite.

Misurate prima di cambiare un cifrario

Eseguite un test direzionale che riporti la velocità realmente raggiunta attraverso il tunnel, poi eseguite lo stesso test sull’interfaccia grezza per confronto. La differenza fra questi due numeri è il costo del tunnel, e il più piccolo dei due tetti vi dice quale confine attaccare.

Mantenete intatta la politica di sicurezza mentre confrontate. Un vecchio risultato ottenuto con un cifrario debole o una scheda in overclock non è un piano per la distribuzione attuale.

iperf3 -c 10.44.0.1 -R -t 30
iperf3 -c 10.44.0.1 -t 30
ethtool eth0 | grep -i speed

Conservate i risultati direzionali accanto alle osservazioni dell’estremità della stessa esecuzione. Il prossimo cambiamento dovrebbe puntare al tetto misurato anziché al componente che sembra più piccolo nella scheda tecnica.