Compressione del traffico in VPN: quando accelera e quando rovina tutto. Pratica 2026

Perché comprimere il traffico in VPN e perché se ne parla tanto

La compressione sembra un pasto gratis, ma è davvero così?

Sembrerebbe il sogno: attiviamo la compressione, i pacchetti si alleggeriscono, la velocità cresce, la bolletta del traffico dati cala. Fantastico? Peccato che non sempre sia così. La compressione in VPN è un’arma a doppio taglio: in alcuni casi fa miracoli, in altri rallenta la velocità, scarica la batteria dello smartphone e compromette persino la sicurezza. Come capire dove porta vantaggi e dove invece è un palliativo? Mettiamola a fuoco senza magie e con dati concreti.

Il punto chiave: la compressione VPN funziona solo se i dati non sono già compressi o cifrati a livello applicativo. Nel 2026 quasi tutto il web usa HTTPS e HTTP/3 (QUIC), i contenuti multimediali sono codificati con codec moderni e backup e log spesso passano già da zstd. Quindi lo "spazio per comprimere" è ridotto. Ma rimangono molte nicchie — dai protocolli testuali a carichi aziendali specifici — dove la VPN può ancora dare un vantaggio tangibile.

Perché il tema è di nuovo caldo nel 2026

La risposta semplice: il lavoro ibrido, le reti mobili 5G/SA, la diffusione di QUIC e l’esplosione di telemetria e log. Puoi andare in campagna, connetterti a Starlink, condividere internet dal telefono e caricare in tempo reale migliaia di eventi JSON piccoli in cloud. Qui la compressione può o salvare la banda o consumare il processore del dispositivo. E poi c’è sulla scena il tema delle configurazioni sicure, sempre più rilevante a causa di attacchi vecchi ma ancora attivi, come VORACLE. Insomma, la questione non è solo teorica ma molto pratica.

Dilemma essenziale: la compressione deve avvenire prima della cifratura

Perché la compressione abbia senso, deve avvenire prima della cifratura. Altrimenti l’entropia è troppo alta e non si comprime niente. La VPN offre compressione a livello tunnel, prima della cifratura dei pacchetti. Ma questo apre la porta ad attacchi tipo CRIME/BREACH/VORACLE — quando la lunghezza e il comportamento del blocco compresso possono “sussurrare” informazioni preziose al malintenzionato. Non è questione di “attivare o no”, ma di “usare con cautela, selettivamente e consapevolmente”.

Come funziona la compressione nei tunnel VPN

Dove si colloca la compressione nello stack e cosa succede all’MTU

La compressione in una VPN classica avviene su client e server subito prima della cifratura e incapsulamento. Significa che sul traffico “grezzo” l’algoritmo cerca di spremere al massimo la ridondanza. Però la compressione cambia la dimensione del pacchetto, con impatto su MTU reale e possibilità di frammentazione. Il risultato non ovvio: sembra che riduciamo il traffico ma aumentano i ritardi causati dal riadattamento di MSS, rischiando anche di rompere il Path MTU Discovery in reti particolari. Consiglio semplice: se tocchi la compressione, gestisci parallelamente MTU/MSS con cura, step by step, verificando ogni passaggio.

Algoritmi: LZO, LZ4, Zstd e i loro ambiti d’uso

Storicamente OpenVPN ha usato a lungo LZO. Velocissimo, ma ormai superato e poco sicuro come compressione in tunnel. LZ4 è un compromesso per bassa latenza e alta velocità, tollerabile su CPU poco potenti. Zstd (Zstandard) è nel 2026 il “re” della compressione generalista: comprime bene a livelli bassi, migliora molto ad efficienza media e alta, bilanciando adattivamente velocità e qualità. Il lato negativo è il carico CPU, specie su smartphone più vecchi di 3-4 anni. Per la VPN è critico: se si surriscalda il core, si perde stabilità. Ecco perché nelle configurazioni reali la compressione si usa miratamente e a livelli moderati, quando la si usa.

Stream vs datagram: TCP, UDP e QUIC

