なぜ5の理由 WAN 最適化はアプリケーション プロキシを超えて進化しました

アプリケーション プロキシについて
アプリケーション プロキシは、パフォーマンス低下の原因となったアプリケーションの特性を「修正」するためのシムとして、アプリケーション データ ストリーム (通常は OSI モデルのレイヤー 4 ～ 7 の間で動作) の途中に挿入されるソフトウェアでした。を超えて WAN 繋がり。 これらの「修正」には、次の XNUMX 種類がある傾向がありました。

• アプリケーション データのデータ重複排除を可能にするもの。 また
• XNUMX つのアプリケーション エンドポイントが必要とする通信の総量 (「おしゃべり」) を削減するのに役立つもの WAN 接続。

アプリケーション プロキシ (従来のアプリケーション プロキシで使用される) WAN Riverbed などの最適化ベンダーは古いテクノロジーであり、現在ではあまり使用されていません。 WAN 今日の最適化スペース。

この移行の主な理由は次の 5 つです。

1) アプリケーション プロキシは、支援すると称するアプリケーションの多くを「破壊」する傾向が高くなります。

これが断然最大の理由です WAN 最適化テクノロジーは、「レイヤー 7 プロキシ」モデルから大幅に移行しました。

アプリケーション プロキシは、アプリケーション プロトコルの正確な仕様に従って作成する必要があります。 これは通常、次のような安定した低レベルのプロトコルには問題ありません。 SSLただし、MS-SQL や Citrix ICA などのより高度な独自のプロトコルでは問題になります。 これらのプロトコルは頻繁に変更されるため、変更内容は公開されません。

ネットワーク管理者の世界ではよくあることですが、どこかのサーバーがアップグレードされ、アプリケーションが正しく機能しなくなったというユーザーからの苦情が殺到し始めたときに、アプリケーション プロトコルが変更されたことを示す最初の手がかりが得られます。

アプリケーション プロキシが破損の原因として特定されたら、新しいアプリケーション バージョンと互換性があるようにプロキシをアップグレードする必要があります。 また、これらのプロトコルはプロキシ プロバイダーによるリバース エンジニアリングが必要になることが多いため、この破損の「修正」が利用可能になるまでに（「広く使用されている」とみなされるかどうかに応じて）何か月以上かかる場合があります。

このため、ネットワーク管理者に残された選択肢は 1 つだけです。 2) ネットワークが新しいアプリケーション バージョンをサポートしていないことをサーバー管理者に伝えます。 または XNUMX) 新しいアプリケーションを無視 (バイパス) するようにアプリケーション プロキシを設定し、基本的に最適化を行わずにアプリケーションをレンダリングします。

2) 特定のプロトコルがゆっくりと使用されなくなる。

このタイプの移行の例は、今日、MAPI などの独自の暗号化プロトコルで発生していることがわかります。 MAPI は Microsoft 独自の Exchange Server 電子メール プロトコルですが、さらに進化しています。 cloudベースと SaaS SSL は、SOHO やモバイル ユーザーにとって急速に企業プロトコルとして選ばれつつあります。 Microsoftもサポートしているので、 SSL Exchange の電子メール配信に関して、多くの企業が MAPI から非独自仕様に移行しつつあります。 SSL。 アプリケーションが独自のプロトコルから離れて進化するにつれて、この種のプロキシは時代遅れになります。

3) WAN 最適化テクノロジーは、特定のプロキシが不要になるまで進化しました。

NFS が良い例です。 ファイル共有プロトコルとしての NFS v3 には、スループットとエンドユーザーの応答時間に一定の制限がありました。 WAN 待ち時間。 これは主にプロトコルの設計方法が原因で、アプリケーションの応答を受信せずに一度に送信できるデータ量が制限されていました。

同時に、既存の WAN 最適化テクノロジーは主に、ネットワーク上で送受信する必要がある総データを削減する方法としてのデータ重複排除に焦点を当てていました。 WAN、それによって輻輳を解消し、応答時間を改善します。 しかし、これらの古いものは、 WAN 最適化テクノロジでは、ブロック レベルの重複排除の形式が使用されていましたが、NFS トラフィックではあまりうまく機能しませんでした。データ ブロックを照合するには、送信のデータ部分がどこから始まるかを知ることが役立つためです。 NFS プロトコル送信内のデータ部分の位置は異なる場合があります。

NFS を「修正」するための現時点での最良のソリューション WAN 問題は、アプリケーション プロキシを作成することでした。これにより、プロトコルで必要な通信量が人為的に削減され、ブロック レベルの重複排除が効果的に行われるように、NFS 送信のデータ部分がどこにあるかを把握することもできました。

伝統的な WAN 最適化ベンダーは依然として古い重複排除テクノロジーを使用しているため、NFS 最適化に shim を必要とします。しかし、新しいベンダーはアプリケーション固有のプロキシを必要とせずに NFS トラフィックを最適化でき、プロキシの最適化が最小限に抑えられるため、ネットワークに侵入するものが少なくなります。

4) 一部のアプリケーションまたはプロトコルは、長時間にわたってうまく動作しませんでした。 WAN 10 年前の接続は進化または再設計され、長時間にわたって動作できるようになりました。 WAN 中間シムなし。

もう一度、NFS を見てみましょう。 現在に遡ります。NFS v4.x の新しいバージョンでは、チャット性とスループットに関連するプロトコル制限のほとんどが修正されました。 残りの制限は汎用によって解決されます。 TCP アプリケーション固有のシムを必要とせずに最適化できます。

5) 「アプリケーション プロキシ」テクノロジ アーキテクチャは、ビジネスおよび開発の観点からは持続可能なモデルではありません。

まず、維持費が非常にかかる。 アプリケーションの新しいバージョンまたはその更新がアプリケーション ベンダーによってリリースされるたびに、アプリケーション プロキシ用に新しい固有の最適化メカニズムを開発する必要があります。

Citrix ICA を例に挙げると、Citrix ICA はプロトコルを所有しており、いつでもプロトコル仕様を変更できます。 リリースからリリースへ、またはサービス パックのアップデート内でも。 これらすべてのアプリケーション プロキシを追跡し、非推奨のプロトコルをサポートし続けることは、あまり効率的なビジネス モデルとは言えません。

また、将来のスケーラビリティも制限されます。 プロキシの本質は、リモート サーバーに代わって動作することです。 これを行うには、プロキシは各アプリケーション セッションを終了して追跡する必要があります。 これにより、ハードウェア要件の点で非常に高いオーバーヘッドが生じ、その結果、ますます大きなボックスが必要になります。

幸いなことに、かつてアプリケーション レベルのプロキシによって解決されていた問題は、現在ではより効率的な方法で解決されており、古いプロキシ テクノロジの元々の利点の一部が時代遅れになっています。 古いバージョンの CIFS や SMB など、アプリケーション層プロトコルはまだいくつかありますが、これらは、特定のプロキシを使用して最適化を行うことで恩恵を受けます。 WAN, しかし、そのリストはどんどん短くなっていきます。 特定のアプリケーション層プロキシへの依存を減らすことにより、今日のテクノロジーは、信頼性を向上させ、潜在的な障害点を排除しながら、より優れた最適化を提供できます。