Come misurare veramente la VPN: metodologia passo dopo passo, metriche e strumenti senza illusioni

Perché misurare le prestazioni di una VPN e cosa significa davvero la realtà

Cos’è la «prestazione reale» e non il marketing

Le prestazioni di una VPN non sono un semplice numero su un bel banner, ma un insieme di metriche che influenzano la tua esperienza reale: quanto velocemente scarichi file, quanto fluido è il videochiamata, se il gioco non fa «teletrasportare» il personaggio. La realtà è sempre contestuale. L’ora del giorno, il percorso verso il server, il tipo di crittografia, il carico sull’hardware, il provider, persino un router malandato con un chip surriscaldato: ogni dettaglio cambia il quadro.

Quando parliamo di «reale», intendiamo condizioni fisse e ripetibili, un piano di misurazione controllato e un’interpretazione onesta. Non serve un laboratorio da milioni di euro. Serve disciplina, strumenti giusti e sapere quali numeri contano davvero e quali sono solo rumore sui grafici.

Quando ha senso fare test e quali obiettivi porsi

Testa la VPN quando cambi provider, modifichi il protocollo (per esempio da OpenVPN a WireGuard), cambi il percorso di rete (nuovo provider, Starlink, 5G), configuri QoS o MTU, o noti un degrado — «ieri andava bene, oggi lagga». L’obiettivo è fondamentale: massimizzare il throughput per il backup? Minimizzare la latenza per i giochi? Ridurre il jitter per le chiamate? Il tutto insieme porta a compromessi. Meglio dare priorità.

Le insidie comuni nella percezione e come evitarle

Un singolo test speedtest non dice nulla. Misurare «in ufficio su Wi-Fi» non è comparabile a «a casa su cavo». Il percorso verso il nodo di test è mezza verità; l’altra metà è il server VPN e il suo contesto. La baseline senza VPN è indispensabile, altrimenti confronti mele e patate. E sì, la CPU spesso è il collo di bottiglia quando usi crittografie pesanti, specialmente su router senza AES-NI o con firmware stanco.

Metriche chiave: throughput, latenza, jitter e perdite

Throughput: la larghezza di banda come pane quotidiano

Il throughput indica quanti dati passano attraverso il tunnel in un’unità di tempo. Si misura in Mbps e Gbps. In pratica guardiamo non il picco istantaneo ma la media stabile in un intervallo di 30-60 secondi sotto carico costante. Differenziamo throughput TCP (dipende da finestra, perdite e latenza) e throughput UDP (limitato dal mittente e dalle perdite). Per la VPN è importante testare entrambi: TCP mostra l’esperienza utente, UDP indica il massimo throughput con stima delle perdite.

Scenari tipici: 1 flusso, 4-8 flussi, molti flussi per simulare carichi reali. Un aumento con il multi-threading indica limitazioni nascoste, per esempio nella crittografia su singolo core CPU.

Latenza: il ritardo che senti sulla pelle

La latenza è il tempo andata e ritorno (RTT). Misuriamo la mediana, il 95º e 99º percentile. La mediana mostra la base, le code il dolore. Nei giochi serve RTT basso e stabile. Per il web conta anche la variabilità: picchi nelle code fanno rallentare il caricamento pagine, specialmente con molte connessioni TCP/QUIC.

Importante: misuriamo la latenza fino al punto finale su internet via VPN, non solo fino al server VPN. Altrimenti ottieni un numero «bello» che non dice nulla sul percorso reale.

Jitter: il tremolio della latenza, killer delle chiamate

Il jitter è la variazione di latenza nel tempo. I servizi vocali e video soffrono proprio di questo: 60 ms costanti vanno bene, 20-120 ms saltellanti fanno saltare i buffer e immagini a scatti. Il jitter si calcola con la formula standard della variazione di latenza tra pacchetti consecutivi (ad esempio stream UDP in iperf3). Nei report guardiamo media e 95º percentile. Per chiamate il comfort è sotto 20-30 ms con perdite fino all’1%.

Perdite di pacchetti e la relazione con il MOS

Le perdite incidono pesantemente sul throughput TCP (che deve ritrasmettere) e con il tempo aumentano la latenza per buffering. Per i media le perdite sono critiche: il MOS (qualità del parlato) cala drasticamente già al 2-3%. Nel 2026 molte VPN su QUIC sopportano più perdite grazie a FEC e meccanismi intelligenti di controllo streaming, ma non sono miracoli: con il 5% di perdite stabili la qualità soffre anche con buona velocità media.

