Repérer les goulots d'étranglement réseau avec traceroute

Un goulot d'étranglement réseau est le point d'un chemin où le retard ou la perte commence et ne disparaît plus jamais. Traceroute et mtr peuvent le trouver, mais l'essentiel de ce qu'ils montrent est du bruit : des routeurs qui répondent lentement aux sondes, les rejettent ou restent muets, tout en acheminant parfaitement le vrai trafic. Ce guide s'appuie sur de vrais tracés lancés depuis nos serveurs le 7 octobre 2026 pour montrer la règle qui distingue les deux, puis ce qu'il faut faire une fois un vrai goulot trouvé.

La règle : le problème doit durer jusqu'à la destination

Chaque ligne d'un tracé est un aller-retour distinct, auquel répond un routeur différent. Les routeurs acheminent le trafic en matériel mais répondent aux sondes en logiciel, avec une faible priorité, et la plupart limitent le nombre de réponses qu'ils envoient par seconde. Un saut qui semble lent ou sujet à des pertes ne compte donc que si tous les sauts suivants, jusqu'à la destination, montrent la même chose. TraceMapper applique cette même règle quand il rédige son verdict sur un tracé : une hausse ne compte que si elle persiste jusqu'à la destination.

Tracé réel n° 1 : 82 % de « perte » qui n'en est pas

Depuis notre serveur de Falkenstein, en Allemagne, vers un hôte de test Vultr à Singapour (mtr -rwz -c 60, 60 sondes par saut) :

  5. AS1299   hbg-b2-link.ip.twelve99.net                      0.0%    60   11.9  11.7  11.3  12.1   0.2
  6. AS1299   hbg-bb3-link.ip.twelve99.net                    53.3%    60   25.0  25.0  24.7  25.3   0.2
  7. AS1299   ffm-bb1-link.ip.twelve99.net                     0.0%    60   30.2  30.1  29.8  30.5   0.2
  8. AS1299   prs-bb1-link.ip.twelve99.net                     0.0%    60   38.6  38.1  37.7  38.6   0.2
  9. AS1299   mei-b5-link.ip.twelve99.net                      0.0%    60   32.3  32.3  32.0  32.7   0.2
 10. AS1299   sng-b6-link.ip.twelve99.net                      0.0%    60  169.7 178.0 169.5 249.9  16.1
 11. AS1299   sng-b7-link.ip.twelve99.net                      0.0%    60  169.0 169.0 168.0 179.5   2.2
 12. AS1299   sng-b5-link.ip.twelve99.net                     81.7%    60  168.0 190.1 167.6 381.6  64.2
 13. AS1299   constantcompany-ic-379815.ip.twelve99-cust.net   0.0%    60  164.7 165.1 164.7 166.3   0.2
 14. AS???    ???                                             100.0    60    0.0   0.0   0.0   0.0   0.0
 15. AS???    ???                                             100.0    60    0.0   0.0   0.0   0.0   0.0
 16. AS20473  45.32.98.222.vultrusercontent.com                0.0%    60  172.5 172.3 172.0 172.5   0.1
 17. AS20473  45.32.100.168                                    0.0%    60  164.7 165.5 164.3 175.0   1.8

• Le saut 6 perd 53 % des sondes, le saut 7 aucune. Si des paquets étaient vraiment perdus au saut 6, tous les sauts suivants montreraient aussi cette perte. Le routeur de Hambourg rationne simplement ses réponses.
• Le saut 12 perd 82 %, avec un pire temps de 381,6 ms et un écart-type de 64,2 ms. Le saut juste après répond aux 60 sondes avec une dispersion de 0,2 ms, et la destination répond elle aussi à toutes. Des chiffres alarmants, aucun problème.
• Le saut 10 montre de la gigue (249,9 ms au pire, écart-type de 16,1 ms), le saut 11 presque aucune. Là encore, ce sont les réponses du routeur, pas le chemin.
• Le saut 9 répond plus vite que le saut 8 (32,3 ms contre 38,1 ms). La latence des sauts intermédiaires n'augmente pas forcément : chaque routeur prend son propre temps pour répondre.

Toutes les alertes de ce tracé ne sont que du bruit. La destination, c'est-à-dire ce à quoi vous vous connectez réellement, a répondu à 100 % des sondes en 165,5 ms en moyenne.

Tracé réel n° 2 : un gros bond dû à la distance, pas à un goulot

Dans le même tracé, le temps passe de 32 ms au saut 9 à environ 169 ms aux sauts 10 et 11, et reste à ce niveau jusqu'à la destination. La hausse persiste, elle est donc réelle. Mais ce n'est pas un goulot d'étranglement : les noms des routeurs passent de villes européennes (hbg Hambourg, ffm Francfort, prs Paris) à sng, Singapour. Les 137 ms supplémentaires, ce sont les câbles sous-marins entre l'Europe et l'Asie ; Singapour se trouve à environ 10 000 km de Falkenstein, ce qui coûte au moins 100 ms d'aller-retour dans la fibre, avant même tout routage.

