Comment utiliser cet outil
- Gardez l’onglet visible et évitez un autre test de transfert. Sélectionnez Démarrer pour envoyer 20 petites requêtes HTTP au site, avec une courte pause entre requêtes.
- Attendez la fin de la série ou sélectionnez Arrêter pour annuler. Les requêtes échouées ou annulées ne comptent pas comme des valeurs de zéro milliseconde.
- Lisez les temps individuels avec la moyenne et la variation. Répétez dans des conditions similaires pour comparer des observations de ce serveur.
Méthode de calcul
Chaque échantillon inclut la requête HTTP et sa réponse lue et validée. Le RTT moyen est la somme des durées valides divisée par leur nombre. La variation est l’écart absolu moyen entre requêtes successives réussies : somme de |suivant − précédent| ÷ paires valides. Les paires traversant une requête échouée sont exclues.
Exemple de calcul
Avec 40, 60 et 50 ms, le RTT moyen vaut 50 ms. Les écarts successifs valent 20 et 10 ms, donnant une variation absolue moyenne de 15 ms. Trois valeurs de 40 ms ont une variation nulle, mais leur délai moyen reste de 40 ms.
Choisir le trajet à mesurer
Les durées concernent le trajet de ce navigateur jusqu'au serveur de ce site. Elles comprennent la connexion locale, le parcours Internet, le traitement du serveur et le travail du navigateur. Le point de mesure apparaît pendant le test. Aucun sélecteur ne permet de viser un jeu, un service de réunion ou le routeur. Un résultat stable ici peut coexister avec des difficultés vers un autre serveur.
Notez l'appareil, le type de connexion, l'état du VPN et l'heure approximative. Gardez ces informations pour comparer les essais. Ethernet et Wi-Fi permettent d'examiner le trajet local, mais changer aussi d'appareil empêche d'attribuer l'écart à une seule modification. Cet outil ne localise pas un relais défectueux et ne certifie pas tout le réseau du fournisseur.
Lancer une série limitée de requêtes HTTP
L'ouverture de la page ne lance pas les mesures. Lisez le consentement, cochez la case et démarrez le test. Vingt petites requêtes HTTP sont envoyées successivement au serveur du même site, avec une attente de 250 ms entre tentatives. Chaque réponse valide contient 32 octets de test. Les en-têtes et l'établissement de la connexion ajoutent du trafic : vingt fois 32 octets ne représente pas le volume facturé.
Gardez la page visible. Masquer l'onglet arrête le test en cours. Un délai par requête et un délai global évitent une attente indéfinie. Arrêter annule la requête active ; réinitialiser efface les résultats et le consentement. Un nouveau test remplace les anciennes mesures. Copiez donc un relevé utile avant de modifier les conditions et de recommencer.
Séparer les réponses réussies des échecs
Le minimum et le maximum sont les durées HTTP réussies la plus courte et la plus longue. La moyenne additionne ces durées et divise par leur nombre. La médiane trie les valeurs puis prend celle du milieu ; un nombre pair utilise la moyenne des deux valeurs centrales. Une requête échouée garde sa ligne d'échec et ne devient jamais une durée fictive de zéro milliseconde.
Un écart marqué entre moyenne et médiane peut révéler une réponse particulièrement lente. Consultez l'ordre des mesures pour la retrouver. La première tentative reste incluse : aucune phase de préparation n'est retirée du calcul. Le démarrage de la connexion peut donc peser sur le résumé. Il s'agit de temps HTTP observés côté client, sans mesure du délai dans un seul sens, ping ICMP ni mesure directe du temps radio.
Calculer la variation entre réponses consécutives
La variation affichée est la moyenne des écarts absolus entre mesures réussies adjacentes dans l'ordre original. Pour 20, 30 et 50 ms, les écarts sont 10 et 20 ms, soit une moyenne de 15 ms. La durée moyenne vaut environ 33,333 ms et la médiane 30 ms. Le délai moyen et sa variation répondent à des questions distinctes.
Prenez ensuite 20 ms, 30 ms, un échec, 50 ms et 70 ms. Seules les paires 20 vers 30 et 50 vers 70 sont retenues ; leur variation moyenne reste 15 ms. Le calcul ne relie pas 30 à 50 en sautant l'échec. Les quatre réponses réussies ont une moyenne de 42,5 ms et une médiane de 40 ms. La mesure absente demeure absente.
La deuxième ligne correspond à la série avec une troisième tentative échouée décrite ci-dessus. Les durées réussies sont listées séparément ; les paires dépendent toujours des positions originales.
| Durées réussies (ms) | Moyenne (ms) | Médiane (ms) | Écart adjacent (ms) |
|---|---|---|---|
| 20 / 30 / 50 | 33,333 | 30 | 15 |
| 20 / 30 / 50 / 70 | 42,5 | 40 | 15 |
Distinguer zéro et valeur indisponible
Une seule réussite fournit minimum, maximum, moyenne et médiane, mais aucune paire adjacente. Deux réussites séparées par un échec ne forment pas davantage une paire valide. Une variation indisponible dans ces situations ne signifie pas une variation mesurée de zéro. Des durées adjacentes égales peuvent donner zéro : aucun changement n'a été observé dans cette paire, sans démontrer une arrivée parfaitement régulière des paquets.
Toutes les tentatives échouées ne donnent aucun résumé de durée. Un délai dépassé ou un serveur indisponible ne prouve pas que tout Internet est inaccessible. La charge du serveur, des restrictions de connexion et l'exécution du navigateur peuvent intervenir. Copier demande l'accès au presse-papiers et signale son échec ; imprimer utilise la fenêtre habituelle du navigateur. Ces actions ne créent aucune mesure réseau supplémentaire.
Comparer une condition à la fois
Répétez d'abord dans les mêmes conditions, puis changez un seul facteur. Comparez le même appareil sur une connexion filaire autorisée et à sa place habituelle en Wi-Fi. Notez les transferts simultanés depuis les commandes normales des applications. Une amélioration répétée aide à choisir le prochain contrôle, sans identifier à elle seule des interférences, un canal occupé ou un câble endommagé.
Pour un jeu ou un appel, relevez aussi ses propres délais et interruptions. Les protocoles et les destinations peuvent se comporter différemment. Ce test ne sépare pas des phases avec et sans charge et ne dispose pas des horodatages des paquets multimédias. Son écart HTTP n'est pas l'estimateur lissé d'arrivée RTP du RFC 3550. Les échecs HTTP ne sont pas un pourcentage mesuré de pertes UDP ; aucun seuil ne garantit la qualité d'une application.
Conserver un relevé exploitable
Copiez les mesures avec le serveur, l'heure, le type de connexion et le symptôme précis. Gardez la mention incomplète pour un test arrêté ou échoué. Décrivez une tendance sur plusieurs essais plutôt que le meilleur chiffre isolé. Une demande d'assistance nécessite rarement des mots de passe, des identifiants complets de compte ou des captures contenant des informations personnelles sans rapport avec le problème.
Le test de débit répond à la question distincte du transfert de données. Le contrôle du retard dans les jeux aide à séparer faible fréquence d'images, délai d'entrée et symptômes réseau. Aucun outil ne transforme ce relevé en diagnostic. Un trajet HTTP stable reste une observation utile ; un problème persistant dans l'application demande des contrôles adaptés à son propre trajet et à son fonctionnement.
Comment interpréter le résultat
Le navigateur, la réutilisation des connexions, le serveur et le trajet influencent ces temps. La variation exige au moins deux valeurs successives valides. Les erreurs HTTP ne mesurent pas la perte de paquets IP. Les résultats ne déterminent ni gigue unidirectionnelle, ni gigue RTP, ni latence vers un serveur de jeu ou d’appel. Les requêtes arrivent au site et exposent les métadonnées habituelles de connexion.
Questions fréquentes
Est-ce identique à la commande ping ?
Non. La commande ping utilise généralement ICMP. Ce test chronomètre des requêtes HTTP et inclut le travail du navigateur et du serveur.
Une variation nulle signifie-t-elle un délai nul ?
Non. Des temps égaux ont une variation nulle, même lorsque chaque requête prend un temps important.