Strumenti del 2026: cosa scegliere e come prepararsi

iperf3: lo standard d’oro per throughput e metriche UDP

iperf3 è lo strumento base per misurare TCP e UDP. Per TCP lanciamo test da 30-60 secondi, variando il numero di stream (-P 1,4,8) e la dimensione della finestra (default va bene, ma a volte -w aiuta). Per UDP variamo il bitrate (-b) a scalini finché le perdite superano 1-2%, segnando il jitter. Importante: il server iperf3 deve essere fuori dal server VPN, nel paese o regione d’interesse.

Novità 2026 — modalità per backend orientati QUIC (esistono fork e plugin), ma iperf3 classico su TCP/UDP copre il 95% dei casi. Per replicabilità ideale, usa Docker e versioni fissate.

ping, fping, mtr: la triade per latenza e diagnosi di percorso

ping misura RTT. fping lo fa su larga scala stabilmente, utile per percentili. mtr combina traceroute e ping: vedi percorso, latenze e perdite ogni hop. Usa mtr fino al punto finale via VPN per individuare bottlenecks: per esempio un’incrocio sovraccarico o un percorso strano a loop su altro continente.

Consiglio: registra mtr 2-3 volte al giorno in ore di punta e fuori picco. Nel 2026 i percorsi cambiano spesso: provider bilanciano il traffico dinamicamente, soprattutto con SASE e proxy cloud in crescita.

Speedtest CLI e server self-hosted

Speedtest CLI è comodo per un controllo rapido, ma non è laboratorio. I risultati dipendono dal nodo; spesso sono «troppo buoni» vicino a cache provider. Meglio hostare LibreSpeed su un VPS nella geografia desiderata: il browser simula carico reale e controlli il server. Ottimo per report al management — «come vive l’utente» — e per confrontare protocolli con condizioni identiche.

Wireshark, tcpdump e profiler eBPF

Wireshark per analisi dettagliate: vediamo ritrasmissioni, MSS, MTU, finestre, cause di perdite. tcpdump per raccolta leggera con filtri. Nel 2026 si usano spesso strumenti eBPF (es. bpftrace per stack di rete) per vedere dove la CPU fatica: crittografia, copia memoria, code. Spesso la scoperta è sorprendente: non è colpa della rete ma di driver imperfetti o offload NIC spenti.

Metodo di test: dalla baseline al confronto protocolli VPN

Passo 1. Baseline: senza VPN ma professionale

Prima misuri senza VPN. Su cavo. Stesso percorso verso server di test. Fai tre set: mattina, ora di punta, notte. Salva iperf3 TCP/UDP, ping/fping, mtr. Questa è la «velocità e stabilità di riferimento», senza cui non sai davvero cosa rallenta: rete o crittografia, percorso o server.

In parallelo prendi metriche di sistema: carico CPU (soprattutto single thread), IRQ, frequenze core, temperature. Sul router: acceleratori hardware, offload, stato buffer. Senza questo puoi facilmente incolpare la VPN per problemi CPU.

Passo 2. Piano di esperimento: randomizzazione, ripetibilità, durata

Definisci piano: quali protocolli (WireGuard, OpenVPN, IPsec, soluzioni moderne basate su QUIC), quali cipher (ChaCha20-Poly1305 per ARM e CPU deboli, AES-GCM per x86 con AES-NI), quali location (vicina, media, lontana), quali carichi (1 flusso, multi-flusso, UDP al limite). Randomizza ordine test per evitare degradazioni progressive server o rete.

Ogni test dura almeno 30 secondi, meglio 60. Ripeti 3-5 volte. Usa mediana e intervallo di confidenza per i risultati. Scarta outlier evidenti (esempio: se durante un test cambia il routing).

Passo 3. Confronto e controllo variabili

Cambia un parametro alla volta. Inizia con WireGuard vs OpenVPN a MTU e cipher uguali, poi l’impatto MTU, multithreading, location. Fondamentale: stesse porte e protocollo di trasporto (UDP vs TCP). Cambiare porta può far cambiare QoS da parte provider.

Annota versione client/server VPN, configurazioni, keepalive, timer di rinegoziazione chiavi. Nel 2026 molti client hanno funzioni smart di failover e multipath—disattivale per test puliti, altrimenti confronti mele con ananas.

Casi pratici: gaming, videochiamate, lavoro remoto e file sharing

Gaming: priorità latenza e stabilità code

