Bien que cette commande n'utilise pas que les propriétés d'ICMP, il est utile de bien comprendre son utilité, son fonctionnement et ses limites.

Comme son nom le laisse supposer, cette commande s'efforce de tracer l'itinéraire d'une trame émise par une source pour atteindre une cible quelque-part sur l'internet.

La commande envoie une trame vars la cible, avec un «Time To live» initialement = 1, puis incrémenté jusqu'à l'arrivée vers la cible. Nous savons qu'un routeur décrémente ce TTL sitôt que la trame lui arrive, puis toutes les secondes et que si ce TTL arrive à 0, le message ICMP de code 11 est renvoyé à la source. Lorsque tout se passe bien, la source est donc capable de reconstituer la liste de tous les routeurs impliqués dans le chemin.

La commande traceroute de GNU/Linux utilise par défaut des datagrammes UDP vers le port Port 33434 de la cible. Les routeurs qui mettent à 0 le TTL réponde par le message ICMP type 11 (Time-to-live exceeded). Il est cependant possible de paramétrer le fonctionnement de façon différente, par exemple en envoyant un «ICMP echo request» plutôt qu'un datagramme UDP. Il existe même une commande analogue tcptraceroute qui envoie un paquet [SYN] sur un port indiqué dans la commande. Le principe de fonctionnement reste le même. Voici un exemple:

traceroute -4 -n www.free.fr

traceroute to www.free.fr (212.27.48.10), 30 hops max, 60 byte packets
 1  192.168.60.254  0.366 ms  1.036 ms *
 2  * 194.149.174.110  15.461 ms *
 3  212.27.57.126  15.357 ms  15.531 ms  16.008 ms
 4  194.149.161.246  16.276 ms  17.439 ms  17.436 ms
 5  212.27.48.10  15.805 ms  15.801 ms  15.798 ms

Lorsqu'il y a des étoiles dans les réponses, c'est justement que la commande n'a pas reçu de réponse. Graphiquement, ça donne ceci: Si nous recherchons avec whois à qui sont attribuées ces adresses, il y a des chances de retrouver Proxad ou une de ses filiales. Mais en regardant bien ce graphique, que voyons-nous ?

• nous ne voyons que les adresses par lesquelles le datagramme entre sur les routeurs, donc:
• au mieux nous visualisons le chemin pour aller vers la cible.

Ce qui ne donne aucune informations sur le chemin de retour. De plus, rien ne dit que les messages ICMP que l'on reçoit reviennent par le même chemin.

Comme nous ne sortons probablement pas du réseau Proxad, il n'est pas forcément absurde d'imaginer une architecture de ce genre: Les chemins de retour des divers messages ICMP et même le retour du serveur www.free.fr peuvent être totalement différents du chemin de la requête et traceroute ne le montrera pas.

Finalement, cette commande n'offre qu'assez peu d'intérêt sur le bon (ou le mauvais) état d'une connexion entre client et serveur lorsque l'on ne connaît pas déjà plus ou moins l'architecture de l'inter-réseau impliqué, sans compter les cas où les routeurs ne répondent tout simplement pas.

traceroute a de plus en plus de difficultés à tracer son chemin, compte tenu des routeurs ou même des cibles qui ne répondent plus. En revanche, tcptraceroute, si l'on cible un hôte dont on est certain que le port demandé est ouvert, affichera généralement au moins la dernière étape. Voici un exemple qui permet de découvrir quelques informations. Le site ipindia.gov présente un site web en https (port 443)

tcptraceroute ipindia.gov.in 443

Selected device sw0, address 192.168.60.47, port 49657 for outgoing packets
Tracing the path to ipindia.gov.in (164.100.236.140) on TCP port 443 (https), 30 hops max
 1  192.168.60.254  0.529 ms  0.432 ms  0.255 ms
 2  * * *
 3  * * *
 4  * * *
 5  prs-bb2-link.ip.twelve99.net (62.115.118.62)  15.299 ms  15.812 ms  15.578 ms
 6  mei-b5-link.ip.twelve99.net (62.115.124.57)  25.359 ms  26.241 ms  25.838 ms
 7  reliance-ic-361536.ip.twelve99-cust.net (62.115.155.139)  39.008 ms  38.343 ms  38.923 ms
 8  103.198.140.210  142.933 ms  222.755 ms  143.117 ms
 9  49.44.220.240  141.860 ms  141.285 ms  141.508 ms
10  * * *
11  * * *
12  103.156.182.67  144.159 ms  143.503 ms  143.514 ms
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  164.100.236.140 [open]  160.266 ms  160.591 ms  159.867 ms

Il y a une très grosse différence de temps de réponse entre le hop 7 et le hop 8. La géolocalisation des IP concernées dit que:

• 62.115.155.139 est gérée par Arelion en Suède;
• 103.198.140.210 l'est par Reliance Jio Infocomm Limited à Singapour

La latence entre les deux routeurs peut paraître anormale, mais nous avons vu précédemment que la distance à parcourir était supérieure à 11000 km.

• 49.44.220.240 du hop 9 est également attribuée à Reliance Jio Infocomm Limited mais en en Inde (en gros 3500 km en ligne droite et il n'y a quasiment aucune latence entre les deux);
• 103.156.182.67 du hop 12 à BHARTI Airtel Ltd (Inde)
• 164.100.236.140, la cible est assignée à National Informatics Centre.

Entre les hops 12 et 20 il y a également un peu de latence, pourtant dans le même pays.

Il peut donc y avoir quelques informations intéressantes à tirer d'un tcptraceroute lorsque la cible est très lointaine.