Tailscale diventa più veloce: cosa cambia sotto il cofano della VPN

Rendere una VPN più veloce non significa soltanto aumentare la banda disponibile tra due nodi. Tailscale lavora da tempo sull’ottimizzazione delle parti meno visibili della rete: dopo aver migliorato il throughput TCP, superato i 10 Gbps su Linux in alcune configurazioni bare metal e accelerato sensibilmente i flussi UDP, il progetto sta preparando un nuovo gruppo di interventi su memoria, parallelismo, inoltro dei pacchetti e tempi di avvio.

Il lavoro annunciato a fine settembre riguarda soprattutto Linux e Android e rappresenta la prosecuzione di un percorso iniziato diversi anni fa attorno a wireguard-go, l’implementazione di WireGuard che Tailscale esegue direttamente come software, anziché affidarsi al modulo WireGuard integrato nel kernel Linux, e che gestisce concretamente cifratura e trasferimento dei pacchetti tra i dispositivi.

Come la VPN di Tailscale diventa più veloce

Non si tratta quindi di un singolo boost applicato alla VPN Tailscale, ma di interventi in punti diversi della catena di elaborazione che, sommati, possono incidere parecchio quando transitano molti pacchetti o quando un nodo deve servire numerose connessioni contemporaneamente.

Il primo fattore resta il percorso scelto tra i dispositivi: una connessione UDP diretta è normalmente preferibile a un collegamento che passa attraverso un relay.

Come abbiamo spiegato nell’approfondimento sui Peer Relays di Tailscale, quando NAT o firewall impediscono il collegamento peer-to-peer, un relay collocato nella propria infrastruttura può evitare i limiti prestazionali dei server DERP condivisi. Questi ultimi sono server relay gestiti da Tailscale che inoltrano il traffico tra due dispositivi quando non è possibile stabilire una connessione diretta peer-to-peer. “Condivisi” significa che la stessa infrastruttura DERP serve più utenti e reti Tailscale.

Le nuove ottimizzazioni intervengono invece soprattutto su ciò che accade dopo aver trovato il percorso: come il client riceve, cifra, decifra, copia e consegna i dati.

Perché un pacchetto da 1 KB può occupare un buffer da 64 KB

Uno dei problemi individuati dagli sviluppatori riguarda il modo in cui i pacchetti entrano nel client. Sulle reti reali moltissimi datagrammi sono piccoli, spesso nell’ordine di 1 KB.

Linux, però, dispone di meccanismi come Generic Receive Offload (GRO), progettati per elaborare gruppi di pacchetti insieme e ridurre il numero di attraversamenti dello stack di rete. Per sfruttarli, il software deve poter ricevere blocchi decisamente più grandi: tipicamente fino a 64 KB.

Qui nasceva uno spreco non trascurabile: il codice derivato da wireguard-go utilizzava buffer da 64 KB per ospitare i pacchetti estratti da una lettura aggregata. In pratica, anche un pacchetto molto più piccolo poteva finire copiato in un’area di memoria predisposta per la dimensione massima. Moltiplichiamo l’operazione per migliaia o milioni di pacchetti e il costo non riguarda soltanto la RAM occupata: aumentano le allocazioni, le copie e il lavoro necessario alla CPU e al garbage collector di Go.

La nuova implementazione per Linux e Android cerca di evitare proprio la copia: i pacchetti restano nella memoria nella quale sono arrivati; Tailscale registra invece posizione iniziale, lunghezza e destinazione di ciascun elemento all’interno del buffer ricevuto. Più pacchetti possono così condividere la stessa allocazione senza trasformarsi individualmente in blocchi da 64 KB.

Secondo i test pubblicati da Tailscale, questa sola modifica ha prodotto un miglioramento nell’ordine del 5% in diverse configurazioni di rete. Si elimina semplicemente lavoro che non serviva.

Da una sola corsia a più code parallele

Il risparmio di memoria apre la strada a un intervento ancora più interessante per subnet router, app connector ed exit node. Sono nodi particolari: non gestiscono soltanto il proprio traffico, ma inoltrano dati per altri dispositivi o utenti. Un piccolo subnet router domestico può servire poche macchine della LAN; lo stesso componente inserito in un’infrastruttura cloud può trovarsi davanti centinaia di peer e molte connessioni simultanee.

La nuova architettura introduce un modello multi-queue: più corsie di elaborazione funzionano in parallelo e ogni flusso resta associato alla stessa corsia, così da preservare l’ordine dei pacchetti che gli appartengono. Le code possono però lavorare contemporaneamente su core differenti della CPU.