Idealmente RTT sotto 50 ms verso server gioco, jitter sotto 15-20 ms, perdite meno di 0.5%. Throughput è poco rilevante salvo per aggiornamenti. Testa ping/fping verso IP gioco reali o PoP vicini sviluppatore, mtr per trovare hop «ballerini». Controlla MTU: se il client gioco è sensibile alla frammentazione vedi spike RTT con carico. WireGuard spesso offre code più stabili del 10-20% rispetto a tunnel TCP, specialmente su Wi-Fi.

Videochiamate e streaming: jitter tutto, throughput secondario

Zoom, Meet, Teams, WebRTC sono adattivi. Serve canale stabile. Per valutare, usa test UDP iperf3 da 2 a 8 Mbps per 5-10 minuti, analizza jitter e perdite. MOS sopra 4.0 si raggiunge di solito con jitter fino a 20 ms e perdite 1-2%. Ottimo risultato viene da QoS ben configurato sul router: marca DSCP e previeni bufferbloat soprattutto in upload.

Lavoro remoto: web, IDE, RDP/SSH

Per il web conta la combinazione RTT e throughput. QUIC/HTTP3 è diffuso nel 2026, 0-RTT riduce i ritardi di apertura schede. Ma se la VPN aggiunge 40-60 ms lo senti come lentezza. Per RDP/SSH comfort a RTT sotto 80 ms senza jitter irregolare. Controlla keepalive VPN per evitare riconnessioni improvvise.

File sharing, torrent e backup: collo di bottiglia in CPU e finestra

Massimo throughput è il re. Testa TCP multi-flusso (4-16) e confronta con uno solo. Se aumenta 2-3 volte sei limitato da finestra/RTT. Se poco, è crittografia/CPU o limiti server. Upload è critico per torrent: verifica comportamento VPN a 80-90% di saturazione uplink. FQ o Cake sul router risolvono spesso problemi di blocco upload.

Interpretazione risultati: dove sono i colli di bottiglia e come intervenire

Rete e percorso: provider, peering, code

Se senza VPN RTT è stabile e basso, con VPN aumenta e salta, guarda il percorso: mtr mostra hop con code o perdite. Può succedere che server VPN sia in data center «economico» con incroci congestionati. Soluzione: cambia location o provider, o prova porta/protocollo diversi (UDP 443 via QUIC può comportarsi diversamente da UDP 51820).

Crittografia e CPU: la realtà dell'hardware

Se la CPU è al 100% su un singolo thread durante crittografia, hai il limite fisso. WireGuard su x86 con AES-NI e ChaCha20-Poly1305 spesso batte OpenVPN in user space. Su router ARM ChaCha20 vince quasi sempre su AES senza accelerazione hardware. Controlla offload: GRO/LRO, TSO, accelerazione crittografica hardware. A volte disattivarli riduce latenza a scapito di velocità picco—dipende dall’obiettivo.

MTU, MSS e «black hole» PMTUD

MTU errato è classico problema. Sintomi: throughput instabile, ritardi strani sotto carico, siti «bloccati» nel caricamento risorse. Soluzione: trova MTU giusto sperimentalmente (spesso per WireGuard 1420 ma non sempre), attiva MSS clamping sul router, verifica che ICMP necessario per PMTUD non sia bloccato. Dopo aggiustamenti MTU jitter cala e throughput si stabilizza.

Lato server: limiti nascosti

I server VPN non sono magici. Limiti sessioni, pool CPU condiviso, effetti NUMA, VM rumorose vicino: tutto conta. Per onestà esegui test di notte e confronto con picco. Se throughput di notte è 30-40% superiore, hai semplicemente risorse insufficienti o uplink dati congestionati.

Ottimizzazione e tuning: vittorie rapide e soluzioni durature

Scelta di protocollo e cifrari

Nel 2026 per la maggior parte dei casi il punto di partenza migliore è WireGuard (UDP) con ChaCha20-Poly1305. Per reti con QoS/Firewall aggressivi il modo QUIC trasparente su 443/UDP (supportato da molte implementazioni commerciali e open source) è utile. OpenVPN serve solo se serve comportamento complesso L7 o retrocompatibilità, ma solitamente è più lento.

Configurazioni TCP/QUIC e gestione buffer

Attiva algoritmi moderni di congestion control: BBRv2 su client e server dà vantaggi su canali lunghi con perdite. Per RTT brevi CUBIC resta stabile. Cura sysctl: rmem, wmem, tcp_timestamps, SACK, ECN. Per QUIC molti client si adattano dinamicamente, ma limiti sistema socket rimangono importanti.

