PR

 前回は,もともとのTCP/IPが二つの理由で力不足になっていると説明し,その一つめの理由「フロー制御」を説明した。今回は二つめの理由「輻輳制御」に注目する。

 もともとのTCPは輻輳によりパケット損失が発生すると,送信データ量(セグメント数)を半減させる(図1左)。セグメント数を一気に半減させた後,再びスロー・スタートのようにセグメント数を徐々に増やしていく。ただしパケット損失後は,セグメント数を倍増させるのではなく,一つずつ追加する。指数関数的にセグメント数が増えるスロー・スタートと比べ,スループットの上昇は緩やかになる。

図1●パケット損失後の動き
図1●パケット損失後の動き
もともとのTCPは,パケット損失が起きると送信データ量が一気に半減し,そこから少しずつ回復する。広帯域・遅延大のネットワークほど,スループットが頭打ちとなる。HSTCP(HiSpeed TCP)は,送信データ量が多い場合に,送信データ量に応じて削減率や増加率を決める。広帯域・遅延大でも帯域を効率よく使える
[画像のクリックで拡大表示]

 1Gビット/秒クラスの帯域では,元の状態に戻るのに1時間近くかかるケースもあるという。しかも,回復の過程で再びパケット損失が発生すると,さらにセグメント数は半減する。これを繰り返すので,時間経過に対する送信データ量のグラフは目の粗いノコギリ状となり,スループットの平均はやや低くなる。

 このような問題を解決する技術が「HSTCP(HiSpeed TCP)」である。まだ標準化されていない技術だが,一部ベンダーの製品やLinuxカーネル 2.6.13以降への実装が始まっている。HSTCPを使うと,パケット損失後にもともとのTCPよりも素早くスループットを回復できる(図1右)。

 仕組みはこうだ。まず,送信するセグメント数が一定値以上であれば,セグメント数を少しだけ減らす。TCPのように一気に半減させるのではなく,HSTCPでは少しだけ減らして様子を見る。その後の回復の仕方も異なる。TCPのようにセグメント数を一つずつ増やすのではなく,HSTCPでは直前のセグメント数に応じて増加量を変える。つまり送信するセグメント数が多い場合,パケット損失時には緩やかにデータ量を減らして素早く回復する。これを繰り返すので経過時間に対する送信データ量のグラフは目の細かなノコギリ状になり,もともとのTCPよりも平均スループットは向上する。

 ただ,HSTCPに問題がないわけではない。最大の問題は,もともとのTCPとの併用を想定していないことだ。実際に併用すると,HSTCPがTCPのスループットを奪ってしまう。そこで,HSTCPとTCPの混在を避けるために,遅延が大きな回線の両端にTCPとHSTCPとを相互変換するPEPを配置し,回線内をHSTCP通信だけにするという構成が多用される。WAN高速化装置の多くは,ほぼ同様の仕組みでTCPの遅延を改善する。例えば米Riverbed TechnologyのWAN高速化装置「Steelhead」が,HSTCPへの変換オプションを備える。

経路上でクライアントに成り代わる

 ここまで説明した技術は,TCP/IPを利用するすべての(TCP/IPより上位の)プロトコルに適用できる。適用範囲が広い半面,プロトコルによっては大きな効果は期待しづらい。そこで,プロトコルを限定し,プロトコルの特性に合わせて高速化を図る技術がある。そうした発想に基づく技術の代表格は「先読み」である。特定のパターンで要求/応答を繰り返すプロトコルの場合,回線の両端に対向でPEPを配置し,経路上でPEPがクライアントに成り代わってデータを先読みすれば遅延を小さくできる。

 典型的なのは,ファイル共有プロトコル「CIFS」である。ファイル・サーバーから大容量のファイルをクライアントにコピーする場合を例に,通常のCIFSの動きを説明しよう。クライアントから読み出し命令を受信すると,ファイル・サーバーはファイル内容を複数のデータ・ブロックに分割し,データ・ブロックごとにクライアントに送り出す(図2左)。クライアントは,送られてきたデータ・ブロックの受信に成功すると,次のデータ・ブロックを要求する。この要求を受けて,ファイル・サーバーは後続のデータ・ブロックを送出する。この仕組み上,遅延が大きい環境では,データ・ブロックの送信待ち時間が長くなり,平均スループットが低下する。

図2●CIFS通信の動き
図2●CIFS通信の動き
CIFS(Common Internet File System)は1回の通信で送れるデータ量が制限されているので,大容量ファイルを転送する際には要求/応答を繰り返す。その結果,遅延が大きくなる。そこで,クライアントからの要求を待たずに,経路上でデータを先読みして送信することで,通信を高速化する。図にはないが,複数のデータ(例えばData1~3)を独自プロトコルでまとめ送りすることで,さらに高速化することも可能
[画像のクリックで拡大表示]

 PEPがクライアントに成り代わってデータを先読みすると,ファイル・サーバーの送信待ち時間は短くなる(図2右)。ファイル・サーバー側にあるPEPは,データ・ブロックを受信したら,すぐに次のデータ・ブロックをファイル・サーバーに要求する。受け取ったデータ・ブロックは,あらかじめクライアント側のPEPに転送しておく。クライアント側のPEPは,クライアントから後続のデータ・ブロックを要求された時点で,それを送り返す。WAN高速化装置で言えば,Juniper Networksの「WX/WXC」や米F5 Networksの「WANJet」などが,この仕組みを実装している。

 同様の仕組みは,HTTPの高速化にも応用できる。例えば,HTMLデータの内容をサーバー側のPEPで解析し,HTMLデータでリンクされている画像ファイルをあらかじめWebサーバーからリクエストするのだ。米Blue Coat SystemsのWAN高速化技術「MACH5」は,この方式もサポートする。