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

こんにちは！NOC（ネットワークオペレーションセンター）で日々、モニターの向こう側のパケットたちと格闘しているシニアエンジニアです。

大規模なデータセンターで障害対応をしていると、「なんか最近、リモートデスクトップの動きがカクつくんだよね」「Web会議の音声が時々途切れるんだよ」といった、エラーログには現れない厄介な相談を本当によく受けます。こういう時、私たちが真っ先にスナイパーのように取り出すのが、おなじみの ping コマンドです。

「あぁ、あいつね。宛先に届くかどうか確認するやつでしょ？」と思ったそこのあなた。大正解です！でも、 ping の本当の実力は、単に「届く・届かない」を調べるだけじゃないんです。

今回は、 ping が返してくる往復遅延時間（RTT）の裏側にある「計測の仕組み」と、ネットワークの隠れた曲者である「ジッター（jitter：遅延のゆらぎ）」を算出する統計マジックについて、身近な例えを交えながら、泥臭く熱く紐解いていきたいと思います。

難しい専門用語に気おじする必要はありませんよ。一歩ずつ、一緒に理解していきましょう！

—

1. 郵便配達でイメージする ping のRTT（往復遅延時間）

まず、 ping がやっていることを現実世界に例えてみましょう。
あなたが遠くに住む友人に手紙を出すとします。

1. 手紙を出す（Echo Request）: 「元気？」と書いた手紙をポストに投函します。
2. 相手が受け取り、返事を書く: 友人が手紙を受け取り、すぐに「元気だよ！」とお返事を書いて送り返してくれます。
3. 手紙を受け取る（Echo Reply）: あなたの手元に返事が戻ってきます。

この「手紙を投函してから、お返事が手元に戻ってくるまでのすべての時間」が、ネットワークの世界でいう RTT（Round Trip Time：往復遅延時間） です。ミリ秒（ms）という、まばたきよりも一瞬の単位で計測されます。

私たちのコマンド画面には、こんな風に表示されますよね。

# ターゲットのサーバー（例: 8.8.8.8）に対してpingを4回送信してみます
$ ping -c 4 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=115 time=12.4 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=115 time=25.8 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=115 time=11.9 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=115 time=18.2 ms

おや？ 4回送ったうち、 time= の数字が 12.4 ms だったり 25.8 ms だったり、バラバラですよね。
「あれ？同じ宛先なのに、なんでスピードが毎回違うの？」と思いますよね。ここがネットワークの面白いところであり、悩ましいところなんです。

—

2. RTTの背後にある「遅延の正体」

パケットが通信回線を旅するとき、その時間はいくつかの要素に分解されます。

伝播遅延（がいこつ旅行の時間）: 光や電波がケーブルや空間を進む物理的な時間。距離が遠ければ遠いほど時間がかかります（東京から大阪より、東京からロンドンの方が遅いのはこれです）。
処理遅延（ルーターの考えごと）: 途中のルーターが「このパケットはどっちに行けばいいんだっけ？」と宛先を確認する時間。
キューイング遅延（渋滞待ちの時間）: 道路が混雑しているときに、料金所で車が列を作って待たされる時間。

この中で、一番厄介で、変動しやすいのが最後の 「キューイング遅延（渋滞）」 です。データセンターのネットワークスイッチや、インターネットの交差点では、一瞬一瞬で交通量が変わります。だから、 ping を打つタイミングによって、RTTが伸び縮みするわけなんです。

—

3. 「ジッター（Jitter）」ってなに？なぜそれが問題なの？

さて、ここからが本題です。
先ほどの ping の結果を見てみてください。

1回目: 12.4 ms
2回目: 25.8 ms （おっと、ちょっと遅い！）
3回目: 11.9 ms （また速くなった）
4回目: 18.2 ms

このように、「RTTのバラつき（ゆらぎ）」のことを、ネットワーク業界ではジッター（Jitter） と呼びます。

ファイルダウンロード（FTPやHTTP）であれば、多少パケットがバラバラに届いても、最後にパソコン側できれいに並べ直せばいいので、ジッターはあまり問題になりません。

しかし、ZoomやTeamsなどのWeb会議、IP電話、オンラインゲームはどうでしょう？
相手の声や映像が、
「あ、いま…（2秒止まる）…すいません聞こえますか！（早口）」
となったら、会話が成立しませんよね。リアルタイム通信の世界では、遅延が大きいこと（ハイラテンシー）以上に、ジッターが大きいこと（遅延が安定しないこと）が致命傷になるのです。

