ここまでどうやって来たのだろう？

 (how-did-i-get-here.net)
27 ポイント 投稿者 GN⁺ 2025-11-09 | 1件のコメント | WhatsAppで共有
  • ユーザーの パケットがインターネットを通ってウェブサイトのサーバーに到達する経路 をリアルタイムで可視化したインタラクティブページ
  • 自作の traceroute プログラム「ktr」 が ICMP パケットの TTL 値を活用して各ネットワークホップの情報を収集
  • ウェブサイトは JavaScript なしでも動作し、サーバーが traceroute の結果をストリーミング形式で HTML に反映
  • 経路分析には WHOIS・PeeringDB データ を用いて、各 IP が属する 自律システム（AS） と企業情報を表示
  • traceroute と BGP ベースのインターネット構造 を組み合わせ、インターネットが企業間の ピアリング関係で構成されたネットワークの集合 であることを示す

あなたのパケットがたどった旅

  • ページ上部の traceroute は、ユーザーのコンピューターからサーバーまでの パケット移動経路 を示している
    • ルーター、ISP、Amazon、NTT Global IP Network、Hetzner などのネットワークを順番に通過
    • 一部区間は「(no response)」と表示されるが、これは応答しないサーバーがあるため
  • Hetzner ネットワーク内部では複数のルーターを経由して最終サーバーに到達
  • IP アドレス 213.239.252.10 は 逆引き DNS 参照 によって core0.fra.hetzner.com と表示される

Behind the Scenes

  • ウェブサイトはユーザーのリクエストを受けると サーバー上で traceroute を実行 し、結果をリアルタイムで送信
  • traceroute は ICMP プロトコル を使い、TTL（Time To Live）値を 1 ずつ増やしながら各ホップの応答を収集
  • TTL が 0 になると該当ルーターがエラーメッセージを返し、これによって パケットが通過した経路を追跡 する
  • ktr は traceroute の結果をストリーミングしながら、各ホップの IP・ASN・所有ネットワーク情報 も同時に照会

Frontend Fun

  • JavaScript なしでも動作し、ブラウザーには単に ゆっくり読み込まれるページ のように見える
  • サーバーは HTTP 接続を維持したまま traceroute の結果を順次 HTML に挿入
  • 各更新ごとに CSS ブロックを挿入して前の結果を隠す方式 でリアルタイム更新の効果を実現

Front to Back, Back to Front

  • 実際には サーバーからユーザーの IP に向けて traceroute を実行 し、その結果を 逆順で表示 している
  • これは「reverse traceroute」であり、双方向の経路が完全に同一ではないものの おおむね似た経路 を示す

ネットワークと自律システム（AS）

  • インターネットは 自律システム（Autonomous System, AS） と呼ばれる 企業単位のネットワーク同士の接続網 で成り立っている
  • 各 AS は固有の ASN（Autonomous System Number） を持ち、相互の ピアリング（peering） を通じてトラフィックを交換
  • インターネットは個人ではなく 企業が所有するネットワークの集合 であり、接続は 金銭的契約と事務手続き によって決まる
  • ASN は 5 つの地域インターネットレジストリ（RIR） のいずれかを通じて申請できる

WHOIS と PeeringDB

  • traceroute の各 IP が属する AS を調べるために WHOIS プロトコル と PeeringDB データベース を使用
  • WHOIS は TCP 接続後にクエリーを送るとサーバーが情報を返すシンプルな構造
  • サーバーごとにフィールド名や形式が異なるため、パーサーは 人間が読むやり方に近いシンプルなシミュレーター形式 で実装
  • PeeringDB は全 AS の約 3 分の 1 について企業情報を提供

BGP（Border Gateway Protocol）

  • BGP はインターネットの形を決める中核プロトコル であり、AS 間で経路情報を交換する
  • 境界ルーター（border router）は BGP ルーティングテーブル を保持し、各経路の ASN 一覧を保存
  • 2 つの AS がピアリングすると、それぞれのルーターが BGP セッション を張り、経路広告（route advertisement） を交換
  • ルーターは複数の経路の中から 最短、または選好度の高い経路 を選んでパケットを転送

BGP の歴史

  • 1969 年の ARPANET に始まるネットワーク実験は、1989 年の Cisco と IBM の RFC 1105 へとつながり、BGP v1 が登場
  • その後 BGP v2（1990） 、v4（1994） が発表され、v4 は現在まで使われている
  • BGP は インターネット上のあらゆるネットワーク間の接続経路を決める 標準プロトコルとして定着した

Traceroute と BGP の関係

  • 例の経路: AS16509 → AS2914 → AS24940
    • Amazon（AS16509）→ NTT Global IP Network（AS2914）→ Hetzner（AS24940）の順
  • 同じ ASN 内にも複数のホップが存在し、これは内部ルーティングプロトコルや固定経路で処理される
  • AS 間のピアリング関係 がインターネット上で実際に到達可能かどうかを決定する

