Test di Ping e Perdita di Pacchetti

Come funziona

1. Chiudi altri download e streaming. Un altro dispositivo o app che consuma banda durante il test gonfierà il numero di latenza sotto carico per motivi che non hanno nulla a che fare con il comportamento reale della tua connessione.
2. Preferisci l'Ethernet, o siediti vicino al router. Il Wi-Fi aggiunge la propria latenza e il proprio jitter sopra a ciò che fa la tua linea internet — un cavo isola la misurazione alla linea stessa.
3. Premi Avvia e lascia la scheda in primo piano. I browser rallentano le schede in background, il che comprometterebbe silenziosamente la misurazione da cui dipende questo test.
4. Osserva prima la latenza a riposo, poi quella sotto carico. La prima fase misura la connessione a riposo; la seconda avvia un download insieme alle stesse sonde di latenza per vedere quanto rallenta mentre è occupata.
5. Leggi i contatori di stabilità, non una percentuale di perdita. Non esiste — vedi sotto il perché — ma il numero di sonde senza risposta e quante sono tornate insolitamente lente ti dicono quasi la stessa cosa.
6. Ripetilo nelle ore di punta. Latenza e bufferbloat sono più sensibili all'orario del giorno rispetto alla velocità grezza — un risultato serale può apparire molto diverso da uno pomeridiano.

