2009年11月14日土曜日

Willcom WX310K で PPP 接続 (3)

 Willcom WX310K で PPP 接続が出来るようになって、ブラウザで各種のウェブサイトを閲覧して回ってみていることでしょう。しかし異常な通信の遅さに驚いていませんか?私も驚きました。Willcom WX310K 本体だとここまで遅くないからです。

 原因はもちろん基本的な通信速度の遅さ(32kbps or 64kbps)なのですが、さらにパケットの応答の遅さも原因となっています。

 さらに DNS の名前解決でも通信の反応が遅くなっているようです。ブラウザの通信ステータスの部分を観察していると「アドレス解決をしています」の文字が頻繁に、それも数秒間にも渡って見られます。

IPv6対策
 IPv6の接続でも DNS の名前解決で時間がかかることがあることが知られていますが、debian-lennyでは ppp 接続では問題はないようです。
 がしかし、念のためにIPv6の動作を停止させておきました。WX310Kで通信をするノートパソコンなどでは当分 IPv6 は必要ないと思われるからです。

/etc/modprobe.d/aliases の中の "alias net-pf-10 ipv6" の項目を "alias net-pf-10 off"に変更します。これでOSを再起動させれば IPv6 が無効になっているはずです。試しにスーパーユーザーになって ifconfig のコマンドを実行すると LAN の eth0 の項目にあった IPv6 アドレスなどが表示されなくなっているはずです。

mdns4(マルチキャストDNS)対策
 それから DNS の名前解決で時間がかかっている理由にmdns4(マルチキャストDNS)も悪さをしているようです。/etc/nsswitch.conf を修正して mdns4 を利用しないようにします。

/etc/nsswitch.conf を以下のように修正します。これで hosts などの files を検索した後、resolv.conf にある DNS を検索するようになります。

hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4
    ↓
hosts: files dns

以上の対策で随分と通信が速くなったように感じます。しかし ping コマンドを IP ではなくドメイン名で行うとパケットロスが異常に発生していることが判ります。

以下は一例です。

IP で ping を実行した場合
# ping 125.1.152.139
PING 125.1.152.139 (125.1.152.139) 56(84) bytes of data.
64 bytes from 125.1.152.139: icmp_seq=1 ttl=51 time=562 ms
64 bytes from 125.1.152.139: icmp_seq=2 ttl=51 time=237 ms
64 bytes from 125.1.152.139: icmp_seq=3 ttl=51 time=233 ms
64 bytes from 125.1.152.139: icmp_seq=4 ttl=51 time=228 ms
64 bytes from 125.1.152.139: icmp_seq=5 ttl=51 time=226 ms
^C
--- 125.1.152.139 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4016ms
rtt min/avg/max/mdev = 226.181/297.635/562.011/132.243 ms

ドメイン名で ping を実行した場合
# ping tatsuya.dnsalias.com
PING tatsuya.dnsalias.com (125.1.152.139) 56(84) bytes of data.
64 bytes from nthrsm091139.hrsm.nt.ftth4.ppp.infoweb.ne.jp (125.1.152.139): icmp_seq=2 ttl=51 time=238 ms
64 bytes from nthrsm091139.hrsm.nt.ftth4.ppp.infoweb.ne.jp (125.1.152.139): icmp_seq=4 ttl=51 time=239 ms
64 bytes from nthrsm091139.hrsm.nt.ftth4.ppp.infoweb.ne.jp (125.1.152.139): icmp_seq=6 ttl=51 time=219 ms
^C
--- tatsuya.dnsalias.com ping statistics ---
8 packets transmitted, 3 received, 62% packet loss, time 21796ms
rtt min/avg/max/mdev = 219.281/232.374/239.428/9.267 ms

なんとドメイン名で ping を実行した場合には、一つおきにしかパケットが返ってきませんでした。"icmp_seq=" の文字のところの数字が何番目の通信かを示しています。この例では 2,4,6,と偶数番目のパケットしか返ってこなかったわけです。
この状態では上手く通信ができません。パケットロスが大発生している状況だからです。これは DNS の名前解決の応答に時間がかかっているためです。検証には "ping -n ドメイン名" のコマンドで調べることができます。IP で ping を実行した場合と同様の結果が得られます。

応答時間の問題からくる DNS の名前解決の問題対策
この応答時間の問題からくる DNS の名前解決の問題対策は簡単です。単純に DNS の名前解決をキャッシュしておけばよいことなのです。一般的な Linux ディストリビューションでは、通信の度に DNS の名前解決を行っています。この DNS の名前解決をキャッシュで行ってしまえば、レスポンスが改善されるはずです。

DNS の名前解決をキャッシュすることとして、ネット上では "dnsmasq" を使う方法と "NSCD" を使う方法が紹介されています。両方を確かめたところ、NSCD の方が設定などの面で楽だと判断しました。ここでは NSCD による方法を紹介します。

NSCD は aptitude でインストールしました。

# aptitude install nscd

NSCD がインストールされると、各種設定ファイルなども一緒にインストールされます。この中で、"/etc/nscd.conf" の中にある "hosts" の項目が "no" になっているのを "yes" に変更しておきます。

これで DNS の名前解決で得られた IP がキャッシュされることとなり、何度も DNS へ問い合わせを行って無駄な時間を使ってレスポンスが低下するのを防ぎます。

NSCD の設定を変更したら、NSCD のデーモンを再起動させておきます。

# /etc/init.d/nscd restar

この状態で無駄な DNS の問い合わせがなくなり、通信がかなり改善されていると思います。
Willcom の端末を使って通信をしている人で通信速度に不満のある人は試してみては如何でしょうか?

0 件のコメント:

コメントを投稿

注: コメントを投稿できるのは、このブログのメンバーだけです。