Un bond qui persiste n'est un goulot d'étranglement que s'il est plus grand que ce qu'explique la distance, ou s'il varie selon l'heure de la journée. Comparez-le au plancher : à raison d'environ 1 ms d'aller-retour par 100 km de fibre, 137 ms pour un saut intercontinental, c'est normal ; 137 ms entre deux routeurs de la même ville, non.

Tracé réel n° 3 : un saut à Londres qui répond en 298 ms

Vers Sydney, depuis le même serveur, à la même minute :

  6. AS24940  core7.lon.hetzner.com                         0.0%    60   22.2  22.1  21.7  22.4   0.1
  7. AS???    ???                                          100.0    60    0.0   0.0   0.0   0.0   0.0
  8. AS4637   i-1001.ulhc-core03.telstraglobal.net          6.7%    60  299.7 298.8 297.6 302.2   0.8
  9. AS4637   i-1045.paix-core02.telstraglobal.net          0.0%    60  297.6 298.7 297.6 299.6   0.6
 10. AS1221   bundle-ether6.stl-core30.sydney.telstra.net   0.0%    60  346.6 345.7 344.6 346.7   0.6
 ...
 16. AS20473  108.61.212.117.vultrusercontent.com           0.0%    60  341.4 341.2 340.9 341.5   0.1

Le saut 6, c'est Hetzner à Londres, à 22 ms. Au saut 8, Telstra Global (AS4637) prend le relais, à Londres également d'après RIPE IPmap, qui géolocalise les routeurs, et pourtant ce saut répond en 298 ms. Un paquet ne peut pas mettre 276 ms à traverser Londres. En réalité, la réponse du routeur revient par une autre route, bien plus longue. Chaque temps d'un traceroute est un aller-retour, et le trajet retour vous est invisible. Le bond qui compte ici, ce sont les 341 ms de la destination, face à un plancher de 162 ms pour les 16 220 km jusqu'à Sydney : c'est la route, et non le câble, qui double la latence.

Les cas types en un coup d'œil

Ce que vous voyez	Ce que cela signifie	Que faire
Perte ou retard à un saut, qui disparaît au saut suivant	Le routeur rationne ou retarde ses réponses	Rien
Perte ou retard qui commence au saut N et dure jusqu'à la destination	Un vrai problème au saut N ou sur le lien juste avant	Rassembler des preuves (voir plus bas) et le signaler au réseau auquel appartient le saut N
Un gros bond qui persiste et correspond à la distance	La propagation : un océan ou un continent	Rien, ou rapprocher le serveur des utilisateurs
Un gros bond plus grand que ce qu'explique la distance, ou une ville très éloignée de la ligne directe	Un détour de routage	Essayer un autre opérateur ou un autre fournisseur amont, un CDN, ou signaler le détour
Un retard qui n'apparaît qu'aux heures de pointe, à partir d'un saut donné	De la congestion : une file d'attente à ce saut	Tracer à différentes heures et signaler le problème avec horodatage
Des astérisques jusqu'au bout, mais le ping répond	La destination ignore ce type de sonde	Relancer le tracé avec -I (ICMP) ou -T -p 443 (TCP)
Des astérisques du saut N jusqu'au bout, et pas de réponse au ping	Le chemin s'arrête là, ou un pare-feu bloque tout	Tester le port du service, et tracer depuis un autre endroit
Le problème commence dans les sauts 1 à 3	Votre propre réseau ou votre ligne d'accès	Tester en filaire, sans rien d'autre en cours, puis appeler votre fournisseur d'accès

Localiser le saut

• Les noms des routeurs contiennent généralement un code de ville ou d'aéroport : nbg Nuremberg, nyk New York, hbg Hambourg, ffm Francfort, prs Paris, lon Londres, sng Singapour, tky Tokyo. Lancez le tracé sans -n pour les voir.
• Les numéros d'AS (mtr -z) indiquent à quel réseau appartient chaque saut. Dans les tracés ci-dessus : Hetzner AS24940, Arelion AS1299, Telstra Global AS4637, Telstra AS1221, Vultr AS20473. La congestion se manifeste souvent à l'interconnexion entre deux d'entre eux ; voir comment fonctionnent les ASN et le routage BGP.
• Une carte rend les détours évidents. TraceMapper y place chaque saut, avec son réseau et sa latence.

Des preuves qu'un opérateur prendra en compte

• Un rapport mtr -rwzb -c 100 pris pendant que le problème se produit, et un autre pris quand tout va bien, pour comparer.
• Le même test depuis un autre endroit. Le même hôte du New Jersey a répondu à notre serveur de Falkenstein en 86,4 ms et à celui de Gravelines en 71,7 ms, par des réseaux différents : comparer les points de mesure vous dit si le problème suit votre connexion ou la destination.
• Les deux sens si possible : demandez à l'autre partie un tracé en retour vers vous.
• La date, l'heure avec son fuseau horaire, votre adresse IP publique et la destination.

Pour lire chaque colonne de ces rapports, voir comment lire un rapport mtr ; pour les commandes de chaque système, la commande traceroute sous Windows, Mac et Linux.