Windows管理者のためのネットワークコマンド実践テクニック

Command-3 ネットワークが遅い

この記事を読むのに必要な時間:およそ 4 分

回線の輻輳,回線品質の確認

万一,図1で「Request timed out.」が混在している場合は,パケットの消失が発生していることがわかります。画面が流れてしまった場合は,[Ctrl]+[C]を押下すると現れる統計情報画面でパケットの消失有無を確認できます。消失が発生している場合は,パケットの再送が発生しますので,結果として通信が遅くなります。

この場合は,本当に通信量が多く回線が輻輳している,あるいは回線自体の品質が悪いといった可能性が考えられます。なお,デフォルトのパケットサイズ(32バイト)で問題が発生しなかった場合,図4のように-lオプションでパケットサイズを500バイト程度の大きさにして,パケットの消失が発生しないかを確認してみましょう。これで消失したりしなかったりといった現象が発生する場合も,回線の輻輳や品質の問題が疑われます。

図4 サイズを996にして送信している例
なお,この環境ではサイズを997以上(ICMPヘッダなどのバイト数28を加算すると1025以上)にすると送信できなかった。

C:\>ping -l 996 www.monyo.com

Pinging WWW.MONYO.COM [202.224.206.195] with 996 bytes of data:

Reply from 202.224.206.195: bytes=996 time=41ms TTL=243
Reply from 202.224.206.195: bytes=996 time=42ms TTL=243
Reply from 202.224.206.195: bytes=996 time=42ms TTL=243
Reply from 202.224.206.195: bytes=996 time=44ms TTL=243

Ping statistics for 202.224.206.195:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 41ms, Maximum = 44ms, Average = 42ms

C:\>

ただし,一定のバイト数までは消失が0%であるにもかかわらず,その大きさを1バイトでも超えるとパケットが100%消失するという場合は,途中の機器の設定で(ICMPのペイロードが)その大きさ以上のパケットの通過を禁止していると思われますので,⁠遅い」という現象とは無関係だと考えられます。

MTUサイズの確認

この他,⁠遅い」要因としてはMTUサイズの問題も考えられます。pingコマンドに対する応答があることが前提ですが,図5のようにpingコマンドに「-f -l サイズ」オプションを付けてプロバイダ側の直近のルータやサーバ(もしくはアクセスが遅いという申告があるサーバ)にpingを行い,⁠...but DF set.」というメッセージが表示されない最大のサイズを確認します。その上で,LANインターフェースのMTUを「最大サイズ+28」に設定することで速度が改善されます。

図5 tracertコマンドで直近のプロンバイダ側のルータを確認の上,⁠ping -f -l サイズ」コマンドを実行している。

C:\Documents and Settings\monyo>tracert www.monyo.com

Tracing route to WWW.MONYO.COM [202.224.206.195]
over a maximum of 30 hops:

  1     1 ms     1 ms     1 ms  modemnv3-e68c8e [192.168.1.1]
  2    10 ms    10 ms    10 ms  10.100.100.1
^C
C:\Documents and Settings\monyo>ping 10.100.100.1 -f -l 1426

Pinging 10.100.100.1 with 1426 bytes of data:

Reply from 10.100.100.1: bytes=1426 time=15ms TTL=254
Reply from 10.100.100.1: bytes=1426 time=15ms TTL=254

Ping statistics for 10.100.100.1:
    Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 15ms, Maximum = 15ms, Average = 15ms
Control-C
^C
C:\Documents and Settings\monyo>ping 10.100.100.1 -f -l 1427

Pinging 10.100.100.1 with 1427 bytes of data:

Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Ping statistics for 10.100.100.1:
    Packets: Sent = 2, Received = 0, Lost = 2 (100% loss),
Control-C
^C
C:\Documents and Settings\monyo>

たとえばフレッツADSLなどではMTUを1454バイトに設定することが推奨されています。なおこの原理や便利な設定ツールなどについては,検索エンジンで「1454 MTU 変更」といったキーワードで検索すると情報を掲載しているサイトが多数ヒットしますので,そちらを参照してみてください。

パケットキャプチャが必要な場合

これらの切り分けを行っても原因の追求ができない場合,あるいはサーバ側に原因があるかどうかを明示的に切り分けたい場合などは,パケットキャプチャの取得が必要となります。可能であればクライアント側とサーバ側で,⁠遅い」とされる一連の通信について取得を行い,パケットの消失,再送,重複などが発生していないか,サーバからは妥当な時間内に反応が戻ってきているかといった点を調査します。たとえばクライアントから正常に通信が送出されているにも関わらず,サーバに到達した時点では異常が発生しているという場合は,中間のネットワーク機器に問題があると想定されますので,そこまで正常に到達しているのか,経路途中でパケットキャプチャを取得して切り分けていきます。残念ながら定番の方法はないので,機器,ネットワーク構成を勘案した上での対応が必要となります。

筆者がいままで経験したネットワーク側に問題があるケースとしては,ルータの全二重,半二重の設定ミスによるパケット消失,オフロード機能の問題によるTCPシーケンス異常,ロードバランサや負荷分散装置の不具合によるパケット重複や不正なRST送出といったケースがありますが,これ以外にもさまざまな要因が考えられます。