La compressione non va d’accordo con TCP-over-TCP. Se fai girare una sessione TCP dentro un tunnel TCP, rischi la “trappola del doppio controllo di flusso”, head-of-line blocking doloroso e spike di latenza. I tunnel UDP come WireGuard o OpenVPN UDP sono di solito più tolleranti alle compressioni, ma allora serve curare bene pacchetti, jitter e buffer. QUIC (HTTP/3) sopra UDP ha già sue ottimizzazioni, compressione header e recupero perdite — la compressione VPN “extra” di solito non porta benefici.

Quando la compressione aiuta: scenari testati e dati

Protocolli testuali ed eventi: JSON, logging, telemetria

Tutto ciò che assomiglia a JSON, CSV, XML, syslog, metriche Prometheus e dump testuali grezzi è un ottimo candidato. Risparmi tipici: 40-80% sul volume. In un’azienda abbiamo attivato zstd “intrinseco” su canale log tra filiali e centro: traffico ridotto del 63% con latenza media aumentata solo di 3-5 ms. Prezzo: moderato carico CPU server (12-18%) e consumo accettabile sui thin client (5-10%).

Backup e migrazione dati

Molti strumenti di backup già compressi. Ma se per motivi storici è disabilitato o “modesto”, la compressione VPN può ancora dare una mano. Caso pratico 2025-2026: backup incrementali di configurazioni e report testuali tra sedi via IPsec con IPComp. Risultato: -28-35% byte sul canale, andamento stabile e risparmio su banda noleggiata. Ripetiamo: se la sorgente usa zstd, la compressione VPN di rincorsa non serve.

RDP/SSH e sessioni “leggere”

RDP e SSH già risparmiano traffico, non sempre in modo aggressivo, specie con aggiornamenti schermo in app non standard o molti cambi testuali. Su canali lenti LZ4 in OpenVPN UDP ha portato vantaggi del 10-20% sul volume e leggero miglioramento di latenza. Non un miracolo, ma sul 4G debole in periferia si sente: il cursore smette di “appiccicarsi”.

IoT e traffico industriale

Sensori, macchine e controller a volte usano protocolli testuali semplici. In reti chiuse senza HTTPS si può comprimere fino al 50% guardando i payload. Sembra vintage, ma in officina funziona così: se il protocollo è degli anni zero senza compressione integrata, quella VPN è un upgrade economico. Cruciale: valutare prima i rischi di sicurezza (vedi di seguito VORACLE e minacce correlate), poi abilitare la compressione solo sulle subnet necessarie.

Quando la compressione danneggia: punti critici poco discussi

Codec moderni e cifratura erodono i benefici

Video H.265/H.266, audio Opus/AAC, immagini WebP/AVIF, archivi e TLS 1.3 sopra HTTP/3 sono già compressi o “rumore bianco” per compressori. Risultato: quasi zero risparmio e gasto CPU inutile. Conclusione: velocità massima più bassa, latenza maggiore e batteria che si scarica prima. Abbiamo visto cali di velocità utile fino al 50% con LZO su OpenVPN solo perché il traffico era per il 95% media video e TLS.

TCP-over-TCP e “incollamento” delle finestre

Se la VPN usa TCP e dentro si fa passare altro TCP, alla perdita di pacchetti il TCP esterno ritrasmette, quello interno aspetta e accumula. Aggiungi la compressione e le code del processo VPN competono con le finestre TCP. Esito: velocità a scatti, cali imprevedibili di FPS nei giochi cloud, utenti che si lamentano di “scatti”. Meglio evitare tunnel TCP, figuriamoci compressione.

MTU, MSS, frammentazione e dolori nascosti

La compressione cambia media e variabilità dimensione pacchetti. Dove prima PMTUD funzionava, ora possono capitare rare ma severe frammentazioni. Nel 5G SA quasi impercettibile, ma in LTE su router datati succede eccome. Aggiungi nodi CGNAT imprevedibili e vulnerabili, e il tunnel cade misteriosamente. Rimedio: regolare con cautela mssfix e tun-mtu in OpenVPN, testare scenari blackhole ICMP e misurare percentuale frammentazioni in percorso.

