今回は「もしかしてネットワークがおかしい?」という時のポイントの話をしようとおもいます。「もしかしておかしい?」というのは随分と曖昧な表現ですが、実際にこのような微妙な状況というのはよく起こるものです。

- 通常の処理は全部正常に出来るのだけれども、時間がかかりすぎているような感じがする。
- ほとんどの処理は正常なのだけれども、サイズの大きなファイルを扱う時だけうまくいかない。
- ネットワーク上のファイルコピーになんだかやけに長い時間がかかる・・・けど、ほおっておけば終わる。
- なんとなくネットワークを利用する処理が重い気がする。

このようなことは良くあります。よくある問題やチェックポイント等、私がいつも意識してチェックしている項目を紹介します。

SNP

Windows Vista以降、ネットワーク関連で何か怪しいところがあればまず試してみるのがこの項目です。本来性能Upのためにあるものなのですけど…ね。

- [予期せぬ挙動が!? 新機能 Scalable Networking Pack をご存知ですか? - Ask the Network & AD Support Team - Site Home - TechNet Blogs](http://blogs.technet.com/b/jpntsblog/archive/2010/03/23/scalable-networking-pack.aspx)
- [[Windows 7編]ネットワーク設定を標準で使ってはいけない - ITアーキテクトの「やってはいけない」:ITpro](http://itpro.nikkeibp.co.jp/article/COLUMN/20100824/351391/)

SNPの実装自体はWindows Server 2003 SP2のころからあったようですが、規定の状態で有効になったのはVista以降とのことです。時間がたち、技術が成熟することで問題は落ち着き本来の性能向上の恩恵にあずかれる…状態には残念ながらまだまだならないようです。さらにHyper-V上で複数の仮想OSが稼働するようになって問題発生時の複雑度がさらに上がっている印象です。残念ですが、とりあえず現段階では「すべて無効にする」のが得策だと思います。

得に注意したいのは「OSで設定を無効にするだけではなく、HW側の設定も無効にする」という事です。「SNP無効にしてる?」「うん。してるよ。それでもまだ問題が発生しているんだ。」というケースでも実はHW側ではまだ機能が有効で、それにより問題が引き起こされていた…ということが何度かありました。

ジャンボフレーム

ジャンボフレームが原因でネットワークのトラブルが起きるケースがあります。もちろんこちらもきちんと構成すればパフォーマンスが向上するのですが…。ジャンボフレームについては以下の記事が理解しやすいと思います。

- [イーサネットを高速化するジャンボ・フレーム技術 - @IT](http://www.atmarkit.co.jp/fwin2k/pchard/05jumbo/05jumbo_01.html)

ジャンボフレームはTCPの3ウェイ・ハンドシェイクの中でMSSとして値が渡されホスト間でパケットサイズが決定されるので、「通信するホストはどちらもジャンボフレームに対応しているんだけど、間のネットワークにはジャンボフレーム未対応のスイッチやルーターがある」というような場合にトラブルが発生します。しかも小さいサイズのパケットは普通に通るので「pingは全く問題ないんだけどな」というようなことになりがちです。

ブラックホールルーター

ジャンボフレームの問題とかなり発生メカニズムや症状は似てくるのですが、発生原因が異なるのがブラックホールルーター問題。昔からときおり見かけるやっかいな存在です。

- [ブラック ホール ルーターの問題をトラブルシュートする方法](http://support.microsoft.com/kb/314825/ja)

解決手順にはセオリーがありますので上記のKBをよく読んでもらえるといいと思います。

ポート枯渇

TCPポートが枯渇することで問題が発生することもあります。TCPポートについてはレイヤ4 -トランスポート層- ポート番号をご覧ください。1つの典型的なケースとしてフロントエンド/バックエンドシステムでTCPポートが涸渇する問題への対処方法を紹介しましたが、このパターン以外でも様々なケースでポート枯渇問題に遭遇することがあります。基本的にnetstat -anコマンドにてコネクションの数を確認すればこの問題が発生しているかどうか判別することができます。集計にはPowerShellで簡単に集計する方法なども使えます。

パケットを見る

上記のどの問題も、それ以外の問題もパケットを見れば理屈上は全部わかるはずです。パケットを見るにはパケットをキャプチャする方法で紹介した方法をつかってまずパケットを取得します。

その後色々な見方がありますが、私がまずお勧めするのはwiresharkでのフィルタを使った確認方法です。

image

image

 

Filterの部分に「tcp.analysis.」と入力すると多数出てきます。このうち、以下のあたりのフィルタを入れてみてその数が多いようなら「ネットワーク的におかしなことが起きている可能性がある」ということで細かく調査を進めていくのがいいと思います。

- tcp.analysis.ack_lost_segment

- パケットがロストしている

- tcp.analysis.duplicate_ack

- パケットが重複している

- tcp.analysis.fast_retransmission

- 再送が発生している

- tcp.analysis.lost_segment

- パケットがロストしている

- tcp.analysis.out_of_order

- パケットの到達順序が入れ替わっている

- tcp.analysis.retransmission

- 再送が発生している

- tcp.analysis.window_full

- データ受信が遅くなっている

- tcp.analysis.zero_window

- データ順が遅くなっている

ここまでに紹介した問題についてはどの問題でも上記のあたりのフィルタをかけた時に多数パケットが確認できるはずです。