MTU/MSS, ECN e QoS contro bufferbloat

Configura MTU corretto e attiva MSS clamping: base! Poi QoS: priorizza traffico interattivo (DSCP CS6/EF per voce), limita trafficone upload pesante. Installa Cake o FQ-CoDel sul router di confine. Effetto spesso drammatico: jitter si dimezza o triplica, chiamate più stabili, web più veloce anche con RTT uguale.

Accelerazione hardware e architettura

Se regolarmente saturi CPU, aggiorna hardware (x86 con AES-NI, ARM moderni con core crittografici) o sposta crittografia più vicino al kernel (WireGuard in kernel space è ormai standard). Per velocità 1-5 Gbps logici NIC con offload e driver scelti con cura. A volte conviene dividere utenti su più server piccoli invece di uno solo «gigante»: NUMA e cache ringraziano.

Automazione e report: test come codice

Script, container e replicabilità

Automatizza tutta la metodologia con script. Bash o Python, conta poco. iperf3, fping/mtr, raccolta metriche di sistema, parsing JSON/CSV. Usa container Docker e versioni fissate. Così fra sei mesi ripeti test identico e confronti mele con mele.

Scheduler, monitoraggio e alert

Esegui test brevi ogni ora: RTT, jitter, mini traffico UDP. Se il grafico si muove sai prima di utenti che si lamentano. Integra con Prometheus/Grafana o semplice exporter CSV su BI cloud. Alert su salite del 95º percentile jitter e cali throughput TCP >30% vs baseline mediana.

Report per business e SLA

Non appesantire con numeri. Mostra 3 cose: throughput medio, RTT mediano, 95º percentile jitter, comparazioni per protocollo e posizione, e una sintesi in un paragrafo: «Per videochiamate - location A, per backup - location B». Se interno SLA, definisci soglie: es. RTT Europa max 80 ms, jitter max 25 ms, perdite <1% per il 95% del tempo.

Errori comuni e anti-pattern

Tunnel dentro tunnel e magia eccessiva

VPN dentro VPN dentro proxy sembra sicuro ma diventa un casino di problemi MTU, handshake inutili e mal di testa. Se serve multipath, usa soluzioni con MPTCP/QUIC o meccanismi nativi multi-canale. Evita cascata di protocolli senza motivo.

Ignorare baseline e statistica

Pecca maggiore è non misurare prima senza VPN, poi con VPN in condizioni identiche e con ripetizioni. Un dato non è dato. Due test già suggeriscono qualcosa. Tre o più permettono conclusioni. Usa mediane e percentili, non guardare solo il test «più bello».

Interpretazione errata e conclusioni affrettate

«VPN è lenta perché throughput basso». Può essere. O magari il provider limita traffico su porta, o CPU è sotto sforzo, o MTU crea problemi. Analizza sistematicamente: percorso, CPU, MTU, protocollo, poi eventualmente cambia provider. E annota modifiche per non perdere la bussola.

Esempi dettagliati di misurazioni e casi 2026

Caso 1: WireGuard vs OpenVPN su fibra gigabit domestica

Baseline senza VPN: 930-940 Mbps TCP, RTT verso Francoforte 28 ms, jitter 2-3 ms. WireGuard: 820-860 Mbps TCP (4 flussi), UDP senza perdite fino a 900 Mbps, RTT 30-32 ms, jitter 4-6 ms. OpenVPN (UDP): 450-520 Mbps, RTT 35-38 ms, jitter 10-14 ms. Conclusione: per backup e surfing generale — WireGuard; per compatibilità con router vecchi — OpenVPN, ma a prezzo di velocità e jitter.

Caso 2: 5G SA + laptop, priorità videochiamate

Baseline senza VPN: RTT 22-35 ms, jitter oscillante 5-25 ms in picco, perdite fino all’1%. Con WireGuard: RTT 28-40 ms, jitter stabilizzato 6-12 ms grazie a QoS router (FQ-CoDel). Test UDP a 6 Mbps con perdite 0.6%, chiamate senza crepitii. Conclusione: VPN non deve accelerare, deve essere prevedibile. Con QoS e MTU corretto va meglio che senza VPN.

Caso 3: ufficio remoto su Starlink

