WAN経由でのアプリケーションレスポンスを向上させるWAN高速化の技術だ。今回は前回紹介したTCPの弱点を補う各種の拡張のほか、対向で利用する製品ならではのユニークなキャッシング、圧縮などの機能を紹介する。
本記事は「アプリケーショントラフィック管理入門」の第6回です。過去の記事も合わせてご覧ください。
標準のTCPの改良技術を利用
TCPは、インターネットですでに25年近く用いられている老舗のプロトコルだ。そのため、前回紹介したような弱点は以前から認識されており、以下のようなTCP最適化機能が、RFC化されている。
ウィンドウサイズの拡張
すべてのパケットにタイムスタンプを入れることで、RTTを正確に計測する。また、ウィンドウサイズを、最大1GBまで拡張。両者を組み合わせることで、最適なウィンドウサイズに設定することが可能になる。
選択確認応答(Selective ACK)
標準のTCPでは、複数のパケットのうち「どこまで受信したか」が確認応答で伝えられる。そのため、5つのパケットのうち、2番目が喪失したら、2番目以降をすべて再送してしまう。一方、選択確認応答は受け取っているパケットの情報を送信することで、ロスしたパケットのみ再送を依頼する。
限定転送(Limited Transmit)
TCPでは、2つのパケットが異なる順番で到着することがある。そのため、単に重複したACKが連続して戻ってきても、パケットロスかどうか判断できない。限定転送では、この場合はパケットの到着の順番がずれたものと判断し、そのままバッファにあるデータを転送する(図1)。もちろん、3回目で同じ確認応答が来た場合は、高速再転送を用いて、再送を行なう。
高速再転送(Fast Retransmit)
TCPではタイムアウトをパケットロスで判断するため、確認応答を待つRTTが無駄になる。これに対して高速再転送では、タイムアウトではなく、同一の確認応答が3回連続で到着した場合に再送を行なう(図2)。
その他、送信ウィンドウの初期値を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高速化装置同士では、数回の送受信を束ねてしまうのだ。これにより、送信側はいちいちレスポンスを待たずに済む。
このCIFSの最適化と後述するキャッシング、圧縮などを組み合わせることで、WAN経由でのファイル共有でも高いレスポンスでの利用が可能になる。第1回で話したとおり、アクセスした際に取得したデータをキャッシュとして再利用する方法は、高速化のために幅広く用いられている。
(次ページ、WAN高速化で大きな効果を上げるキャッシュ)
この連載の記事
-
第5回
ネットワーク
WANの遅延を抑えて、レスポンスアップする -
第4回
ネットワーク
サーバーの処理を肩代わりする「オフロード」とは? -
第3回
ネットワーク
ますます高機能化するロードバランサーの技術 -
第2回
ネットワーク
知っておきたいロードバランサーの基礎技術 -
第1回
ネットワーク
アプリケーションを快適に使うためになにが必要? -
ネットワーク
アプリケーショントラフィック管理入門<目次> - この連載の一覧へ