このページの本文へ

前へ 1 2 次へ

アプリケーショントラフィック管理入門 第6回

WAN高速化の基礎技術 第2弾

TCPの改良やキャッシング、圧縮でより速く

2010年04月19日 07時30分更新

文● 大谷イビサ/TECH.ASCII.jp

  • この記事をはてなブックマークに追加
  • 本文印刷

WAN経由でのアプリケーションレスポンスを向上させるWAN高速化の技術だ。今回は前回紹介したTCPの弱点を補う各種の拡張のほか、対向で利用する製品ならではのユニークなキャッシング、圧縮などの機能を紹介する。

本記事は「アプリケーショントラフィック管理入門」の第6回です。過去の記事も合わせてご覧ください。

標準のTCPの改良技術を利用

 TCPは、インターネットですでに25年近く用いられている老舗のプロトコルだ。そのため、前回紹介したような弱点は以前から認識されており、以下のようなTCP最適化機能が、RFC化されている。

ウィンドウサイズの拡張

すべてのパケットにタイムスタンプを入れることで、RTTを正確に計測する。また、ウィンドウサイズを、最大1GBまで拡張。両者を組み合わせることで、最適なウィンドウサイズに設定することが可能になる。

選択確認応答(Selective ACK)

標準のTCPでは、複数のパケットのうち「どこまで受信したか」が確認応答で伝えられる。そのため、5つのパケットのうち、2番目が喪失したら、2番目以降をすべて再送してしまう。一方、選択確認応答は受け取っているパケットの情報を送信することで、ロスしたパケットのみ再送を依頼する。

限定転送(Limited Transmit)

TCPでは、2つのパケットが異なる順番で到着することがある。そのため、単に重複したACKが連続して戻ってきても、パケットロスかどうか判断できない。限定転送では、この場合はパケットの到着の順番がずれたものと判断し、そのままバッファにあるデータを転送する(図1)。もちろん、3回目で同じ確認応答が来た場合は、高速再転送を用いて、再送を行なう。

図1 TCPの限定転送

高速再転送(Fast Retransmit)

TCPではタイムアウトをパケットロスで判断するため、確認応答を待つRTTが無駄になる。これに対して高速再転送では、タイムアウトではなく、同一の確認応答が3回連続で到着した場合に再送を行なう(図2)。

図2 同じ確認応答が3階連続で到着した場合、TCPの高速再転送の仕組み

 その他、送信ウィンドウの初期値を1パケットから2パケットに拡張する「ふくそう回避機能付きスロースタート」、ふくそうが発生する前の状態を監視し、送信量を絞る「ふくそう情報通知」などが用意されている。こうした標準的なTCP最適化オプションは、WAN高速化装置だけではなく、通常のWebブラウザなどでサポートされているい。そのため、対称型のWAN高速化装置だけではなく、ロードバランサーやWeb高速化装置などでもサポートされている。

拡張TCP等を利用する対向型で用いる

 対向で設置するのが前提になっているWAN高速装置は、必ずしも標準のTCPを用いる必要はない。そのため、拡張TCPを用いるオプションも用意されている。

 たとえば、HSTCP(High speed TCP)では、ふくそう制御のメカニズムに改良を加えている。たとえば、通常のTCPではふくそうが発生するとウィンドウサイズを半分に落とし、RTTごとに1セグメントずつ増加させる。この場合、広帯域の回線では、元のサイズまで戻るまで非常に時間がかかってしまう。それに対して、HS-TCPではふくそうの発生頻度がどの程度かを監視し、帯域に応じて増減幅を決める。減らすときも一気に減らすのではなく緩やかに、戻すときは直前のセグメント量に応じて素早く増やすわけだ。そのため、スループットや帯域の利用効率は一気に向上する。

 こうした拡張TCPは、遅延の大きい国際WANや衛星通信で有効である。TCPの最適化は、TCPを用いるアプリケーションであれば、どれでもその恩恵を受けられる。

CIFSの最適化でファイル共有速くする

 これに加え、アプリケーションごとの最適化を施すことで、より高い効果が得られる。前回はHTTPの最適化を見てきたが、今回はファイル共有で用いられるCIFS(Common Internet File Systems)の高速化について見ていこう。

 CIFSはWindowsのファイル共有で用いられるプロトコルで、ネットワーク上のリソースを指定し、コマンドを送受信することで、ユーザー認証を行なったり、ファイルを送受信することが可能になる。

 ただ、このCIFSでは遅延の少ないLANでの利用を前提としているので、非常にやり取りの多い(チャッティ)のが悩みだ。1回のファイルのドラッグ&ドロップでなんと4000回のやり取りを行なう必要がある。LAN内でのファイル送受信であれば、これでもあまり問題はないが、WAN経由で利用する場合は致命的だ。そのため、エンドユーザーにストレスを与えるWAN経由でのファイル共有(WAFS:Wide Area File Services )は、これまで事実上実現できないソリューションであった。

 これに対して、WAN高速化装置ではホスト同士のCIFSのやり取りに割り込み、CIFSを最適化し、WAFSを実現する。具体的には、複数回に渡って行われているCIFSコマンドやデータの送受信を、少数にまとめてしまう(図3)。ホストとWAN高速化装置では、これまで通りのCIFSのやり取りだが、間を仲介するWAN高速化装置同士では、数回の送受信を束ねてしまうのだ。これにより、送信側はいちいちレスポンスを待たずに済む。

図3 CIFSのリクエストを少数にまとめる

 このCIFSの最適化と後述するキャッシング、圧縮などを組み合わせることで、WAN経由でのファイル共有でも高いレスポンスでの利用が可能になる。第1回で話したとおり、アクセスした際に取得したデータをキャッシュとして再利用する方法は、高速化のために幅広く用いられている。

(次ページ、WAN高速化で大きな効果を上げるキャッシュ)


 

前へ 1 2 次へ

カテゴリートップへ

この連載の記事
  • 角川アスキー総合研究所
  • アスキーカード