Cosa misura davvero questo test (e perché "ping" qui è un termine un po' improprio)

Il comando `ping` invia un pacchetto ICMP grezzo e cronometra la risposta. Una pagina web non può farlo — i browser non hanno accesso a ICMP né a socket grezzi di alcun tipo, per gli stessi motivi di sandboxing per cui una pagina web non può leggere i tuoi file senza chiedere permesso. Perciò questo test fa la cosa più onesta possibile: cronometra una normale richiesta HTTPS verso la rete di Cloudflare e sottrae il tempo di elaborazione riportato dal server stesso, lasciando solo il tragitto di andata e ritorno sulla rete.

• È un tragitto di andata e ritorno reale e misurato — non una simulazione né una stima, solo via HTTPS invece che ICMP.
• Di solito legge qualche millisecondo in più rispetto a un ping da terminale verso la stessa destinazione, perché uno scambio HTTP protetto da TLS costa comunque un po' di più di un semplice eco ICMP, anche dopo aver sottratto il tempo di elaborazione del server.
• Misura il tragitto verso una postazione edge di Cloudflare, non verso un server di gioco, un provider di chiamate o un sito specifico — trattalo come un indicatore di "quanto è buona la mia connessione, in generale", non come il numero esatto che otterresti verso una destinazione specifica.

Perché non c'è una percentuale di pacchetti persi in questa pagina

Vale la pena spiegarlo chiaramente invece di limitarsi a omettere il numero, perché la sua assenza è una scelta deliberata, non una funzione mancante.

• TCP — il protocollo alla base di ogni normale richiesta web — ritrasmette automaticamente e invisibilmente i dati persi. Un pacchetto perso non fallisce; arriva semplicemente in ritardo, dopo un tentativo.
• Questo significa che una pagina web che cronometra richieste HTTP non può letteralmente vedere un pacchetto perso come perdita — vede una risposta lenta, indistinguibile a prima vista da una normale congestione.
• Uno strumento che calcolasse "0% di pacchetti persi" da questi dati non starebbe riportando un tasso di perdita basso — starebbe riportando di non aver rilevato alcuna perdita, il che è tutt'altra cosa da dire a chi sta risolvendo una connessione instabile.
• Misurare la vera perdita di pacchetti richiede un protocollo che non nasconda la perdita — ICMP o UDP grezzo — che è esattamente ciò che a un browser non è permesso inviare.

Ciò che questo test riporta invece: quante sonde di latenza non hanno ricevuto alcuna risposta entro un tempo generoso, e quante sono tornate molto più lente della sonda tipica sulla tua connessione — un segnale che probabilmente c'è stata una ritrasmissione, anche se non può essere contata direttamente. Nessuno dei due numeri è perdita. Entrambi sono la prova più vicina che un browser possa realmente raccogliere.

Latenza, jitter e caso peggiore: cosa significa ogni numero

Il test riporta tre numeri correlati ma distinti dalla sua fase di latenza a riposo.

• Latenza (ms): il tempo tipico di andata e ritorno — tecnicamente la mediana di tutte le sonde, che resiste a essere distorta da un singolo valore anomalo lento, a differenza di una media.
• Jitter (ms): quanto varia quel tempo di andata e ritorno da una sonda all'altra, non quanto è alto in media. Una connessione può avere una latenza media decente e comunque sembrare a scatti in una chiamata se il jitter è alto.
• Caso peggiore (ms): il tragitto di andata e ritorno al 95° percentile — vicino al numero che noteresti davvero in una chiamata o in una partita, poiché un singolo momento molto lento si nota molto più di quello tipico.

Bufferbloat: perché la connessione diventa lenta proprio quando parte un download

Questo è il numero che la maggior parte dei test di velocità ignora completamente, ed è spesso la spiegazione reale di "la mia connessione va bene finché qualcun altro non inizia a scaricare qualcosa".

• La maggior parte di router e modem mette in coda i dati in uscita in un buffer prima di inviarli — un'idea ragionevole che va storta quando quel buffer è sovradimensionato rispetto alla connessione.
• Quando un grande download o upload riempie quel buffer, ogni altro pacchetto — incluse le sonde di latenza di questo test, e ogni pacchetto di una chiamata o di una partita — deve aspettare in coda dietro di esso.
• Il risultato: una latenza che va bene quando la connessione è libera può salire da 20ms a 300ms o più nell'istante in cui qualcosa satura la linea, per poi tornare giù quando finisce.
• Questo test misura esattamente questo: esegue un download saturante in background continuando a inviare sonde di latenza, poi confronta la latenza prima e durante.

I voti vanno da A+ a F, in base a quanto aumenta la latenza sotto carico — A+ è un incremento di appena qualche millisecondo, F sono centinaia di millisecondi, il tipo di picco che fa cadere una chiamata proprio quando il telefono avvia un backup su cloud sulla stessa connessione.

Come appaiono i numeri buoni, per attività

Non esiste un unico numero "buono" — ciò che conta dipende interamente da cosa stai facendo sulla connessione.

• Chiamate vocali: confortevoli sotto circa 200ms di andata e ritorno con jitter basso; la maggior parte dei codec VoIP ha abbastanza buffering da smussare più del video.
• Videochiamate: latenza sotto 150ms e jitter sotto 30ms si sente solido; un voto di bufferbloat C o peggiore è spesso la causa reale di una chiamata che si interrompe ogni volta che qualcun altro è online.
• Gaming online: sotto 50ms con jitter contenuto è eccellente per qualsiasi cosa competitiva; 50-100ms va bene per la maggior parte del gioco casual.
• Cloud gaming: il caso più rigoroso — sotto 40ms con jitter molto basso, perché l'intero fotogramma video fa il tragitto di andata e ritorno, non solo un input.
• Navigazione, streaming, download: qui la latenza conta a malapena — consulta il test di velocità internet per i numeri che governano davvero questi casi.

Ecco perché questo test mostra direttamente un verdetto per ciascuna di queste attività, invece di lasciarti interpretare da solo tre numeri grezzi.

Wi-Fi, VPN e altre cose che gonfiano il risultato

Prima di dare per scontato che un brutto risultato significhi una brutta linea internet, escludi le cose più probabilmente responsabili di aggiungere latenza per conto proprio.

• Wi-Fi: aggiunge la propria latenza e, specialmente su una banda a 2,4GHz congestionata o in un condominio con decine di reti sovrapposte, il proprio jitter — spesso più di quanto contribuisca la linea internet stessa.
• Una VPN: instrada ogni pacchetto attraverso un server aggiuntivo, spesso lontano, aggiungendo distanza reale di andata e ritorno oltre al costo di crittografia.
• Un router sovraccarico: un router datato o poco potente può aggiungere latenza di elaborazione sotto carico indipendentemente dalla tua reale connessione internet — dall'esterno appare identico al bufferbloat.
• App in background: sincronizzazione cloud, aggiornamenti automatici e altri dispositivi sulla stessa rete possono saturare silenziosamente la connessione durante quello che pensavi fosse un test a riposo.

Il modo più rapido per isolare la causa: esegui il test via cavo con tutto il resto in pausa, poi di nuovo via Wi-Fi con il tuo normale carico di sottofondo — il divario tra i due ti dice dove si trova davvero il problema.

Quando il risultato indica davvero un problema

La maggior parte dei risultati irregolari ha una delle spiegazioni sopra. Un insieme più piccolo di schemi merita davvero di essere segnalato al proprio ISP.

• Un voto di bufferbloat D o F su una connessione via cavo, confermato su più di un'esecuzione — spesso risolvibile dal lato ISP con una moderna gestione delle code (commercializzata come SQM o fq_codel), se supportata.
• Latenza a riposo ben oltre 100ms verso una postazione Cloudflare vicina su una connessione via cavo, costantemente a diverse ore del giorno — questo indica un problema di instradamento o congestione a monte, non qualcosa in casa tua.
• Un numero elevato di sonde senza risposta su una connessione via cavo senza VPN attiva — vale la pena riprodurlo e segnalarlo con uno screenshot, poiché può indicare un problema reale nella rete del provider.
• Numeri buoni alle 3 di notte ma costantemente cattivi ogni sera — congestione di rete locale, uno schema specifico che vale la pena segnalare direttamente al proprio ISP.

Domande frequenti