Tipi di dati e compressione attesa

Ben comprimibili: testi e simili

- JSON, CSV, XML, YAML: risparmio 40-80% - Log, configurazioni, script, dump SQL (senza pre-archiviazione): 50-85% - Protocolli tipo MQTT senza compressione integrata: 30-60% - RDP/SSH con carichi testuali: 10-30%

La variazione dipende dall’entropia: più ripetitività di strutture e parole, più alto il guadagno. Zstd a livelli 3-5 spesso è la via di mezzo ideale, soprattutto su server con CPU decenti.

Poco comprimibili: già pacchettizzati e cifrati

- HTTPS, HTTP/3, traffico TLS qualsiasi: 0-5% - Video, audio, immagini in formati moderni: 0-3% - Archivi zip/7z, database, blob, backup cifrati: 0-1%

Qui il compressore non trova nulla: entropia alta, nessuna regolarità. Ogni tentativo di comprimere è solo spreco CPU.

Casi situazionali: SMB, vecchi protocolli, telemetria

SMB 3.1.1 in Windows recenti ha compressione propria (e zstd non è raro). Quindi la compressione VPN spesso disturba. Ma se hai client vecchi o app senza compressione, LZ4 a livello VPN può portare 10-25% di risparmio. Telemetria di solito è testo incapsulato, ma talvolta ha campi binari; guarda i pcap e calcola i coefficienti reali.

Rischi di sicurezza: VORACLE, attacchi correlati e come evitarli

Cos’è VORACLE e perché è ancora attuale

VORACLE è un attacco in cui la compressione pre-cifratura in VPN fa trapelare segreti da traffico HTTP analizzando le dimensioni dei blocchi compressi. Scenario tipico: l’attaccante induce la vittima a visitare una pagina con “iniezione” di contenuto controllato e, osservando le lunghezze compressi, indovina gradualmente il valore di segreti (per esempio cookie). È simile a CRIME e BREACH, ma con particolarità di OpenVPN e LZO. Nel 2026 il meccanismo è vivo: se attivi la compressione “così com’è” e sul tunnel passa testo sensibile non compresso, sei a rischio.

Quali protocolli sono vulnerabili e quali no

Se tutto il traffico è HTTPS configurato correttamente, la probabilità di successo di VORACLE è minima, perché il compressore VPN vede solo dati ad alta entropia da TLS. Ma se c’è HTTP non sicuro, API non protette, vecchie interfacce amministrative o portali interni “solo per interni” è una minaccia reale. Anche i portali aziendali interni possono essere vulnerabili se passano su VPN con compressione attiva senza contromisure.

Misure pratiche di protezione

- Di default disabilitare la compressione in VPN. Attivarla solo su flussi chiaramente sicuri e non sensibili. - In OpenVPN usare policy allow-compression no oppure modalità asimmetrica: solo ricezione compressione, niente invio. - Forzare HTTPS, abilitare HSTS, usare cookie HttpOnly, Secure, SameSite=Strict. - Per web disabilitare compressione su pagine con segreti o applicare padding randomizzato a livello applicazione. - Segmentare: tunnel o policy separati per log/telemetria e traffico web utenti.

Configurazione pratica: OpenVPN, WireGuard, IPsec, Shadowsocks

OpenVPN: come vivere senza comp-lzo senza piangere

Il vecchio comp-lzo ora è un flag “pericoloso”. Nelle versioni attuali usa allow-compression no, evita compress se non conosci i rischi. Se serve la compressione selettiva: - crea profili/tunnel separati per flussi testuali non sensibili; - scegli LZ4 con livello basso su quei tunnel; - imposta anche mssfix (es. 1400-1420 per LTE) e regola con cautela tun-mtu; - monitora CPU su client (smartphone, thin client) e server; - fai test A/B almeno 24 ore con carico reale.

WireGuard: niente compressione ed è un pregio

