「ネットワークが遅い」という申告もさまざまな場面で聞く苦情のひとつです。こちらも考えられる原因はいろいろあります。最初にやるべきは影響範囲のヒアリングでしょう。
たとえば、特定のWebサイトやサーバにアクセスするときだけ遅いのであれば、ネットワークの問題ではなくて該当のサーバ側の問題である可能性が高くなりますし、特定の個人マシンでだけ発生するのであれば、該当マシンでプロセスが暴走してCPUを使いきっているだけかも知れません。
ping応答による原因の切り分け
ヒアリングと合わせて有効なのが、図1のpingコマンドによる応答状況の確認です。
-tを付けることで、[Ctrl]+[C]で強制終了させるまで継続してpingコマンドが実行されます。デフォルトでは4回で終了してしまいますが、傾向を見る上では数十秒位続けた方がよいでしょう。
サーバをIPアドレスで指定した場合と名前で指定した場合との応答を見比べることをお勧めします。名前でアクセスした時に初回の応答までにちょっと間が空くという場合は、ネットワークの問題ではなく、名前をIPアドレスに変換する名前解決機構の問題であると推測できます。
名前解決機構のトラブルシューティング
名前解決機構のトラブルシューティングはかなり繁雑ですが、まずは図2のipconfig /allコマンドでDNSサーバが構成されている場合は、そのDNSサーバにアクセス可能かを確認してみましょう。とくに1台目のDNSサーバに障害が発生しており、2台目以降を使って名前解決が成功している場合は、結果として応答が「遅く」なりますので、注意が必要です。
DNSサーバへのアクセスに問題がない場合は、図3のようにnslookupコマンドで明示的に問い合わせ先のDNSサーバを指定して名前解決を行ってみることをお勧めします。
DNSサーバで名前解決が失敗しているにもかかわらず、最終的に名前解決が成功している場合は、LMHOSTSファイルやWINSサーバを用いて名前解決が成功している可能性が考えられます。これは通常ネットワーク管理者の意図する動作ではないと思いますので、名前解決の構成を見直した方がよいでしょう。
回線の輻輳、回線品質の確認
万一、図1で「Request timed out.」が混在している場合は、パケットの消失が発生していることがわかります。画面が流れてしまった場合は、[Ctrl]+[C]を押下すると現れる統計情報画面でパケットの消失有無を確認できます。消失が発生している場合は、パケットの再送が発生しますので、結果として通信が遅くなります。
この場合は、本当に通信量が多く回線が輻輳している、あるいは回線自体の品質が悪いといった可能性が考えられます。なお、デフォルトのパケットサイズ(32バイト)で問題が発生しなかった場合、図4のように-lオプションでパケットサイズを500バイト程度の大きさにして、パケットの消失が発生しないかを確認してみましょう。これで消失したりしなかったりといった現象が発生する場合も、回線の輻輳や品質の問題が疑われます。
ただし、一定のバイト数までは消失が0%であるにもかかわらず、その大きさを1バイトでも超えるとパケットが100%消失するという場合は、途中の機器の設定で(ICMPのペイロードが)その大きさ以上のパケットの通過を禁止していると思われますので、「遅い」という現象とは無関係だと考えられます。
MTUサイズの確認
この他、「遅い」要因としてはMTUサイズの問題も考えられます。pingコマンドに対する応答があることが前提ですが、図5のようにpingコマンドに「-f -l サイズ」オプションを付けてプロバイダ側の直近のルータやサーバ(もしくはアクセスが遅いという申告があるサーバ)にpingを行い、「...but DF set.」というメッセージが表示されない最大のサイズを確認します。その上で、LANインターフェースのMTUを「最大サイズ+28」に設定することで速度が改善されます。
たとえばフレッツADSLなどではMTUを1454バイトに設定することが推奨されています。なおこの原理や便利な設定ツールなどについては、検索エンジンで「1454 MTU 変更」といったキーワードで検索すると情報を掲載しているサイトが多数ヒットしますので、そちらを参照してみてください。
パケットキャプチャが必要な場合
これらの切り分けを行っても原因の追求ができない場合、あるいはサーバ側に原因があるかどうかを明示的に切り分けたい場合などは、パケットキャプチャの取得が必要となります。可能であればクライアント側とサーバ側で、「遅い」とされる一連の通信について取得を行い、パケットの消失、再送、重複などが発生していないか、サーバからは妥当な時間内に反応が戻ってきているかといった点を調査します。たとえばクライアントから正常に通信が送出されているにも関わらず、サーバに到達した時点では異常が発生しているという場合は、中間のネットワーク機器に問題があると想定されますので、そこまで正常に到達しているのか、経路途中でパケットキャプチャを取得して切り分けていきます。残念ながら定番の方法はないので、機器、ネットワーク構成を勘案した上での対応が必要となります。
筆者がいままで経験したネットワーク側に問題があるケースとしては、ルータの全二重、半二重の設定ミスによるパケット消失、オフロード機能の問題によるTCPシーケンス異常、ロードバランサや負荷分散装置の不具合によるパケット重複や不正なRST送出といったケースがありますが、これ以外にもさまざまな要因が考えられます。