アプリケーション・プロキシについてアプリケーション・プロキシとは、アプリケーション・データ・ストリーム（一般に OSI モデルのレイヤ 4～7 間で動作する）の途中に挿入され、WAN 接続上でパフォーマンスが低下するアプリケーションの特性を「修正」するためのシムとして使用されるソフトウェアです。
この「修正」には2つの種類があります：

  • アプリケーションデータのデータ重複排除を可能にするのに役立ったもの。
  • WAN接続を介して2つのアプリケーション・エンドポイントが必要とする通信（「チャット性」）の総量を削減するのに役立つもの。

アプリケーション・プロキシ（リバーベッドのような従来のWAN最適化ベンダーが使用）は古い技術であり、今日のWAN最適化の分野ではあまり使用されなくなってきています。 5理由 この変遷の理由トップ5は次のとおりです：1) アプリケーション・プロキシは、それが支援すると称するアプリケーションの多くを「壊す」傾向があります。これが、WAN最適化技術が「レイヤ7プロキシ」モデルから大きく移行した最大の理由です。 アプリケーション・プロキシは、アプリケーション・プロトコルの仕様に忠実に記述する必要があります。 SSLのような安定した低レベルのプロトコルでは一般的に問題ありませんが、MS-SQLやCitrix ICAのような高レベルの独自プロトコルでは問題になります。 これらのプロトコルは頻繁に変更され、その変更は公表されていません。 ネットワーク管理者の世界ではよくあることですが、どこかのサーバーがアップグレードされ、アプリケーションのプロトコルが変更されたことを知る最初の手がかりは、アプリケーションが正しく機能しなくなったというユーザーからの苦情が殺到したときです。 アプリケーションのプロキシが破損の原因として特定されたら、プロキシを新しいアプリケーションのバージョンと互換性を持つようにアップグレードする必要があります。 また、これらのプロトコルはしばしばプロキシプロバイダーによってリバースエンジニアリングされなければならないため、この破損に対する「修正」が利用可能になるまでには、（それが「広く使われている」とみなされるかどうかにもよりますが）何ヶ月も、あるいはそれ以上かかることがあります。 このため、ネットワーク管理者には2つの選択肢しかありません： 1) ネットワークが新しいアプリケーションのバージョンをサポートしていないことをサーバー管理者に伝える、または 2) アプリケーションプロキシを設定し、新しいアプリケーションを無視（バイパス）します。 2) 特定のプロトコルが徐々に使われなくなること。 このような移行の例は、MAPI のような独自の暗号化プロトコルに見られます。
MAPIはマイクロソフトが独自に開発したExchangeサーバーの電子メールプロトコルですが、クラウドベースやSaaSアプリケーションの進化に伴い、SSLはSOHOやモバイルユーザーが企業で選択するプロトコルに急速になりつつあります。
また、マイクロソフト社もExchangeのメール配信にSSLをサポートしているため、多くの企業がMAPIから非独占的なSSLへと移行しています。
アプリケーションがプロプライエタリ・プロトコルから離れるにつれて、この種のプロキシは時代遅れになります。 3) WAN最適化技術は、もはや特定のプロキシを必要としないところまで進化しています。 NFSが良い例です。
NFS v3はファイル共有プロトコルとして、WANの遅延に関連するスループットとエンドユーザーの応答時間に一定の制限がありました。
これは主にプロトコルの設計方法によるもので、アプリケーションの応答を受信せずに一度に送信できるデータ量が制限されていました。
同時に、既存のWAN最適化技術は、WAN上で送受信されるデータの総量を減らし、それによって輻輳を解消してレスポンスタイムを改善する方法として、主にデータ重複排除に焦点を当てていました。
しかし、これらの古い WAN 最適化技術は、NFS トラフィックではあまりうまく機能しないブロックレベルの重複排除を使用していました。
NFSプロトコル伝送内のデータ部分の位置は様々です。
当時、NFS WAN問題を「解決」するための最善の解決策は、アプリケーションプロキシを作成することでした。これは、プロトコルが必要とする通信量を人為的に減少させるとともに、NFS伝送のデータ部分がどこにあるかを把握することで、ブロックレベルの重複排除を効果的に行うことができます。
従来のWAN最適化ベンダーは、古い重複排除技術を使用しているため、NFS最適化のためのシムをまだ必要としていますが、新しいベンダーは、アプリケーション固有のプロキシを必要とせずにNFSトラフィックを最適化することができます！ 4) 10年前にはWAN接続でうまく動作しなかったアプリケーションやプロトコルが、中間シムなしでWAN上で動作するように進化したり、再設計されたりしています。 もう一度、NFSを見てみましょう。
NFS v4.xの後のバージョンでは、チャット性とスループットに関するプロトコルの制限のほとんどが修正されました。
残りの制限は、アプリケーション固有のシムを必要とせず、一般的なTCP最適化によって解決されています。 5) 「アプリケーション・プロキシ」技術アーキテクチャは、ビジネスと開発の観点から持続可能なモデルではありません。 第一に、メンテナンスに非常にコストがかかります。
アプリケーションの新しいバージョンやそのアップデートがアプリケーション・ベンダーからリリースされるたびに、アプリケーション・プロキシ用に新しい特定の最適化メカニズムを開発しなければなりません。
例えば、Citrix ICAはプロトコルを所有しており、リリースからリリースへ、あるいはサービスパックのアップデートの中でさえ、いつでもプロトコル仕様に変更を加えることができます。
これらすべてのアプリケーション・プロキシを追跡し、非推奨のプロトコルをサポートし続けることは、あまり効率的なビジネスモデルではありません。
それはまた、将来のスケーラビリティを制限します。
プロキシの本質は、リモートサーバに代わって動作することです。
これを行うために、プロキシはそれぞれのアプリケーションの セッションを終了して追跡しなければなりません。
これは、ハードウェアの要件という点で 非常に高いオーバーヘッドを生み出し、その結果、より大きな、より大きな箱が 必要になります。
幸運なことに、かつてアプリケーションレベルのプロキシによって解決されていた問題は、現在ではより効率的な方法で解決され、古いプロキシ技術の本来の利点のいくつかは時代遅れになっています。
古いバージョンのCIFSやSMBのように、WAN上での最適化のために特定のプロキシを持つことで恩恵を受けるアプリケーション層のプロトコルはまだいくつかありますが、そのリストは常に少なくなっています。
特定のアプリケーション層プロキシへの依存を減らすことで、今日のテクノロジーは、信頼性を向上させ、潜在的な障害点を取り除きながら、より優れた最適化を提供することができます。