(57)【要約】任意のアプリケーションの応答時間挙動を監視するシステムが提供される。このシステムは、パケットレベルおよびトランザクションレベルの応答時間を提供する。応答時間遅延は、ボトルネックを識別するためにネットワーク成分およびサーバ成分に分けられる。ネットワーク遅延成分は、連続的な革新を使用して更新することができる。応答時間の計算は、任意の所望のクライアントからの実際のアプリケーションに基づいている。
2005506605.tif 000002
【特許請求の範囲】
【請求項１】
クライアントサイトエージェントに依存することなくネットワークにおける応答時間を決定する方法であって、
サーバサイトエージェントを提供するステップと、
サーバ遅延を測定するステップと、
ネットワーク遅延を推定するステップと、
測定されたサーバ遅延および推定されたネットワーク遅延に基づいてネットワーク上のクライアントの応答時間を決定するステップと
を備える方法。
【請求項２】
サーバ応答と応答のクライアント肯定応答の間の時間量を測定することによってネットワーク遅延が推定される請求項１に記載の方法。
【請求項３】
ネットワーク遅延が連続的に推定される請求項２に記載の方法。
【請求項４】
クライアントがサーバからの応答を承認するたびにネットワーク遅延が推定される請求項２に記載の方法。
【請求項５】
応答時間が実際のアプリケーションパケットを使用して決定される請求項１に記載の方法。
【請求項６】
応答時間がテストパケットを使用することなく決定される請求項５に記載の方法。
【請求項７】
複数の応答時間がある期間にわたって決定される請求項１に記載の方法。
【請求項８】
応答のサイズに基づいて決定された応答時間を区別するステップをさらに備える請求項７に記載の方法。
【請求項９】
任意のアプリケーション用の応答時間挙動を決定するサーバサイト監視システムであって、
サーバサイトエージェントを備え、サーバサイトエージェントが
アプリケーション応答時間を決定する処理ステップと、
決定された応答時間をネットワーク遅延成分とサーバ遅延成分に分ける処理ステップと
を行うシステム。
【請求項１０】
ネットワーク遅延を推定し、サーバ遅延を決定し、ネットワーク遅延およびサーバ遅延に基づいて合計遅延を推定することによってアプリケーション応答時間が決定される請求項９に記載のサーバサイト監視システム。
【請求項１１】
アプリケーション応答時間がクライアントサイトエージェントに依存することなく決定される請求項９に記載のサーバサイト監視システム。
【請求項１２】
複数のエージェントを必要とすることなくＷＡＮにおける応答時間を決定する方法であって、
ＷＡＮ上のどこかにエージェントを提供するステップと、
ＷＡＮ上の１つまたは複数のトランザクションについて、終端間応答時間、サーバ遅延、およびネットワーク遅延を決定するステップと
を備える方法。
【請求項１３】
エージェントがサーバサイトエージェントである請求項１２に記載の方法。
【請求項１４】
サーバ遅延を測定するステップと、
ネットワーク遅延を近似するステップと、
測定されたサーバ遅延を近似されたネットワーク遅延に追加することによって終端間応答時間を決定するステップと
によって終端間応答時間が決定される請求項１３に記載の方法。
【請求項１５】
エージェントがクライアントサイトエージェントである請求項１２に記載の方法。
【請求項１６】
終端間応答時間を測定するステップと、
ネットワーク遅延を近似するステップと、
測定された終端間応答時間から近似されたネットワーク遅延を差し引くことによってサーバ遅延を決定するステップと
によってサーバ遅延が決定される請求項１５に記載の方法。
【請求項１７】
エージェントがクライアント−サーバ経路に沿って配置されている請求項１２に記載の方法。
【請求項１８】
ネットワークにおけるトランザクションレベルの応答時間を決定する方法であって、
複数の個々の成分から成るトランザクションについて、個々の成分のそれぞれの応答時間を追跡するステップと、
個々の成分の追跡された応答時間を使用してトランザクションを再構築することによってトランザクションの応答時間を決定するステップと
を備える方法。
【請求項１９】
トランザクションを表す数式を導出するステップと、
導出された数式を使用してトランザクションを再構築するステップと
をさらに備える請求項１８に記載の方法。
【請求項２０】
パケットレベル応答時間がネットワーク上にインストールされたエージェントによって決定される請求項１８に記載の方法。
【請求項２１】
エージェントがサーバサイトエージェントである請求項２０に記載の方法。
【請求項２２】
エージェントがクライアントサイトエージェントである請求項２０に記載の方法。
【請求項２３】
ネットワーク上の別のエージェントに依存することなくパケットレベル応答時間がエージェントによって決定される請求項２０に記載の方法。
【請求項２４】
ネットワークにおけるトランザクションの応答時間を決定する方法であって、
要求および応答のシーケンスから成るトランザクションを定義するために数式を導出するステップと、
要求および応答のシーケンスのパケットレベルの応答時間を決定するステップと、
導出された数式およびパケットレベル応答時間に基づいてトランザクションを再構築するステップと
を備える方法。
【請求項２５】
パケットレベル応答時間がサイズによって追跡される請求項２４に記載の方法。
【請求項２６】
パケットレベル応答時間がアプリケーショングループによって追跡される請求項２４に記載の方法。
【請求項２７】
パケットレベル応答時間がサーバグループによって追跡される請求項２４に記載の方法。
【請求項２８】
パケットレベル応答時間がクライアントグループによって追跡される請求項２４に記載の方法。
【請求項２９】
エージェントを提供してトランザクションの応答時間を決定するステップをさらに備える請求項２４に記載の方法。
【請求項３０】
エージェントがサーバサイトエージェントである請求項２９に記載の方法。
【請求項３１】
サーバサイトエージェントがクライアントサイトエージェントに依存することなく応答時間を決定する請求項３０に記載の方法。
【請求項３２】
エージェントがクライアントサイトエージェントである請求項２９に記載の方法。
【請求項３３】
ネットワークにおけるネットワーク遅延を推定する方法であって、
（Ａ）サーバサイトエージェントを提供するステップと、
（Ｂ）サーバがクライアントに応答を送信したときからサーバがクライアントから肯定応答を受信したときまでの時間量を決定するステップと、
（Ｃ）決定された時間量に基づいてネットワーク遅延を推定するステップと、
（Ｄ）ネットワーク遅延が一定ではない場合、ステップ（Ｂ）および（Ｃ）を繰り返してネットワーク遅延の推定の精度を向上させるステップと
を備える方法。
【請求項３４】
クライアントから肯定応答が受信されるといつでもステップ（Ｂ）および（Ｃ）が繰り返される請求項３３に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータサーバとクライアントの間の通信に必要な時間を決定するための方法に関する。
【背景技術】
【０００２】
ネットワークおよびＭＩＳの管理者は、ビジネス上重要なアプリケーションをエンドユーザからサーバを分離するネットワークを介して円滑に動作し続ける状態にしておきたいという意識をもつ。管理者は、ユーザが経験する応答時間の挙動を監視し、潜在的なネットワークとサーバのボトルネックをできるだけ迅速に明確に識別したい。また管理者は、専門家は危機的に不足しているために監視システムの管理／メンテナンスによって工数コストを低減することを好む。疑陽性がほとんどなく（そうでなければ警報が無視される）、また偽陰性もほとんどなく（そうでなければ問題にすぐに気づかない）、情報が一貫して信頼性の高いものであることが望ましい。
【０００３】
既存の応答時間の監視の解決策は、３つの主なカテゴリの１つに分類される。３つのカテゴリとは、クライアントサイトエージェント（クライアントと同じサイトにあるクライアントの近くに配置されているエージェント）を必要とするもの、加入サービス（ｓｕｂｓｃｒｉｐｔｉｏｎ  ｓｅｒｖｉｃｅ）、および特殊なアプリケーション専用の解決策である。こうした既存の解決策について、以下で簡単に説明する。
【０００４】
終端間応答時間、または合計応答時間がそこから計算される各クライアントサイトの近くにハードウェアおよび／またはソフトウェアエージェントがインストールされていることを必要とする既存の応答時間監視ツールがいくつかある（ＮｅｔＩＱのＰｅｇａｓｕｓやＣｏｍｐｕｗａｒｅのＥｃｏｓｃｏｐｅなど）。この手法に関する主な問題は、エージェントをインストールさせ、動作し続けるようにすることが難しい、あるいは不可能である場合があることである。グローバルネットワークの場合、エージェントはかなりの数となる可能性があり、インストールに手間取り、メンテナンスが困難となる場合がある。ｅＣｏｍｍｅｒｃｅサイトの場合、エージェントのインストールは現実的ではない。ソフトウェアをコンピュータにインストールするよう潜在顧客に要求していては、おそらく大きな成功を得られないであろう。この手法に関する２番目の問題は、各クライアントサイトエージェントは各測定値を中央管理プラットフォームにアップロードしなければならず、これによって高価となり得る広域エリアリンク上に不要なトラフィックが追加される。この手法に関する３番目の問題は、サーバ遅延の寄与率（ｃｏｎｔｒｉｂｕｔｉｏｎ）からネットワークを実際に分離することは難しいということである。
【０００５】
膨大な数のエージェントのインストールに関する問題を克服するために、一部の企業（ＫｅｙＮｏｔｅｓやＭｅｒｃｕｒｙ  Ｉｎｔｅｒａｃｔｉｖｅなど）は、プリインストールされたエージェントを使用して応答時間を監視するための加入サービスを提供している。この手法に関して主に２つの問題がある。１つは、エージェントは「真の」クライアントトラフィックを監視するのではなく、「定義された」わずかのトランザクションを人工的に生成することである。別の問題は、監視は、すべてのクライアントサイトの全範囲を全体的にカバーしているのではなく、サービスプロバイダがインストール済みのエージェントを有しているところに限定されることである。
【０００６】
ごく少数の企業（Ｌｕｍｉｎａｔｅ）が使用している３番目の手法は、クライアントサイトエージェクトではなく、サーバサイトエージェント（サーバと同じサイトにあるサーバの近くに配置されているエージェント）を介して監視の解決策を提供することである。こうした既存のツールに関する欠点は、単一のアプリケーション（ＳＡＰ／Ｒ３またはＷｅｂ）しかサポートしない、実際のクライアントアプリケーションパケットではなく、生成されたインターネット制御メッセージプロトコル（ＩＣＭＰ）パケットを使用してネットワーク応答時間を推定する、あるいはＴＣＰセッションの期間を通じて一定のネットワーク応答時間を想定することである。ＩＣＭＰパケットは、それらのプロトコル（個別の管理キューおよび／ＱｏＳポリシ）、サイズ（直列化および／またはスケジューリング規範）、およびタイミング（アプリケーションパケットと同じときに送信されない）のために、実際のクライアントアプリケーションパケットとずいぶん異なるように扱われる場合がある。ネットワーク応答時間は一般に、ＴＣＰセッションを通じてかなり変化する。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
したがって、従来技術に見られる問題を克服するサーバサイト応答時間の計算方法が必要であることがわかる。
【課題を解決するための手段】
【０００８】
クライアントサイトエージェントに依存することなくネットワークにおける応答時間を決定する本発明の方法が提供される。この方法は、サーバサイトエージェントを提供するステップと、サーバ遅延を測定するステップと、ネットワーク遅延を推定するステップと、測定されたサーバ遅延および推定されたネットワーク遅延に基づいてネットワーク上のクライアントの応答時間を決定するステップとを備える。
【０００９】
本発明の一実施形態は、任意のアプリケーション用の応答時間挙動を決定するサーバサイト監視システムを提供する。このシステムは、サーバサイトエージェントを備え、サーバサイトエージェントがアプリケーションの応答時間を決定する処理ステップと、決定された応答時間をネットワーク遅延成分とサーバ遅延成分に分ける処理ステップとを行う。
【００１０】
本発明の一実施形態は、複数のエージェントを必要とすることなくＷＡＮにおける応答時間を決定する方法を提供する。この方法は、ＷＡＮ上のどこかにエージェントを提供するステップと、ＷＡＮ上の１つまたは複数のトランザクションについて、終端間応答時間、サーバ遅延、およびネットワーク遅延を決定するステップとを備える。
【００１１】
本発明の一実施形態は、ネットワークにおけるトランザクションレベルの応答時間を決定する方法を提供する。この方法は、複数の個々の成分から成るトランザクションについて、個々の成分のそれぞれの応答時間を追跡するステップと、個々の成分の追跡された応答時間を使用してトランザクションを再構築することによってトランザクションの応答時間を決定するステップとを備える。
【００１２】
本発明の一実施形態は、ネットワークにおけるトランザクションの応答時間を決定する方法を提供する。この方法は、要求および応答のシーケンスから成るトランザクションを定義するために数式を導出するステップと、要求および応答のシーケンスのパケットレベルの応答時間を決定するステップと、導出された数式およびパケットレベルの応答時間に基づいてトランザクションを再構築するステップとを備える。
【００１３】
本発明の一実施形態は、ネットワークにおけるネットワーク遅延を推定する方法を提供する。この方法は、（Ａ）サーバサイトエージェントを提供するステップと、（Ｂ）サーバがクライアントに応答を送信したときからサーバがクライアントから肯定応答を受信したときまでの時間量を決定するステップと、（Ｃ）決定された時間量に基づいてネットワーク遅延を推定するステップと、（Ｄ）ネットワーク遅延が一定ではない場合、（Ｂ）および（Ｃ）を繰り返してネットワーク遅延の推定の精度を向上させるステップとを備える。
【００１４】
本発明の他の目的、特徴、および利点は、添付の図面、および以下の詳細な説明から明らかになる。
本発明は、限定的なものではなく、例示的なものとして添付の図に示す。図中、同様の参照番号は同じ要素を示す。
【発明を実施するための最良の形態】
【００１５】
簡単に言えば、本発明は、任意のアプリケーションの応答時間挙動を報告するサーバサイト監視プロセスである。本発明では、クライアントサイトにエージェントを配備する必要はないが、本発明はこの構成に対応している。エージェントをサーバサイトとクライアントサイトの両方に配備した場合、情報を相関させて精度が向上する。サーバサイトを配備することによって、管理およびマネジメント上の問題が大幅に低減する。
【００１６】
本発明の解決策は、任意のアプリケーションに対応しており、ハイパーテキスト転送プロトコル（ＨＴＴＰ）やＳＡＰなど特定のアプリケーションに限定されない。本発明は、パケットレベルの応答時間を自動的に提供するとともに、トランザクション定義に基づいてトランザクションレベルの応答時間を提供する。トランザクションレベルの応答時間は、再構築プロセスを使用して取得される。応答時間遅延は、ボトルネックを明確に識別するために（アプリケーション転送遅延や再送遅延など他の遅延測定基準に加えて）ネットワーク成分およびサーバ成分に分けられる。ネットワーク遅延成分は、連続的な革新（ｃｏｎｔｉｎｕａｌ  ｉｎｎｏｖａｔｉｏｎｓ）を使用して更新される。応答時間の計算は、（加入エージェントが配置されているところだけではなく）それぞれすべての所望のクライアントからの（被模倣アプリケーションまたはＩＣＭＰではなく）実際のアプリケーションに基づいている。信頼性の高いアプリケーションでは、ネットワーク遅延に対する連続的な革新がクライアントの肯定応答ごとに計算される。信頼性の低いアプリケーションでは、ネットワーク遅延に対する連続的な革新は、接続設定時間とともに被模倣アプリケーションパケットを使用して得られる。
【００１７】
本発明の解決策では、応答サイズが許容可能な性能を決定するための重要なパラメータであることを認識している。たとえば、１００ＭＢのダウンロードを要求するユーザは、当然、１００ＫＢのダウンロードを要求するユーザより長い応答時間を経験するはずである。したがって応答時間の測定値および警報は、応答のサイズに基づいて分けられる。
【００１８】
本発明をよりよく理解するために、本発明を、ネットワークを介してサーバと通信するクライアントの文脈で説明する。以下は、本発明を使用できるネットワーク環境における応答時間の背景説明である。
【００１９】
図１は、ネットワーク１４を介してサーバ１２と通信するクライアント１０を示す。クライアント１０は、要求１６をサーバ１２に送信し、サーバは１つまたは複数の応答パケット１８に応答する。肯定応答を使用している信頼性の高いアプリケーションの場合、クライアントは、肯定応答２０で応答メッセージの受領を通知する。次いでクライアントは、別の要求２２をサーバに送信することができる。一般に、トランザクション（Ｗｅｂページ上のＵＲＬをクリックする、注文する、クエリを実行するなど）は、いくつかのクライアント要求および対応するサーバ応答で構成することができる。図１では、Ｔ０からＴ１４でさまざまな時間が指定されている。以下の時間を次のように定義することができる。
【００２０】
第１の合計応答時間：Ｔ７−Ｔ０
合計応答時間：Ｔ８−Ｔ０
サーバ処理遅延（下限）：Ｔ３−Ｔ２
サーバ処理遅延（上限）：Ｔ４−Ｔ２
アプリケーション転送遅延：Ｔ４−Ｔ３
ネットワーク遅延：Ｔ２−Ｔ０＋Ｔ８−Ｔ４
合計応答時間＝サーバ処理遅延（上限）＋ネットワーク遅延
合計応答時間＝サーバ処理遅延（下限）＋アプリケーション転送遅延＋ネットワーク遅延
クライアント思考時間：Ｔ１２−Ｔ８
要求到着間時間：Ｔ１２−Ｔ０
一般に、クライアント要求１６は、ある時点ではなく、ある期間にわたって到着する可能性がある（クライアント要求が複数のパケットで構成されている場合など）。このイベントで、時刻Ｔ２は要求の最後の到着時刻を表すが、要求到着継続時間もまた合計応答時間に追加する必要がある。
【００２１】
アプリケーション応答測定（ＡＲＭ）アプリケーションプログラムインターフェース（ＡＰＩ）を使用して書かれたアプリケーションの場合、アプリケーションは、そのトランザクションの成分を明示的に識別する。よく知られているアプリケーションの場合、パケットフィルタパターン照合を使用して、開始、中間、終了、肯定応答といった異なる成分のトランザクションフローを識別することができる。任意のトランザクション制御プロトコル（ＴＣＰ）アプリケーションでは、トランザクションをパケットレベルで定義することができる。トランザクションレベルの応答時間の代わりにパケットレベルの応答時間が使用される。クライアント要求は、データを含むクライアントからのパケット（ゼロ以外のＴＣＰ  ＬＥＮＧＴＨフィールド）として識別される。サーバ応答は、データを含むサーバからのパケット（ゼロ以外のＴＣＰ  ＬＥＮＧＴＨフィールド）として識別される。要求は、タイミング情報と併せて、ＴＣＰ  ＳＥＱＵＥＮＣＥフィールドおよびＡＣＫＮＯＷＬＥＤＧＭＥＮＴフィールドで応答に一致する。一例として、ＴＣＰプロトコルは、応答パケットのＡＣＫＮＯＷＬＥＤＧＭＥＮＴフィールドに適切な値を入れることによってパケットが肯定応答されるよう要求する。この値は、要求側パケット内のペイロードバイト数を要求側パケットのＳＥＱＵＥＮＣＥ番号に追加することによって決まる。これに加えて、ＳＹＮまたはＦＩＮのフラグが要求側パケットに設定されている場合は、肯定応答値を１ずつ増分させる必要がある。データパケットが観察されているときはいつでも、（数ある中でも特に）パケットが検出された時刻、およびパケットの受領を通知するために他のホストが使用する値を含む、Ｏｐｅｎ  ＭｉｎｉＴｒａｎｓａｃｔｉｏｎと呼ばれるデータ構造を割り振ることができる。肯定応答側パケットが観察されているときはいつでも、そのＡＣＫＮＯＷＬＥＤＧＭＥＮＴフィールドが既存のＯｐｅｎ  ＭｉｎｉＴｒａｎｓａｃｔｉｏｎデータ構造内の肯定応答予想値と比較される。一致が検出されると、データパケットが観察された時刻が肯定応答パケットが観察された時刻から差し引かれ、その差がミニトランザクション時間（ｍｉｎｉｔｒａｎｓａｃｔｉｏｎ  ｔｉｍｅ）とみなされる。最初のミニトランザクションデータパケットがサーバホストから開始した場合、ミニトランザクション時間は、ネットワーク往復時間とみなされる。ミニトランザクションデータパケットがクライアントホストから開始した場合、ミニトランザクション時間は、サーバ処理時間とみなされる。
【００２２】
再度図１を参照すると、クライアントが要求１６（パケットレベルまたはトランザクションレベル）を送信したときから応答１８の最後のパケットを受信したときまでに経過した時間を合計応答時間（Ｔ８−Ｔ０）と呼ぶ。この応答時間は、サーバ処理遅延およびネットワーク遅延で構成される。サーバ処理遅延は、任意のアプリケーションの場合、明確に識別するのは難しいが、範囲を定めることはできる。サーバ処理遅延における下限は、サーバがクライアント要求１６を受信したときから応答メッセージ１８の最初のデータパケットを送信したときまでの時間（Ｔ３−Ｔ２）である。このサーバ処理遅延（下限）は、要求を完全に処理する前にサーバが予備情報（たとえば「要求を処理する間お待ちください」というメッセージ）を発送した場合、本当のサーバ処理遅延とは大幅に異なる可能性がある。サーバ処理遅延における上限は、サーバがクライアント要求１６を受信したときから応答メッセージ１８の最後のパケットを送信したときまでの時間（Ｔ４−Ｔ２）である。このサーバ処理遅延（上限）は、プロトコルのウィンドウ表示（ｗｉｎｄｏｗｉｎｇ）および再送による大幅なネットワーク遅延を含んでいる可能性がある。このタイミング情報の識別は、ボトルネック識別およびネットワーク／アプリケーション計画には重要である。サーバ処理遅延（上限）とサーバ処理遅延（下限）の間の差がアプリケーション転送遅延である。
【００２３】
エージェントを使用して、ネットワーク上のさまざまな場所にあるアプリケーションに関するタイミング情報を収集することができる。一般にエージェントが時間を捕らえることができるのは、パケットがエージェントを通過するときのみである。たとえば、図１で、クライアント１０に配置されているエージェント２４が観察できるのは、時刻Ｔ０、Ｔ７、Ｔ８、Ｔ９、Ｔ１２のみである。サーバ１２に配置されているエージェント２６が観察できるのは、時刻Ｔ２、Ｔ３、Ｔ４．Ｔ１１、Ｔ１４のみである。広域ネットワーク（ＷＡＮ）１４に沿って配置されているエージェント２８が観察できるのは、Ｔ１、Ｔ５、Ｔ６、Ｔ１０、Ｔ１３のみである（アプリケーションパケットはＷＡＮエージェント２８を過ぎて両方向に経路指定されると仮定する）。
【００２４】
クライアントサイトエージェント２４は、合計応答時間を正確に計算することはできるが、サーバ処理成分およびネットワーク遅延成分を識別することは難しい。商用エージェントで使用されている一般の識別方法は、ＴＣＰセッション設定時間に等しいネットワーク遅延を割り当てることである。この方法は、セッション設定中サーバ処理がごくわずかである（しばしば妥当）、およびネットワーク遅延がセッションを通じて一定である（セッションが非常に短い場合にのみ妥当）という２つの前提に基づいている。一部のアプリケーション、特にＴｅｌｎｅｔおよびファイル転送プロトコル（ｆｔｐ）に基づくものの中には、セッションを何時間も開いたままにしているものもある。動的なＷｅｂサイトと結合されているＨＴＴＰでのキープライアイブの選択によって、結果的に従来よりＷｅｂセッションが長くなる。バースト性のネットワークトラフィックが与えられた場合、セッションを通じて一定したネットワーク遅延を想定するのは非現実的である。実際にネットワーク遅延が短い時間間隔にわたって動的に変化する可能性がある場合、クライアント側でのネットワーク遅延の計算には、ある期間にわたって遅延が一定であるという前提が必要である。
【００２５】
クライアント−サーバおよびサーバ−クライアントの経路に沿ったどこかに配置されているエージェント２８は、通過するパケットの到着時刻を記録することができる。エージェント２８は、クライアント要求１６をインターセプトしたときから最初および最後（およびその間のすべて）のサーバ要求１８を受信したときまでに経過した時間を特定することができる。これらの時間はそれぞれ「最初のエージェント＝＞サーバ＝＞エージェント」応答時間および「最後のエージェント＝＞サーバ＝＞エージェント」応答時間と呼ばれる。エージェント２８がクライアント１０の近くに配置されている場合、「最後のエージェント＝＞サーバ＝＞エージェント」応答時間は、合計応答時間にほぼ等しいことになる。エージェント２８がクライアント１０から離れている場合、２つの統計値もクライアント要求１６がクライアント１０からエージェント２８にトラバースするのに必要な時間プラス最後の応答パケット１８がエージェント２８からクライアント１０に移動するのに必要な時間だけ異なることになる。本質的に、合計応答時間および「最後のエージェント＝＞サーバ＝＞エージェント」応答時間は、クライアント１０とエージェント２８の間の往復ネットワーク遅延だけ異なる。
【００２６】
エージェント２８は、信頼性の高いアプリケーションの場合、エージェント２８がサーバ応答パケット１８をインターセプトしたときから関連するクライアント肯定応答２０を検出したときまでに経過した時間を計算することによって、この往復の「クライアント＝＞エージェント＝＞クライアント」ネットワーク遅延の推定を行うことができる。この推定は、「最初のエージェント＝＞クライアント＝＞エージェント」応答時間と呼ばれる。この推定は、プローブするクライアントからの要求パケット１６ではなく肯定応答２０の送信時間を使用するという点で実時間とは異なる。信頼性の低いアプリケーションの場合、セッション時間に結合されるアプリケーションプローブパケット（ａｐｐｌｉｃａｔｉｏｎ  ｐｒｏｂｅ  ｐａｃｋｅｔ）（たとえばそのアプリケーションと同じＴＣＰポートを使用するＴＣＰ  ＳＹＮ／接続要求パケット）は、推定要素（ｅｓｔｉｍａｔｏｒ）として使用することができる。
【００２７】
サーバサイトエージェント２６は、サーバ遅延（図１のＴ３−Ｔ２およびＴ４−Ｔ２）を正確に計算することはできるが、何らかの方法を使用してネットワーク遅延時間および合計応答時間を概算する必要がある。ネットワーク遅延は、上述したように推定することができる（図１のＴ１１−Ｔ４）。合計応答時間は、他の２つの確率変数の合計となる確率変数である。２つの確率変数とは、サーバの第１の応答処理遅延Ｔ３−Ｔ２、および混合の遅延（ｍｉｘｅｄ  ｄｅｌａｙ）Ｔ１１−Ｔ３である（サーバ合計遅延Ｔ４−Ｔ２は一般に、再送およびプロトコルのウィンドウ表示によるネットワーク遅延を含むことに注意されたい）。２つの追加物を無関係とみなすことは非常に妥当な仮定であり、そのように仮定すると、合計応答時間の分布は、追加物の応答時間分布のたたみ込み（ｃｏｎｖｏｌｕｔｉｏｎ）から求めることができる。パケットサイズの差による往復のクライアントエージェント遅延を実際より低く推定することによって、一般に、合計応答時間が気になるほど大きい場合、合計応答時間の統計値に与える影響が無視できるはずである。この遅延差は、ネットワーク経路に沿ってサイズ差による直列化遅延を計算することによって推定することができ、したがって修正することができる。
【００２８】
パケットレベルの応答時間の計算は、ＴＣＰおよびＩＰのパケットヘッダに格納されている情報に基づいている。したがって、任意のＴＣＰ／ＩＰアプリケーションとともに使用することができる。対象となるもう１つの測定基準は、トランザクションが１つまたは複数のクライアント要求で構成されるトランザクションレベルの応答時間である。たとえば、Ｗｅｂをブラウズしているユーザを考察する。ユーザはＵＲＬ上をクリックし、それによってサーバに送信される５つのクライアント要求パケット（テキストのパケット、およびそのページ上の４つ画像のそれぞれのパケット）がもたらされる。トランザクション応答時間は、ユーザがＵＲＬをクリックしたときからページのロードが完了したときまでの経過時間となり得る。このトランザクションは、関連し、おそらく重なるパケット応答時間を５つ有していることになる。Ｗｅｂを介して注文するユーザを考察する。ユーザは、課金、発送、および要求情報を入力するためにいくつかのＵＲＬをクリックする必要がある場合がある。トランザクション応答時間は、ユーザが個人情報の入力を開始したときから発注が完了したときまで（クライアントの思考時間も伴う場合がある）の経過時間となり得る。トランザクションは、目的に応じて異なる多くのやり方で定義することができる。最後の例では、トランザクションの変形（ｍｅｔａ  ｔｒａｎｓａｃｔｉｏｎ）は、クライアント入力時間を含むように定義されている。別のトランザクションの変形は、クライアントの入力時間または思考時間を差し引くように定義することができる。別のトランザクションは、発注プロセスにおいて単一の書式と定義することができる。
【００２９】
ユーザは、パケットではなくトランザクションに関して考える傾向にある。しかし、製品ネットワーク上で動作する任意のアプリケーションのトランザクションを定義し、測定することは難しい。特定のトランザクションのパターン照合フィルタを使用してトランザクション成分を識別することができる。あるプロトコルは、簡単にデコードして要求および応答のパケットを識別することができる。本発明の手法は、既知のアプリケーションの場合はパターン照合／プロトコルデコードを使用し、任意のＴＣＰ／ＩＰアプリケーションの場合は上記のパケットレベル手法を使用することから成る。本発明のトランザクション再構築方法を使用することによって定義済みのトランザクションに関するトランザクションレベルの応答時間が得られる。
【００３０】
図２および図３は、任意のＴＣＰ／ＩＰアプリケーション（後述）のパケットレベルの応答時間を計算するための異なる技術を示している。図２は、クライアント１０とサ―バ１２の間のネットワークパケットフローを示している。クライアントサイトエージェント２４などのクライアントサイトエージェントは、市販のアプリケーションでは一般的である。サーバサイトエージェント２６などのサーバサイトエージェントは、任意選択でクライアントサイトエージェントに結合され、本発明とともに使用する好ましい方法である。
【００３１】
以下は、クライアントサイトの解決策の説明である。クライアントサイト受動エージェントが「標準的な」クライアント上またはその近くにインストールされる。クライアントサイト受動エージェントは、パケットを（最低限トランスポート層、可能な場合アプリケーション層まで）デコードする、あるいはＡＲＭ  ＡＰＩを使用してアプリケーショントランザクションの開始および終了を識別する。クライアント上のエージェントを使用すると、正確な終端間応答時間統計値が計算される（図３の参照番号４２を参照）。しかし、この応答時間は、ネットワーク遅延およびサーバ遅延の両方を含んでいる。図３に示すように、近似値を使用してサーバ遅延からネットワーク遅延を分離する。
【００３２】
ネットワーク遅延の一般的な近似法では、わずかなサーバ処理を頻繁に伴うＴＣＰセッション接続時間（図３の参照番号４０）を、セッションを通じて一定したネットワーク遅延として使用する。測定されたパケット応答時間４２と一定したネットワーク遅延４０の間の差は、サーバによるものである（近似のサーバ遅延４４）。この方法は、セッションが非常に短いアプリケーション（ネットワーク遅延を再確立する頻繁なＴＣＰセッション接続）の場合はかなりうまく働くが、セッションがより長い場合は誤りが多くなるおそれがある。ネットワーク遅延の変動は、たとえ小さい時間尺度でもかなり大きくなり得る。ＦＩＦＯサービス規範を使用している単一のホップでは、ネットワーク遅延が０（キューなし）から最大ルータ／スイッチバッファとリンク速度の積までにおよぶ可能性がある。
【００３３】
別の近似技術は、ＩＣＭＰエコー（ピング）パケットを使用して、ネットワーク寄与率を推定する。しかし、ネットワーク装置は、実際のアプリケーションとは異なるように（たとえば異なる優先順位で）ＩＣＭＰを非常によく扱うことがある。ＩＣＭＰパケットサイズは、おそらく実際のアプリケーションを表してはおらず、ピンギングが提供するのは、ネットワーク待ち時間（ｎｅｔｗｏｒｋ  ｌａｔｅｎｃｙ）のサンプリングにすぎない。
【００３４】
別のクライアント側エージェントをサーバの近くに配置し、２つのエージェント間でデータを相関させることによって、統計値を向上させることができる。
以下は、サーバサイトの解決策の説明である。サーバサイト受動エージェントをサーバ上またはサーバの近くにインストールする。サーバサイト受動エージェントは一般に、パケットを（最低限トランスポート層、可能な場合アプリケーション層まで）デコードして、アプリケーショントランザクションの開始および終了を識別する。サーバ上のエージェントを使用すると、正確なサーバ遅延統計値が計算される（図３の参照番号４８）。しかし、この遅延は、ネットワーク寄与率を含んでいない。近似法を使用してネットワーク遅延を計算する。ある近似法では、サーバ応答とクライアントの肯定応答の間の時間を測定してネットワーク遅延成分５０を決定する。このサーバ−クライアント−サーバの往復時間は、実際には、クライアントの肯定応答処理を含むが、これは一般に、ＷＡＮ環境におけるネットワーク遅延に比べて無視できる。この場合、計算されたネットワーク遅延は、そのセッションを通じて可変であり、一定とはみなされないことに注意されたい。新しいネットワーク遅延は、認められたクライアント応答ごとに計算される。ネットワーク遅延を近似する他の方法は、セッション設定時間およびアプリケーションプローブパケットの使用を含む。これらは、信頼性の低いアプリケーションに有用である。図３に示すように、終端間応答時間５２は、測定されたサーバ遅延４８を近似されたネットワーク遅延５０に追加することによって近似することができる。複数のサーバ応答パケットの場合、終端間応答時間５２は、測定されたサーバ遅延（下限）４８、測定されたアプリケーション転送遅延５４、および近似されたネットワーク遅延５０を追加することによって近似することができる。
【００３５】
以下は、クライアントサイトおよびサーバサイトの解決策の比較である。要約すれば、クライアントサイト受動エージェントは、最も正確な終端間応答時間の統計値を提供するはずであるが、ネットワークとサーバの遅延成分の分離に問題がある。多くのエージェントをさまざまなクライアントサイトに配備する必要があるため、管理および維持がより困難である。クライアントサイトエージェントが提供する視野は、単一のクライアントまたはクライアントサイトに限定される。
【００３６】
サーバ側の受動エージェントは、最も正確なサーバ遅延の統計値を提供するはずであるが、ネットワーク成分を近似する必要がある。サーバサイトエージェントにおけるネットワーク遅延の統計値（分布、相関）は、クライアントサイトエージェントのものより正確となり得る。また、サーバサイトエージェントは、１つのエージェントにつき多くのクライアントという、企業全体をよりよく見ることができる「視野」を有している。また、サーバサイトエージェントは、配備および維持がかなり簡単である。
【００３７】
以下は、本発明の一例のより詳細な説明である。ビジネスプロセストランザクションは、それら自体がいくつかのパケットレベルの要求および応答から成るいくつかの小さいトランザクションで構成することができる。たとえば、ビジネスプロセストランザクションは、Ｗｅｂを介して購入注文することと定義することができる。購入注文は、項目の選択、課金および発送のための書式への記入、および注文の確認を含むいくつかのステップで構成することができる。購入注文トランザクション内の各ステップ自体は、小さいトランザクションである。サイズを問わず、各トランザクションは、少なくとも１つのポケットレベルの要求および応答から成る。
【００３８】
トランザクションは異なる多くの方法で定義することができるため、本発明は、その応答時間の計算でトランザクション分解／再構築方法を使用する。本発明は、上述のパケットレベルアルゴリズムを使用して応答時間情報を追跡する。本発明は、処理後まで定義されたトランザクションを再構築するために応答、アプリケーショングループ、サーバグループ、およびクライアントグループのサイズに従ってパケットレベル応答を追跡する。本発明は、任意のアプリケーションにはこのパケットレベル応答時間情報を提供し、このパケットレベル応答時間情報を使用して、定義されたトランザクションのトランザクション応答時間を再構築する。ＨＴＴＰなどよく知られているアプリケーションの場合は、パケットレベル応答時間に加えてＨＴＴＰトランザクション応答時間を計算する。本発明は、ＨＴＴＰトランザクションからトランザクションの変形を再構築する。
【００３９】
要約すると、パターン照合およびプロトコルデコードは、ＨＴＴＰなどよく知られているアプリケーションに使用してトランザクション成分を識別する。上記のパケットレベルアルゴリズムは、信頼性の高い、および信頼性の低い任意のアプリケーションに使用する。ネットワーク遅延成分は、信頼性の高いアプリケーションの場合はアプリケーション肯定応答、信頼性の低いアプリケーションの場合はアプリケーションプローブとともに接続設定時間に基づいて連続的な革新（ｉｎｎｏｖａｔｉｏｎ）を使用して推定される。応答時間測定値は、定義されたオブジェクト（ＵＲＬなど）および応答サイズごとに別々に計算され、より現実的なサービスレベルアグリーメント（ＳＬＡ）管理装置が可能となる。
【００４０】
以下は、本発明によるトランザクションの分解および再構築の説明である。トランザクションは、要求のシーケンスとして定義することができる。シーケンスは、結合されている、あるいは結合されていない並列および直列の要求で構成することができる。たとえば、シーケンスは、以下のシーケンスで構成することができる。
【００４１】
１．セッションＺを開く
２．Ｗｅｂページを要求し、応答を待つ
３．並列の３つのＴＣＰセッションＡ、Ｂ、Ｃを開く
４．セッションＡ：１つの要求を送信し、応答を待ち、セッションＡを閉じる
５．セッションＢ：１つの要求を送信し、応答を待ち、別の要求を送信し、応答を待ち、セッションＢを閉じる
６．セッションＣ：２つの要求をその間の応答を待つことなく連続して送信し、両方の応答を待ち、Ｃを閉じる
７．セッションＺを閉じる
このトランザクションは、次の式を使用してモデル化することができる。
ＯＰＥＮ＋Ｗ＿ＲＥＱ−Ｚ１＋ＯＰＥＮ＋ｍａｘ｛Ｗ＿ＲＥＱ−Ａ１，Ｗ＿ＲＥＱ−Ｂ１＋Ｗ＿ＲＥＱ−Ｂ２，Ｐ＿ＲＥＱ−Ｃ１Ｃ２｝
式中、ＯＰＥＮはセッション接続時間を表す確率変数、Ｗ＿ＲＥＱ−Ｚ１はＷｅｂページをダウンロードするための応答時間を表す確率変数、Ｗ＿ＲＥＱ−Ａ１はセッションＡの単一要求についての応答時間を表す確率変数、Ｗ＿ＲＥＱ−Ｂ１はセッションＢの最初の要求についての応答時間を表す確率変数、Ｗ＿ＲＥＱ−Ｂ２はセッションＢの第２の要求についての応答時間を表す確率変数、Ｐ＿ＲＥＱ−ＣｌＣ２はセッションＣの結合された要求についての応答時間を表す確率変数である。つまり、結合された要求は、クライアント要求がある単一の時点ではなく有限の時間にわたって到着する単一の要求とみなされる（Ｔ２は最後のパケットの到着を表し、到着継続時が合計応答時間に追加される）。トランザクションはすべてのセッションが完了するまで終わらないため、最大演算子は、並列する３つのセッションのそれぞれが完了するための最高時間を選択する。セッションクローズコマンドは、ユーザ体験に直接に影響を及ぼさないため、表されない。
【００４２】
本発明の解決策は、ＯＰＥＮ（セッション接続時間）確率変数の統計関数を計算する。また、Ｗ＿ＲＥＱ−Ｚ１、Ｗ＿ＲＥＱ−Ａｌ、Ｗ＿ＲＥＱ−Ｂｌ、Ｗ＿ＲＥＱ−Ｂ２の確率変数の統計関数を計算する。この場合、インスタンスは、上述したパケットレベルアルゴリズム（任意のアプリケーションの場合）およびパターン照合／プロトコルデコード（よく知られているアプリケーションの場合）に基づいている。確率変数Ｐ＿ＲＥＱ−Ｃ１Ｃ２で表される結合された要求の場合、本発明は、若干変更したアルゴリズムを使用する。これは、標準的な個々のパケットレベル（またはトランザクションレベル）の応答時間ではなく、結合されたパケットレベル（またはトランザクションレベル）の応答時間を計算する。したがって、この解決策は、結合されたＰ＿ＲＥＱ−Ｃ１Ｃ２確率変数の統計関数も計算する。確率変数の統計関数は、トランザクション式を定義してトランザクション応答時間確率変数を取得することによって計算される。
【００４３】
したがって任意の所望のトランザクションは、直列および並列の個々のまたは結合された（パケットレベルまたはトランザクションレベルの）要求および応答のシーケンスに分解される。その成分に基づいて所望のトランザクションを再構築するために数式が（パケットトレースなどから）導出される。１組の実行可能な成分は、サーバグループ、アプリケーショングループ、クライアントグループ、およびオブジェクト（任意のアプリケーションの場合の応答サイズなど）ごとに応答時間を追跡することによって識別される。応答時間は、適切なサーバグループ、アプリケーショングループ、クライアントグループ、およびオブジェクトタイプ（ＨＴＴＰの場合のＵＲＬや、知られていない任意のアプリケーションの場合の応答サイズなど）を有している場合、トランザクションの実行可能な成分に関連付けられる。次いで集合統計（ｅｎｓｅｍｂｌｅ  ｓｔａｔｉｓｔｉｃｓ）が実行可能な成分ごとに形成される。次いでトランザクションを定義する数式が集合統計に適用されてトランザクション統計を形成する。
【００４４】
本発明は、上記のアルゴリズムに従ってクライアントサイトモードまたはサーバサイトモード（または任意サイトモード）で動作するように構成可能である。クライアントサイトおよびサーバサイトの両方にインストールした場合、サーバサイトボックスは、情報を相関させて最も正確な結果を生成する。クライアントサイトモードでは、本発明は、ネットワーク遅延の良いサンプリングを取得するために、実アプリケーション接続設定時間を測定し、疑似定期的（ｐｓｅｕｄｏ−ｐｅｒｉｏｄｉｃａｌｌｙ）にアプリケーションプローブ（ＴＣＰ通信要求など）を送信する。このアクティブモードの挙動によって生成されるひずみは最低限に抑えられるはずである。クライアントサイトモードでは、本発明は、信頼性の高いアプリケーションの場合、サーバ応答とクライアント肯定応答の間の時間を使用してネットワーク遅延を近似する。上述したように、ネットワーク遅延の推定は、肯定応答が行われるときに連続的に更新することができる。本発明は、信頼性の低いアプリケーションの場合、疑似定期的に生成されたアプリケーションピング（ｐｉｎｇ）を使用してネットワーク遅延を近似する。本発明は、解決策の精度、拡張性、および管理可能性のために設計されている。
【００４５】
上記の本発明の解決策は、リアルタイムパケットレベル／トランザクションレベル応答時間計算エンジンおよび準リアルタイム処理後トランザクション再構築エンジンの２つのモジュールを含む。警報機構は、リアルタイム応答時間計算エンジンに含まれ、自動しきい値計算は、再構築エンジンで行われる。図４および図５のフロー図は、２つのエンジンの機能を示している。
【００４６】
図４は、リアルタイム応答時間計算エンジンの機能を示すフロー図である。図４のフロー図は、計算エンジンの高レベルデータフローを示す。フロー図の最初に、フィルタブロック６０は、生パケットをサーバおよびアプリケーション別にフィルタに掛ける。たとえばアプリケーションは、ＴＣＰまたはＵＤＰのポート番号によって定義することができる。サーバは、ＴＣＰまたはＵＤＰポート番号から推測する、あるいはＩＰアドレスまたはアドレス範囲によって定義することができる。カテゴリ分類ブロック６２で、フィルタに掛けられた生パケットは、サーバ、セッション、クライアントグループ、および方向によって分類される。次にブロック６４で、適切な要求および肯定応答を対にする。次に、パケットトランザクション遅延、セッション情報、および分類されたパケットがブロック６６に挿入され、ビニングリスナ（ｂｉｎｎｉｎｇ  ｌｉｓｔｎｅｒ）および他の所望のリスナがビン（ｂｉｎ）を更新する。最後に、ビンに入れられたデータがブロック６８に挿入され、ＸＭＬライタがＸＭＬファイルを生成し、データベースライタがデータベースを更新する。
【００４７】
図５は、準リアルタイムトランザクション再構築エンジンの機能を示すフロー図である。トランザクション再構築エンジンは、図５に示すデータを使用して、実行可能な成分を識別し、計算を行い、統計関数を生成する。
【００４８】
ブロック７０は、リアルタイムエンジン（上述）からの応答時間情報を表す。ブロック７２は、デフォルトのトランザクション定義を表す。デフォルトのトランザクション定義は、次の式で定義される。
【００４９】
Ｔ（ｋ）＝Ｗ＿ＲＥＱ（ｋ）
式中、ｋは応答サイズ範囲を表し、Ｔ（ｋ）は応答サイズ範囲ｋの場合のトランザクション定義、Ｗ＿ＲＥＱ（ｋ）はｋで指定される範囲のサイズを有する応答の応答時間を表す確率変数である。たとえば、ｋ＝３は１４８１バイトから１９６０バイトの間の応答サイズを指定すると仮定すると、Ｔ（３）＝Ｗ＿ＲＥＱ（３）は、１４８１バイトから１９６０バイトの間の応答サイズを有するすべての応答時間がＷ＿ＲＥＱ（３）確率変数のインスタンスであるとみなされることを示す。定義式から、Ｔ（３）の統計値は、Ｗ＿ＲＷＱ（３）のものと同じである。ブロック７４は、追加のトランザクション定義を表す。本発明は、定義されたトランザクションごとに、トランザクションがその成分からどのように構築されるかを示すトランザクションの数式でトランザクション成分（ＵＲＬや応答サイズなど）および要求タイプ（単体または結合など）の特徴付けを作成する。
【００５０】
定義されたトランザクションごとに、トランザクション再構築エンジンは、要求のタイプ（単体の要求または結合された要求）、オブジェクト（ＵＲＬや応答サイズなど）、アプリケーショングループ（Ａｍａｚｏｎ  Ｗｅｂ  Ｏｒｄｅｒなど）、サーバグループ（ＩＰアドレス範囲１９２．２３．４８．３１−１９２．２３．４８．３３など）およびクライアントグループ（ＩＰアドレス範囲１６３．１８５．０．０−１６３．１８５．２５５．２５５など）に基づいて１組の実行可能な成分を識別する。これをブロック７６に示している。デフォルトのトランザクションが、アプリケーショングループ、サーバグループ、およびクライアントグループごとにさまざまな応答サイズを備える単一のパケットレベル応答と定義される。次にブロック７８で、トランザクション再構築エンジンは、定義されたトランザクションごとの実行可能な成分の組ごとに平均値、分布関数、相関関数を計算する。また、トランザクション再構築エンジンは、トランザクションを定義する数式を使用してトランザクション統計関数を生成する。
【００５１】
要約すると、本発明は、サーバサイトのみに配置されているエージェントを使用して（ただしエージェントはアルゴリズムの軽微な変更によってクライアントおよび任意のサイトでも使用できる）任意のアプリケーションの応答時間挙動を監視するプロセスを提供する。ネットワークおよびサーバの遅延成分は、実際のアプリケーション挙動に基づいて連続的な革新を使用して個々に識別される。本発明は、応答のサイズに基づいて応答時間測定値と警報とを区別し、より知能の高い警報を可能にする。本発明は、任意のアプリケーションの場合、パケットレベルの応答時間を提供する。定義されたトランザクションでは、本発明は、トランザクションをパケットレベル情報に分解し、次いでパケットレベル応答時間からトランザクション応答時間を再構築する。以下は、本発明の特徴の一部の一覧である。
【００５２】
・サーバの近くに単一エージェントを配備することをサポートする。この場合単一エージェントを容易に管理でき、結果的にさまざまなクライアントサイトに複数のエージェントを配備する必要がなくなる
・ＨＴＴＰやＳＯＬＮＥＴ（データベースとの連動に使用されるプロトコル）など特定のアプリケーションに限定されるのと比べてどんなアプリケーションでもサポートする
・移送ヘッダが一貫性のある暗号化されたアプリケーションをサポートする（たとえばＨＴＴＰをサポート）
・単に人工の疑似定期サンプルに基づくのではなく、アプリケーションの実際の経験に基づいてアプリケーション遅延をネットワーク成分およびサーバ処理成分に分ける
・セッション確立中の単一のスナップショットだけでなく、ネットワーク遅延の推定に対する連続的な革新をサポートする
・応答のサイズに基づいて応答時間測定値と警報を区別する（１００ＭＢのダウンロードの応答時間挙動は、１００ＫＢのダウンロードのものとは別に、またそれと同時に取得することができる）
・再構築方法を使用して任意のアプリケーションの場合にトランザクションおよびパケットレベル応答時間をサポートする
・サービスレベルアグリーメント（ＳＬＡ）管理ツールだけでなくネットワーク計画およびポリシ管理のためにフロー情報を提供する。
【００５３】
上記の詳細な説明では、本発明を、特定の実施形態の例との関連で説明している。特許請求の範囲に記載した本発明の広範な意図および範囲から逸脱することなくさまざまな修正および変更をそれに加えることができる。したがって本明細書および図面は、限定的な意味ではなく、例としてみなされるものとする。
【図面の簡単な説明】
【００５４】
【図１】ネットワークを介してサーバと通信するクライアントを示す図である。
【図２】クライアントとサーバの間のネットワークパケットフローを示す図である。
【図３】任意のＴＣＰ／ＩＰアプリケーションのパケットレベルの応答時間を計算するための技術を示す図である。
【図４】リアルタイム応答時間計算エンジンの機能を示すフロー図である。
【図５】準リアルタイムトランザクション構築エンジンの機能を示すフロー図である。
【図１】
2005506605.tif 000003
【図２】
2005506605.tif 000004
【図３】
2005506605.tif 000005
【図４】
2005506605.tif 000006
【図５】
2005506605.tif 000007
【国際公開パンフレット】
2005506605.tif 000008
2005506605.tif 000009
2005506605.tif 000010
2005506605.tif 000011
2005506605.tif 000012
2005506605.tif 000013
2005506605.tif 000014
2005506605.tif 000015
2005506605.tif 000016
2005506605.tif 000017
2005506605.tif 000018
2005506605.tif 000019
2005506605.tif 000020
2005506605.tif 000021
2005506605.tif 000022
2005506605.tif 000023
2005506605.tif 000024
2005506605.tif 000025
2005506605.tif 000026
2005506605.tif 000027
2005506605.tif 000028
2005506605.tif 000029
2005506605.tif 000030
2005506605.tif 000031
2005506605.tif 000032
2005506605.tif 000033
2005506605.tif 000034
2005506605.tif 000035
2005506605.tif 000036
2005506605.tif 000037
2005506605.tif 000038
2005506605.tif 000039
2005506605.tif 000040
2005506605.tif 000041
2005506605.tif 000042
2005506605.tif 000043
【国際公開パンフレット（コレクトバージョン）】
2005506605.tif 000044
【国際調査報告】
2005506605.tif 000045
2005506605.tif 000046