Q. Windows XPからファイルサーバへの接続が非常に遅い

現在のネットワークはWindows 2000 ProfessionalとWindows XP Professionalが混在している環境です。ファイルサーバが何台かありますが、Windows XP Professionalの端末からアクセスする時だけ、特定のサーバの反応が非常に遅いことに気づきました。 反応が遅いケースも、最終的にはアクセスできますので、アクセス権の問題ではないと思います。また端末側の名前解決の設定ミスかとも思いましたが、設定はDHCPで行なっており、Windows 2000 Professionalで問題が発生しているマシンはないため、原因とは考えにくい状態です。 原因として考えられることはないでしょうか。

Answer

これだけでは断定することはできませんが、このような条件であれば、まずはWindows XPから搭載されているWebClientサービスとパケットフィルタリングの設定との相性による副作用を疑ってみるのがよいでしょう。 WebClient機能は、WebフォルダなどHTTPを使ったファイル共有機能であるWebDAVのクライアント機能を実現しているサービスです。このサービスがなぜ問題となるのかを、以下例を交えて説明していきましょう。

WebClientが有効だと発生する余分な通信

WebClientサービスが動作しているクライアントマシンがWebサーバが起動しているファイルサーバにアクセスしようとした際のパケットキャプチャを図xx1に示します。このように実際のファイルサーバに対してアクセスが行なわれる前に、必ずWebDAVによるアクセス(HTTP)が試行されます。

図xx: Windows XPがファイルサーバに接続する際の通信
Windows XPがファイルサーバに接続する際の通信
(*)ACKのみのパケットはTCPコネクション接続時のものを除きフィルタしています。
フレーム22およびそれ以降の省略したフレームでは実際の接続処理が行なわれています。

このサーバ上ではWebサーバが起動しているため、フレーム14-21でHTTP(ポート80)に対する通信が行なわれています。図xx1からは確認できませんが、実際はフレーム20であるURLへのアクセスを試み、フレーム21でURLが存在しないというエラーが返却されています。

この場合Webサーバのアクセスログには図xx1.5のようにUser-AgentにMicrosoft-WebDAV-MiniRedir/5.1.2600という値が入った内容が記録されます。

図xx1;5: WebClientによるアクセス時に記録されるアクセスログ
02:45:49 192.168.10.239 - W3SVC1 MEGUMI 192.168.10.10 80 OPTIONS / - 200 HTTP/1.1 MEGUMI Microsoft-WebDAV-MiniRedir/5.1.2600 - -
(*) 上記はIISの標準のログ形式の場合

WebDAV自体はHTTPアクセスの一種のため、こうしたログが記録されること自体は正常な動作となります。 なお、単にWebサーバが存在していない状態の場合は、HTTPポートへの接続要求(SYNパケット)に対して即座に拒否(リセットパケット)が返却され、約0.5秒間隔で3回繰り返した時点で次の処理に移ります。 いずれの場合も、サーバ側ではWebDAVによるアクセスに対して即座に応答していますので、結果として無駄な通信は発生するものの、クライアント側から見た時のレスポンスはほとんど変わりません。

HTTPポートのフィルタリング方式によっては思わぬタイムアウト待ちが発生

一方、サーバ側のパケットフィルタ機能で、HTTPポートへの接続を明示的に拒否せず、だまって破棄するように設定していた場合、クライアントは図xx2のようにWebDAV経由でのアクセスを何回か行ない、反応がないことを確認した上で、通常のファイル共有の手順に移ります。

図xx: Windows XPがファイルサーバに接続する際の通信
Windows XPがファイルサーバに接続する際の通信
(*)ACKのみのパケットはTCPコネクション接続/終了時のものを除きフィルタしています。
フレーム37およびそれ以降の省略したフレームでは実際の接続処理が行なわれています。

このサーバでは、HTTPに対する通信は、すべて破棄しています。このためフレーム14でクライアントからHTTPに対する通信が開始されていますが、サーバからの反応がないため、一度途中まで行なわれた接続がフレーム15〜25でクローズされてしまっています。結局3秒後(フレーム26)、更に6秒後(フレーム27)とHTTPへの接続を試行した後で、更に12秒後(フレーム28)で、改めてNBT(ポート139)への接続が開始されています。フレーム15〜25で接続が一度クローズされてしまっているため、フレーム29以降では改めて認証をやり直して接続処理を行なっています。

上記の例では、接続処理が再開されるまで結局21秒近く経過してしまっています。このため、Windows XPのようにWebClientサービスが有効になっている端末では、ファイルサーバへのアクセスまでに時間が掛かってしまうという事象が発生するわけです。

WebDAVが不要であればサービスの停止を

本事象はWebClientサービスが有効な場合にのみ発生しますので、WebDAVを全く使う予定がない場合は、クライアント側のWebClientsサービスを停止してしまうことが一番簡単な解決策です。Active Directoryに所属していれば、GPOなどを使うことで、一括しての設定変更も可能です。

WebClientサービスを停止できない場合、この通信自体を止めることはできませんが、ファイアウォールの設定を変更してパケットを破棄ではなく拒否する、もしくはWebサービスを起動していない場合は単にHTTPポートを開放することで、レスポンスの改善は可能です。

注記・補足