Ping

 

 Tout le monde parle du ping, mais sait-on exactement de quoi l’on parle ? Pas si sûr...
Quelques explications semblent être les bienvenues.
 

15 mai 2004

Qu’est-ce que c’est ?
Basiquement, ping apparaît sous la forme d’une commande en mode texte. Elle est destinée à évaluer le temps de réponse d’un serveur distant. Cette commande est disponible sur tous les systèmes d’exploitation .
A quoi ça sert ?
Le ping permet donc d’évaluer un temps de réponse, mais c’est un outil de diagnostic de base permettant, normalement, de savoir simplement si la cible distante est en état de fonctionner. Nous verrons plus loin que c’est un usage de moins en moins fiable.
En voici deux exemples :

Dans une fenêtre DOS (Windows XP)

ping DOS - 15.7 ko
ping DOS

 

Dans une console Linux :

Ping Linux - 15.1 ko
Ping Linux

 

Dans le Terminal (Mac OS X)

Ping Mac OS X - 67.1 ko
Ping Mac OS X

 

Comment ça marche ?


La source (celui qui émet un ping) envoie un petit paquet de données vers la cible, et déclenche un chronomètre. Lorsque la cible reçoit se paquet, elle répond à la source par un autre petit paquet de données.
Lorsque la source reçoit la réponse, elle arrête le chronomètre et affiche le temps.

Pour aller plus loin, ping utilise un protocole de transport particulier, appelé ICMP (Internet Control Message Protocol. protocole de gestion des erreurs de transmission), qui est un protocole au-dessus d’IP, au même niveau que TCP ou UDP. La source envoie sur la cible un paquet normalisé appelé « Echo request » et la cible répond par un autre paquet normalisé appelé « Echo reply »

 

Les effets pervers


Le protocole IPv4, en usage sur l’internet, n’est pas un protocole sécurisé. Il existe d’innombrables façons de le dévoyer pour un usage frauduleux. Ping peut constituer un moyen de rendre un hôte inaccessible en faisant un « Denial of Service », c’est à dire en saturant le système réseau de la cible, par un envoi massif de paquets de type ping, plus ou moins légèrement traffiqués.
En bref, ping peut permettre de « mettre à genoux » une machine sur un réseau en général et sur l’internet en particulier.
Pour cette raison, nombre d’administrateurs de sites décident de filtrer ICMP. Les paquets « Echo request » qui arrivent sur le réseau sont jetés par les firewalls et les machines qui sont derrière ne répondent pas, même si elles sont présentes.
En voici un exemple :

C:\ >ping www.ibm.com

Envoi d'une requête 'ping' sur www.ibm.com [129.42.18.99] avec 32 octets de données :

Délai d'attente de la demande dépassé.
Délai d'attente de la demande dépassé.
Délai d'attente de la demande dépassé.
Délai d'attente de la demande dépassé.

Statistiques Ping pour 129.42.18.99:
   Paquets : envoyés = 4, reçus = 0, perdus = 4 (perte 100%),

C:\ >

 

Pourtant, avec votre navigateur, vous atteindrez le site d’IBM sans difficulté, preuve que le serveur est opérationnel..

 

Les idées reçues


Beaucoup d’internautes croient que le ping est une mesure absolue, qui ne dépend que de la qualité de sa connexion à l’internet.
C’est faux. Le temps de réponse mesurée dépend de tous les éléments entrant en jeu entre la source et la cible, source et cible comprises. Avec une même connexion et au même moment, je pourrais obtenir un « bon » ping sur une cible :

gw2:~# ping -c 4 www.grenouille.com
PING grenouille.com (213.186.35.33): 56 data bytes
64 bytes from 213.186.35.33: icmp_seq=0 ttl=52 time=29.4 ms
64 bytes from 213.186.35.33: icmp_seq=1 ttl=52 time=23.4 ms
64 bytes from 213.186.35.33: icmp_seq=2 ttl=52 time=32.6 ms
64 bytes from 213.186.35.33: icmp_seq=3 ttl=52 time=22.6 ms

--- grenouille.com ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 22.6/27.0/32.6 ms

 

et un « moins bon » ping sur une autre :

gw2:~# ping -c 4 62.147.142.125
PING 62.147.142.125 (62.147.142.125): 56 data bytes
64 bytes from 62.147.142.125: icmp_seq=0 ttl=119 time=83.1 ms
64 bytes from 62.147.142.125: icmp_seq=1 ttl=119 time=80.6 ms
64 bytes from 62.147.142.125: icmp_seq=2 ttl=119 time=77.3 ms
64 bytes from 62.147.142.125: icmp_seq=3 ttl=119 time=89.8 ms

--- 62.147.142.125 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 77.3/82.7/89.8 ms

 

Beaucoup croient que la valeur du ping dépend du débit de la connexion (avec du 1024/256, le ping devrait être meilleur qu’avec une 512/128). C’est faux. Et en voici une preuve immédiate. Les deux mesures sont effectuées à la même heure, sur la même cible, depuis la même ville, avec le même fournisseur (Wanadoo) :

L’une avec une connexion câble 512/128 :

gw2:~# ping -c 4 www.grenouille.com
PING grenouille.com (213.186.35.33): 56 data bytes
64 bytes from 213.186.35.33: icmp_seq=0 ttl=52 time=51.3 ms
64 bytes from 213.186.35.33: icmp_seq=1 ttl=52 time=38.4 ms
64 bytes from 213.186.35.33: icmp_seq=2 ttl=52 time=22.9 ms
64 bytes from 213.186.35.33: icmp_seq=3 ttl=52 time=38.3 ms

