Perché una VPN sembra lenta durante i caricamenti: ritardo di coda

Un backup inizia a caricare, il contatore di trasferimento sembra sano e la videochiamata diventa una poltiglia. Il collegamento non manca di larghezza di banda nel senso che quel numero suggerisce; i pacchetti aspettano in una coda da qualche parte e quelli interattivi restano dietro i dati di massa. È il ritardo di coda, comunemente chiamato bufferbloat. Una VPN può aggiungere la propria coda, ma raramente crea il problema da sola.

Larghezza di banda e ritardo sono misure diverse

La velocità di trasferimento risponde a quanti dati si muovono al secondo, mentre il ritardo risponde a quanto tempo impiega un pacchetto ad attraversare il percorso. Un collegamento saturo può mantenere un grande arretrato e riportare comunque una buona velocità, perché la coda si svuota alla velocità della linea quando la raffica finisce. Il traffico interattivo soffre per primo, poiché una chiamata ha bisogno di un pacchetto ogni pochi millisecondi, non di un file grande alla fine. Misurare solo il risultato di un test di velocità nasconde quindi il sintomo che vi ha fatto guardare.

Notate anche la direzione sotto carico. Un buffer di caricamento pieno può ritardare tutto il resto mentre la capacità di download resta inattiva.

Misurate l’andata e ritorno sotto carico

Prendete una linea di base su un collegamento tranquillo, poi ripetete la stessa misura mentre è in corso un trasferimento controllato. Confrontate le due esecuzioni, non i numeri assoluti.

ping -c 20 -i 0.2 203.0.113.5
dd if=/dev/zero bs=1M count=50 | ssh [email protected] "cat > /dev/null"

Il primo comando campiona il tempo di andata e ritorno, e il secondo crea un caricamento sostenuto senza bisogno di un servizio di test di velocità. Una linea di base che resta piatta seguita da un’esecuzione sotto carico che sale di centinaia di millisecondi è la firma da cercare. Alcune reti abbassano la priorità dell’ICMP, quindi trattate il ping come un indizio e confermatelo con la visualizzazione della latenza dell’applicazione stessa. Tenete il test breve sui collegamenti a consumo, perché un contrasto ripetibile conta più di una saturazione lunga.

Spostate la coda dove si trova il collo di bottiglia

La gestione delle code aiuta solo sul dispositivo che trattiene davvero l’arretrato. Ispezionate cosa fa l’interfaccia prima di aggiungere regole.

tc -s qdisc show dev eth0
tc qdisc replace dev eth0 root fq_codel

Il comando show riporta la disciplina attuale più i contatori di arretrato e di scarto, il che vi dice se questa interfaccia è il collo di bottiglia o se sta solo facendo passare traffico. Sostituire la disciplina radice con un algoritmo di coda equa dà ai flussi brevi il proprio turno invece di un’unica FIFO condivisa con i dati di massa. Applicatelo sull’interfaccia WAN del router quando il router è il collo di bottiglia, non sul dispositivo del tunnel per abitudine. Conservate la configurazione precedente e riprovate sia la reattività sotto carico sia la velocità di trasferimento, perché una velocità di massa un po’ più bassa è un buon scambio per chiamate utilizzabili.

Cosa cambia il tunnel e cosa nasconde

Una VPN aggiunge cifratura e un salto in più, e nasconde anche i singoli flussi alle apparecchiature fuori dal tunnel. Questo conta quando un dispositivo a monte offre la priorizzazione per applicazione, perché vede pacchetti cifrati invece delle conversazioni originali. Un router che termina il tunnel da sé ha una vista e un carico di lavoro diversi e può classificare al suo interno. Nessuna delle due disposizioni elimina la coda sul collegamento di accesso, che di solito è dove il ritardo si accumula.

Se il ritardo non segue il carico, smettete di regolare le code e guardate altrove: condizioni del Wi-Fi, problemi di dimensione dei pacchetti o un’uscita scadente. Le impostazioni di coda applicate senza misura spostano solo il mistero.