tracerouteがタイムアウトする可能性はありますが、サイトはブラウザーで正常にロードされますか？
Chromeでwww.cnn.comをロードできますが、コマンドライン（OSX）からtracerouteを実行すると、level3.netでタイムアウトします
このChrome拡張機能を使用して、Chromeがwww.cnn.comに使用しているIPを確認しました（Chrome IPアドレスを表示するためのデバッガー）： https://chrome.google.com/webstore/detail/ipvfoo/ecanpcehffngcegjmadlcijfolapggal
そして、CLIを使用して同じIPアドレスへのtracerouteを行うと、タイムアウトしますか？
この場合にtracerouteがタイムアウトになる理由を理解または理解するための診断はありますか？ tracerouteとブラウザの両方が同じOSネットワークレイヤーを使用してTCP/IPトラフィックをルーティングしていると思いましたか？
途中のルーターが、ICMP時間を超えないように（つまりTTL到達途中で到達））または宛先到達不能メッセージ（つまりUDPパケットが最終ホストに到達したがポートが閉じている）を送信しないことを決定した場合、適切な動作）、tracerouteのその時点でタイムアウトが発生します。
つまり、traceroute xyz UDPベースのtracerouteと呼ばれる処理を行っています。これは、1から始まり、ステップごとに1ずつ増加する、低いTTLでUDPパケットを送信しています。 TTLが0になる場合、パケットがルーターで死ぬ場合、RFC 792や他のいくつかによれば、そのルーターは、ICMPの「時間超過」メッセージを送信する必要があります。期限内のパッケージですが、少なくとも私たちはあなたのパッケージが死んだとあなたに伝えます。
Tracerouteを実行する方法は他にも2つあります。違いをより深く理解したい場合は、 this one などのマンページをお勧めします。しかし、簡単に言えば、ICMPエコーパケットまたはTCP SYNパケットを送信することもできます。要約すると、すべてのTTLルート沿いの「ホスト」：
- 低TTLのホストでランダムポート（通常は33434 + 100）へのUDP
- 私の経験では、
tracerouteやtracertなどのすべてのコマンドラインツールのデフォルト
- 私の経験では、
- ICMP Echo to Host to low TTL
- これは、いくつかのグラフィカルツールで、またほとんどのコマンドラインツールのオプションとして発生しました。
- TCP SYNは、多くの場合80番ポートで、http-trafficは通常ICMPエコーとUDPパケットを通常とは異なるポートにドロップする多くのルーターによって渡されるため、トラフィックは「ちょっと」マスクされます。
- ホストへのルートを見つけるための、正統ではないが、きちんとしたトリックと「新しい」方法。あなたがインターネット標準を誤用しているという点で、正統ではありません。ほとんどのコマンドラインツールのオプションとして存在します。
ルーターは通常のトラフィックを通過させ、TCPベースのhttpリクエストを完了させますが、UDPを奇妙なポートに静かにドロップし、ハーフオープンTCP奇妙なポートまたは低TTLのICMP pingに、ローカルtracerouteプロセスを待機したままにし、そのストップでタイムアウトします。
Tracerouteは、データがパスを解決するときにWebサーバーに依存して応答を返します。これらのサーバーは、応答を提供したり、tracerouteに応答したりする義務はありません。したがって、データが目的の場所に到達しても、tracerouteは、応答が来ないのを待っています。
ユーザーとcnn.comの間のサーバーがtracerouteの応答を送信しないことを決定した場合、残りの応答が切り捨てられる可能性があります。