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

高高橋基信

2007-08-24

「ネットワークが遅い」という申告もさまざまな場面で聞く苦情のひとつです。こちらも考えられる原因はいろいろあります。最初にやるべきは影響範囲のヒアリングでしょう。

たとえば、特定のWebサイトやサーバにアクセスするときだけ遅いのであれば、ネットワークの問題ではなくて該当のサーバ側の問題である可能性が高くなりますし、特定の個人マシンでだけ発生するのであれば、該当マシンでプロセスが暴走してCPUを使いきっているだけかも知れません。

ping応答による原因の切り分け

ヒアリングと合わせて有効なのが、図1のpingコマンドによる応答状況の確認です。

図1　pingコマンド
-tオプションにより[Ctrl]＋[C]で強制終了させるまでpingが継続している。また、「⁠Request timed out」が1回発生している。

C:\>ping -t www.monyo.com

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

Reply from 202.224.206.195: bytes=32 time=41ms TTL=243
Reply from 202.224.206.195: bytes=32 time=29ms TTL=243
Request timed out.
Reply from 202.224.206.195: bytes=32 time=29ms TTL=243
Reply from 202.224.206.195: bytes=32 time=30ms TTL=243
Reply from 202.224.206.195: bytes=32 time=28ms TTL=243

Ping statistics for 202.224.206.195:
    Packets: Sent = 6, Received = 5, Lost = 1 (16% loss),
Approximate round trip times in milli-seconds:
    Minimum = 28ms, Maximum = 41ms, Average = 31ms
Control-C
^C
C:\>

-tを付けることで、[Ctrl]＋[C]で強制終了させるまで継続してpingコマンドが実行されます。デフォルトでは4回で終了してしまいますが、傾向を見る上では数十秒位続けた方がよいでしょう。

サーバをIPアドレスで指定した場合と名前で指定した場合との応答を見比べることをお勧めします。名前でアクセスした時に初回の応答までにちょっと間が空くという場合は、ネットワークの問題ではなく、名前をIPアドレスに変換する名前解決機構の問題であると推測できます。

名前解決機構のトラブルシューティング

名前解決機構のトラブルシューティングはかなり繁雑ですが、まずは図2のipconfig /allコマンドでDNSサーバが構成されている場合は、そのDNSサーバにアクセス可能かを確認してみましょう。とくに1台目のDNSサーバに障害が発生しており、2台目以降を使って名前解決が成功している場合は、結果として応答が「遅く」なりますので、注意が必要です。

図2　ipconfig /allコマンド

C:\>ipconfig /all

Windows IP Configuration

        Host Name . . . . . . . . . . . . : madoka
        Primary Dns Suffix  . . . . . . . : monyo.local
        Node Type . . . . . . . . . . . . : Hybrid
        IP Routing Enabled. . . . . . . . : No
        WINS Proxy Enabled. . . . . . . . : No
        DNS Suffix Search List. . . . . . : monyo.local

Ethernet adapter LAN2:

        Connection-specific DNS Suffix  . : localdomain
        Description . . . . . . . . . . . : VMware Accelerated AMD PCNet Adapter #2
        Physical Address. . . . . . . . . : 00-0C-29-11-C0-EF
        Dhcp Enabled. . . . . . . . . . . : Yes
        Autoconfiguration Enabled . . . . : Yes
        IP Address. . . . . . . . . . . . : 192.168.135.153
        Subnet Mask . . . . . . . . . . . : 255.255.255.0
        Default Gateway . . . . . . . . . : 192.168.135.2
        DHCP Server . . . . . . . . . . . : 192.168.135.254
        DNS Servers . . . . . . . . . . . : 192.168.1.1
                                            172.16.100.1
        Primary WINS Server . . . . . . . : 192.168.135.2
        Lease Obtained. . . . . . . . . . : 2007年8月10日 10:12:25
        Lease Expires . . . . . . . . . . : 2007年8月10日 10:42:25

DNSサーバへのアクセスに問題がない場合は、図3のようにnslookupコマンドで明示的に問い合わせ先のDNSサーバを指定して名前解決を行ってみることをお勧めします。

図3　nslookupコマンド
最初は192.168.1.1のDNSサーバへ、次は172.16.100.1のDNSサーバに対してwww.monyo.comの名前解決を実施している。

C:\>nslookup www.monyo.com 192.168.1.1
Server:  modemnv3-e68c8e
Address:  192.168.1.1

Non-authoritative answer:
Name:    www.monyo.com
Address:  202.224.206.195


C:\>nslookup www.monyo.com 172.16.100.1
*** Can't find server name for address 172.16.100.1: Non-existent domain
Server:  UnKnown
Address:  172.16.100.1

Non-authoritative answer:
Name:    www.monyo.com
Address:  202.224.206.195


C:\>

DNSサーバで名前解決が失敗しているにもかかわらず、最終的に名前解決が成功している場合は、LMHOSTSファイルやWINSサーバを用いて名前解決が成功している可能性が考えられます。これは通常ネットワーク管理者の意図する動作ではないと思いますので、名前解決の構成を見直した方がよいでしょう。

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

万一、図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送出といったケースがありますが、これ以外にもさまざまな要因が考えられます。