WireGuard non include compressione integrata e fa bene così: meno attacchi di tipo “compressione pre-cifratura = fuga”. Se vuoi risparmiare, fallo a livello applicazione: - comprimi backup con zstd prima di inviarli; - usa compressione in client telemetria; - ottimizza formati (protobuf con campi varint, dedup a sorgente). Noioso, ma sicuro e prevedibile nei consumi.

IPsec e IPComp: la classica prudenza

IPComp (RFC 3173) è compressione opzionale del payload IPsec. Funziona, ma conviene solo su flussi “testuali”. Nel 2026 è opzione di nicchia: attiva solo su subnet specifiche e misura i risultati. Attenzione all’hardware: alcune appliance supportano IPComp male — bug rari e frammentazioni imprevedibili.

Shadowsocks/proxy stack: compressione come plugin

In certi ambienti si usano plugin con offuscamento e a volte compressione. Qui conta sapere: si risparmia solo su contenuto non compresso e rischi di sicurezza sono simili — la compressione prima della cifratura aumenta la superficie d’attacco basata sulla lunghezza. Meglio mantenere compressione a livello applicazione, evitando sovrapposizioni con offuscamento trasporto se non indispensabile.

Monitoraggio, test e metriche: senza numeri la compressione è un azzardo

Come testare bene: A/B su traffico reale

Avvia due branch paralleli: con e senza compressione. Passa carichi simili per uno o due giorni. Misura: - byte in ingresso/uscita tunnel; - latenza p95/p99; - CPU e RAM su endpoint; - % perdite e ritrasmissioni. Testa sia nelle “ore di punta” sia durante “picchi di background” (patch, mailing, aggiornamenti).

Strumenti e metodi 2026

Usa iperf3 per banda di riferimento, tc per emulare canali con latenza e jitter, esportatori metriche di sistema (tipo node-exporter). Analizza pcap filtrando per interfacce tunnel, calcola ratio compressione, studia MTU/MSS e frammentazioni. Visualizza differenze su Grafana — niente misteri, solo curve pratiche.

Quando considerare successo o fermarsi

Lascia la compressione attiva se: - risparmio traffico stabile sopra 15-20%; - latenza cresce max 5-10 ms su task interattivi; - CPU non supera il 70-75% in picchi prolungati; - nessun aumento di frammentazioni o errori PMTUD. Se uno di questi cala, disattiva compressione o spostala a livello applicazione.

Casi reali 2024-2026: dove ha funzionato e dove no

Vendite mobili e CRM sul campo

Smartphone di agenti inviano molti ordini testuali e mini-report. OpenVPN UDP con LZ4 su server filiale: risparmio 22-35%, latenza +3-4 ms. Batteria si consuma 4-7% più veloce, ma utenti soddisfatti — moduli si aprono più rapidamente, anche in LTE instabile.

Canale satellitare e telemetria azienda agricola

VSAT con latenza oltre 600 ms. Telemetria: pacchetti brevi JSON. Compressione attivata sul server con zstd a livello applicazione, non VPN. Risparmio 58%, rifiutato l’IPsec compression. Risultato: oscillazioni CPU più basse e traffico regolare. Conclusione: compressione applicativa porta più controllo e prevedibilità.

Videosorveglianza e accesso remoto

Provato a comprimere stream H.265 su OpenVPN. Più o meno zero. In alcune sedi peggioramento latenza 10-15% per CPU. Soluzione: niente compressione, ottimizzazione bitrate cam e GOP. In VPN traffico pulito senza interventi inutili.

Backup aziendali tra data center

Backup già con zstd, flussi paralleli. IPsec con IPComp risparmio 1-3% ma picchi CPU evidenti su gateway. Disabilitato IPComp e regolato parallelismo nel software backup — risultato canale stabile e senza sorprese.

Parco IoT con protocollo datato

Vecchi controller inviano pacchetti semi-testi senza TLS. Tunnel OpenVPN dedicato con LZ4 solo per questa subnet ha portato risparmio 45-55% e risparmio costi operatore. Il team ha accettato il rischio perché non c’erano dati sensibili e il guadagno era rilevante. Abbiamo aggiunto monitoraggio e limitazione MTU per evitare frammentazioni.

