曖昧な「重い」を数式レベルで分解せよ。Ubuntu Pro環境におけるネットワーク障壁を完膚なきまでに特定する「レイヤー別診断レシピ」の全貌
Webサービスやインフラ運用において、最も曖昧で対応を難航させるトラブル——それが「なんとなく通信が遅い」「稀にタイムアウトする」という非決定的なネットワーク障害です。直感や気休めの再起動に頼る対応は、根本解決の遠回りになるばかりか、障害を深刻化させます。
本記事では、Ubuntu Pro（22.04 LTS/24.04 LTS）環境において、単なる導通確認（ping）を超えた「L3/L4/L7レイヤー別の決定論的診断レシピ」と、それらを統合する自動化スクリプト『net-doctor.sh』を提案します。
1. 経路とパケットロスをミリ秒単位で可視化する「L3/L4統合追跡法」
従来の ping や traceroute は単発の確認には便利ですが、間欠的なパケットロスや特定ホップでのジッター（遅延の揺らぎ）を見落としがちです。ここで威力を発揮するのが、双方を融合したインタラクティブ診断ツール mtr です。
単なる接続確認から「ロス発生地点の特定」へ
# Ubuntu Pro環境への導入とレポート出力 (100パケット計測)
sudo apt update && sudo apt install -y mtr-tiny
mtr --report --report-cycles 100 --no-dns 1.1.1.1
-
--report-cycles 100：100回の連続試行により、1%未満の微少なパケットロスも確率的に検出。 -
--no-dns：DNS逆引きによるレスポンス遅延を排除し、純粋なIPレイヤーのレイテンシを測定。
HOST: ubuntu-pro-server Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.1.1 0.0% 100 0.2 0.3 0.2 0.8 0.1
2.|-- 10.0.0.1 0.0% 100 4.1 4.5 3.8 12.1 1.2
3.|-- 203.0.113.55 12.0% 100 15.2 18.4 14.1 89.3 11.5
4.|-- 1.1.1.1 0.0% 100 14.8 15.1 14.2 18.0 0.6
上記のように「途中ホップでのみロスが発生し、最終目的地では0%」である場合、中間ルータのICMPレートリミットであり障害ではないと即座に判断できます。
2. カーネル内のソケット状態を直接覗く「ss＋TCPスタック解析」
レガシーな netstat は処理性能が低く非推奨です。現代のLinuxネットワーク解析の中核は ss（Socket Statistics）コマンドであり、netlink 内部インターフェースを通じてTCPスタックの詳細メトリクスを取得します。
ソケットバッファとTCP RTT（ラウンドトリップタイム）の可視化
# 接続中のTCPソケットのRTT・再送（retrans）・ウィンドウサイズを詳細表示
ss -ti 'sport = :http or sport = :https'
| 取得パラメータ | 意味と診断時の判定基準 |
|---|---|
rtt:12.4/2.1 |
平均RTT 12.4ms（ジッター ±2.1ms）。高すぎれば回線混雑や距離の問題。 |
retrans:2/15 |
再送回数。この値が頻発している場合、物理層やスイッチでのパケット破棄が疑われる。 |
send 100Mbps |
該当ソケットの推定実効帯域幅。 |
# 状態ごとのソケット集計（TIME-WAITの枯渇チェック）
ss -s
「アプリ層のレスポンス低下か、ネットワーク帯域の枯渇か。TCP内部の
retransとrttの値は嘘をつかない。」
3. 障害時にワンショットで一次切り分けを行う「自動化シェルスクリプト」
障害発生時の緊急時に手作業で複数のコマンドを打つのは時間がかかります。診断プロセスをコード化し、標準出力およびログファイルへと出力する自動化レシピを用意します。
ワンステップ診断スクリプト：net-doctor.sh
#!/usr/bin/env bash
set -euo pipefail
TARGET="${1:-1.1.1.1}"
LOG_FILE="/tmp/net_diag_$(date +%Y%m%d_%H%M%S).log"
exec > >(tee -a "${LOG_FILE}") 2>&1
echo "=========================================="
echo " Network Diagnostic Report - $(date)"
echo " Target: ${TARGET}"
echo " Host: $(hostname) ($(lsb_release -ds 2>/dev/null || echo 'Linux'))"
echo "=========================================="
echo -e "\n[1. Interface & Route Check]"
ip -brief addr show
echo "--- Routing Table ---"
ip route show
echo -e "\n[2. DNS Resolution Test]"
time dig +short "${TARGET}" || echo "DNS Lookup Failed"
echo -e "\n[3. Socket & TCP State Summary]"
ss -s
echo -e "\n[4. MTR Path Analysis (10 cycles)]"
mtr --report --report-cycles 10 --no-dns "${TARGET}"
echo -e "\n=========================================="
echo "Diagnostic complete. Saved to: ${LOG_FILE}"
# 実行権限の付与と実行
chmod +x net-doctor.sh
./net-doctor.sh example.com
ネットワークエンジニアリングが到達する決定論的世界
ネットワーク障害の現場において、「経験と勘」によるアプローチは時間とリソースを浪費します。
- レイヤーごとの責任分離（L3の経路問題か、L4のTCP制御問題か）
-
カーネル統計情報のダイレクトな抽出（
ssによる再送率の確認） - 測定のコード化と自動化（一貫したログ採取）
Ubuntu Pro環境の堅牢なLinuxカーネル機能を駆使し、コマンド群を「レシピ」として体系化・自動化することで、未知の障害であっても即座に再現性と客観性のある根拠を叩き出し、迅速な復旧へと導くことが可能になります。