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

Pingの向こう側に何が見えるか――RTTとタイムアウトが語る「ネットワークの体温」

障害対応の現場に立つと、まず最初に打つのが ping だ。新米エンジニアは「疎通確認」という言葉だけで片付けるが、百戦錬磨のエンジニアにとって、ping はネットワークの健康状態を測る「聴診器」に他ならない。

単に「返ってきたか、否か」だけで満足してはいけない。返ってくるまでの時間（RTT）が何を意味し、なぜタイムアウトするのか。その裏側のロジックを理解することこそが、複雑なネットワークトラブルを紐解く第一歩だ。

RTT（Round Trip Time）の正体：パケットの往復旅路

ping が実行されると、クライアントはICMPの「Echo Request」パケットを送信する。ターゲットホストがそれを受け取り、即座に「Echo Reply」を返送する。この往復にかかる時間が RTT だ。

この数値が示すのは、単なる距離ではない。

物理的伝搬遅延: 光ファイバー内を光が走る時間。
シリアライズ遅延: パケットが物理線路に乗るまでの処理時間。
キューイング遅延: 途中のルーターやスイッチのバッファでパケットが順番待ちをしている時間。

特に厄介なのが「キューイング遅延」だ。ここが揺らぐ（ジッターが発生する）場合、ネットワークのどこかで輻輳が起きているか、あるいはNICの負荷が高まっている可能性が高い。

タイムアウトの仕組み：なぜ「待ち」が必要なのか

ping には必ず timeout という概念が存在する。これは、「指定した時間内に応答がなければ、パケットがロストした（あるいは帰ってこない）とみなす」という境界線だ。

OSのスタックレベルでは、タイマーがセットされる。ping コマンドで -W (待機秒数) を指定する際、実務ではこの値を慎重に決める必要がある。

短すぎると: ネットワークが一瞬混雑しただけで「ロス」と判定され、誤検知を招く。
長すぎると: 障害検知の初動が遅れ、サービスダウンの時間が延びる。

実践：計測とデバッグの現場テクニック

現場では、標準の ping だけでは足りないことが多い。特にWeb APIの疎通確認や、負荷が重いサーバーへの調査では以下のツールを使い分ける。

1. 高精度な計測を行う（fping の活用）

標準の ping は1パケットずつ待つが、fping を使えば複数のターゲットに対して非同期で並列送信できる。大規模なセグメント調査で「どこまで届いているか」を可視化するのに最適だ。

# 192.168.1.0/24の範囲を一斉にスキャンし、応答時間を計測する
# -g: ネットワーク指定, -c 3: 各ホストに3回送信
fping -g 192.168.1.0/24 -c 3

2. Pythonでカスタムヘルスチェックを書く

WebサービスのAPIエンドポイントに対して、単なる ping ではなく TCP SYN での疎通確認を行いたい場合、Pythonで簡易的な計測スクリプトを書くのが手っ取り早い。

import socket
import time

def check_latency(host, port, timeout=2):
    # ソケットを作成
    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    sock.settimeout(timeout)
    
    start = time.perf_counter()
    try:
        # TCPハンドシェイクのみを実行
        sock.connect((host, port))
        end = time.perf_counter()
        return (end - start) * 1000 # ミリ秒単位に変換
    except socket.timeout:
        return None
    finally:
        sock.close()

# APIサーバーの応答時間を計測
print(f"Latency: {check_latency('api.example.com', 443):.2f} ms")

障害対応における鉄則：平均値に騙されるな

ping の結果で最も注意すべきは「平均（Average）」だ。
100回送って平均が5msだったとしても、そのうち数回が100ms跳ね上がっていれば、それは「マイクロバースト」という立派な障害の兆候である。

現場でトラブルシューティングを行う際は、必ず最大値（max）と標準偏差（mdev）を見る癖をつけよう。特に mdev が大きいときは、ネットワーク経路のどこかでバッファあふれが起きている可能性が高い。

最後に：CLIを使いこなすということ

「なぜこの数値が出ているのか？」を推測し、検証コマンドで裏付けをとる。このプロセスを繰り返すことが、エンジニアとしての確かな経験値になる。

教科書的な知識はあくまで地図であり、現場のパケットの挙動こそがコンパスだ。今日学んだ ping のRTTとタイムアウトの概念を、ぜひ次回の運用監視やトラブルシュートで活用してほしい。パケットが語る声に耳を澄ませば、障害の正体は必ず見えてくるはずだ。