tracerouteが語る「嘘」：非対称ルーティングを見抜く現場の知見
データセンターの深夜、アラートの音が鳴り響く。監視ダッシュボードには特定のリージョン間でのレイテンシスパイクが刻まれている。インフラエンジニアにとって、この瞬間が最も心拍数を高める。
「パケットがどこで迷子になっているのか？」
多くの若手エンジニアは traceroute を打ち、表示されたホップ数を見て安心する。だが、我々のような現場の人間にとって、traceroute は単なる「経路探索ツール」ではない。それは、複雑怪奇なインターネットの深淵を覗き込むための、唯一の、そしてしばしば「嘘をつく」観測装置だ。
1. 非対称ルーティングという「不可視の罠」
ネットワークエンジニアが最初に学ぶべき教訓は、「往路と復路は同一であるはずだ」という性善説を捨てることだ。BGP（Border Gateway Protocol）が支配する広域ネットワークにおいて、経路の非対称性はもはやデフォルトと言っていい。
あなたが traceroute を実行したとき、表示されるのは「往路」のホップだけである。もし、往路は最短パスを通っているのに、復路で地球の裏側を経由していたら？当然ながら、TCPのハンドシェイクは深刻な遅延を抱え、RTT（Round Trip Time）は跳ね上がる。
非対称ルーティングを可視化するテクニック
標準的な traceroute では不十分だ。我々は paris-traceroute のようなツールを活用する。これは、フロー識別子（UDP ポート番号や TCP シーケンス番号）を固定し、L3レベルでのロードバランシングを突き抜けて「特定の経路」を正確にトレースするためのものだ。
# パスごとの変動を抑え、特定のフローの経路を追跡する（Paris Tracerouteの概念）
# -q 3 で各ホップ3回試行し、経路の揺らぎ（Equal-Cost Multi-Path）を検知する
sudo traceroute -n -I -q 3 203.0.113.1もし、ICMP Time Exceeded が返ってくるホップが不自然に揺れ動くなら、そこには ECMP（Equal-Cost Multi-Path）が存在する。ここで注目すべきは、最終ホップ付近での RTT の急増だ。これが観測されたなら、それはバックボーンでの混雑ではなく、復路のISPピアリングにおける「政策的な遠回り」を疑うべきだ。
2. トランスポート層の最適化：RTTとTCPバッファの相関
非対称ルーティングによって RTT が長くなると、TCP のスループットは BDP（Bandwidth-Delay Product）の壁にぶつかる。
スループット = TCPウィンドウサイズ / RTT
この式を忘れてはならない。往復で時間がかかるということは、パケットが帰ってくるまでの間に送信できるデータ量（インフライトデータ）を増やすために、カーネルのウィンドウサイズを動的に拡張する必要がある。
# LinuxカーネルのTCPバッファチューニング（sysctl.conf）
# 広帯域・高遅延環境（LFN: Long Fat Networks）向けの設定例
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
# 自動調整を有効にし、かつ上限を大きく引き上げる
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# RTTが大きい場合に有利なTCP BBRアルゴリズムへの切り替え
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbrBBR（Bottleneck Bandwidth and RTT）は、現在のネットワークコンディションにおいて最も強力な武器だ。従来の Cubic がパケットロスを「混雑のサイン」と誤認してウィンドウを縮小するのに対し、BBR はスループットと遅延を直接計測して最適解を導き出す。非対称な環境下でこそ、BBR の真価が発揮される。
3. TLSハンドシェイクとヘッダー圧縮の罠
非対称ルーティングは、TLS ハンドシェイクのパフォーマンスにも影を落とす。TLS 1.3 では 1-RTT ハンドシェイクが導入されたが、それでも往復の遅延が加算されれば、Webページの初回描画（FCP）には致命的な影響が出る。
ここで重要なのが HTTP/2 や HTTP/3 のヘッダー圧縮（HPACK / QPACK）だ。ネットワークの遅延が避けられないのであれば、物理的なパケットサイズを削り、セッションのステートフルな再利用を徹底するしかない。
- 0-RTT（Early Data）の是非: セキュリティとパフォーマンスのトレードオフをどう捉えるか。リプレイ攻撃のリスクを許容できるAPI設計であれば、迷わず導入すべきだ。
- TCP Fast Open (TFO): 初回接続からデータを送ることで、ハンドシェイクのオーバーヘッドを削減する。ただし、ミドルボックス（ファイアウォールやIDS）が
TFOを「不正なパケット」と見なして破棄するケースがあるため、パケットキャプチャでの監視は必須だ。
最後に：エンジニアとしての嗅覚
トラブルシューティングにおいて、最後に行き着くのは「ツール」ではなく「エンジニアの嗅覚」だ。traceroute の結果に現れるホップごとの RTT の揺らぎ、TCP セッションの再送カウント、そして TLS ハンドシェイクのタイミング。これらをパズルのピースのように組み合わせ、脳内で物理的なパケットの流れを再現する。
「データは嘘をつかない」という言葉があるが、ネットワークにおいては「データは観測者の立場を反映する」というのが正しい。非対称ルーティングというインターネットの宿命を理解し、その上で TCP スタックをいかにしなやかに制御するか。
それこそが、大規模データセンターを支えるエンジニアの矜持だ。今夜もまた、コマンドプロンプトの先にある未知の経路に思いを馳せながら、我々はパケットを流し続ける。
コメント