Il punto è che il parallelismo non cresce in funzione del numero di peer, scelta che potrebbe diventare rapidamente ingestibile, ma in rapporto alle risorse della macchina. Un server con più core può distribuire meglio ricezione, cifratura, decifratura e inoltro; un sistema più piccolo mantiene invece un numero di code compatibile con l’hardware disponibile.

Il vantaggio dovrebbe emergere soprattutto nei nodi che concentrano molto traffico: un subnet router Tailscale, ad esempio, permette di raggiungere dispositivi che non eseguono direttamente il client; un exit node riceve invece il traffico Internet dei sistemi che lo utilizzano come uscita.

Meno passaggi tra Tailscale e il kernel Linux. L’introduzione della cache di rete

Una parte delle ottimizzazioni riguarda il modo in cui Tailscale scambia continuamente pacchetti con il kernel Linux. Invece di copiare e trasferire piccoli blocchi di dati uno alla volta, il client può adesso raggruppare più operazioni e lavorare su quantità maggiori di dati per ciascun passaggio.

Il vantaggio risiede soprattutto nella riduzione del lavoro svolto per ogni singolo pacchetto: meno copie in memoria, meno chiamate di sistema e meno passaggi tra il client Tailscale e il kernel.

Il risultato diventa particolarmente importante sulle connessioni molto veloci, dove il limite può non essere più la rete fisica ma il tempo CPU necessario per cifrare, decifrare e spostare continuamente migliaia o milioni di pacchetti. Tailscale aveva già ottenuto forti incrementi di throughput con ottimizzazioni analoghe; gli interventi più recenti cercano di ridurre ulteriormente questo costo.

Un’altra novità riguarda invece il tempo necessario per tornare operativi dopo l’avvio di Tailscale. Il client deve contattare il control plane e scaricare la cosiddetta network map, che contiene le informazioni necessarie per sapere quali dispositivi appartengono alla rete privata e come raggiungerli.

Tailscale sta introducendo la netmap caching: il client conserva sul disco l’ultima configurazione valida e può utilizzarla subito dopo l’avvio per tentare di raggiungere i peer già conosciuti. Nel frattempo continua a contattare il control plane per ottenere informazioni aggiornate.

La cache non rende quindi Tailscale indipendente dai server di coordinamento, ma permette alla rete di tornare operativa più rapidamente quando il dispositivo ha già una configurazione valida e il control plane risulta temporaneamente lento o difficile da raggiungere.

Nei test di Tailscale, in condizioni di scarsa connettività verso il control plane, il cosiddetto avvio “warm” ha permesso di iniziare a trasferire dati molto più rapidamente rispetto a una partenza senza informazioni già memorizzate.

Cosa arriva con Tailscale 1.104 e cosa richiederà più tempo

Al momento dell’annuncio, il ramo stabile risulta ancora nella serie 1.102. Il piano pubblicato dagli sviluppatori colloca nella versione 1.104 la nuova gestione dei buffer per Linux e Android e l’attivazione predefinita della cache netmap.

Il sistema multi-queue per subnet router e app connector dovrebbe invece arrivare dopo la 1.104. Anche ulteriori benefici legati alle modifiche di throughput, parzialmente introdotte durante la primavera 2026, richiederanno una release successiva.

Linux resta la piattaforma sulla quale Tailscale può intervenire più direttamente sul percorso dei pacchetti, sfruttando funzioni del kernel come le interfacce TUN, gli offload per ridurre il numero di pacchetti elaborati singolarmente e le operazioni di I/O che consentono di trasferire più buffer con una sola chiamata.

Android condivide una parte di queste possibilità perché utilizza anch’esso il kernel Linux, anche se introduce ulteriori vincoli legati al sistema mobile. Su Windows, macOS e iOS, invece, Tailscale deve adattarsi a stack di rete, API e modelli di sicurezza differenti, perciò non tutte le ottimizzazioni realizzate su Linux possono essere replicate nello stesso modo o con gli stessi benefici.

Per capire meglio dove si inseriscono queste ottimizzazioni, può essere utile riprendere il funzionamento generale di Tailscale e di WireGuard che abbiamo approfondito nell’articolo su come creare una VPN distribuita con Tailscale. Anche il ruolo delle connessioni dirette, dei relay DERP e dei meccanismi di attraversamento dei NAT torna centrale: sono gli stessi elementi che abbiamo analizzato parlando di Peer Relays e di Tailcat, il progetto Tailscale dedicato proprio allo studio e al miglioramento della connettività peer-to-peer.