← TORNA ALLE GUIDE / Diagnostica

Test ping, jitter e 0 ms: leggere la latenza HTTP

Interpreta latenza e jitter nel browser, valori di 0 ms e connessioni riutilizzate. Scopri perché HTTP/3 usa QUIC e in cosa il test differisce dal ping.

Di IPNixaPubblicato il Aggiornato il

Misura la mia latenza HTTP

Leggi insieme mediana, intervallo e jitter

Lo strumento di latenza registra otto tempi di risposta HTTP in sequenza dopo una richiesta iniziale di preparazione. La mediana è il valore centrale delle misurazioni ordinate; l’intervallo mostra il minimo e il massimo. Qui il jitter è la media delle variazioni assolute tra campioni consecutivi, non una misura a livello di pacchetto.

Esempio con otto campioni: 20, 30, 10, 40, 20, 30, 10, 40 ms. Ordinandoli, la coppia centrale è 20 e 30, quindi la mediana è 25 ms. Le sette variazioni consecutive sommano 140 ms; dividendo per sette si ottengono 20 ms di variazione. L’intervallo è 10–40 ms. Sono dati illustrativi del calcolo, non misurazioni della connessione di un visitatore.

Come il test di latenza HTTP distingue configurazione e tempo di richiestaCONFIGURAZIONE DELLA CONNESSIONEDNS e trasporto possono essere riutilizzati1 richiesta di preparazione8 richieste HTTP misurateMediana · intervallo · variazioneL’RTT del nodo edge è un’osservazione separata
Il test di latenza esclude una richiesta di preparazione, poi cronometra otto piccole richieste HTTP. Il DNS e la configurazione della connessione possono essere riutilizzati. È una sequenza esplicativa, non un percorso di rete misurato né un test della larghezza di banda.

Cosa significa un tempo di 0 ms o non disponibile

I tempi di risposta e il dettaglio delle fasi di apertura sono misurazioni separate. Una connessione riutilizzata può gestire una nuova richiesta senza una nuova risoluzione DNS o un nuovo handshake.

Etichette dei tempi di connessione
Valore mostratoSignificatoCosa fare
In cache o connessione riutilizzataPer questa richiesta non è stata misurata una nuova fase DNSNon interpretarlo come la velocità di risoluzione del resolver DNS
Nessuna nuova apertura (connessione riutilizzata)La voce Resource Timing non contiene un nuovo intervallo di apertura della connessioneConfronta i tempi di risposta delle richieste, senza interpretare l’apertura come latenza di andata e ritorno
TCP non utilizzato (HTTP/3 · QUIC)Questa richiesta ha usato HTTP/3, il cui protocollo di trasporto è QUICLeggi il QUIC RTT se il nodo edge lo ha comunicato
Non comunicatoIl dato temporale richiesto era assente o non utilizzabileLascialo come sconosciuto: non è uno zero misurato
0 ms comunicati (precisione non disponibile)Il nodo edge ha fornito zero senza precisione sufficiente per interpretarlo ulteriormenteNon dedurre da questo campo un ritardo fisico nullo o il riutilizzo della connessione

Confronta Wi-Fi, dati mobili o VPN in modo coerente

Per un confronto semplice, usa lo stesso dispositivo e browser. Il risultato è un’osservazione utile alla diagnosi, non una misurazione calibrata dell’intera connessione internet.

  1. Metti in pausa download, streaming e altro traffico intenso, poi avvia lo strumento di latenza e annota mediana, intervallo e variazione.
  2. Cambia solo la rete o la configurazione VPN che vuoi confrontare, attendi che la connessione si stabilizzi e ripeti.
  3. Annota più esecuzioni e l’ora del test. Se cambia il nodo edge osservato o il percorso, considera il risultato come un confronto tra i percorsi completi.
  4. Usa Verifica TLS per il protocollo HTTP e l’RTT riportato dal nodo edge. Questi metadati provengono da una richiesta di verifica distinta, quindi non devono necessariamente coincidere con un campione di latenza.

Annota i confronti per capire cosa è cambiato

Per ogni esecuzione, annota l’ora, il nome della rete, l’impostazione VPN, la mediana, l’intervallo e la variazione. Se vuoi confrontare una VPN, mantieni invariati Wi-Fi e dispositivo. Se vuoi confrontare Wi-Fi e dati mobili, non cambiare l’impostazione VPN. Una mediana più alta dopo due modifiche contemporanee non rivela quale delle due l’abbia causata.

Confronta l’esempio con otto campioni di esattamente 25 ms: entrambe le mediane sono 25 ms, ma la sequenza costante ha un intervallo di 25–25 ms e una variazione consecutiva di 0 ms. Mediane uguali possono nascondere una regolarità molto diversa. Questi esempi sintetici isolano il calcolo; la pianificazione reale del browser aggiunge rumore. Ripeti le prove inattese e annota le etichette di apertura della connessione. Non sommare l’RTT dell’edge al tempo totale della richiesta del browser: i valori possono sovrapporsi e provenire da richieste diverse.

Perché il ping nel browser differisce da quello nei giochi

Una richiesta HTTP comprende il lavoro del browser e del server oltre al tempo di rete. Un gioco comunica con un altro endpoint e può usare un protocollo diverso. Un risultato verso un nodo Cloudflare vicino non può prevedere la latenza verso uno specifico server di gioco, e questo strumento non misura ping ICMP, perdita di pacchetti o velocità di download.

Se vuoi ospitare una partita, usa la pagina IP per il gaming per preparare un indirizzo ed esaminare gli indizi WAN del router. Per i ritardi durante il gioco, consulta anche le statistiche di rete del gioco e ripeti i test quando si presenta il problema. Gli indizi di CGNAT e una latenza elevata sono osservazioni distinte: una non dimostra l’altra.

Domande frequenti

Perché TCP RTT indica «non utilizzato» con HTTP/3?

HTTP/3 usa QUIC anziché TCP. Il campo TCP non si applica a quella richiesta. IPNixa mostra il QUIC RTT separatamente quando il nodo edge lo comunica.

0 ms significa che la connessione non ha ritardo?

No. Una fase di apertura può essere saltata quando la connessione viene riutilizzata, oppure un server può riportare zero senza la precisione necessaria per interpretarlo. Questi casi sono indicati separatamente dai valori mancanti.

La latenza nel browser equivale al ping ICMP?

No. Questi campioni misurano piccole richieste HTTP a IPNixa, inclusi i tempi di elaborazione del browser e dell’endpoint. ICMP, giochi e altre destinazioni usano misurazioni diverse.

Questo test rileva perdita di pacchetti o bufferbloat?

No. Otto piccole richieste HTTP non misurano la perdita di pacchetti né la latenza durante un carico controllato in upload o download. Usa uno strumento progettato per queste misurazioni.

Fonti e approfondimenti