Comment est-il possible pour traceroute à timeout, pourtant le site se chargera bien dans un navigateur?
Je suis capable de charger www.cnn.com dans Chrome. Cependant, lorsque je fais un traceroute à partir de la ligne de commande (OSX), le délai est dépassé à level3.net.
J'ai utilisé cette extension Chrome pour vérifier l'adresse IP utilisée par Chrome pour www.cnn.com (le débogueur Chrome ne permet pas d'afficher les adresses IP): https://chrome.google.com/webstore/ detail/ipvfoo/ecanpcehffngcegjmadlcijfolapggal
Et lorsque j'utilise la CLI pour traceroute à la même adresse IP, le délai est dépassé ??
Existe-t-il des diagnostics permettant de comprendre ou de comprendre pourquoi traceroute arrive à expiration dans ce cas? Je pensais que traceroute et les navigateurs utilisaient la même couche réseau de système d'exploitation pour acheminer le trafic TCP/IP?
Si un routeur en cours de route décide de ne pas envoyer le temps ICMP dépassé (c'est-à-dire TTL atteint en route) ou le message inaccessible de destination (le paquet UDP a atteint l'hôte final mais le port fermé, mais son comportement est correct), obtiendra un délai d’attente à ce stade de la traceroute.
En bref, si vous exécutez un traceroute xyz, vous effectuez ce que l’on appelle un traceroute basé sur UDP, c’est-à-dire que l’envoi de paquets UDP avec une faible durée de vie, commençant à 1 et augmentant de 1 par étape. Si votre paquet meurt sur un routeur, c'est-à-dire que TTL devient 0, ce routeur devrait, selon le RFC 792 et d'autres, envoyer un message ICMP "Délai dépassé", indiquant qu'il était impossible de livrer le colis dans les délais. le calendrier, mais au moins nous vous disons que votre colis est mort.
Il existe deux autres méthodes de création de traceroute. Je vous recommanderais la page de manuel d'aide, telle que celle-ci , si vous souhaitez mieux comprendre les différences. Mais en bref, vous pouvez également envoyer des paquets ICMP Echo ou TCP SYN. Pour résumer, il existe trois méthodes, toutes basées sur un TTL toujours croissant pour mapper les "hôtes" le long de l'itinéraire:
- UDP vers un port aléatoire (généralement 33434 + 100) chez l’hôte avec un faible TTL
- D'après mon expérience, la valeur par défaut pour tous les outils de ligne de commande, tels que
tracerouteettracert
- D'après mon expérience, la valeur par défaut pour tous les outils de ligne de commande, tels que
- ICMP Echo to Host avec TTL bas
- J'ai rencontré ce problème dans quelques outils graphiques, également en tant qu'option pour la plupart des outils de ligne de commande.
- TCP SYN, souvent sur le port 80, ainsi le trafic est "un peu" masqué car le trafic http passe par de nombreux routeurs qui abandonnent normalement les échos ICMP et les paquets UDP vers des ports étranges.
- Astuce astucieuse et "nouvelle" méthode, bien que peu orthodoxe, pour trouver une route vers un hôte. Peu orthodoxe en ce sens que vous êtes en train de manquer aux normes Internet. Existe en option pour la plupart des outils de ligne de commande.
Le routeur peut laisser passer le trafic normal, permettant ainsi à votre requête http basée sur TCP de se terminer, mais il peut également ignorer UDP sur des ports étranges, semi-ouvert TCP sur des ports étranges ou des pings ICMP à faible TTL, processus de traceroute local en attente puis en arrêt sur cet arrêt.
Traceroute s'appuie sur les serveurs Web pour renvoyer une réponse lorsque vos données résolvent le chemin. Ces serveurs ne sont pas obligés de vous fournir une réponse, ni de répondre à votre traceroute. Ainsi, votre traceroute est bloqué dans l'attente d'une réponse qui ne vient pas, même si vos données sont arrivées à destination.
Si un serveur entre vous et cnn.com décide de ne pas envoyer de réponse pour votre traceroute, il peut tronquer les réponses restantes.