pingだけでは分からない「ネットワークが遅い」の正体――2万人会場に学ぶ“切り分け方法”：“どこが遅いのか”を調べる

Webサイトの表示やアプリケーションの応答が遅いとき、ネットワークのどこに問題があるのか。Ciscoは、「Black Hat USA 2026」のネットワーク運用で活用した“通信の遅延を切り分ける手法”を公開した。

[＠IT]

　ネットワークの遅延を調べる際によく使われるのが「ping」や「traceroute」といったコマンドだ。通信先までの応答時間や経路を確認できるが、これらの結果だけでは、Webサイトの表示やサービスの応答が遅くなっている原因を特定できないことがある。

　こうした問題は、2万人を超える参加者が集まったセキュリティカンファレンス「Black Hat USA 2026」のネットワーク運用でも調査の対象となっていた。

pingだけでは分からない「なぜ遅いのか」――どう調べる？

　Cisco Systems（以下、Cisco）は2026年9月7日（米国時間）、Black Hat USA 2026で実施したネットワーク監視の取り組みと、Linuxコマンドを使って通信の遅延を詳しく調べる手法をブログで公開した。

　会場ではネットワーク監視サービス「ThousandEyes」の複数の監視エージェントを配置し、HTTPS接続、DNS（ドメインネームシステム）の名前解決、ファイルのダウンロード速度などを継続的に測定した。

　こうした監視に加えて、問題が発生した際に通信のどこで遅延が起きているのかを詳しく調べる手段も必要だった。

　Ciscoによると、Black Hatなどのカンファレンスでは、特定のプロトコルに関係する遅延が発生し、pingやtracerouteだけでは十分に調査できないケースがあったという。

　そこで活用したのが、Linuxの「curl」コマンドだ。

　WebサイトへのHTTPS接続では、一般にDNSによる名前解決、TCP接続の確立、TLSによる暗号化通信の確立、HTTPリクエストの送信とサーバからの応答受信といった複数の処理が発生する。

　curlでは、これらの処理にかかった時間を個別に測定できる。Ciscoは、HTTPS通信の所要時間を各指標に分けて表示するコマンドを紹介した。

curl -sS -o /dev/null \
-w '%{time_namelookup} %{time_connect} %{time_appconnect} %{time_starttransfer} %{time_total}\n' \
https://example.com |
awk '{
printf "DNS lookup: %8.2f ms\n", $1 * 1000
printf "TCP connection: %8.2f ms\n", ($2 - $1) * 1000
printf "TLS handshake: %8.2f ms\n", ($3 - $2) * 1000
printf "Wait for first byte: %8.2f ms\n", ($4 - $3) * 1000
printf "Total: %8.2f ms\n", $5 * 1000
}'
DNS lookup: 73.30 ms
TCP connection: 37.77 ms
TLS handshake: 64.52 ms
Wait for first byte: 48.11 ms
Total: 224.94 ms

　このコマンドでは、curlが取得した各処理の経過時間を「awk」で加工し、ミリ秒単位で表示する。Ciscoが示した実行例は次の通りだ。

測定項目	所要時間
DNS名前解決	73.30ミリ秒
TCP接続	37.77ミリ秒
TLSハンドシェイク	64.52ミリ秒
最初の1バイトを受信するまでの待ち時間	48.11ミリ秒
合計	224.94ミリ秒

　例えば、DNS名前解決に時間がかかっていればDNS関連の処理を、TCP接続の確立が遅ければ通信経路や接続先の状態を重点的に調べるといった判断につなげられる。

　ただし、最初の1バイトを受信するまでの待ち時間には、サーバ側の処理だけでなくネットワーク通信の時間も含まれるため、測定値だけで原因を断定できるわけではない。

DNSの調査には「dig」も活用

　Ciscoは、curlによる調査ではDNSキャッシュの影響にも注意が必要だと説明する。

　同じWebサイトに対して繰り返しコマンドを実行すると、DNSの名前解決結果がキャッシュから取得され、DNSサーバへの問い合わせが省略される場合がある。Ciscoが示した実行例でも、先ほどは73.30ミリ秒だったDNS名前解決の所要時間が、別の測定では4.86ミリ秒となっていた。

　こうしたキャッシュの有無によって測定結果が大きく変わる可能性があるため、DNSサーバへの問い合わせにどの程度の時間がかかっているのかを詳しく調べるには、別の方法が役立つ。

　Ciscoが紹介したのが「dig」コマンドだ。DNSサーバを指定して問い合わせを実行し、応答にかかった時間を確認できる。

　Ciscoは、パブリックDNSサーバに問い合わせ、応答時間を表示する次のコマンドを紹介している。このコマンドでは、「Cisco Umbrella」のパブリックDNSサーバ（208.67.220.220）に問い合わせ、応答にかかった時間だけを表示する。

$ dig @208.67.220.220 example.com | grep -i "query time"
;; Query time: 61 msec

　指定したDNSサーバへの問い合わせにかかった時間を測定できる。ただし、DNSサーバ側のキャッシュや通信経路の状態などによって結果が変わる可能性があるため、複数回の測定や他の監視情報との比較が重要になる。

Webサイトの表示遅延、原因は意外な場所にあった

　こうした調査が役立った例として、Ciscoは別のカンファレンスで発生したネットワーク障害を紹介している。

　この事例では、Webサイトの表示が遅くなるなど、一見するとネットワーク全体に遅延が発生しているように見える問題が起きていた。通信の処理を個別に調べたところ、問題は主にDNS名前解決に集中していたことが分かった。原因は、NAT（ネットワークアドレス変換）で利用するリソースの枯渇だった。

　NATは、端末が外部ネットワークと通信する際にIPアドレスやポート番号を変換する仕組みだ。この事例では、DNS問い合わせに伴う通信でNATのポート割り当てが失敗し、名前解決に影響が生じていた。

　Ciscoは、プロトコルごとに遅延を切り分けたことで問題の所在を絞り込み、その後、パケットキャプチャーによって実際の通信状況を確認したという。

　Webサイトの表示が遅いという症状だけでは、DNS、通信経路、サーバなど、どこに原因があるのかは分からない。ネットワークの状態を継続的に監視するだけでなく、通信の各処理にかかる時間を個別に調べることが、問題の切り分けにつながる。