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

通信の多いファイル共有を高速化できるソリューションであっても、それ以外のアプリケーションの高速化については得手、不得手がある。WAN高速化装置は決して万能ではないのだ。

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

本記事の関連コンテンツは、オンライン・ムック「最適化から始まる、WAN高速化への道」でご覧になれます。

岩本直幸／中島幹太（ネットマークス）

　前回は、WAN高速化装置がキャッシュ機能、圧縮機能、ウィンドウサイズの拡張機能などでWAN上に流れるデータ量を減らし、キャッシュにヒットしないデータをバースト転送することで高速化できることを説明した。そこで、「アプリケーションの高速化」という観点からファイル共有技術について掘り下げてみたい。

ウィンドウサイズのスループットの関係

　まず、ウィンドウサイズとファイル共有のバッファとの関係について説明する。

　ここでいうウィンドウサイズとは、TCPコネクションの接続中にバッファに格納できる受信データの量（バイト数）を表している。送信側は受信側で決めた量を転送し、確認応答（ACK）やウィンドウ更新を受信するとその量を変更する。最初に送信される接続要求に対して通知されるのは16KBで、TCPコネクションの接続確立時に送信側と受信側で取り決める最大セグメントサイズ（MSS）の4倍に当たる64KBが最大のウィンドウサイズとなる。ウィンドウスケールオプション（RFC1323）が有効となっている場合には、これ以上のウィンドウサイズを使用することができる。

　このウィンドウサイズはOSによっても多少違いがあり、Windows XPの場合、SP（Service Pack）1が最大16KBでSP2が最大64KBとなっている。ウィンドウサイズと遅延時間の関係でTCP通信の最大スループットが決まっており、例えばウィンドウサイズが最大の64KB、遅延時間が10ms（ミリ秒）という東京−名古屋間100MbpsのWAN環境におけるスループットを算出すると、64KB×8／10ms＝約51Mbpsとなる。もちろん、回線帯域が理論上のスループットを下回る環境であれば、実回線よりもスループットが上がらないことはいうまでもない。

　もう1つ例を挙げると、ウィンドウサイズが最大の64KB、遅延時間が600msの衛星回線1.5Mbpsの環境におけるスループットを算出すると、64KB×8／600ms＝約850Kbpsとなる。600msほどの高遅延環境になると、1.5Mbpsという細い回線であっても帯域を使い切れないことが分かる。

　このように、ウィンドウサイズと遅延時間からスループットを予測することができるため、ファイル共有についても同様に計算したくなるのが人情だが、ファイル共有のスループットは同様には計算できない。なぜなら、Windowsファイル共有がSMB（Server Message Block）のブロックサイズを使用して通信しているからだ。

　ファイル転送といっても、エクスプローラでコピーする場合もあれば、コマンドプロンプトを使用する場合もある。前者の方法はコアモードという転送方式で、使用されるブロックサイズが4KBである。後者の方法はRawモードという転送方式で、使用されるブロックサイズが60〜64KBとなる。当然、Rawモードの転送方式の方がコアモードよりも高速であるが、Rawモードの使用には幾つかの条件があり、その条件をクリアしないと使用することができない。

　ここでは、コアモードの転送方式をファイル共有の転送方式と考えて話を進める。ファイル共有のブロックサイズが4KB（4356Bytes）であるため、多少強引だがこれをウィンドウサイズに読み替えて上記2つの例に当てはめてみると、東京−名古屋間100Mbps回線のファイル共有時のスループットは4KB×8／10ms＝約3.2Mbpsとなり、衛星回線1.5Mbpsのファイル共有時のスループットは4KB×8／600ms＝約50Kbpsとなる。

　これらはブロックサイズをウィンドウサイズと半ば強引に読み替えた値のため、参考程度と考えていただきたいが、過去の経験上、10msの100Mbps環境ではファイル共有のスループットが約4Mbpsだったため、非常に近い値と言える。ちなみに、512MB以上のメモリを搭載したPCであれば、サイズを16KBに増やしても問題はないだろう。当然スループットも向上させることができるが、ブロックサイズを大きくするとその分メモリの使用率も上がるため、注意が必要だ。