【実務・中級編】 pingの往復遅延時間(RTT)計測アルゴリズムとjitterの算出 – トラブルシューティング＆ネットワーク運用監視実践ガイド

PingのRTTとJitter：その「一瞬のゆらぎ」に潜むネットワークの真実

「Pingが通るからネットワークは正常」。もし君がそう思っているなら、そろそろその甘い考えを捨てる時期だ。

データセンターの深夜、バックエンドのマイクロサービスが断続的にタイムアウトを起こす。アプリ側のログには 504 Gateway Timeout。しかし、監視ツール上のPingグラフは「オールグリーン」。これが現場で最も胃が痛くなる瞬間の一つだ。

ネットワークの世界において、平均的な遅延（RTT）以上に重要なのが、その「揺らぎ」、すなわち Jitter（ジッター） である。今日は、Pingという枯れた技術の奥底に眠る統計メカニズムと、それを実務でどう武器にするかについて語ろう。

—

1. RTTの計測アルゴリズム：ICMPの旅路

Pingは、ICMP Echo Request を投げ、ICMP Echo Reply を待つ。この往復時間（RTT: Round Trip Time）の計測は、OSのカーネルレベルで高精度タイマーを用いて行われる。

RFC 792で定義されたこの挙動だが、実務で意識すべきは「どこで計測が止まっているか」だ。

送信（T1）: Echo Request をNICから送出した時刻。
受信（T2）: Echo Reply のパケットヘッダーをNICが捉えた時刻。

RTT = T2 - T1。このシンプル極まりない計算が、ネットワークの品質を決定づける。だが、注意してほしい。OSのユーザー空間で実行される ping コマンドの結果には、カーネルのスケジューリングの誤差が乗る。コンテナ環境や高負荷なホストでは、この「ノイズ」が計測結果を汚染する。これをどう読み解くかが、シニアの腕の見せ所だ。

—

2. Jitterの正体：平均値という名の「嘘」

Jitterとは、連続するパケット間でRTTがどれだけ変動したかを示す値だ。

例えば、RTTが 10ms, 12ms, 10ms, 11ms と推移すれば安定しているが、10ms, 50ms, 10ms, 60ms となると話は別だ。後者は平均すれば 32ms だが、実際にはバッファ溢れや輻輳が起きている。

Jitterの計算式は、RFC 3550（RTPプロトコル）で標準化されているような手法を用いるのが一般的だ。

# 簡易的なJitter計算ロジック
import time

def calculate_jitter(current_rtt, previous_rtt, current_jitter):
    # RFC 3550準拠の計算式を簡略化したもの
    # 差分の絶対値をとる
    diff = abs(current_rtt - previous_rtt)
    # 平滑化して変動を算出
    return current_jitter + (diff - current_jitter) / 16

# 運用監視のスクリプトに組み込む際は、移動平均を利用してスパイクを検知する

Jitterが大きいということは、ネットワーク機器のキューイング遅延が不安定であることを意味する。Web APIのレスポンスが「速い時と遅い時がある」という現象の正体は、このJitterにある可能性が高い。

—

3. 実践：CLIによる計測とデバッグ

ただ ping を打つだけでは素人だ。現場では、パケットのサイズとインターバルを操作して、論理的な負荷をかける。

# 1秒間隔で1000バイトのペイロードを送信（MTU境界付近の遅延を調査）
# -i 0.2 は200ms間隔。微小なパケットロスを検知するのに有効
sudo ping -s 1000 -i 0.2 192.168.1.1

# もしLinuxでJitterを詳細に見たいなら mtr が必須
# --report-wide オプションで詳細な統計を表示する
mtr -rw 8.8.8.8

mtr は traceroute と ping を組み合わせたもので、パス上の全ホップのJitterを可視化してくれる。特定のルーターでJitterが跳ね上がるなら、そこがボトルネックだ。

—

4. アプリケーション層からの計測：Fetch APIの罠

Webエンジニアが「ブラウザからPingが打てない」と嘆くことがあるが、当然だ。ブラウザはICMPを使えない。そこで fetch や XMLHttpRequest を使って疑似RTTを計測するわけだが、これには「TCPハンドシェイク時間」が含まれることを忘れてはならない。

// APIのレイテンシを計測する際のTips
async function measureLatency(url) {
  const start = performance.now();
  try {
    // HEADメソッドはレスポンスボディを落とさないので軽量
    await fetch(url, { method: 'HEAD', cache: 'no-store' });
    const end = performance.now();
    return end - start; // これはTCP+TLS+RTTの総和
  } catch (e) {
    console.error("計測失敗:", e);
  }
}

この値と、OS上の ping 値の乖離が大きければ、それはネットワークではなく「サーバー側のアプリケーションの処理遅延（あるいはTCPスタックの輻輳制御）」が原因であると切り分けられる。

—

最後に：ネットワークは「生き物」だ

トラブルシューティングで最も恐ろしいのは、計測したその瞬間だけネットワークが「良い子」になることだ。だからこそ、我々は統計的なアプローチをとる。

平均値に騙されないこと：Jitter（最大値と最小値の差）を見ろ。
パケットサイズを変えること：小さなパケットは通るが、大きなパケットが断片化・破棄されるケースは多い。
コンテキストを忘れないこと：ツールが出した数字を鵜呑みにせず、それが「どの階層の遅延なのか」を常に問い続けること。

ネットワーク運用は、いわば暗闇の中でのパズルだ。だが、今日話したJitterの概念さえ持っていれば、暗闇の中でも「どこが歪んでいるか」という指針は見えてくるはずだ。健闘を祈る。