こんにちは、かつコーチです。
ここまでIPアドレス、DNS、HTTP、TCP/UDPと通信の仕組みを学んできました。
今回はいよいよ実践編として、「相手先に通信できているか」を実際に手を動かして確認するpingとtracerouteコマンドを解説します。
「サイトが表示されない」というトラブルが起きたとき、真っ先に使う調査コマンドです。
pingとは？疎通確認の基本
配達物が届くか確認する「着払い確認」という比喩
pingとは、相手先の機器に対して小さなデータを送り、返事が返ってくるかを確認するコマンドです。
これは、荷物を送ったときに「ちゃんと届きましたか」と配達確認の電話を1本かけるようなイメージです。
返事が返ってくれば、少なくとも道のり（ネットワーク経路）はつながっていることがわかります。
内部的にはICMP（Internet Control Message Protocol、ネットワーク機器同士がエラーや状態を通知し合うためのプロトコル）というOSI参照モデル第3層の仕組みを使って、この確認を行っています。
pingコマンドの使い方
実際にターミナルでpingを実行してみましょう。
# Googleのパブリックサーバーに対して疎通確認（4回送信）
ping -c 4 8.8.8.8
# ドメイン名を指定してDNSの名前解決も含めて確認
ping -c 4 example.com
実行すると、以下のような結果が返ってきます。
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=115 time=12.345 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=115 time=11.982 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=115 time=13.021 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=115 time=12.556 ms
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 11.982/12.476/13.021/0.377 ms
timeが応答にかかった時間、packet lossが届かなかった割合です。
-cオプションは送信回数の指定で、Windowsでは-cの代わりに-nを使います。
tracerouteとは？経路をたどる仕組み
郵便物の配達記録・中継地点をたどる比喩
pingが「届いたかどうか」だけを教えてくれるのに対し、tracerouteは「どの中継地点を通って届いたか」を1つずつ教えてくれます。
これは、郵便物の配達記録を確認して、どの集配局を経由して届いたかを追跡するようなイメージです。
途中のどこかで配送が止まっていれば、traceroute（Windowsではtracert）を使うことで「どの中継地点まではたどり着けているか」を切り分けられます。
tracerouteコマンドの使い方
# macOS / Linux
traceroute example.com
# Windowsの場合はコマンドプロンプトで
tracert example.com
実行結果は次のように、経由したルーターが1行ずつ表示されます。
traceroute to example.com (93.184.216.34), 64 hops max
1 192.168.1.1 (192.168.1.1) 1.234 ms 1.102 ms 1.056 ms
2 10.0.0.1 (10.0.0.1) 5.678 ms 5.432 ms 5.321 ms
3 203.0.113.1 (203.0.113.1) 12.345 ms 11.987 ms 12.111 ms
4 * * *
5 93.184.216.34 (93.184.216.34) 20.456 ms 20.123 ms 19.987 ms
各行が1つの中継地点（ルーター）で、応答時間が3回分表示されます。
* * *は、その中継地点からの応答が返ってこなかったことを示しています。
よくあるつまずきポイント・エラー対処
pingが通らないのにブラウザは繋がるケース
以前、クライアントから「サーバーにpingが通らないので落ちているのでは」と連絡を受け、確認したところ、実際にはブラウザからサイトには問題なくアクセスできる状態でした。
❌Before：pingの結果だけで「サーバーがダウンしている」と判断する
✅After：ping（ICMP）とHTTPアクセス（TCP）は別物と理解し、
curlやブラウザでの疎通も合わせて確認する
原因を調べると、サーバー側のファイアウォールでICMP（ping応答）だけをセキュリティ対策として意図的にブロックしており、HTTP通信（ポート443）は正常に通っていました。
pingが失敗しても即座に「サーバーダウン」と判断せず、目的のサービスが動くポートで確認することが大切だと学んだ出来事です。
応用・一歩先の使い方
パケットロス率と応答時間の見方
pingの結果に出てくるpacket loss（パケットロス率）が高い場合は、途中の経路が混雑しているか、不安定な状態にある可能性があります。
timeの値が大きくばらついている場合も、回線品質に問題がある兆候です。
継続的に様子を見たい場合は、回数を指定せずに実行し続けるオプションも便利です。
# macOS / Linuxで継続的にpingを送り続ける（Ctrl+Cで停止）
ping example.com
障害調査の際は、pingで大まかな疎通を確認し、tracerouteでどこまで届いているかを絞り込む、という順番で使うのが基本の流れです。
まとめ
この記事のポイント
- pingは「配達確認の電話」のように、相手に届いているかを1本の応答で確認するコマンド
- tracerouteは「配達記録」のように、経由した中継地点を1つずつたどるコマンド
- pingが失敗してもHTTPなど目的のサービスは動いていることがあるため、目的のポートでの確認も併用する
- パケットロス率や応答時間のばらつきは、回線品質を判断する材料になる
次に読むべき記事
- ネットワークトラブルシューティングの基本の流れ
タグ: ネットワーク, 中級者向け, 実践Tips