【テクニカル・上級編】 pingによるRTT(Round Trip Time)計測とタイムアウト判定の仕組み – トラブルシューティング＆ネットワーク運用監視実践ガイド

pingの「その先」へ：RTT計測の深淵とパケットが語るネットワークの真実

「pingが通らない」という報告を受けたとき、新人エンジニアはただ呆然と画面を見つめる。だが、百戦錬磨のNOCエンジニアにとって、それは「ネットワークが発する静かな悲鳴」を解読するための最初のシグナルに過ぎない。

多くの人は ping を単なる疎通確認ツールだと思っている。しかし、ICMP Echo Request/Replyの往復に費やされる RTT（Round Trip Time）の微細な揺らぎには、カーネルのスタック処理から光ファイバーの物理的な遅延、さらにはロードバランサーの負荷状況まで、あらゆる情報が刻み込まれている。今日は、この「最も基本的だが最も奥深い」コマンドの裏側に潜む深淵を覗いてみよう。

—

1. RTTの計測ロジックと「見えない時間」の正体

ping が計測する RTT は、パケットがワイヤーに載った瞬間から、対向ホストのNICで受診され、カーネルのネットワークスタックを通り、即座に折り返されて戻ってくるまでの時間だ。

ここで注意すべきは、RTT が純粋な「伝搬遅延」だけではないという点だ。以下の要素がミリ秒単位の数値に複雑に絡み合っている。

シリアライゼーション遅延: パケットサイズが大きければ、NICから送り出すのに時間がかかる。
キューイング遅延: ルーターやスイッチのバッファでパケットが詰まれば、その分だけ RTT は跳ね上がる。
カーネル処理時間: Linuxの iptables や nftables でのフック処理、あるいは過負荷なCPUによるコンテキストスイッチ。

特に、ping の出力で見られる「揺らぎ（Jitter）」は、その先に潜むボトルネックの予兆だ。単に平均値を追うのではなく、標準偏差や最大値に注目することで、ネットワークの「不安定さ」を嗅ぎ取らなければならない。

—

2. タイムアウト判定の背後にあるロジックとチューニング

デフォルトの ping は、応答がなければ1秒待つ。しかし、地球の裏側のデータセンターと通信する際や、輻輳が激しい環境では、このデフォルト値が「誤検知」を招くことがある。

ここで、Linuxにおける ping のタイムアウト制御と、カーネルレベルのチューニングについて触れておこう。特にパケットロスを意図的に引き起こすような過酷な環境では、以下のパラメーター調整が不可欠だ。

# -W オプションでタイムアウトをミリ秒単位で指定する
# -i で送信間隔を短縮（flood pingと組み合わせる際は要注意）
# -q でサマリーのみ表示させるのがプロの流儀だ
ping -c 10 -W 200 -i 0.2 8.8.8.8

# 解説:
# -c 10: 10回送信
# -W 200: 200ミリ秒以上応答がなければタイムアウトとみなす（高速な環境向け）
# -i 0.2: 200ミリ秒間隔で連射（ネットワークへの負荷を考慮すること）

また、TCPのハンドシェイク最適化に関連して、sysctl でネットワークバッファを調整し、パケットロスに対する回復力を高めることも忘れてはならない。

# /etc/sysctl.conf に追記すべきパフォーマンスチューニング例
# TCPウィンドウサイズを拡張し、高遅延環境でのスループットを維持する
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_congestion_control = bbr # BBRアルゴリズムでパケットロス耐性を強化

—

3. 現代の脅威：ICMPフィルタリングとTLSハンドシェイクの罠

セキュリティ専門家として忠告しておきたい。現在、多くのクラウド環境や堅牢なファイアウォールは、ICMP を遮断するように設定されている。あるいは、ICMP の優先順位を極端に下げている。

このとき、ping が通らないからといって「ダウンしている」と断定するのは早計だ。実務では tcpping や hping3 を使い、TCPの SYN パケットを特定のポート（例えば 443/TCP）に送り込むことで、実機と同じトランスポート層での応答を計測するのが定石である。

# TCPポート 443 へのパケット到達性を確認する（hping3使用）
# セキュリティ機器を透過する実際のサービス疎通を模倣できる
sudo hping3 -S -p 443 -c 5 192.168.1.1

また、TLS ハンドシェイクの遅延は、RTT の3倍から4倍もの時間を食う。RTT が 50ms あれば、ハンドシェイクだけで 200ms 以上が溶ける計算だ。これを回避するためには TLS 1.3 の 0-RTT（Early Data）の導入や、QUIC（HTTP/3）への移行を検討すべきだ。ヘッダー圧縮（HPACK / QPACK）と併せれば、極限のパフォーマンスが実現できる。

—

最後に：ネットワークを「見る」ということ

ping の数値一つ一つに、背後のハードウェアの挙動を投影できるか。これがエンジニアとしての「解像度」を決定づける。

パケットはただ飛んでいるのではない。ルーターのASICを通り、光の中を走り、カーネルの深い階層で解析され、そして戻ってくる。その一連のドラマを想像し、cliの出力から物理層の異常を透視する。それこそが、我々NOCエンジニアが日々行っている「技術的な対話」なのだ。

教科書通りのコマンドを打つのは今日で終わりにしよう。次に ping を打つときは、その応答時間の「1ミリ秒」の中に、ネットワークの真実が隠されていないか、耳を澄ませてみてほしい。