pingで「死活監視」しているうちは素人。RTTの揺らぎからネットワークの深淵を読み解く
NOCの現場で「pingが通っているからネットワークは正常です」という報告を聞くと、私はいつも苦笑いしてしまう。pingはあくまで入り口に過ぎない。ICMP Echo Request/Replyの往復時間（RTT）が示すのは、単なる「疎通の可否」ではなく、ネットワーク機器のキューイング遅延、輻輳、そしてTCPスタックの振る舞いを示唆する貴重な先行指標だ。
本稿では、単なるパケットロス率の測定という枠を超え、極限のパフォーマンスを追求するエンジニアのためのping診断と、その先にあるカーネルチューニングの世界を紐解いていく。
—
1. RTTの揺らぎが語る「不可視のボトルネック」
標準的な ping コマンドで表示される mdev（mean deviation：平均偏差）を軽視してはならない。この数値こそが「ジッター」の正体だ。
特にクラウド環境のマルチテナントなネットワークにおいて、RTTがスパイク（急増）する瞬間は、多くの場合、スイッチやルータのバッファ溢れによる再送か、CPUの割り込み処理が滞留している証拠だ。
高精度な観測のためのコマンド選定
Linux環境であれば、iputils-ping ではなく fping を使うべきだ。なぜなら、fping はノンブロッキングI/Oを利用し、複数のターゲットに対して並列で高頻度な送信が可能なため、スパイクを見逃さない。
# -c 100: 100パケット送信
# -i 10: 送信間隔を10msに設定（ミリ秒単位のジッターを捉える）
# -Q 1: 1秒ごとの統計を出力
fping -c 100 -i 10 -Q 1 192.168.1.1この結果、もし mdev が平均値に対して10%以上乖離しているなら、物理層のCRCエラーか、バッファの枯渇を疑うべきだ。
—
2. TCPハンドシェイクとRTTの「物理的な限界」
アプリケーション層でレイテンシを語る際、多くが忘れるのが「TCPハンドシェイクの3往復」だ。TLS 1.3以前であれば、これに加えてTLSハンドシェイクが乗るため、RTTの3〜4倍の時間がデータ送受信開始までに費やされる。
RTT削減のためのカーネルチューニング
TCPの初期ウィンドウサイズ（initcwnd）を調整することで、最初のパケット交換で送信できるデータ量を増やし、TCP Slow Startによる遅延を抑止できる。
# 現在のルートキャッシュを確認
ip route show
# 特定のネットワーク経路に対して初期ウィンドウを10に設定（標準は10だが、環境により調整）
# これにより、コネクション確立直後のデータ転送効率が劇的に向上する
sudo ip route change default via 192.168.1.254 dev eth0 initcwnd 10—
3. ヘッダー圧縮とパケットロスの相関
広域ネットワーク（WAN）を跨ぐ際、MTUサイズを超過したフラグメンテーションは、パケットロス率を劇的に悪化させる。特にVPNやGREトンネルを掘っている場合、ヘッダーオーバーヘッドにより実効ペイロードが削られる。
ここで検討すべきは、TCP MSS Clamping だ。パケットが物理経路を通る際、断片化によるCPU負荷増大とロスを防ぐために、TCPヘッダーの MSS 値を強制的に小さくする。
# iptablesによるMSS調整例
# 1360バイトを上限に設定することで、オーバーヘッド分を吸収する
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1360—
4. セキュリティとパフォーマンスのトレードオフ：ICMPの扱い
セキュリティ専門家は「ICMPは遮断すべき」と教えるかもしれない。しかし、実務において MTU Path Discovery に使われる ICMP Destination Unreachable を全て遮断することは、ネットワークの「サイレントな停止」を招く。
パフォーマンスを極めるのであれば、必要なICMPタイプのみを許可し、レートリミットをかけるのが正解だ。
# レート制限をかけつつ、診断に必要なICMPを許可する設定例
sudo iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s --limit-burst 5 -j ACCEPT—
最後に：数字の裏側にある「息遣い」を感じろ
ネットワークトラブルは、多くの場合、データシート上には現れない「微細な事象の積み重ね」から始まる。RTTが0.5ms増えたこと、パケットが10万回に1回欠落したこと。これらを「誤差」として片付けるか、それとも「ネットワークが発しているSOS」と捉えるか。
シニアエンジニアである我々の仕事は、コマンドの出力をただ読むことではない。パケットがNICから送出され、光ファイバーを駆け抜け、対向のバッファで待機するその一連の「旅」を頭の中でシミュレーションし、ボトルネックを可視化することだ。
もし貴方の目の前でネットワークが揺らいでいるなら、まずは ping の結果からパケットの「息遣い」を聞き取ってみてほしい。そこには必ず、解決のヒントが隠されている。
コメント