—

4. 現場のプロはどうやってジッターを算出しているのか？

実は、標準的な ping コマンドの画面をパッと見ても、「平均値はこれくらいだな」とは分かりますが、厳密なジッターの数値までは表示してくれないことが多いです。

そこで、現場のエンジニアや監視システム（ZabbixやPrometheusなど）は、複数回の ping で得られたRTTの時系列データから、統計的な計算を行ってジッターをはじき出しています。

代表的な算出方法の一つに、「隣り合う測定値の差の絶対値の平均（Mean Deviation）」 や、標準偏差（統計学でいうバラつきを表す指標）を使うアプローチがあります。

ちょっとイメージしやすいように、Python風の簡単なスクリプト（概念コード）でジッターを計算する仕組みを見てみましょう。

import math

# pingで計測したRTTのリスト（単位: ms）
rtt_list = [12.4, 25.8, 11.9, 18.2, 13.0, 14.1]

def calculate_jitter(rtts):
    """
    隣り合うRTTの差（変動幅）の平均をジッターとして簡易算出する関数
    """
    if len(rtts) < 2:
        return 0.0
    
    differences = []
    # 隣り合う測定値同士の差の絶対値を計算していく
    for i in range(len(rtts) - 1):
        diff = abs(rtts[i+1] - rtts[i])
        differences.append(diff)
    
    # 差の平均値を「ジッター（ゆらぎの大きさ）」とする
    jitter = sum(differences) / len(differences)
    return jitter

# 計算を実行
result_jitter = calculate_jitter(rtt_list)
print(f"計測されたRTTのリスト: {rtt_list}")
print(f"算出されたジッター値: {result_jitter:.2f} ms")

このコードの考え方はとてもシンプルです。「さっきの測定値と、今の測定値の間で、どれくらいスピードが急変したか」の差をひたすら集めて、その平均を取っているわけですね。この数値が小さければ小さいほど、ネットワークの道筋が安定している（ジッターが少ない）と言えます。

—

5. 実務で役立つ！ ping とジッター監視のTips

最後に、インフラ現場で私たちが日々行っている、ちょっと実践的なテクニックをいくつかご紹介しますね。

① 連続して高速に ping を打つ（パケット間隔の調整）

通常、Linuxの ping は1秒に1回しかパケットを飛ばしません。これだと、ネットワークの瞬間的な混雑（マイクロバースト）を取り逃してしまいます。
そんなときは、 -i オプションを使って送信間隔を短くしてみましょう。

# 0.2秒間隔（1秒間に5回）でパケットを送信する
$ ping -i 0.2 192.168.1.1

*(※注意：商用回線や他人のサーバーに対してこれをやると、DDoS攻撃と勘違いされたり、回線事業者から怒られたりするので、必ず自分の管理下にある検証環境や、許可された宛先で行ってくださいね！)*

② 標準の ping よりも専用ツール（fping や MTR）を使う

より高度に、かつリアルタイムにジッターを評価したい場合は、 fping や mtr というコマンドが非常に強力です。
特に mtr（My Traceroute）は、経路上のすべてのルーターでの遅延とジッターをマトリクス状にリアルタイム表示してくれるため、障害切り分けの際には手放せない神ツールです。

# mtrコマンドで経路上のジッターを可視化する（インストールが必要な場合あり）
$ mtr 8.8.8.8

—

まとめ

いかがでしたでしょうか？
今回は、 ping が叩き出す往復遅延時間（RTT）の裏側の仕組みと、リアルタイム通信の命運を握る「ジッター」の正体についてお話ししました。

RTT は、パケットの往復にかかったトータルの時間。
ジッター は、その時間のバラつき（ゆらぎ）のこと。
ネットワークの快適さは、遅延の「小ささ」だけでなく、変動の「少なさ（ジッターの低さ）」が鍵を握っている。

次に黒い画面（ターミナル）を開いて ping を打つときは、ただ数字の大小を見るだけでなく、「お、今ちょっと渋滞してるな」「このバラつき具合ならWeb会議は大丈夫そうだな」と、パケットたちの旅の様子を頭に思い浮かべられるようになっているはずです。

日々の地道なネットワーク監視やトラブルシューティング、一緒に楽しく乗り越えていきましょう！それでは、また次の現場でお会いしましょう！