「アプリケーションが遅い」をなくす仕組み（2）：最適化から始まる、WAN高速化への道（2/3 ページ）

[岩本直幸、中島幹太，ITmedia]

ファイル共有をLAN内に閉じる工夫

　ここまで、ウィンドウサイズとファイル共有のバッファとの関係について述べたが、続いてファイル共有技術の「やり取り」について説明しよう。

　ファイル共有ではクライアントからサーバにReadやWriteなどの「要求」を送信し、その要求に対する「応答」を受信後、続く「要求」を送信する。つまり、「要求」→「応答」がセットとなっており、「応答」が戻って初めて「要求」を送信することができる。もともとWindowsファイル共有がLAN内で使用することを想定して作られたプロトコルであるため、このようなやり取りの多さが遅延の小さいLAN環境であれば問題にならなかったが、遅延がより大きいWAN環境では「要求」送信後、「応答」が戻ってくるまでの時間が影響するため、このやり取りの多さが直接通信の遅さにつながってしまう。

　例えば、LAN環境で1000回の「要求」「応答」を繰り返した場合、遅延（RTT）が1msとしても1000ms＝1秒となり、遅いとは感じられない。だがWAN環境で1000回の「要求」「応答」を繰り返した場合、遅延（RTT）が10msとなれば10000ms＝10秒となり、LAN環境で1秒で終わるものが10秒になれば遅いと感じるであろう（図1）。

図1●Windowsファイル共有の仕組み（クリックで拡大）

　このように、ファイル共有技術はブロック転送による通信のためスループットが上がらず、またその「やり取り」の多さからWANで使用するには非常に不向きなプロトコルであることがご理解いただけたと思う。WAN高速化装置は、このようなファイル共有技術の欠点を補い、WANを介したファイル共有をLAN環境のように快適にする技術を提供している。では、WAN高速化装置はどのようにファイル共有を高速化しているのだろうか。

　まず、SMBブロックサイズが小さいためにスループットが上がらないことに対しては、WAN高速化装置間でファイル共有プロトコルを使用しないことで対応している。例えば、シスコシステムズやリバーベッドテクノロジーの場合、WAN高速化装置内でNAT（ネットワークアドレス）変換を行うが、ファイル共有プロトコルで使用するポート番号139や445ではなく装置間で固有のポート番号を使用することで、WAN上にファイル共有プロトコルが流れないようにするため、ウィンドウサイズと遅延の関係でスループットを上げることが可能となる。ちなみに、シスコがWAN上で使用するポート番号はTCP4050であり、リバーベッドはTCP7800となる。このように、WAN高速化装置でファイル共有プロトコルを終端すれば、WAN上のスループットを向上することができる（図2）。

図2●Windowsファイル共有の高速化（クリックで拡大）

　また、やり取りの多さという点に関しても、WAN高速化装置がサーバ拠点ではクライアントになり、またクライアント拠点ではサーバになりきることで、本来クライアントとサーバ間で行うやり取りをLAN内で閉じられる。例えば、WAN回線の遅延（RTT：Round Trip Time）が10msの環境であってもLAN内には遅延がないので、1000回のやり取りも1秒で終了することになる。

　ここで説明した2社の技術は、いずれもファイル共有技術の欠点を補うものであるが、逆に大きな違いとなるのがキャッシュ、つまりファイル自体を装置内に保存するか否かという点だ。

　シスコの製品はファイルを装置内に保存するため、高速化の代償としてセキュリティ面に弱点がある。もちろん、拠点内にファイルが存在してはならないというセキュリティ要件がないユーザーなら、高速化の恩恵を受けることができる。

　一方のリバーベッド製品は、ファイルではなく、ファイルをシュレッダーにかけたような細分化したデータセグメントを装置内に保存するため、クライアントは最初と最後にサーバへアクセスしてファイルの整合性をチェックする必要がある。したがって、ファイルが拠点にあるシスコ製品よりも遅くなるケースも考えられるが、セキュリティ上、拠点にファイルを置かないというポリシーを持ったユーザーには有効だ。