Router o laptop a corto di CPU? Perché la tua velocità VPN si ferma prima

Un router pubblicizza un Wi-Fi veloce e poi fatica a cifrare il traffico di tre dispositivi insieme. Un laptop raggiunge un limite di elaborazione mentre il collegamento di accesso ha ancora spazio. Di solito si accusa prima il server, ed è di solito innocente. Il limite sta sulla macchina che fa il lavoro del tunnel, e trovarlo significa osservare quella macchina invece del test di velocità.

Il sintomo indica una macchina, non Internet

Dove gira il tunnel decide quale processore paga. Se lo termina il router, ogni client coperto condivide il budget di quel router. Se il laptop esegue un client, paga il laptop e non il router. Tunnel su entrambe le estremità creano due carichi di lavoro che possono diventare il limite in giorni diversi. Nominare la macchina è il primo passo, ed è quello che le persone saltano quando aprono un ticket contro il fornitore.

Conta i dispositivi tra l'applicazione e l'estremità remota, poi segna quello che cifra. Tutto il resto è solo un trasportatore di byte che non può leggere.

Osserva il carico per core durante un trasferimento

Una percentuale CPU complessiva è lo strumento sbagliato, perché il lavoro di cifratura spesso blocca un singolo core mentre gli altri restano inattivi. Guarda i valori per core durante un trasferimento controllato e osserva un core vicino alla saturazione. Una media moderata con un solo thread occupato è un segnale forte, mentre una media alta senza thread occupato di solito significa un programma non correlato. Il pattern conta più del numero.

mpstat -P ALL 1 5
top -H -b -n 1 | head -20
lscpu | grep -i -E "model name|aes"

Il terzo comando ti dice se il processore espone istruzioni AES, il che cambia il costo dello stesso cifrario di molto. Non ti dice se l'implementazione VPN le usa, e proprio il divario tra questi due fatti è l'origine della maggior parte delle promesse di ottimizzazione.

Separa la cifratura dalla gestione dei pacchetti

La cifratura è un costo tra diversi. La copia dei pacchetti tra kernel e spazio utente, le ricerche di routing, le regole del firewall e la gestione delle interfacce contribuiscono tutti, e alcune implementazioni pagano più la copia della crittografia. Nota quale contatore sale insieme al trasferimento invece di fidarti del nome del processo per spiegare ogni ciclo. Un tunnel in spazio utente e un tunnel nel kernel possono mostrare profili completamente diversi per lo stesso traffico.

Se un core è occupato dentro il kernel, il rimedio è diverso da un thread occupato in spazio utente, e il profilo ti dice quale hai. Quella distinzione vale un'ora prima di comprare hardware.

Confronta il simile con il simile prima di concludere

Un confronto è utile solo se l'attività, la rete di accesso e l'endpoint restano gli stessi. Cambia il server e il risultato include la rotta e la capacità di quel server; cambia la rete e include l'operatore. Usa lo stesso file, la stessa destinazione e la stessa ora del giorno, e ferma il tuo lavoro in background. Se devi cambiare dispositivo, cambia solo il dispositivo.

Alimentazione e calore cambiano le prestazioni sostenute, quindi una breve esecuzione su una macchina fredda non è la stessa misura di un trasferimento lungo su una calda. Confronta condizioni di alimentazione simili e annotale, perché un limite termico sembra esattamente un limite di elaborazione su un grafico.

Usa l'offload supportato e verifica che si sia davvero attivato

Alcune implementazioni possono spostare parte del percorso dati nel kernel o nell'hardware, e la disponibilità dipende dal client, dal sistema operativo, dal server e dalla configurazione. Leggi la documentazione della versione che esegui e usa il suo output di stato o i suoi log per confermare che la funzione sia attiva. Un pacchetto installato o una casella spuntata non sono una prova. Il manuale di OpenVPN documenta le opzioni del canale dati per le proprie versioni, e queste opzioni differiscono tra versioni.

Quando una modifica supportata sposta il tetto, riesegui sia l'attività dell'applicazione sia un trasferimento in blocco, e conserva il profilo precedente per poter tornare indietro. Una velocità in blocco che raddoppia mentre l'applicazione resta lenta ha spostato il collo di bottiglia invece di rimuoverlo.

Se le osservazioni del processore non seguono il sintomo, torna al lato rete. I tentativi ripetuti Wi-Fi, la coda e il percorso di uscita producono lo stesso risultato senza alcun coinvolgimento della CPU.