前回は，もともとの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」は，この方式もサポートする。