Linux / Commande ping : réponses ICMP, temps aller-retour et pertes

ping envoie des requêtes ICMP Echo pour vérifier si une destination répond et mesurer le temps d’aller-retour, ou RTT. Une réponse valide ce type d’échange à cet instant ; une absence de réponse ne démontre pas à elle seule que le serveur est arrêté. Un service web ou SSH peut fonctionner même si ICMP est filtré.

Choisir la destination et limiter les requêtes

ICMP signifie Internet Control Message Protocol. Le ping décrit ici est celui d’iputils sous Linux ; les options de Windows, BusyBox ou d’autres systèmes peuvent différer. Vérifiez man ping et ping -V sur le système concerné avant de reprendre une commande.

ping [OPTIONS] DESTINATION

Pour commencer par la boucle locale IPv4 et envoyer deux requêtes :

ping -c 2 127.0.0.1

Ce contrôle porte sur la pile locale et son traitement d’ICMP. Il ne traverse ni le câble ni le Wi-Fi, la passerelle ou Internet : son succès ne valide donc pas la connexion externe. Sans limite de nombre ou de durée, ping peut continuer jusqu’à son interruption ; Ctrl+C l’arrête et affiche le résumé.

Pour une destination distante dont le test est autorisé, remplacez example.com par le nom pertinent :

ping -c 4 example.com
ping -4 -c 4 example.com
ping -6 -c 4 example.com

-c 4 limite le nombre de requêtes envoyées, et non un nombre de réponses garanti. -4 et -6 sélectionnent respectivement IPv4 et IPv6 ; un nom peut ne pas posséder d’adresse dans la famille demandée. Une erreur de résolution empêche de commencer l’échange ICMP avec cette destination.

Lire les réponses, le RTT et les pertes

Dans un environnement de boucle locale qui répond aux deux requêtes, une partie du résumé peut ressembler à ceci :

2 packets transmitted, 2 received, 0% packet loss

Cette ligne est un exemple de format, pas une mesure de votre machine. Les lignes de réponse comportent normalement time=, un RTT exprimé en millisecondes. Le trajet aller et le trajet retour participent tous deux au délai ; ce nombre n’est ni un débit de téléchargement ni un temps de traitement complet d’une application.

Le résumé peut aussi présenter les RTT minimum, moyen et maximum ainsi que mdev, une mesure de leur dispersion. Une variation importante mérite une observation contextualisée : charge, files d’attente et traitement prioritaire ou limité d’ICMP peuvent modifier ces réponses.

Le taux de perte concerne les sondes de cette courte observation. Quatre requêtes ne suffisent pas à établir un taux durable pour tout le trafic. Des doublons peuvent également apparaître ; iputils les traite différemment pour le calcul des pertes et les statistiques de temps, comme le précise son manuel.

Distinguer délai d’attente et durée totale

ping -n -c 4 -W 2 -w 10 192.0.2.1

192.0.2.1 est une adresse réservée à la documentation ; remplacez-la par une adresse autorisée de votre environnement. Ne l’utilisez pas comme cible dont la réponse serait attendue. La RFC 5737 sur les adresses d’exemple définit ce bloc.

Dans iputils, -W 2 règle l’attente d’une réponse lorsque aucune réponse n’a été reçue ; si des réponses ont déjà été reçues, l’attente se fonde sur deux RTT. Ce n’est donc pas un délai fixe indépendant appliqué mécaniquement à chaque paquet. -w 10 donne une échéance globale en secondes. Quand -c et -w sont combinés, ping peut attendre les réponses jusqu’au nombre demandé ou jusqu’à cette échéance.

-n n’évite pas la résolution initiale d’un nom donné en destination. Pour séparer résolution et échange IP, utilisez l’adresse correcte du service en tenant compte de sa famille et de sa configuration. Évitez les modes de forte fréquence ou flood pour un contrôle ordinaire ; quelques requêtes espacées suffisent pour commencer.

Interpréter un échec et vérifier le vrai service

1. Si le nom ne se résout pas, vérifiez la résolution DNS, Domain Name System. Il s’agit d’une étape différente d’une absence de réponse ICMP.
2. Contrôlez l’adresse locale et la route vers la destination avec la commande ip pour les interfaces et routes. Une route calculée ne garantit pas le passage des paquets.
3. Si ICMP ne répond pas, examinez les politiques de filtrage et le chemin. Un message d’erreur et une absence de réponse n’apportent pas les mêmes informations.
4. Testez le protocole de l’application depuis le point d’accès concerné. Sur le serveur, la commande ss pour les ports en écoute aide à vérifier la liaison locale.

Un ping réussi n’atteste ni qu’un port TCP est ouvert ni que l’application fournit le contenu attendu. À l’inverse, une perte de 100 % signifie seulement qu’aucune réponse Echo exploitable n’a été reçue dans cette observation, lorsque les requêtes ont effectivement été envoyées. Ne présentez pas une erreur DNS préalable comme une mesure de perte ICMP.

Pour un script iputils, le code de retour vaut 1 en l’absence de toute réponse, ou si le nombre demandé n’est pas atteint avant l’échéance lorsque -c et -w sont combinés. Les autres erreurs donnent 2 ; les autres cas donnent 0. Un code 0 sans échéance ne signifie donc pas nécessairement zéro perte. Le manuel ping d’iputils détaille ces conditions et les différences d’options.