Checklist e raccomandazioni per il 2026

Quando attivare la compressione

- Traffico principalmente testuale, bassa entropia - Carico stabile e con monitoraggio abilitato - Tunnel o policy separati per subnet specifiche - Accettabile leggero aumento latenza per risparmio banda

Quando evitarla categoricamente

- Streaming video, audio, gaming e traffico sensibile a latenza - Traffico massivo HTTPS/HTTP3, archivi e backup già compressi - Tunnel TCP-over-TCP - Reti con MTU/PMTUD instabili o problematiche

Sicurezza prima di tutto

- Di default disattivare compressione in VPN - Traffico web segreto solo su HTTPS con best practice sui cookie - Separare tunnel: log/telemetria da traffico utente - Considerare padding applicativo se c’è compressione risposte

Performance ed esercizio

- Monitorare CPU sugli endpoint, tenere margini di capacità - Su mobile usare compressione con prudenza per non prosciugare batteria - Gestire MTU/MSS e osservare frammentazioni - Effettuare test A/B almeno 24 h, confrontare p95/p99

Errori comuni e anti-pattern

Attivare “per sicurezza” e dimenticare

È così che si rovinano i canali. La compressione è un’ipotesi da validare, non un interruttore magico. Se non misuri, parte dal presupposto cheva peggio.

Comprimere contenuti già compressi

Comprimere H.265 o zip è come passare il ferro da stiro su cubetti di ghiaccio: fa rumore, spreca risorse e non serve a nulla. Sposta la compressione dove c’è ripetitività.

Ignorare la sicurezza

VORACLE non è sparita. Se hai HTTP non sicuro e compressione in VPN, il rischio c’è ancora. Chiudi le falle o segmenta il traffico.

TCP su TCP

Doppio controllo di flusso più compressione è ricetta per lag strani. Vuoi prevedibilità? Evita questa architettura.

FAQ: chiaro, diretto e senza fronzoli

Sicurezza e rischi

È pericoloso attivare la compressione in OpenVPN nel 2026?

Di default sì, sconsigliato. Il rischio VORACLE e perdite correlate non è sparito. Se necessario, attiva solo per subnet non sensibili, usa LZ4 e profili dedicati.

La compressione aiuta contro DPI e blocchi?

No. La compressione riguarda dimensione e ripetitività, non mascheramento. Per DPI servono offuscamento, plugin di trasporto o protocolli diversi — un altro discorso e rischio.

tls-crypt protegge da VORACLE?

No. tls-crypt cifra e autentica il canale di controllo, ma non cambia il fatto che se comprimi prima della cifratura payload, l’attacco basato su lunghezza rimane reale.

Performance e vantaggi

Quanto si può davvero accelerare internet con la compressione?

Se il traffico è testuale e non compresso, si possono ottenere risparmi 20-60% sul volume e caricamenti pagina più rapidi. Con video, HTTPS e archivi niente vantaggi o peggiora.

Quanto consuma la batteria dello smartphone la compressione?

Dipende da algoritmo e dispositivo. In media LZ4 consuma 3-7% in più durante la giornata lavorativa, zstd può richiedere di più. Smartphone vecchi si surriscaldano prima.

Pratica e configurazione

Ha senso IPComp per IPsec?

Sì, se i flussi sono comprimibili (log, telemetria). Ma testalo su hardware, possono esserci problemi di frammentazione. Su traffico cifrato/media IPComp è inutile.

Come capire se la compressione aiuta o danneggia?

Fai test A/B di 24-48 ore. Guarda i byte risparmiati, latenza p95, CPU, frammentazioni. Se il risparmio è sotto il 15% o latenza aumenta oltre 10 ms, disattiva.

Perché WireGuard non ha aggiunto compressione?

Per evitare vulnerabilità e complessità. La compressione porta rischi e carico CPU, i benefici sono dubbiosi con traffico moderno. Meglio comprimere a livello applicativo dove serve davvero.