WAN高速化装置は，拠点間通信のレスポンスを改善する製品。ともすればブロードバンド回線があれば不要にも思えるが，むしろブロードバンドが普及した最近になって注目を集めるようになった。その理由は，WANのブロードバンド化ではレスポンス向上が解決できないアプリケーションの存在が認識され，その原因として「遅延」という問題が顕在化してきたからだ。

　ここ数年，拠点間通信のレスポンスを改善することをうたうWAN高速化装置という製品が市場で盛り上がりを見せている。

　例えば，米シスコ，米ジュニパーネットワークス，米リバーベッド・テクノロジーなどの通信機器メーカーが相次いで参入し，競って装置を販売している。日本のユーザー企業の注目度も相応に高い。製造業などで導入が進んでいる。

　ところで，WAN高速化装置に注目が集まり出した時期は，光ファイバに代表されるブロードバンド・インフラが企業に浸透した時期と一致する。通信回線がブロードバンド化したことで，十分にレスポンス向上効果を得られているようにも思える。にもかかわらず，なぜ装置が必要とされているのだろうか。

広帯域化で新しいWANの使い方が出現

　理由を探るために，まずWANがどのように進展してきたかを整理しておこう。

　近年，企業のWAN環境は目覚ましい勢いで進化した。現在ではブロードバンド回線を足回りに，IP-VPN（仮想閉域網），広域イーサネット，インターネットVPNなどを活用した高速の社内ネットワークを運用する企業が多数を占める。専用線時代であればkビット/秒単位が一般的だった拠点間の通信速度は，今や数十Mビット/秒ということさえ珍しくなくなった。

　ブロードバンド化の進展により，企業は従来のWANでは見られなかった使い方をするようになった。

　典型的な例は，全国各地の拠点に設置していたファイル・サーバーをデータ・センターに集約し，WAN経由でアクセスさせる取り組み。セキュリティの向上や，サーバー運用コストの削減が目的である。

　サーバー集約は今後も多くの企業に広がる可能性が高い。いわゆる「日本版SOX法」の規定により，企業はメールなどの情報を保管する措置が求められるようになった。このような作業の負荷を抑えるには，サーバーを集約・統合することが望ましいからだ。

立ちふさがる遅延の壁

　ところが，実際に各拠点からWAN経由でファイル・サーバーにアクセスする形態にした企業は，問題にぶつかることになる。各拠点にサーバーを置いていたときと比べて，レスポンスが悪化してしまうのである。たとえ帯域が十分にあっても，この現象に見舞われる。問題を理解するには，WANの「遅延」に注目する必要が出てくる。

　通信のレスポンスを決める要素は大きく三つある。具体的には，（1）遅延，（2）1回のやり取りで送信するデータ量である「ウインドウ・サイズ」，（3）アプリケーションのバースト転送性である。

　（1）の遅延は，ネットワークの品質で決まる。一方の（2）と（3）は，アプリケーションやプロトコルによって決まる。このため，遅延の影響を受けやすいアプリケーションが存在する。その代表格は，米マイクロソフトのファイル共有プロトコルのCIFS（common internet file system）や，データベースに使われるMicrosoft SQL（MS-SQL）などのアクセスである（図1-1，1-2）。ここでは，CIFSの通信形態をサンプルに解説する。

図1_1●CIFSの通信シーケンス
図1_1●CIFSの通信シーケンス

図1_2●ODBCの通信シーケンス
図1_2●ODBCの通信シーケンス

　理論上のスループット（ビット/秒）は，「ウインドウ・サイズ×8÷遅延値（秒）」という計算式で求められる。この計算式から，ウインドウ・サイズが大きく，遅延値が小さい環境ほど良好なスループットを得られることが分かる。

　WindowsXPであれば通常，ウインドウ・サイズは最大64Kバイトとなる。ところが，CIFSを使う場合には転送サイズの制限がある。一つのAckに対し，最大で1514バイト×2（＝3Kバイト）のデータしか送信できない。WindowsXPからのウインドウ・サイズの要求は64Kバイトなのだが，CIFSの通信形態は1514バイトのパケットを二つ転送するにとどまる。これは，CIFSの仕様上の転送制限である。

　さらにCIFSの通信では，送信したデータに対するAckが返ってくるまで，送信側は次のデータを送信しない。データを連続して送信するバースト転送ができないわけだ。

　このようなメカニズムでは，遅延が大きくなるとレスポンスが悪化する。遅延によってAckが到達するまでの時間が増え，サーバー側が次のデータを送信する間隔が長くなるからだ。

　例として，700KバイトのファイルをCIFSで転送する場合を考えてみよう。遅延が1ミリ秒未満のLAN環境であれば1～2秒で完了する。ところが，遅延40ミリ秒の環境で同様の操作をすれば約60秒もかかる。

　というのも，700Kバイトのデータ量ではネットワーク上でのシーケンス数が1000強にのぼる。シーケンスごとに遅延の影響を受ける結果，何十倍もの時間がかかってしまう。

　このように数十ミリ秒程度の遅延でも，遅延の影響を受けやすいアプリケーションの通信ではレスポンスに大きな差をもたらすことになる。

WAN高速化装置は遅延を克服する

　レスポンスを高めたい場合，すぐに思いつくのは回線の帯域を増強すること。しかし，遅延の影響を受けやすいCIFSやMS-SQLの通信では，帯域を増強してもレスポンス向上は期待できない。

　CIFSやMS-SQLの通信はバースト転送ができず，遅延が大きいとデータを送信していない時間が長くなる。帯域を十分に使い切れていない状態である。このため，いくら帯域を増やしてもレスポンスの改善にはつながらない。ちなみにFTP（file transfer protocol）のようなバースト転送ができるアプリケーションなら，帯域増強でレスポンス向上が期待できる。

　このようにレスポンスを向上させるには，アプリケーションの特性に応じた対処法が必要となる。帯域増強は決して万能の解決策ではない。

　そこで，WAN高速化装置の出番となる。WAN高速化装置は，帯域増強では難しい「遅延を克服する」仕組みなどを備えているからだ。