Il tuo download è veloce, quindi perché ogni clic sembra lento?

Scaricare rapidamente un file grande e poi trovare ogni clic lento non è una contraddizione. La capacità dice quanto può muoversi al secondo; il tempo d’andata e ritorno dice quanto dura uno scambio prima che accada qualcosa di utile. Migliorare il primo non fa nulla per il secondo, e il secondo è ciò che una persona nota mentre scrive, clicca o parla. Misura la lamentela, non la connessione.

File veloce, clic lento: due numeri diversi

Un trasferimento massivo tiene i dati in movimento continuo, quindi può riportare una velocità sana anche quando ogni singola richiesta attende. Molti benchmark aprono anche più connessioni insieme, il che alza la cifra aggregata mentre una singola richiesta resta lenta. I due risultati sono compatibili, e citare quello più alto a un utente che si lamenta del ritardo è il modo in cui si perde la fiducia.

Il caricamento di una pagina è una catena di piccoli scambi: risoluzione dei nomi, setup della connessione, una richiesta, una risposta e poi richieste dipendenti. Ogni passo paga di nuovo l’andata e ritorno, quindi un percorso con ritardo elevato sembra lento anche quando ha capacità in abbondanza.

Il tunnel aggiunge il proprio viaggio e la propria elaborazione, e la rotta conta più dell’etichetta su una mappa. Due uscite nello stesso paese possono avere percorsi molto diversi verso una destinazione. Una differenza di venti millisecondi basta a cambiare come si sente una pagina, anche se sposta appena un numero di throughput. Per questo la scelta dell’uscita dovrebbe seguire un campione di latenza e non un’icona di bandiera.

Misura la lamentela, non la connessione

Scegli la misura che corrisponde alla frase detta dall’utente. Un download lento ha bisogno di una velocità sostenuta nella direzione giusta; una chiamata che scatta ha bisogno delle statistiche di quell’applicazione; una pagina che parte lentamente ha bisogno dei tempi di risoluzione e di setup.

ping -c 20 10.60.0.5
curl -sS -o /dev/null -w 'ttfb=%{time_starttransfer} rate=%{speed_download}\n' https://files.plant.example/1gb.bin
iperf3 -c 10.60.0.5 -t 10 -P 4

Il primo comando dà un campione di andata e ritorno verso un host che risponde in modo prevedibile, il secondo riporta il tempo al primo byte e la velocità sostenuta di una connessione, e il terzo misura il throughput aggregato con quattro flussi paralleli. Esegui questi comandi verso la stessa destinazione alla stessa ora del giorno, perché confrontare un campione del mattino con uno della sera produce una storia invece di una misura.

Tieni fissa la destinazione quando confronti le uscite. Cambiare sia il server sia il tunnel trasforma una variabile in due, e il risultato non può dirti quale contava. Esegui ogni uscita almeno tre volte, perché un singolo campione spesso cade durante un cambio di routing o un minuto rumoroso. La mediana è più utile del caso migliore.

Tratta ICMP come un indizio e non come la risposta. Un host che risponde può gestire le richieste echo su un percorso diverso da quello usato dalla tua applicazione, e una risposta persa non è prova che ogni applicazione stia perdendo pacchetti.

La latenza sotto carico è un problema di code

Il modello che confonde di più le persone è una connessione che sembra a posto da ferma e inutilizzabile durante un backup. Questa è coda, non capacità. Un uplink saturo costruisce un buffer davanti a ogni altro pacchetto, quindi una pressione di tasto aspetta dietro un pezzo dell’upload.

ping -c 20 10.60.0.5 &
iperf3 -c 10.60.0.5 -t 20 -R -b 20M

Il primo comando campiona la latenza in background mentre il secondo satura la direzione inversa. Se i tempi di ping saltano durante il trasferimento e poi si riprendono, hai riprodotto il bufferbloat invece di scoprire un guasto di routing. La correzione è di solito un’impostazione di gestione delle code, una velocità di fondo più bassa o spostare il trasferimento massivo fuori dal percorso interattivo.

Ridurre il traffico di fondo facoltativo spesso aiuta più che cambiare paese di uscita. È anche più economico, reversibile e verificabile in un minuto. Pianifica i caricamenti grandi fuori dall’orario di lavoro se la coda non può essere gestita, e limita la loro velocità se devono girare di giorno. Un’impostazione di gestione delle code è la correzione migliore quando il router ne supporta una.

Cambia una cosa e confronta il simile con il simile

Per un ritardo elevato da fermo, confronta le uscite tenendo fissa la destinazione, poi confronta le rotte per il miglior candidato. Per un throughput basso e stabile, guarda invece capacità, carico del server ed elaborazione del client, perché sono limiti diversi.

Annota cosa hai misurato, contro quale destinazione, a che ora e con quali impostazioni. Un confronto senza questi quattro fatti non si può ripetere, e la persona successiva partirà da zero.

Poi adatta lo strumento all’affermazione del ticket. "Internet lento" non è una misura; "il primo byte ha impiegato 900 ms verso questo host mentre il throughput era buono" lo è, e punta direttamente al ritardo e non alla capacità.