--- grenouille.com ping statistics ---<br />
4 packets transmitted, 4 packets received, 0% packet loss<br />
round-trip min/avg/max = 22.9/37.7/51.3 ms

 

L’autre avec une connexion ADSL pro 1024/256 :

[root@helios root]# ping -c 4 www.grenouille.com
PING grenouille.com (213.186.35.33) from 81.248.157.2 : 56(84) bytes of data.
64 bytes from ns351.ovh.net (213.186.35.33): icmp_seq=1 ttl=53 time=64.6 ms
64 bytes from ns351.ovh.net (213.186.35.33): icmp_seq=2 ttl=53 time=64.2 ms
64 bytes from ns351.ovh.net (213.186.35.33): icmp_seq=3 ttl=53 time=64.1 ms
64 bytes from ns351.ovh.net (213.186.35.33): icmp_seq=4 ttl=53 time=63.0 ms

--- grenouille.com ping statistics ---
4 packets transmitted, 4 received, 0% loss, time 3026ms
rtt min/avg/max/mdev = 63.068/64.043/64.682/0.648 ms

 

Clairement, la connexion câble, bien qu’ayant un débit deux fois inférieur, offre un ping presque deux fois meilleur.
En réalité,

Le ping dépend de la qualité de sa connexion haut débit. C’est vrai, du moins en partie, et l’exemple précédent le prouve, et c’est pour ça que grenouille.com effectue ce genre de mesure, dans un contexte précis (cible dans le réseau du FAI ou, à défaut, le plus proche possible), pour éviter les perturbations apportées par l’internet.
Le ping dépend de la nature du support physique, support qui prend beaucoup d’importance, par exemple, dans le cas d’une connexion par satellite.

 

Le cas d’une connexion par satellite


Les satellites géostationnaires, utilisés pour ce type de connexion, sont, tout comme les satellites relais pour la télévision, sur une orbite équatoriale d’environ 36 000 km de rayon. Si l’on néglige tout le reste, la distance à parcourir est donc de 36 000 x 2 = 72 000 km. Dans le cas d’un ping, cette distance sera parcourue deux fois (aller et retour), ce qui nous fait 144 000 km. Parcouru à la vitesse de la lumière (300 000 km/s) il faudra : 144 000 / 300 000 = 0,48 soit 480 ms. Autrement dit, même en faisant abstraction de tout le reste, y compris et surtout le temps de latence introduit par les équipements actifs du réseau (routeurs, modems...) le ping ne pourra matériellement jamais être meilleur que 480 ms, ce qui n’empêche pas les connexions par satellite de proposer des débits allant jusqu’à 2 Mbps.

 

Le cas de l’ADSL


Une connexion ADSL, techniquement, est assez compliquée (voir
Les dessous d’une connexion ADSL). Certains fournisseurs (France Télécom, dans le cas des lignes non dégroupées) a choisi d’utiliser un algorithme de correction d’erreur par redondance de données. En gros, cela consiste à introduire dans le flux de données un nombre variable de données supplémentaires, redondantes, destinées à permettre la reconstitution des données utiles en cas de perte de bits sur la ligne. Ce type de traitement se retrouve sur la plupart des supports numériques de données, comme le CD audio, les DVD etc.
L’objectif est de rendre le transfert plus solide, mais ça a un coût en terme de temps de traitement, ce qui entraîne un ping plus élevé.

 

Finalement...


•  sur un réseau qualifié de haut débit, le débit n’intervient pas dans le ping, du moins en fonctionnement « normal ». La taille des paquets ICMP est négligeable devant la quantité de bits par seconde que la ligne peut écouler, sauf si le réseau atteint son débit maximum ;
•  la distance, si elle est importante (cas du satellite), peut intervenir de façon significative ;
•  les éléments actifs qui entrent en jeu dans la collecte des abonnés (modem, DSLAM pour l’ADSL, têtes de réseaux pour le câble...) peuvent intervenir de façon plus ou moins significative, suivant les méthodes adoptées pour consolider le transport à bas niveau ;
•  les éléments actifs qui entrent en jeu dans l’interconnexion des réseaux (routeurs, firewalls...) peuvent également intervenir de façon significative, suivant le traitement infligé aux paquets qui passent (priorité sur les protocoles applicatifs, analyse plus ou moins fine des paquets pour le filtrage...). Ce sont probablement les composants du réseau qui influent le plus souvent sur le ping, et le débit des données à traiter dans ces équipements peut influer aussi. Un routeur proche de la saturation pourra même aller jusqu’à éliminer des paquets, ce qui aboutit aux fameux « paquets perdus », mais les paquets peuvent aussi être perdus pour d’autres raisons, comme les perturbations électriques qu’une ligne peut subir ;
•  source et cible interviennent également, au même titre qu’un routeur. S’il y a beaucoup d’activité réseau sur la source et/ou si la cible est très sollicitée, le ping s’en ressentira.

Finalement, un mauvais ping n’est pas forcément imputable à votre fournisseur d’accès, pensez-y, surtout si le phénomène n’intervient que ponctuellement. Faites des essais sur plusieurs cibles, et de préférence choisies dans le même réseau que celui de votre fournisseur (par exemple, http://www.wanadoo.fr/ pour les abonnés Wanadoo). Un mauvais ping sur un serveur de jeux n’est pas obligatoirement de la faute du FAI...

 


Pour en savoir plus


•  Comment ça marche explique le protocole ICMP,
•  Wikipédia aussi.

 

From : http://www.piaf.asso.fr