Recap まとめ

  • ウェブサイトはユーザーの IP に対して traceroute を実行し、その結果を HTTP ストリームで送信
  • traceroute は ICMP パケットの TTL を活用して ルーター間の経路を可視化 する
  • 各ルーターは 自律システム（AS） に属し、BGP によって相互接続されている
  • ピアリング関係 がインターネットの到達性と構造を決める

Epilogue

  • 作者はインターネット構造への理解不足を感じ、プロトコル中心の教育用インタラクティブ記事 を制作
  • 完成度の高い大規模プロジェクトではなく 小さくても公開することを選択 した
  • Hack Club コミュニティの励ましで完成し、オープンソースの traceroute プログラム を活用
  • 「小さくても完成しているほうがよい」というメッセージとともに、持続可能なウェブコンテンツ として残ることを願っている

関連記事

1件のコメント

 
GN⁺ 2025-11-09
Hacker Newsの意見

  • この reverse traceroute 機能は今でも有用だと思う ただし実際には、AS パスが同じでも ピアリングポイント はほとんど常に異なる ほとんどの AS は hot-potato routing を使って、トラフィックの発信元に最も近いピアリング地点へパケットを渡す cold-potato を使っていても非対称になる。さらに AS-path の長さが同じ場合でも、hot-potato ポリシーのために別の経路が選ばれることがある （編集: hot/cold の取り違えを修正）

    • traceroute と reverse traceroute を何度も回してみたが、たいてい AS パス は似た結果になった ただ、traceroute のほうが ISP 内部の経路をより多く見せる場合もあった 全体としては君の言う通りで、あとで hot-potato vs cold-potato ルーティングの違いについてもっと詳しく説明してみたい いずれにせよ、この reverse traceroute の結果だけでもインターネットの構造を説明するには十分だと思う
    • ちなみに、君が言っているのがまさに hot-potato routing だ 各 AS ができるだけ早くパケットを渡す仕組みだ 不公平に感じられるかもしれないが、宛先 AS 内部の詳細な経路は分からないので合理的な選択だ たとえばベルリンとハンブルクにネットワークがあり、相手側もその2都市でピアリングしているなら、近い場所で渡すほうが不要な往復を避けられる

  • traceroute が下から上へ1行ずつ読み込まれる理由を説明していた部分が面白かった JavaScript なしで CSS ブロックを定期的に挿入して前の状態を隠す方式とは、いかにもハック的で創造的だ

    • JavaScript なしでも Declarative Shadow DOM を使えば、順序が前後した HTML ストリーミングを実現できる 例と説明は このブログ記事 にうまくまとめられている

  • “This is not my beautiful website.” という文句が気が利いていると感じた

    • “This is not my beautiful home-page.” と返したのもセンスがあった

  • まだ試していないなら

    tracepath -m60 bad.horse

    そして

    openssl s_client -connect signed.bad.horse:443 -servername signed.bad.horse

    を実行してみるのを勧める

    • いいね！ Dr. Horrible への geeky なオマージュ っぽい tracepath の結果が “bad.horse” から始まって “he.rides.across.the.nation” などへ続くので本当に面白い
    • こういうのもある 
      ssh funky.nondeterministic.computer
    • それから 
      ssh watch.ascii.theater
      も試してみる価値がある

  • このプロジェクトが再び Hacker News のメインページ に載って、サーバーがしばらく重くなったそうだ Lexi が「明日また確認してほしい」と告知していた

    • 今は少し改善したらしい。並行性(concurrency) を少し追加し、次は Tokio を使うべきだという教訓を得たとのこと

  • タイトルを見て Talking Heads の曲が来ると思った

    • “letting the days go by” という歌詞が自動的に頭に浮かんだ
    • HTML を見ると何か隠されているかもしれない :)

  • “Once in a Lifetime” のリンクが脳に焼き付いた感じだ タイトルを見るだけであの ベースライン が自動再生される

    • 私もすぐに 存在論的危機 に襲われた

  • 実際に動かしてみたら、メインのインターネット接続が切れてバックアップ回線 に切り替わっていたことに気づいた 今日は停電があったのだが、このツールのおかげでそれに気づけた。かなり役に立った

    • 本当に あまり通らない経路(route less travelled) を見つけたわけだ

  • ときどき “You are here” の上部情報がこう表示される

    Host               ASN   Network         Region
123-456-789-101.static.kc.net.uk AS19905 UltraDDoS Protect    Global

    ところが別のときには

    Host               ASN   Network         Region
123-456-789-101.static.kc.net.uk AS12390 Kingston Communications Europe

    のように交互に出る。同じ IP なのに、なぜ ASN が 50:50 の割合で切り替わるのか 気になる。ランダムに変わっているように見える

  • ページは最初 JavaScript なしで正常に動作していたが、その後差し替えられた HTML が テキストとしてエンコード されてしまった

    
 #strYQt8 { display: none; }

    こんな感じで表示されて壊れていた この修正 PR を GitHub に上げた