Baseline senza VPN: RTT 45-80 ms con picchi fino a 130 ms (switch tra satelliti), jitter 8-25 ms. WireGuard + BBRv2: throughput TCP 180-220 Mbps (4 flussi), jitter stabile 10-18 ms. OpenVPN: 120-160 Mbps, più sensibile a picchi. Consiglio: WireGuard, MTU 1420, MSS clamping, QoS moderato in upload e test ogni 2 ore per monitorare «finestra satelliti».

Istruzioni passo passo: avviare test in 60 minuti

Preparare il setup

1) Due VPS nella geografia scelta: uno per iperf3 e LibreSpeed, uno di backup. 2) Installa iperf3 server (iperf3 -s). 3) Sul client — iperf3, fping, mtr, speedtest-cli, tcpdump o Wireshark. 4) Configura client VPN con log di versione e config. 5) Tabella su Google Sheets o schema CSV locale per risultati.

Baseline

Esegui senza VPN: iperf3 TCP 60s con -P 1 e -P 4, UDP da -b 50M in su fino a ~1% perdite. fping 300 pacchetti, salva percentili. mtr 3 run da 60s. Registra metriche CPU. Ripeti in orari diversi.

Test protocolli VPN

Connetti WireGuard. Ripeti stessi test. Poi OpenVPN UDP. Se usi modalità QUIC del provider VPN, fissa porta 443/UDP. Per ogni protocollo stessi test e intervalli. Randomizza ordine per non penalizzare ultimo test a causa di degrado canale.

Analisi e report

Costruisci tabelle: mediana TCP, 95º percentile RTT, jitter, perdite UDP a 50-100-200 Mbps. Segna scenari: gaming, chiamate, backup. Dai raccomandazioni: «per chiamate — protocollo X, location Y, MTU 1420, attiva Cake; per backup — location Z, -P 8, BBRv2». Risultato: piano chiaro e attuabile, non «tutto sommato ok».

Tendenze 2026: dove va la performance VPN

QUIC e mimetizzazione su 443/UDP

QUIC è ormai maturo. Molte VPN mascherano traffico come QUIC standard, superando firewall complessi e mantenendo bassa latenza. Non sempre più veloce in picco, ma spesso più prevedibile nelle code e più robusto alle perdite. Nei test includi la modalità QUIC in confronto.

WireGuard come default e multipath

WireGuard è default in quasi tutti gli scenari. Arriva il multipath — traffico parallelo su Wi-Fi+LTE, LTE+Starlink. Nei test significa: esegui scenari con un canale e con due, misura resistenza a disconnessioni e switch, non solo numeri assoluti.

BBRv2, eBPF e acceleratori hardware

Algoritmi più aggressivi ma intelligenti di congestion control riducono «rilassatezza» TCP con perdite, specie su percorsi lunghi. Profilazione eBPF è routine: individuare dove si perde performance è molto più facile. Acceleratori hardware crittografia su chip comuni sono più diffusi — risultato: VPN gigabit su hardware domestico sono fastidiosamente normali.

FAQ: risposte rapide

Risposte veloci per cominciare

• Con quale frequenza testare la VPN? Una volta a settimana test breve (RTT, jitter, un test TCP), una volta al mese test completo con ripetizioni. Cambio provider o protocollo richiede test extra.
• Quanto dura un test «corretto»? 30-60 secondi per flussi TCP/UDP, 5-10 minuti per stabilità jitter su chiamate. Più importanti le ripetizioni e i percentili che un unico test lungo.
• È necessario testare di notte? Sì. Il confronto notte vs ora di punta mostra se il collo di bottiglia è il percorso o il server, non il client.

Metriche e interpretazione

• Quali metriche sono più importanti? Per i giochi — RTT e 95º percentile jitter. Per chiamate — jitter e perdite. Per backup — throughput TCP e stabilità con 4-8 flussi.
• Cosa fare se il throughput cala del 30%? Controlla CPU e cifrari, MTU/MSS, percorso (mtr), poi prova altra location/porta/protocollo. Spesso il colpevole è MTU o CPU.
• Come capire se colpa è del MTU? Sintomi: pagine web che si bloccano, velocità cala con carichi crescenti, aumentano ritrasmissioni. Si risolve con MTU tuning e MSS clamping.

Pratica e strumenti

• Si può fidare di un singolo speedtest? No. È un indicatore, non una diagnosi. Usa iperf3, fping, mtr, controlla percorsi e ripeti test.
• WireGuard è sempre più veloce? Spesso sì, ma non sempre. Su percorsi problematici la modalità QUIC di alcune soluzioni è più stabile. La performance dipende da protocollo, percorso e hardware.