JP4276895B2 - 計測システム - Google Patents
計測システム Download PDFInfo
- Publication number
- JP4276895B2 JP4276895B2 JP2003147802A JP2003147802A JP4276895B2 JP 4276895 B2 JP4276895 B2 JP 4276895B2 JP 2003147802 A JP2003147802 A JP 2003147802A JP 2003147802 A JP2003147802 A JP 2003147802A JP 4276895 B2 JP4276895 B2 JP 4276895B2
- Authority
- JP
- Japan
- Prior art keywords
- measurement
- rule
- analysis
- passive
- information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
Landscapes
- Health & Medical Sciences (AREA)
- Cardiology (AREA)
- General Health & Medical Sciences (AREA)
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、複数のコンテンツから構成されるＷｅｂページに関するトラフィックを計測する計測システムに関する。
【０００２】
【従来の技術】
ハイパーテキスト形式の分散情報システムであるＷＷＷ（World Wide Web）は、通信プロトコルとしてＨＴＴＰ（HyperText Transfer Protocal）を用いた、クライアント・サーバ型のモデルである。クライアントはＵＲＬ（Uniform Resource Locator）を特定してリクエストを送り、サーバが応答することで、サーバが提供するドキュメント（Ｗｅｂページ）にアクセスする。Ｗｅｂページの記述には、ＨＴＭＬ（HyperText Markup Language）と呼ばれる言語が一般に使用され、テキストだけでなく、画像や音声など様々な形式のデータや、別のドキュメントへのリンク情報も組み込むことができる。
【０００３】
クライアント・サーバモデルにおけるトラフィック特性の計測では、ネットワーク内に配置された計測装置によってネットワーク内に流れるデータをキャプチャして遅延時間等の計測を行なうパッシブ型の計測と、計測装置がクライアントとしてサーバに対して要求を送信し、その応答を受信することにより応答時間等の計測を行うアクティブ型の計測とがある。
【０００４】
パッシブ型のＩＰレベルでの計測については、ＩＥＴＦのＲＦＣ２７２２で計測アーキテクチャが示され、ＲＦＣ２６７９、２６８０で、２地点間の遅延時間、パケットロスの計測方法が示されている。
【０００５】
アクティブ型の計測については、特許文献１に、エージェントがトランザクションサーバにアクセスして、応答時間などを測定する方法が示され、特許文献２に、ブラウザエージェントがリクエストを送信して、リクエストの送信時刻とその応答の受信時刻の差分から応答時間を計測する方法が示されている。
【０００６】
【特許文献１】
米国特許第６４４９７３９号明細書
【特許文献２】
米国特許第６００６２６０号明細書
【０００７】
【発明が解決しようとする課題】
一般に、Ｗｅｂページは、テキストや画像等の複数の情報（コンテンツ）から構成されていることが多い。これらは、Ｗｅｂページの表示時に、コンテンツごとにリクエストを送り、表示等すべき情報を順次サーバから取得してＷｅｂページに組み込んでいく。
【０００８】
このため、応答時間、遅延時間等といったＷｅｂページに関するトラフィック特性を計測する場合には、Ｗｅｂページを構成するコンテンツ毎の応答時間、遅延時間等を取得しなければならない。
【０００９】
複数コンテンツから生成されるＷｅｂページに関するトラフィック特性の計測について、従来のアクティブ型の計測方法は、サーバにリクエストを送信し、その応答のデータ部分を解析し、コンテンツ情報を得ることができるため、各コンテンツに対してリクエストを送信し、Ｗｅｂページ全体の応答時間に関する時間を取得可能である。しかし、アクティブ型の計測方法では、例えば、ネットワークの２地点におけるパケットをキャプチャすることが必要となる遅延時間等の計測を行なうことが困難である。
【００１０】
一方、パッシブ型の計測では、２地点でパケットをキャプチャすることによりコンテンツに関する遅延時間等の計測を行なうことができる。しかし、Ｗｅｂページのコンテンツ情報を得るためには、データ部を解析しなければならないので、Ｗｅｂページに関するトラヒック特性の計測の負荷が大きくなる。
【００１１】
このため、アクティブ型の計測装置とパッシブ型の計測装置とを協働させて、Ｗｅｂページに関する計測を柔軟に行なえる計測システムの構築が望まれている。
【００１２】
ところで、クライアント側のネットワークからインターネットへの接続にあたり、セキュリティを確保したり、トラフィックを軽減する目的で、プロキシサーバを設けてアクセス制御を行なう場合がある。プロキシサーバは、一般に、Ｗｅｂドキュメントのキャッシュ機能を有しており、リクエストに対応する情報がキャッシュに存在している場合には、リクエストをインターネットに送信せずに、キャッシュに存在している情報をクライアントに送信する。また、サーバ側のネットワークでも、不正アクセスの防止などセキュリティを確保する目的で、リバースプロキシを設ける場合がある。いずれもアクセスを中継するためのサーバであり、ローカルネットワークとインターネットとを切り離すために、ＩＰアドレスの変換を行なうことができる。また、リバースプロキシでは、サーバ側のＵＲＬと外部に公開するＵＲＬとを変換する場合もある。
【００１３】
遅延時間の計測を行うためには、異なる地点において計測されたＨＴＴＰフローを同定することが必要となる。ここで、ＨＴＴＰフローは、あるＵＲＬで特定されるコンテンツのリクエストから応答までの一連のＨＴＴＰのパケット群を意味するものとする。
【００１４】
ところが、プロキシサーバ、リバースプロキシ等の中継装置が、ＩＰアドレス、あるいは、ＵＲＬの変換を行なう場合には、同一のパケットであっても、計測する場所によってパケットの送信元、宛先ＩＰアドレス、あるいは、ＵＲＬが異なる場合がある。このため、ＨＴＴＰフロー同定が困難である。
【００１５】
また、リバースプロキシで、サーバのＩＰアドレスと外部に公開するＵＲＬを変換している場合には、計測する場所によりリクエストのＵＲＬが一致しないことになる。さらに、プロキシサーバのキャッシュ機能により、リクエストがインターネットに送信されない場合もある。
【００１６】
このように、中継装置が介在すると、計測装置で取得したＨＴＴＰフローの同定が困難になる。このような場合にも柔軟に対応できる計測システムを構築することが望まれる。
【００１７】
本発明の目的は、アクティブ型の計測装置とパッシブ型の計測装置とを協働させて、柔軟な計測を行なえる計測システムを提供することにある。
【００１８】
【課題を解決するための手段】
上記課題を解決するために、本発明の第１の態様によれば、
ネットワークを流れるパケットを受信して、設定された計測ルールに基づく計測を行なう１または複数台のパッシブ型計測装置と、
設定された計測ルールに従って、コンテンツ提供サーバに対して計測用リクエストを送信し、その応答に基づいて計測対象となるコンテンツに関する情報を取得するアクティブ型計測装置と、
前記パッシブ型計測装置の計測結果のうち、前記アクティブ型計測装置が取得した情報に対応する計測結果を用いて、設定された解析ルールに基づく算出を行なうことで、コンテンツ提供に関する特性を導出する解析装置と
を備えることを特徴とする計測システムが提供される。
【００１９】
また、上記課題を解決するために、本発明の第２の態様によれば、
設定された計測ルールに従って、コンテンツ提供サーバに対して計測用リクエストを送信するアクティブ型計測装置と、
前記アクティブ型計測装置とコンテンツ提供サーバ間に設けられ、通信に関する情報を変換して中継する中継装置と、
ネットワークを流れるパケットを受信して、設定された計測ルールに基づく計測を行なう複数台のパッシブ型計測装置と、
パッシブ型計測装置の計測結果を収集し、それぞれのパッシブ計測装置で計測された関連するパケットの集合体であるフローを同定し、ネットワークのトラフィック特性を導出する解析装置とを備えた計測システムであって、
前記解析装置は、前記中継装置から通信に関する情報の変換情報を取得して、この情報に基づいてフローを同定することを特徴とする計測システムが提供される。
【００２０】
なお、第２の態様は、クライアントとコンテンツ提供サーバとの間に設けられ、通信に関する情報を変換して中継する中継装置と、
ネットワークを流れるパケットを受信して、設定された計測ルールに基づく計測を行なう複数台のパッシブ型計測装置と、
パッシブ型計測装置の計測結果を収集し、それぞれのパッシブ計測装置で計測された関連するパケットの集合体であるフローを同定し、ネットワークのトラフィック特性を導出する解析装置とを備えた計測システムであって、
前記解析装置は、前記中継装置から通信に関する情報の変換情報を取得して、この情報に基づいてフローを同定することを特徴とする計測システムとしてもよい。
【００２１】
【発明の実施の形態】
本発明の実施形態について、図面を参照して詳細に説明する。
【００２２】
図１は本発明が適用されるネットワークの構成の一例を示す図である。
【００２３】
本図において、サーバコンピュータ１０５はコンテンツを提供するＷｅｂサーバとして機能し、端末装置１０７はリクエストを送り、コンテンツの提供を享受するＷｅｂクライアントとして機能する。端末装置１０７を含むクライアント側ネットワーク１１１は、ルータ等のネットワーク装置１０６を複数備えて構成されるバックボーンネットワーク１１０に接続している。また、サーバコンピュータ１０５（以下「Ｗｅｂサーバ１０５」）を含むサーバ側ネットワーク１１２がバックボーンネットワーク１１０に接続している。このため、クライアント側ネットワーク１１１とサーバ側ネットワーク１１２との間のトラフィックは、バックボーンネットワーク１１０を介して行なわれることになる。なお、各ネットワークは有線、無線を問わない。また、サーバコンピュータ１０５は、複数台のコンピュータから構成されるサーバコンピュータ群としてもよい。本実施例において、端末装置１０７からのリクエストに対して、Ｗｅｂサーバ１０５が提供するサービスは、ＨＴＴＰによるＷｅｂページとするが、これに限られるものではない。
【００２４】
本実施例では、サービス品質としてのトラフィック特性を計測対象とする。このため、トラフィック計測を行なう計測担当者は、例えば、バックボーンネットワーク１１０を管理あるいは提供する事業者とすることができる。もちろん、本発明は、これに限られるものではない。
【００２５】
クライアント側ネットワーク１１１にはプロキシサーバ１０８が、サーバ側ネットワーク１１２にはリバースプロキシ１０９が、それぞれ備えられている。ただし、これらを備えないネットワーク構成としてもよい。まずは、簡単のため、第１実施例として、プロキシサーバ１０８およびリバースプロキシ１０９によるＩＰアドレスの変換、キャッシュ等の処理が行なわれない、あるいは、影響しない場合について説明する。
【００２６】
図１に示すように、ネットワークには、アクティブ型の計測処理を行なうアクティブメータ１０３と、パッシブ型の計測処理を行なうパッシブメータ１０４とが配置される。本図ではクライアント側ネットワーク１１１にアクティブメータ１０３とパッシブメータ１０４とが１台ずつ配置され、バックボーンネットワーク１１０にパッシブメータ１０４が１台配置されている。
【００２７】
パッシブメータ１０４の台数および配置位置は、ネットワーク構成、計測種別等に応じるが、サービス品質としてのトラフィック特性を計測対象とする本実施例では、少なくとも、バックボーンネットワーク１１０と他のネットワークとの接続箇所付近に配置することが望ましい。
【００２８】
アクティブメータ１０３とパッシブメータ１０４とは、それぞれ識別子が付されている。各メータの識別子、配置箇所、ＩＰアドレス等の情報は、計測担当者に既知であるとする。
【００２９】
アクティブメータ１０３、パッシブメータ１０４は、ソフトウェアあるいはハードウェアで実現することができる。また、ネットワーク装置１０６に組み込んだ構成とすることもできるし、独立の装置等で構成することもできる。
【００３０】
ネットワークには、さらに、計測担当者からトラフィック特性の計測に関する要求を受け付ける計測設定サーバ１０１と、アクティブメータ１０３およびパッシブメータ１０４が収集した計測結果に基づいて解析を行なう解析サーバ１０２とが接続される。これらは、１台あるいは複数台の一般的な情報処理装置、例えばサーバコンピュータを用いて構成することができる。演算処理装置、記憶装置、入出力装置等を備えた一般的な情報処理装置は、後述する各処理を行なうためのプログラムを実行することで計測設定サーバ１０１あるいは解析サーバ１０２として機能することができる。もちろん、計測設定サーバ１０１あるいは解析サーバ１０２は専用の装置を用いて構成するようにしてもよい。
【００３１】
なお、本図では計測設定サーバ１０１と解析サーバ１０２とは同一のブロードキャストドメイン内に存在するようにしているが、それぞれが別々のブロードキャストドメインに存在してもよい。また、ネットワーク上の位置も問わない。
【００３２】
計測設定サーバ１０１および解析サーバ１０２のＩＰアドレスおよびポート番号は、計測担当者に既知であるとする。また、各メータの識別子、配置箇所、ＩＰアドレス等の情報とともにネットワーク構成情報として計測設定サーバ１０１に登録しておくことが望ましい。
【００３３】
本実施例では、計測要求を受け付けた計測設定サーバ１０１が、アクティブメータ１０３、パッシブメータ１０４、解析サーバ１０２に対して処理の内容を定めたルールを送信する。そして、アクティブメータ１０３は、対象となるＷｅｂページの構成情報を取得し、パッシブメータ１０４は、ネットワークに流れるデータをキャプチャして必要なパケットを抽出する。解析サーバ１０２は、アクティブメータが取得したＷｅｂページ構造と、パッシブメータ１０４が抽出したパケットとを対応付けたうえで、トラフィック特性の算出を行なう。
【００３４】
図２は計測設定サーバ１０１の機能構成を示すブロック図である。計測設定サーバ１０１は、計測要求受付部２０１にて、計測担当者からの計測要求を受け付ける。
【００３５】
計測要求は、例えば、以下のような項目を含むものとする。
【００３６】
【表１】
ここで、「計測種別」は、例えば、遅延時間、パケットロス、応答時間、可用性等とすることができる。遅延時間およびパケットロスは、ネットワーク上のある地点からある地点、例えば、バックボーンネットワーク１１０のサーバ側ネットワーク１１２との接続箇所付近からクライアント側ネットワーク１１１との接続箇所付近までの間におけるパケット転送遅延時間およびパケットロスであるので、パッシブメータ１０６を少なくとも２台用いる計測種別である。また、応答時間は、例えば、あるＷｅｂページに対するリクエスト開始時間からそのＷｅｂページ全体が表示されるまでの時間であり、可用性は、例えば、あるＷｅｂページのサービスをどの程度の割合で正常利用できるかを計測するものであるため、パッシブメータ１０６は１台で足りる計測種別である。なお、いずれの計測種別においても、本実施例ではＷｅｂサーバ１０５にリクエストを送り、計測に用いるＷｅｂページに含まれるＵＲＬのリストを取得するためのアクティブメータ１０３を１台用いるものとする。
【００３７】
対象ＷｅｂページのＵＲＬは、計測に用いるＷｅｂサーバ１０５が提供するＷｅｂページのＵＲＬである。
【００３８】
計測に使用するメータの識別子は、少なくとも１台のアクティブメータ１０３の識別子と、計測種別に応じた１台または複数台のパッシブメータ１０４の識別子とする。どのメータを用いるかは、例えば、計測担当者がネットワーク構成に基づいて判断するものとする。
【００３９】
開始時刻、終了時刻は、計測の開始時間と終了時間である。
【００４０】
レポート間隔は、計測結果収集方法がプッシュ型の場合にはパッシブメータ１０４の計測結果の送信間隔であり、計測結果収集法がプル型の場合には解析サーバ１０２が収集要求を送信して計測結果を収集する間隔である。ここで、プッシュ型は、パッシブメータ１０４が定期的に結果を送信する方法で、プル型は解析サーバ１０２の要求に応答してパッシブメータ１０４が計測結果を送信する方法である。
【００４１】
なお、これらの項目は計測担当者がすべて設定するようにしてもよいし、計測担当者が計測の概要を設定し、あらかじめ定めた規則により計測設定サーバ１０１が具体的な内容を決定するようにしてもよい。
【００４２】
図２において、計測設定サーバ１０１のルール生成部２０２は、計測要求受付部２０１が受け付けた計測要求に基づいて、アクティブメータ１０３、パッシブメータ１０４および解析サーバ１０２が行なうべき処理を定めたルールを作成する。
【００４３】
具体的には、以下のような処理を行なう。
【００４４】
まず、受け付けた計測要求に、要求識別子を一意に割り当てる。また、計測に用いるアクティブメータ１０３、パッシブメータ１０４が行なうべき処理（「計測タスク」と称する）、および、解析サーバ１０２が行なうべき処理（「解析タスク」と称する）を決定し、ルール（それぞれ「計測ルール」「解析ルール」と称する）を作成して、それぞれに一意にタスク識別子を割り当てる。
【００４５】
計測要求で指定されたアクティブメータ１０３に対する計測ルールには、要求識別子、タスク識別子、対象ＷｅｂページのＵＲＬ、開始時刻、解析サーバ１０２のアドレスとポート番号とを含める。なお、本実施例では、アクティブメータ１０３が行なう処理は、対象ＷｅｂページのＵＲＬにリクエストを送り、そのＷｅｂページのＵＲＬ構造を取得するものであるから、開始時刻は、即時とすることができる。
【００４６】
計測要求で指定されたパッシブメータ１０４に対する計測ルールには、タスク識別子、フィルタリング条件、計測種別（遅延、応答時間、可用性等）、開始時刻、終了時刻、さらに収集方法がプッシュ型の場合は解析サーバアドレスとポート番号、レポート間隔を含める。
【００４７】
フィルタリング条件は、キャプチャしたパケットを選別するための条件を指定するもので、例えば、プロトコルタイプとしてＨＴＴＰ、送信元であるアクティブメータ１０３のＩＰアドレス、宛先であるＷｅｂサーバ１０５のＩＰアドレス等とすることができる。ＨＴＴＰトラフィックの計測に関しては、例えば、フィルタリング条件のプロトコルタイプにＨＴＴＰを指定し、その他を指定しない場合は、ＨＴＴＰに関する全トラフィックを計測することになる。
【００４８】
解析サーバ１０２に対する解析ルールには、要求識別子、対象ＷｅｂページのＵＲＬ、計測種別、開始時刻、終了時刻、収集方法がプル型の場合はレポート間隔、さらに、アクティブメータ１０３の識別子とアドレスとポート番号およびアクティブメータ１０３に対するタスク識別子、パッシブメータ１０４の識別子とアドレスとポート番号およびパッシブメータ１０４に対するタスク識別子を含める。
【００４９】
計測設定サーバ１０１のルール生成部２０２は、生成した計測ルールおよび解析ルールをルールデータベース２０４に登録するとともに、ルール設定部２０３に通知する。
【００５０】
ルール設定部２０３は、ルール生成部２０２から通知された計測ルールおよび解析ルールを、対応するアクティブメータ１０３、パッシブメータ１０４、解析サーバ１０２に通知する。
【００５１】
なお、計測設定サーバ１０１は、計測要求以外のデータを受信するためのデータ受信部２０５を備えている。また、計測設定サーバ１０１は、ユーザから計測開始の要求だけでなく、計測の中止、変更要求等も受け付ける。これらについては説明を省略する。
【００５２】
図３はアクティブメータ１０３の機能構成を示すブロック図である。本図において、ルール受付部３０１は、計測設定サーバ１０１から送られた計測ルールを受信する。受信した計測ルールは、ルールテーブル３０５に登録し、タスク実行部３０２に通知する。タスク実行部３０２は計測ルールに含まれる対象ＷｅｂページのＵＲＬに対して計測用リクエストを送信し、Ｗｅｂサーバ１０５からの応答を受信する。
【００５３】
受信した応答のメッセージボディ部（ＨＴＭＬファイル）は、分析部３０３に送られる。分析部３０３では、ＨＴＭＬファイルから、対象Ｗｅｂページに含まれるコンテンツの情報（例えば、所定のタグ情報）を抽出して、Ｗｅｂページを構成するＵＲＬのリストを作成する。作成したＵＲＬリストには、タスク識別子を付して管理する。このとき、対象Ｗｅｂページにスクリプトファイルが含まれており、スクリプト内であるＵＲＬにリクエストを送信する場合には、タスク実行部３０１にそのＵＲＬに対するリクエストを依頼し、その応答について、同様の処理を行う。同一のＵＲＬに対して複数回リクエストを送信する場合は、複数回分を、結果のリストに記録する。
【００５４】
作成したＵＲＬリストは、データ送信部３０４が、計測ルールで指定された解析サーバ１０２に計測結果として送信する。
【００５５】
図４はパッシブメータ１０４の機能構成を示すブロック図である。ルール受付部４０１は、計測設定サーバ１０１から送られた計測ルールを受信する。受信した計測ルールは、ルールテーブル４０６に登録する。
【００５６】
計測ルールにしたがって、開始時刻から終了時刻までの間、キャプチャ部４０２は、ネットワークからパケットを取り込み、タイムスタンプを押す。
【００５７】
フィルタリング部４０３は、キャプチャしたパケットのうち、フィルタリング条件に合致するパケットを選別する。
【００５８】
データ編集部４０４で、必要に応じて選別されたパケットを加工し、加工した結果等を記憶装置上にＨＴＴＰフロー情報として、タスク識別子を付して保存する。加工としては、例えば、レスポンスパケットが複数ある場合に、最初および最終レスポンスの時間を取得することがある。また、レスポンスの状態から応答状態（正常またはエラー）を判断したり、コンテンツサイズを取得すること等がある。
【００５９】
データ送信部４０５は、プッシュ型が指定されている場合にはレポート間隔で定められる時間毎に、プル型が指定されている場合には解析サーバ１０２から要求があった時点で、保存している計測結果を解析サーバ１０２に計測結果として送信する。
【００６０】
なお、パッシブメータ１０４は各種プロトコルに対応し、例えば、トランスポート層のＴＣＰ、ＵＤＰ、上位層のＤＮＳやＨＴＴＰの計測が可能である。
【００６１】
図５は解析サーバ１０２の機能構成を示すブロック図である。解析ルール受付部５０１は、計測設定サーバ１０１から送られた解析ルールを受信してルールデータベース５０４に登録する。計測データ収集部５０２は、計測に用いられたアクティブメータ１０３およびパッシブメータ１０４から送られた計測結果を受信して、計測結果データベース５０５に登録する。解析部５０３は、解析ルールにしたがって、受信した計測結果であるＵＲＬリストおよび計測データを用いて遅延時間等の計測種別に応じた算出処理を行なう。
【００６２】
図６にルールデータベース５０４のデータ構成の一例を示す。ルールデータベース５０４は、計測要求に基づく情報として、要求識別子６０１、対象ＷｅｂページのＵＲＬ６０２、計測種別６０３、開始時刻６０４と終了時刻６０５、レポート間隔６０６、状態６０７を管理する。状態６０７は、その計測要求に基づく処理の状態を示すもので、例えば、初期状態（ＩＮＩＴＩＡＬ）、解析処理実行中（ＡＣＴＩＶＥ）、解析処理を正常終了した状態（ＤＯＮＥ）、異常終了した状態（ＥＲＲＯＲ）のいずれかの値をとるものとする。
【００６３】
また、ルールデータベース５０４は、計測要求に対応したメータが実行する計測ルールの情報を関連付けて、計測タスク情報として管理する。
【００６４】
計測タスク情報は、計測タスク識別子６０８、パッシブメータ１０４の識別子６０９とそのＩＰアドレスおよびポート番号６１０、その計測要求についてのアクティブメータ１０３の計測結果であるＵＲＬリストの識別子６１１、計測タスクの状態を示すタスク状態６１２から構成される。複数のパッシブメータ１０４を使用する計測種別の場合は、計測タスク情報はパッシブメータ１０４毎に上述の計測要求に基づく情報と関連付けて管理する。
【００６５】
計測要求に基づく情報、および、計測タスク情報の計測タスク識別子６０８、パッシブメータ１０４に関する情報６０９、６１０は、解析ルール受付部５０１が解析ルールの受付時に設定する。タスク状態６１２には、例えば、計測タスク実行前の初期状態（ＩＮＩＴＩＡＬ）、タスク実行中（ＡＣＴＩＶＥ）、タスクを正常終了した状態（ＤＯＮＥ）、タスクを異常終了した状態（ＥＲＲＯＲ）のいずれかを、状態に合わせて設定する。ＵＲＬリスト識別子６１１は、アクティブメータ１０３からの計測結果であるＵＲＬリストの受信後に計測データ受信部５０２が任意に設定する。
【００６６】
図７に計測結果データベース５０５のデータ構成の一例を示す。計測結果データベース５０５は、計測要求に基づく測定結果を識別するためのＵＲＬリスト識別子７０１、ＵＲＬリストに含まれるＵＲＬを登録するＵＲＬ７０２、リクエスト送信元であるクライアントのＩＰアドレス７０３とポート番号７０４、リクエストの宛先であるサーバのＩＰアドレス７０５とポート番号７０６、応答状態７０７、計測時間情報としてリクエスト送信時刻７０８、最初のレスポンス受信時刻７０９、最終レスポンス受信時刻７１０、サイズ７１１から構成される。ＵＲＬリスト識別子７０１は、ルールデータベース５０４に登録するＵＲＬリスト識別子６１１と対応し、解析ルールに対して計測結果を関連付けるものである。
【００６７】
解析サーバ１０２は、解析ルール受付部５０１で、計測設定サーバ１０１からの解析ルールを受信し、ルールデータベース５０４に登録する。ここでの状態６０７、および、各計測タスクのタスク状態６１２は「初期状態」とする。
【００６８】
開始時刻になった時点で、解析サーバ１０２は、計測データ収集部５０２で計測結果の受信を開始し、状態６０７を「実行中」にする。また、パッシブメータ１０４からの計測結果を受信した時点で、対応する計測タスク情報のタスク状態６１２を「タスク実行中」にする。
【００６９】
つぎに、解析サーバ１０２の計測データ収集部５０２における処理を図８に示したフロー図を参照して説明する。
【００７０】
ステップＳ８０１で、計測データ収集部５０２が計測結果を受信すると、その計測結果がアクティブメータ１０３から送られたものか、パッシブメータ１０４から送られたものかを判断する（Ｓ８０２）。
【００７１】
計測結果がアクティブメータ１０３から送られてきた場合には、計測結果であるＵＲＬリストに識別子を付すとともに、計測結果データベース５０５に新たなレコードを登録する（Ｓ８０３）。新たなレコードは、ルールデータベース５０４を参照して、計測タスク情報の個数分、すなわち、計測に用いるパッシブメータ１０４の数に対応して登録する。なお、上記のＵＲＬリスト識別子も、計測タスク情報の個数に対応して、計測に用いるパッシブメータ１０４それぞれについて一意的に付すものとする。
【００７２】
新たなレコードのＵＲＬリスト識別子７０１には、付されたＵＲＬ識別子を登録し、ＵＲＬ７０２には、ＵＬＲリストに含まれるＵＲＬを登録する。なお、ＵＲＬ識別子は、ルールデータベース５０４の対応する計測タスク情報のＵＲＬリスト識別子６１１にも登録する。ここで、計測結果データベース５０５のＵＲＬ７０２には、ＷｅｂページのＵＲＬおよびそのＷｅｂページを構成するコンテンツのＵＲＬをすべて登録する。したがって、例えば、ＨＴＭＬファイルｉｎｄｅｘ.ｈｔｍｌで特定されるＷｅｂページが、イメージデータｉｍａｇｅ.ｇｉｆを含んで構成される場合には、計測結果データベース５０５において、一つのＵＲＬリスト識別子７０１に対して、２つのＵＲＬ７０２を登録することになる。
【００７３】
一方、計測結果がパッシブメータ１０４から送られてきた場合には、受信した計測結果に含まれるタスク識別子とから、ルールデータベース５０４を参照し、ＵＲＬリスト識別子６１１が登録済であるか、すなわち、計測結果データベース５０５に計測結果を格納するためのレコードが登録されているかを確認する（Ｓ８０４）。
【００７４】
ＵＲＬリスト識別子６１１が登録されていない場合は、一時的に記憶装置に保存しておき（Ｓ８０９）、その後、計測結果を受信した時点で再度検索する。これは、同じ計測要求に係る計測結果について、パッシブメータ１０４からの計測結果の方を早く受信した場合を考慮するためである。
【００７５】
ＵＲＬリスト識別子６１１が登録されている場合は、対応する計測結果データベース５０５に登録されたＵＲＬ７０２に、受信した計測結果に含まれるＵＲＬ情報と一致するものがあるかどうかを判断する（Ｓ８０５）。
【００７６】
その結果、一致するＵＲＬ７０２がない場合には、計測結果を廃棄する（Ｓ８１０）。
【００７７】
一方、一致するＵＲＬ７０２がある場合には、受信した計測結果に含まれる送信元ＩＰアドレス、宛先ＩＰアドレス等のアドレス情報およびリクエスト送信時刻、コンテンツサイズ等のＨＴＴＰフロー情報を、計測結果データベース５０５の、一致したＵＲＬ７０２に対応するアドレス情報（７０３、７０４、７０５、７０６）、応答状態（７０７）、各時刻情報（７０８、７０９、７１０）、サイズ（７１１）にそれぞれ登録する（Ｓ８０６）。
【００７８】
結果を登録後、ＵＲＬ７０２に登録されている全ＵＲＬについての計測結果をパッシブメータ１０４から収集したかどうかを判断する（Ｓ８０７）。全ＵＲＬについて結果を収集している場合は計測タスク終了とみなし、ルールデータベース５０４のタスク状態６１２を正常終了として、計測タスクの終了を解析部５０３に通知する（Ｓ８０８）。収集していないＵＲＬがある場合には、引き続き計測結果の受信を待つ。なお、一定時間経過後も全ＵＲＬについての結果を収集できない場合は、タスク状態６１２を異常終了とし、計測タスクの終了を解析部５０３に通知する。
【００７９】
解析部５０３は、要求識別子に対する各計測タスクの終了通知の受信後、または終了時刻から一定時間経過後に、計測タスクの状態を見て、正常終了しているかを確認する。正常終了している場合、ルールの状態６０７を正常終了状態とする。そして、ルールデータベース５０４の計測種別６０３に基づいて、計測結果を解析する。解析結果は、例えば、解析サーバ１０２の解析結果を利用する上位アプリケーション等に送信する。
【００８０】
解析部５０３の解析処理としては、例えば、計測種別が応答時間（ＬＡＴＥＮＣＹ）である場合、ＨＴＴＰに関しては、リクエスト送信時刻と最初のレスポンスパケット受信時刻との差分（サーバのＬＡＴＥＮＣＹ）、最初のレスポンスパケット受信時刻と最終レスポンス受信時刻との差分（ダウンロード時間）とそれらを加算したＨＴＴＰ全体の時間を算出する。さらに、パッシブメータ１０４からＨＴＴＰに関連するＤＮＳやＴＣＰコネクションの確立時間の計測結果を得て、ＨＴＴＰの時刻情報と合わせて、対象ＵＲＬに対する全ＬＡＴＡＮＣＹを算出するようにしてもよい。
【００８１】
また、Ｗｅｂページ全体のＬＡＴＥＮＣＹについては、最初のＤＮＳの開始時刻と、全ＵＲＬのうち最後のレスポンスパケット受信時刻との差分、または、ページを構成する全ＵＲＬのＬＡＮＴＥＮＣＹを加算することにより算出することができる。
【００８２】
応答状態７０７がエラーで、計測種別に示された処理を行えない場合、または異常終了のタスクがある場合はルールデータベース５０４の状態６０７を「異常終了」として、解析部５０３における解析処理は行わず、上位アプリケーション等に対して、エラーを通知する。
【００８３】
図９にシステム全体のシーケンス図を示す。まず、計測設定サーバ１０１が計測要求に基づくルールを生成して、解析サーバ１０２に解析ルールを、アクティブメータ１０３とパッシブメータ１０４とに計測ルールを送信する（Ｓ９０１）。
【００８４】
アクティブメータ１０３は、計測ルールにしたがって、計測用リクエストをＷｅｂサーバ１０５に送信し、応答に基づいてＵＲＬリストを作成して解析サーバ１０２に送信する（Ｓ９０２）。
【００８５】
パッシブメータ１０４は、計測ルールにしたがって計測を行い、計測結果を解析サーバ１０２に送信する（Ｓ９０３）。
【００８６】
解析サーバ１０２では、アクティブメータ１０３の計測結果であるＵＲＬリストに、パッシブメータ１０４の計測結果を対応付けて計測結果データベース５０５に登録し、解析ルールで示された計測種別に応じた解析を行なう（Ｓ９０４）。
【００８７】
以上により、アクティブ型の計測装置とパッシブ型の計測装置とを協働させて、Ｗｅｂページの構成を考慮した柔軟な計測を行なえる計測システムを構築することができる。
【００８８】
次に上記実施例の第１の変形例について説明する。図１０は、第１の変形例におけるシステム全体のシーケンスを示す図である。
【００８９】
図９との違いは以下の通りである。すなわち、計測設定サーバ１０１はアクティブメータ１０３にのみ計測ルールを送信する（Ｓ１００１）。アクティブメータ１０３は計測用リクエストをＷｅｂサーバ１０５送信し、応答を受信してＷｅｂページの分析を行なう（Ｓ１００２）。その分析結果を基に、パッシブメータ１０４が使用する計測ルールを作成してパッシブメータ１０４に通知し、解析サーバ１０２が使用する解析ルールを生成してを解析サーバ１０２に通知する（Ｓ１００３）。なお、各サーバおよび各メータの機能構成はそれぞれ前述の実施例と同様とすることができる。
【００９０】
第１の変形例における処理の流れについて説明する。
【００９１】
計測設定サーバ１０１は、計測担当者からの計測要求を受け付けた後、パッシブメータ１０４、解析サーバ１０２に対しては送信を行わず、アクティブメータ１０３に対してのみ計測ルールを送信する。
【００９２】
この場合の計測ルールには、要求識別子、タスク識別子、対象ＷｅｂページのＵＲＬ、開始時刻、解析サーバ１０２のアドレスとポート番号に加えて、使用するパッシブメータ１０４の識別子とアドレスとポート番号、および、上記の例でパッシブメータ１０４に対する計測ルールに含めていた項目、すなわち、計測種別、レポート時間、パッシブメータ１０４で使用するフィルタリング条件等と、メータや解析サーバ毎のタスク識別子を含めるようにする。
【００９３】
アクティブメータ１０３は、ルール受付部３０１で、計測設定サーバ１０１から送られた計測ルールを受信する。受信した計測ルールは、ルールテーブル３０５に登録し、タスク実行部３０２に通知する。タスク実行部３０２は計測ルールに含まれる対象ＷｅｂページのＵＲＬに対して計測用リクエストを送信し、Ｗｅｂサーバ１０５からの応答を受信する。
【００９４】
受信した応答のメッセージボディ部（ＨＴＭＬファイル）は、分析部３０３に送られる。分析部３０３では、ＨＴＭＬファイルから、対象Ｗｅｂページに含まれるコンテンツの情報を抽出して、リスト（ＵＲＬリスト）を作成する。作成したＵＲＬリストには、タスク識別子を付して、データ送信部３０４が、パッシブメータ１０４に送信する。ここで、データ送信部３０４は、ルールテーブル３０５を参照して、計測ルール、解析ルールをそれぞれパッシブメータ１０４、解析サーバ１０２に送信する。
【００９５】
パッシブメータ１０４へ送る計測ルールの内容は、第１の実施例の内容に、作成したＵＲＬリストに含まれる全ＵＲＬをフィルタリング条件として追加したものとなる。
【００９６】
また解析サーバ１０２へ送る解析ルールの内容は、計測設定サーバ１０１から受信した計測ルールに基づくもので、上述の実施例と同様とすることができる。
【００９７】
パッシブメータ１０４は、ルール受付部４０１でアクティブメータ１０３から送信された計測ルールを受信する。本実施例では、フィルタリング条件として、送信元のＩＰアドレスおよび宛先のＩＰアドレスに加え、ＵＲＬが指定されている。フィルタリング部４０３では、このフィルタリング条件に従ったフィルタリングを行い、計測結果を解析サーバ１０２に送信する。
【００９８】
解析サーバ１０２は、計測データ収集部５０２がパッシブメータ１０４からの計測データの収集を開始すると、計測タスク情報ごとに計測結果データベース５０５を割り当て、ＵＲＬリスト識別子７０１を設定するとともに、ＵＲＬ７０２に対応する計測結果を計測結果データベース５０５に登録する。
【００９９】
なお、アクティブメータ１０３は計測結果をパッシブメータ１０４にフィルタリング条件として通知するとともに、前述の実施例と同様に、解析サーバ１０２に対してＵＲＬリストを送信してもよい。この場合、解析サーバ１０２は、アクティブメータ１０３からのＵＲＬリスト受信時に計測結果データベース５０５を計測タスクごとに割り当て、ＵＲＬリストの情報を登録しておき、パッシブメータ１０４からの計測結果を対応する計測結果データベース５０５に登録する。
【０１００】
このように、第１の変形例によれば、上記第１の実施例の効果に加え、パッシブメータ１０４では、対象となるＵＲＬを絞ってフィルタリングすることができるため、計測結果のデータ量が削減され、ネットワークの負荷が軽減するとともに、解析サーバ１０２における解析処理の負荷も軽減することができる。
【０１０１】
つぎに、上記実施例の第２の変形例について説明する。
【０１０２】
図１１は別の変形例におけるシステム全体のシーケンスを示す図である。図９との違いは、以下の通りである。すなわち、計測設定サーバ１０１は、アクティブメータ１０３にのみ計測ルールを送信する（Ｓ１１０１）。アクティブメータ１０３は、計測タスクを実行した結果であるＵＲＬリストを、計測設定サーバ１０１に送信する（Ｓ１１０２）。その後、計測設定サーバ１０１が、ＵＲＬリストの情報を含めた計測ルールおよび解析ルールを生成し、パッシブメータ１０４、解析サーバ１０２に対して送信する（Ｓ１１０３）。
【０１０３】
第２の変形例における処理の流れについて説明する。
【０１０４】
計測設定サーバ１０１は計測担当者からの計測要求受付後に、まず、アクティブメータ１０３に対して計測ルールを送信する。
【０１０５】
アクティブメータ１０３は、計測設定サーバ１０１から受け付けた計測ルールをルールテーブル３０５に登録し、計測ルールにしたがって、計測用リクエストを送信し、応答を受信する。分析部３０３においてＵＲＬリストを作成し、データ送信部３０４が計測設定サーバ１０１に結果結果として送信する。
【０１０６】
計測設定サーバ１０１は、データ受信部２０５でアクティブメータ１０３から計測結果を受信し、ルール生成部２０２に通知する。ルール生成部２０２は、計測担当者からの計測要求に基づいて、パッシブメータ１０４と解析サーバ１０２とが行なうべき処理を定めたルールを作成する。その際、第１の変形例と同様に、パッシブメータ１０４に対するルールに含まれるフィルタリング条件については、作成したＵＲＬリストに含まれる全ＵＲＬを追加したものとなる。解析サーバ１０２に対するルールは、第１の実施例と同様である。
【０１０７】
ルール設定部２０３は、それぞれのルールを、計測ルール、解析ルールとして、パッシブメータ１０４および解析サーバ１０２に送信する。
通知の内容は、解析サーバに対しては、実施例１と同様であり、パッシブメータに対しては、実施例１の内容に、結果の全ＵＲＬをフィルタリング条件として追加したものとなる。
【０１０８】
パッシブメータ１０４は、第１の変形例と同様に、ルール受付部４０１で計測設定サーバ１０１から送信された計測ルールを受信する。ＵＲＬが指定されたフィルタリング条件に従って、フィルタリング部４０３でパケットのフィルタリングを行い、計測結果を解析サーバに送信する。
【０１０９】
解析サーバ１０２は、計測データ収集部５０２がパッシブメータ１０４からの計測データの収集を開始すると、計測タスク情報ごとに計測結果データベース５０５を割り当て、ＵＲＬリスト識別子７０１を設定するとともに、ＵＲＬ７０２に対応する計測結果を計測結果データベース５０５に登録する。
【０１１０】
なお、アクティブメータ１０３は計測結果をパッシブメータ１０４にフィルタリング条件として通知するとともに、前述の実施例と同様に、解析サーバ１０２に対してＵＲＬリストを送信してもよい。この場合、解析サーバ１０２は、アクティブメータ１０３からのＵＲＬリスト受信時に計測結果データベース５０５を計測タスクごとに割り当て、ＵＲＬリストの情報を登録しておき、パッシブメータ１０４からの計測結果を対応する計測結果データベース５０５に登録する。
【０１１１】
このように、第２の変形例によれば、上記第１の実施例の効果に加え、パッシブメータ１０４では、対象となるＵＲＬを絞ってフィルタリングすることができるため、計測結果のデータ量が削減され、ネットワークの負荷が軽減するとともに、解析サーバ１０２における解析処理の負荷も軽減することができる。
【０１１２】
つぎに、上記実施例の第３の変形例として、ＨＴＴＰのヘッダ部に含まれる情報を利用する場合について説明する。これは、ＨＴＴＰのリクエストのＲｅｆｅｒｅｒ属性を利用するもので、この属性には該ＵＲＬを呼び出しているＵＲＬの情報が、Ｗｅｂクライアントによって設定される。例えば、Ｗｅｂページの中で要求されるコンテンツのリクエストには、ページＵＲＬがこのＲｅｆｅｒｅｒ属性に設定されるというものである。この情報は全てのクライアントが必ず設定する必要はなく、計測対象とするクライアントによっては設定されていない場合もある。ここでは、設定されているものとして説明する。
【０１１３】
パッシブメータ１０４は、データ編集部４０４において計測結果を登録する時点で、リクエスト受信時のみリクエストのヘッダ部に含まれるＲｅｆｅｒｅｒ属性の情報を記録する。
【０１１４】
解析サーバ１０２では、計測データ収集部５０２において、アクティブメータ１０３からの結果を収集していない場合に、パッシブメータ１０４からの計測結果を受信すると、計測結果にＲｅｆｅｒ属性が含まれていれば、計測タスク識別子とそのＲｅｆｅｒｅｒ属性情報とがページＵＲＬと一致するかを判断し、一致する場合は、その計測タスク識別子に対応する計測結果データベース５０５のＵＲＬ７０２に追加し、計測結果を登録する。
【０１１５】
Ｗｅｂページを構成する全コンテンツの結果を収集したかどうかについては、その計測タスクについてパッシブメータ１０４からの計測結果が一定時間なかった場合に全結果を収集したとみなして、計測タスクを終了とする。終了した計測タスクについて解析部５０３に通知し、解析部５０３が計測結果を解析する。
【０１１６】
以上により、Ｒｅｆｅｒｅｒ属性を利用して、ＷｅｂページとＷｅｂページを構成するコンテンツとについての計測が可能となる。
【０１１７】
次に本発明の第２の実施例について説明する。本実施例では、２箇所以上に設置したパッシブメータでプロキシサーバ１０８等のゲートウェイを介したトラフィックにおける遅延時間を計測する場合について説明する。
【０１１８】
本実施例におけるネットワーク構成は、図１に示した構成と同様とする。ただし、クライアント側ネットワーク１１１のパッシブメータ１０４は、プロキシサーバ１０８よりもアクティブメータ１０３またはＷｅｂブラウザ等のＷｅｂクライアント側に配置されており、別パッシブメータ１０４は、バックボーンネットワーク１１０またはリバースプロキシ１０９よりもＷｅｂサーバ１０５側のサーバ側ネットワーク１１２に配置されているものとする。本実施例は、特に、クライアント側ネットワーク１１１に接続されたプロキシサーバ１０８、および、サーバ側ネットワーク１１２に接続されたリバースプロキシ１０９の処理を考慮した場合である。
【０１１９】
プロキシサーバ１０８は、アクティブメータやＷｅｂブラウザ等のクライアントからのリクエストを受信時、キャッシュにデータがあるかどうかを判断して、キャッシュにない場合は、バックボーンネットワーク１１０を介して、リバースプロキシ１０９にリクエストを転送する。
【０１２０】
まず、プロキシサーバ１０８は、リクエストをクライアントから受信した順序で転送し、また、リバースプロキシ１０９は、ＵＲＬを変換しない場合について、第１の実施例との相違点を中心に説明する。
【０１２１】
第１の実施例と同様に、計測設定サーバ１０１がパッシブメータ１０４に対して計測ルールを設定する。また、解析サーバ１０２に対しては、第１の実施例における解析ルールの内容に追加して、ネットワークを構成する中継装置（ここではプロキシサーバ１０６、リバースプロキシ１０９とする）のＩＰアドレス、ポート番号を含めて通知する。なお、中継装置のＩＰアドレス、ポート番号は既知であり、例えば、計測設定サーバ１０１があらかじめ保持しているものとする。
【０１２２】
パッシブメータ１０４は、各ＵＲＬへのリクエストとその応答について計測し、結果を解析サーバ１０２に送信する。
【０１２３】
解析サーバ１０２では、受信した解析ルールに、中継装置のＩＰアドレス等の情報が含まれている場合には、それらの情報もルールデータベース５０４に登録しておく。解析部５０３では、計測結果データベース５０６に記録された結果にもとづいて、本実施例の計測種別である遅延時間の算出を行う。
【０１２４】
遅延時間の算出では、まず、ルールデータベース５０４に登録された計測タスク識別子６０８からＵＲＬリスト識別子６１１を抽出する。そして、抽出したＵＲＬリスト識別子をキーにして、計測結果データベース５０５から対応するＨＴＴＰフロー情報を抽出する。これは、計測に用いた複数台のパッシブメータ１０４の計測結果である。解析部５０３は、ＵＲＬ毎に、各パッシブメータ１０４が計測したＨＴＴＰフローの情報を比較して、ＨＴＴＰフローの同定を行い、その時刻差から遅延時間を算出する。
【０１２５】
ここで、クライアント側ネットワーク１１１に配置されたパッシブメータ１０４からの計測結果では、プロキシサーバ１０８を経由するため（上述のように、本実施例では、クライアント側ネットワーク１１１のパッシブメータ１０４は、プロキシサーバ１０８よりもアクティブメータやＷｅｂブラウザ等のクライアント側に配置されている）、送信元は、クライアントのＩＰアドレスとポート番号、宛先がプロキシサーバ１０８のＩＰアドレス、ポート番号となっている。また、バックボーンネットワーク１１０に配置されたパッシブメータ１０４からの計測結果では、送信元がプロキシサーバ１０８のＩＰアドレス、ポート番号、宛先がサーバのＩＰアドレスとポート番号になっているので、同一のＨＴＴＰフローであっても両者は一致しない。
【０１２６】
そこで解析サーバ１０２では、ＨＴＴＰフローの同定には、ＵＲＬと時刻とを比較条件とする。解析部５０３では各パッシブメータ１０４から受信した計測結果のデータのＵＲＬ７０２を比較して同一のものを抽出する。同一のエントリが他にない場合は、同じＨＴＴＰフローと判断する。ＵＲＬ７０２が同一のエントリが複数ある場合には、リクエスト送信時刻７０８を参照して、各パッシブメータ１０４における送信されたリクエストの順番を判断し、同一のＨＴＴＰフローを識別する。
【０１２７】
同一のＨＴＴＰフローと判断したものについては、計測結果のリクエスト送信時刻７０８、または、最初のレスポンスパケットの受信時刻７０９、または、最後のレスポンスパケット７１０の受信時刻から差分を算出し、遅延時間とする。
【０１２８】
つぎに、中継装置によるリクエスト送信順の変更がある場合について説明する。この場合は、解析サーバ１０２が、プロキシサーバ１０８から中継についての情報を取得するようにする。
【０１２９】
プロキシサーバ１０８は、アクティブサーバ１０３やＷｅｂブラウザ等からリクエストを受信した際には、このリクエストの中継情報を記録し、定期的に解析サーバ１０２に送信するようにする。解析サーバ１０２は、パッシブメータ１０４等からの計測結果と同様に、計測データ収集部５０２で中継情報を受信して、計測結果データベース５０５に記録する。
【０１３０】
図１２は、計測結果データベース５０５が記録する中継情報のデータ構成の一例である。本図に示すように中継情報は、受信したリクエストから得られる情報としてＵＲＬ１２０１、リクエストの送信元ＩＰアドレス１２０２とポート番号１２０３、宛先ＩＰアドレス１２０４とポート番号１２０５、さらにリクエストを転送した場合は、転送したリクエストの情報として、転送先ＵＲＬ１２０６、転送元ＩＰアドレス１２０７とポート番号１２０８、転送先のＩＰアドレス１２０９とポート番号１２１０、リクエストを送信した時刻である転送時刻１２１１、キャッシュ状態１２１２から構成される。
【０１３１】
解析部５０３では、ＨＴＴＰフローの同定には、ＵＲＬと時刻とを比較条件とするが、プロキシサーバ１０８によってリクエストの送信順が変更されている場合には、同一のＵＲＬであるＨＴＴＰフローの識別ができない。
【０１３２】
そこで、中継情報を基に、ＩＰアドレス、ポート番号を読み替えて比較するものとする。クライアント側ネットワーク１１１のパッシブメータ１０４から得られた計測結果の対象となるＨＴＴＰフローについて、宛先がプロキシサーバ１０８の場合は、計測結果データベース５０５に登録されたプロキシサーバ１０８の中継情報を参照し、ＵＲＬ１２０１、送信元ＩＰアドレス１２０２、ポート番号１２０３が一致するものを抽出する。そして、計測結果の送信元ＩＰアドレス７０３、ポート番号７０４を、抽出した中継情報の転送元ＩＰアドレス１２０７、ポート番号１２０８に読み替え、宛先ＩＰアドレス７０５、ポート番号７０６を抽出した中継情報の転送先ＩＰアドレス１２０９、ポート番号１２１０に読み替えて、バックボーンネットワーク１１０とサーバ側ネットワーク１１１との中継地点付近に配置されたパッシブメータ１０４の計測結果と比較する。そして、ＵＲＬ、送信元、宛先のＩＰアドレス、ポート番号が全て一致するものを、同一のＨＴＴＰフローと判断し、遅延時間の算出を行う。
【０１３３】
また、プロキシサーバ１０８が、ＵＲＬが同じリクエストを、同一の転送先に、短時間に複数回転送する際に、同じポートを使用して送信すると、バックボーンネットワーク１１０での計測結果に、ＵＲＬ、ＩＰアドレス、ポート番号が一致する計測結果が複数存在することになる。
【０１３４】
この場合には、プロキシサーバ１０８の中継情報の転送時刻から、リクエストの順番を判断し、同一のＨＴＴＰフローを識別するようにする。
【０１３５】
つぎに、中継装置でＵＲＬの変換が行われる場合について説明する。
【０１３６】
クライアント側ネットワーク１１１のパッシブメータ１０４は、プロキシサーバ１０８よりもアクティブメータ１０３等のクライアント側に配置されており、サーバ側ネットワーク１１２のパッシブメータ１０４は、リバースプロキシ１０９よりもＷｅｂサーバ１０５側に配置されているものとする。
【０１３７】
サーバ側ネットワーク１１２には複数のサーバが存在し、リバースプロキシ１０９は各サーバに対してリクエストを転送し、その際、必要に応じてＵＲＬの変更を行うものとする。
【０１３８】
ここで、クライアント側ネットワーク１１１のパッシブメータ１０４からの計測結果では、プロキシサーバ１０８を経由しているため、宛先がプロキシサーバ１０８のＩＰアドレス、ポート番号となっている。またサーバ側ネットワーク１１２のパッシブメータ１０４からの計測結果では、リバースプロキシ１０９を経由しているため、送信元がリバースプロキシ１０９のＩＰアドレス、ポート番号になっている。さらにＵＲＬについても、サーバ側ネットワーク１１１でのＵＲＬと外部に公開するＵＲＬとを変えている場合は、リバースプロキシ１０９でＵＲＬの変換が行われるため、ＵＲＬが異なっている。
【０１３９】
この場合、解析サーバ１０２は、プロキシサーバ１０８とリバースプロキシ１０９とから中継についての情報を取得するようにする。
【０１４０】
リバースプロキシ１０９は、上述の中継装置によるリクエスト送信順の変更がある場合におけるプロキシサーバ１０８と同様に、リクエストを受信した際に、このリクエストの中継情報を記録し、定期的に解析サーバ１０２に送信するようにする。解析サーバ１０２は、計測データ収集部５０２で中継情報を受信して、計測結果データベース５０５に記録する。中継情報のデータ構成は、図１２と同様とすることができる。
【０１４１】
解析サーバ１０２では、プロキシサーバ１０８およびリバースプロキシ１０９からの中継情報を利用して、計測結果のＵＲＬ、ＩＰアドレス、ポート番号を読み替えて比較し、ＨＴＴＰフローの同定を行う。
【０１４２】
解析部５０３では、クライアント側ネットワーク１１１のパッシブメータ１０４で計測された解析の対象となるＨＴＴＰフローを抽出し、宛先がプロキシサーバ１０８の場合は、計測結果データベース５０５に登録されたこのプロキシサーバ１０８の中継情報を参照して、ＵＲＬ１２０１、送信元ＩＰアドレス１２０２、ポート番号１２０３の一致するエントリを検索する。
【０１４３】
条件が一致するエントリがあり、他に一致するエントリがない場合には、その中継情報を抽出し、計測結果の送信元ＩＰアドレス７０３、ポート番号７０４を抽出した中継情報の転送元ＩＰアドレス１２０７、ポート番号１２０８に読み替え、宛先ＩＰアドレス７０５、ポート番号７０６を抽出した中継情報の転送先ＩＰアドレス１２０９、ポート番号１２１０に読み替える。ＵＲＬ７０２についても転送先ＵＲＬ１２０６に読み替える。
【０１４４】
さらに、転送先がリバースプロキシ１０９の場合には、リバースプロキシ１０９の中継情報を参照して、ＵＲＬ、送信元ＩＰアドレス、ポート番号が一致するエントリを検索する。
【０１４５】
条件が一致するエントリがあり、他に一致するエントリがない場合には、その中継情報を抽出し、計測結果の送信元ＩＰアドレス７０３、ポート番号７０４を抽出した中継情報の転送元ＩＰアドレス、ポート番号に読み替え、宛先ＩＰアドレス７０５、ポート番号７０６を抽出した中継情報の転送先ＩＰアドレス、ポート番号に読み替える。ＵＲＬ７０２についても転送先ＵＲＬに読み替える。
【０１４６】
転送先ＩＰアドレスが、プロキシサーバ１０８等のＩＰアドレスに一致しない場合には、転送先がＷｅｂサーバ１０５であると判断し、アドレス等の読み替えを終了する。
【０１４７】
この読み替えた情報とサーバ側ネットワーク１１２のパッシブメータ１０４で計測したＨＴＴＰフローとを比較して、送信元、宛先ＩＰアドレスとポート番号、ＵＲＬがすべて一致する情報を抽出する。さらに、条件の一致する他のフローがないことを確認して、同一のＨＴＴＰフローと判断する。
【０１４８】
条件の一致するＨＴＴＰフローが複数ある場合は、リバースプロキシ１０９の中継情報の転送時刻に基づいてリクエストの順番を判断し、同一のＨＴＴＰフローを識別するようにする。
【０１４９】
同一のＨＴＴＰフローと判断したものについては、計測結果のリクエスト送信時刻、または最初のレスポンスパケットの受信時刻、または最後のレスポンスパケットの受信時刻から差分を算出し、遅延時間とする。
【０１５０】
また、キャッシュ機能を有するプロキシサーバ１０８、リバースプロキシ１０９では、解析サーバ１０２に送信する中継情報にキャッシュ状態１２１２を記録する。キャッシュ状態１２１２には、プロキシサーバ１０８等がリクエストを中継する際、以前の応答の内容を保持しており、リクエストを転送せず、応答を作成してクライアントに送信する場合に“ＨＩＴ”を記録し、以前の応答の内容を保持しておらず、リクエストを転送する場合に“ＭＩＳＳ”を記録する。
【０１５１】
解析サーバ１０２の解析部５０３では、ＨＴＴＰフローの同定のために、計測結果データベース５０５の中継情報を参照する際に、キャッシュ状態１２１２を参照する。
【０１５２】
“ＭＩＳＳ”が記録されている場合は、リクエストが転送されているため、転送先アドレスに変換して、上述の処理を継続する。
【０１５３】
一方、“ＨＩＴ”が記録されている場合は、リクエストが転送されておらず、パッシブメータ１０４からの計測結果には、一致するＨＴＴＰフローはないと判断する。そして、ＨＴＴＰフローの同定のためのアドレス変換処理を中止し、このＨＴＴＰフローの遅延時間は“なし”として解析処理を終了する。
【０１５４】
以上により、プロキシサーバ１０８、リバースプロキシ１０９を経由するＨＴＴＰのトラフィックについても複数箇所でのパッシブメータ１０４の計測結果からＨＴＴＰフローの同定を行って、遅延時間を算出することが可能となる。
【０１５５】
【発明の効果】
以上説明したように、本発明によれば、アクティブ型の計測装置とパッシブ型の計測装置とを協働させて、Ｗｅｂページの構成を考慮した柔軟な計測を行なえる計測システムが提供される。さらに、本発明によれば、中継装置を介したＷｅｂトラフィックについてもコンテンツ単位でのＨＴＴＰフローの同定が可能となり、柔軟な計測を行なえるコンテンツ計測システムが提供される。
【図面の簡単な説明】
【図１】 本発明の第１の実施例におけるネットワークシステム構成図である。
【図２】 本発明の第１の実施例における計測設定サーバの機能構成図である。
【図３】 本発明の第１の実施例におけるアクティブメータの機能構成図である。
【図４】 本発明の第１の実施例におけるパッシブメータの機能構成図である。
【図５】 本発明の第１の実施例における解析サーバの機能構成図である。
【図６】 発明の第１の実施例における解析サーバがルールデータベースに保存するルールデータの一実施構成を表す図である。
【図７】 本発明の第１の実施例における解析サーバが計測結果データベースに保存する計測結果データの一実施構成を表す図である。
【図８】 本発明の第１の実施例における解析サーバの計測データ収集時のフローチャートである。
【図９】 本発明の第１の実施例におけるシステムのシーケンス図である。
【図１０】 本発明の第１実施例の第１の変形例におけるシステムのシーケンス図である。
【図１１】 本発明の第１実施例の第２の変形例におけるシステムのシーケンス図である。
【図１２】 本発明の第２の実施例における解析サーバが計測結果データベースに保存する中継情報データの一実施構成を表す図である。
【符号の説明】
１０１…計測設定サーバ、１０２…解析サーバ、１０３…アクティブメータ、１０４…パッシブメータ、１０５…サーバコンピュータ、１０６…ネットワーク装置、１０７…端末装置、１０８…プロキシサーバ、１０９…リバースプロキシ、１１０…バックボーンネットワーク、１１１…クライアント側ネットワーク、１１２…サーバ側ネットワーク
【発明の属する技術分野】
本発明は、複数のコンテンツから構成されるＷｅｂページに関するトラフィックを計測する計測システムに関する。
【０００２】
【従来の技術】
ハイパーテキスト形式の分散情報システムであるＷＷＷ（World Wide Web）は、通信プロトコルとしてＨＴＴＰ（HyperText Transfer Protocal）を用いた、クライアント・サーバ型のモデルである。クライアントはＵＲＬ（Uniform Resource Locator）を特定してリクエストを送り、サーバが応答することで、サーバが提供するドキュメント（Ｗｅｂページ）にアクセスする。Ｗｅｂページの記述には、ＨＴＭＬ（HyperText Markup Language）と呼ばれる言語が一般に使用され、テキストだけでなく、画像や音声など様々な形式のデータや、別のドキュメントへのリンク情報も組み込むことができる。
【０００３】
クライアント・サーバモデルにおけるトラフィック特性の計測では、ネットワーク内に配置された計測装置によってネットワーク内に流れるデータをキャプチャして遅延時間等の計測を行なうパッシブ型の計測と、計測装置がクライアントとしてサーバに対して要求を送信し、その応答を受信することにより応答時間等の計測を行うアクティブ型の計測とがある。
【０００４】
パッシブ型のＩＰレベルでの計測については、ＩＥＴＦのＲＦＣ２７２２で計測アーキテクチャが示され、ＲＦＣ２６７９、２６８０で、２地点間の遅延時間、パケットロスの計測方法が示されている。
【０００５】
アクティブ型の計測については、特許文献１に、エージェントがトランザクションサーバにアクセスして、応答時間などを測定する方法が示され、特許文献２に、ブラウザエージェントがリクエストを送信して、リクエストの送信時刻とその応答の受信時刻の差分から応答時間を計測する方法が示されている。
【０００６】
【特許文献１】
米国特許第６４４９７３９号明細書
【特許文献２】
米国特許第６００６２６０号明細書
【０００７】
【発明が解決しようとする課題】
一般に、Ｗｅｂページは、テキストや画像等の複数の情報（コンテンツ）から構成されていることが多い。これらは、Ｗｅｂページの表示時に、コンテンツごとにリクエストを送り、表示等すべき情報を順次サーバから取得してＷｅｂページに組み込んでいく。
【０００８】
このため、応答時間、遅延時間等といったＷｅｂページに関するトラフィック特性を計測する場合には、Ｗｅｂページを構成するコンテンツ毎の応答時間、遅延時間等を取得しなければならない。
【０００９】
複数コンテンツから生成されるＷｅｂページに関するトラフィック特性の計測について、従来のアクティブ型の計測方法は、サーバにリクエストを送信し、その応答のデータ部分を解析し、コンテンツ情報を得ることができるため、各コンテンツに対してリクエストを送信し、Ｗｅｂページ全体の応答時間に関する時間を取得可能である。しかし、アクティブ型の計測方法では、例えば、ネットワークの２地点におけるパケットをキャプチャすることが必要となる遅延時間等の計測を行なうことが困難である。
【００１０】
一方、パッシブ型の計測では、２地点でパケットをキャプチャすることによりコンテンツに関する遅延時間等の計測を行なうことができる。しかし、Ｗｅｂページのコンテンツ情報を得るためには、データ部を解析しなければならないので、Ｗｅｂページに関するトラヒック特性の計測の負荷が大きくなる。
【００１１】
このため、アクティブ型の計測装置とパッシブ型の計測装置とを協働させて、Ｗｅｂページに関する計測を柔軟に行なえる計測システムの構築が望まれている。
【００１２】
ところで、クライアント側のネットワークからインターネットへの接続にあたり、セキュリティを確保したり、トラフィックを軽減する目的で、プロキシサーバを設けてアクセス制御を行なう場合がある。プロキシサーバは、一般に、Ｗｅｂドキュメントのキャッシュ機能を有しており、リクエストに対応する情報がキャッシュに存在している場合には、リクエストをインターネットに送信せずに、キャッシュに存在している情報をクライアントに送信する。また、サーバ側のネットワークでも、不正アクセスの防止などセキュリティを確保する目的で、リバースプロキシを設ける場合がある。いずれもアクセスを中継するためのサーバであり、ローカルネットワークとインターネットとを切り離すために、ＩＰアドレスの変換を行なうことができる。また、リバースプロキシでは、サーバ側のＵＲＬと外部に公開するＵＲＬとを変換する場合もある。
【００１３】
遅延時間の計測を行うためには、異なる地点において計測されたＨＴＴＰフローを同定することが必要となる。ここで、ＨＴＴＰフローは、あるＵＲＬで特定されるコンテンツのリクエストから応答までの一連のＨＴＴＰのパケット群を意味するものとする。
【００１４】
ところが、プロキシサーバ、リバースプロキシ等の中継装置が、ＩＰアドレス、あるいは、ＵＲＬの変換を行なう場合には、同一のパケットであっても、計測する場所によってパケットの送信元、宛先ＩＰアドレス、あるいは、ＵＲＬが異なる場合がある。このため、ＨＴＴＰフロー同定が困難である。
【００１５】
また、リバースプロキシで、サーバのＩＰアドレスと外部に公開するＵＲＬを変換している場合には、計測する場所によりリクエストのＵＲＬが一致しないことになる。さらに、プロキシサーバのキャッシュ機能により、リクエストがインターネットに送信されない場合もある。
【００１６】
このように、中継装置が介在すると、計測装置で取得したＨＴＴＰフローの同定が困難になる。このような場合にも柔軟に対応できる計測システムを構築することが望まれる。
【００１７】
本発明の目的は、アクティブ型の計測装置とパッシブ型の計測装置とを協働させて、柔軟な計測を行なえる計測システムを提供することにある。
【００１８】
【課題を解決するための手段】
上記課題を解決するために、本発明の第１の態様によれば、
ネットワークを流れるパケットを受信して、設定された計測ルールに基づく計測を行なう１または複数台のパッシブ型計測装置と、
設定された計測ルールに従って、コンテンツ提供サーバに対して計測用リクエストを送信し、その応答に基づいて計測対象となるコンテンツに関する情報を取得するアクティブ型計測装置と、
前記パッシブ型計測装置の計測結果のうち、前記アクティブ型計測装置が取得した情報に対応する計測結果を用いて、設定された解析ルールに基づく算出を行なうことで、コンテンツ提供に関する特性を導出する解析装置と
を備えることを特徴とする計測システムが提供される。
【００１９】
また、上記課題を解決するために、本発明の第２の態様によれば、
設定された計測ルールに従って、コンテンツ提供サーバに対して計測用リクエストを送信するアクティブ型計測装置と、
前記アクティブ型計測装置とコンテンツ提供サーバ間に設けられ、通信に関する情報を変換して中継する中継装置と、
ネットワークを流れるパケットを受信して、設定された計測ルールに基づく計測を行なう複数台のパッシブ型計測装置と、
パッシブ型計測装置の計測結果を収集し、それぞれのパッシブ計測装置で計測された関連するパケットの集合体であるフローを同定し、ネットワークのトラフィック特性を導出する解析装置とを備えた計測システムであって、
前記解析装置は、前記中継装置から通信に関する情報の変換情報を取得して、この情報に基づいてフローを同定することを特徴とする計測システムが提供される。
【００２０】
なお、第２の態様は、クライアントとコンテンツ提供サーバとの間に設けられ、通信に関する情報を変換して中継する中継装置と、
ネットワークを流れるパケットを受信して、設定された計測ルールに基づく計測を行なう複数台のパッシブ型計測装置と、
パッシブ型計測装置の計測結果を収集し、それぞれのパッシブ計測装置で計測された関連するパケットの集合体であるフローを同定し、ネットワークのトラフィック特性を導出する解析装置とを備えた計測システムであって、
前記解析装置は、前記中継装置から通信に関する情報の変換情報を取得して、この情報に基づいてフローを同定することを特徴とする計測システムとしてもよい。
【００２１】
【発明の実施の形態】
本発明の実施形態について、図面を参照して詳細に説明する。
【００２２】
図１は本発明が適用されるネットワークの構成の一例を示す図である。
【００２３】
本図において、サーバコンピュータ１０５はコンテンツを提供するＷｅｂサーバとして機能し、端末装置１０７はリクエストを送り、コンテンツの提供を享受するＷｅｂクライアントとして機能する。端末装置１０７を含むクライアント側ネットワーク１１１は、ルータ等のネットワーク装置１０６を複数備えて構成されるバックボーンネットワーク１１０に接続している。また、サーバコンピュータ１０５（以下「Ｗｅｂサーバ１０５」）を含むサーバ側ネットワーク１１２がバックボーンネットワーク１１０に接続している。このため、クライアント側ネットワーク１１１とサーバ側ネットワーク１１２との間のトラフィックは、バックボーンネットワーク１１０を介して行なわれることになる。なお、各ネットワークは有線、無線を問わない。また、サーバコンピュータ１０５は、複数台のコンピュータから構成されるサーバコンピュータ群としてもよい。本実施例において、端末装置１０７からのリクエストに対して、Ｗｅｂサーバ１０５が提供するサービスは、ＨＴＴＰによるＷｅｂページとするが、これに限られるものではない。
【００２４】
本実施例では、サービス品質としてのトラフィック特性を計測対象とする。このため、トラフィック計測を行なう計測担当者は、例えば、バックボーンネットワーク１１０を管理あるいは提供する事業者とすることができる。もちろん、本発明は、これに限られるものではない。
【００２５】
クライアント側ネットワーク１１１にはプロキシサーバ１０８が、サーバ側ネットワーク１１２にはリバースプロキシ１０９が、それぞれ備えられている。ただし、これらを備えないネットワーク構成としてもよい。まずは、簡単のため、第１実施例として、プロキシサーバ１０８およびリバースプロキシ１０９によるＩＰアドレスの変換、キャッシュ等の処理が行なわれない、あるいは、影響しない場合について説明する。
【００２６】
図１に示すように、ネットワークには、アクティブ型の計測処理を行なうアクティブメータ１０３と、パッシブ型の計測処理を行なうパッシブメータ１０４とが配置される。本図ではクライアント側ネットワーク１１１にアクティブメータ１０３とパッシブメータ１０４とが１台ずつ配置され、バックボーンネットワーク１１０にパッシブメータ１０４が１台配置されている。
【００２７】
パッシブメータ１０４の台数および配置位置は、ネットワーク構成、計測種別等に応じるが、サービス品質としてのトラフィック特性を計測対象とする本実施例では、少なくとも、バックボーンネットワーク１１０と他のネットワークとの接続箇所付近に配置することが望ましい。
【００２８】
アクティブメータ１０３とパッシブメータ１０４とは、それぞれ識別子が付されている。各メータの識別子、配置箇所、ＩＰアドレス等の情報は、計測担当者に既知であるとする。
【００２９】
アクティブメータ１０３、パッシブメータ１０４は、ソフトウェアあるいはハードウェアで実現することができる。また、ネットワーク装置１０６に組み込んだ構成とすることもできるし、独立の装置等で構成することもできる。
【００３０】
ネットワークには、さらに、計測担当者からトラフィック特性の計測に関する要求を受け付ける計測設定サーバ１０１と、アクティブメータ１０３およびパッシブメータ１０４が収集した計測結果に基づいて解析を行なう解析サーバ１０２とが接続される。これらは、１台あるいは複数台の一般的な情報処理装置、例えばサーバコンピュータを用いて構成することができる。演算処理装置、記憶装置、入出力装置等を備えた一般的な情報処理装置は、後述する各処理を行なうためのプログラムを実行することで計測設定サーバ１０１あるいは解析サーバ１０２として機能することができる。もちろん、計測設定サーバ１０１あるいは解析サーバ１０２は専用の装置を用いて構成するようにしてもよい。
【００３１】
なお、本図では計測設定サーバ１０１と解析サーバ１０２とは同一のブロードキャストドメイン内に存在するようにしているが、それぞれが別々のブロードキャストドメインに存在してもよい。また、ネットワーク上の位置も問わない。
【００３２】
計測設定サーバ１０１および解析サーバ１０２のＩＰアドレスおよびポート番号は、計測担当者に既知であるとする。また、各メータの識別子、配置箇所、ＩＰアドレス等の情報とともにネットワーク構成情報として計測設定サーバ１０１に登録しておくことが望ましい。
【００３３】
本実施例では、計測要求を受け付けた計測設定サーバ１０１が、アクティブメータ１０３、パッシブメータ１０４、解析サーバ１０２に対して処理の内容を定めたルールを送信する。そして、アクティブメータ１０３は、対象となるＷｅｂページの構成情報を取得し、パッシブメータ１０４は、ネットワークに流れるデータをキャプチャして必要なパケットを抽出する。解析サーバ１０２は、アクティブメータが取得したＷｅｂページ構造と、パッシブメータ１０４が抽出したパケットとを対応付けたうえで、トラフィック特性の算出を行なう。
【００３４】
図２は計測設定サーバ１０１の機能構成を示すブロック図である。計測設定サーバ１０１は、計測要求受付部２０１にて、計測担当者からの計測要求を受け付ける。
【００３５】
計測要求は、例えば、以下のような項目を含むものとする。
【００３６】
【表１】
【００３７】
対象ＷｅｂページのＵＲＬは、計測に用いるＷｅｂサーバ１０５が提供するＷｅｂページのＵＲＬである。
【００３８】
計測に使用するメータの識別子は、少なくとも１台のアクティブメータ１０３の識別子と、計測種別に応じた１台または複数台のパッシブメータ１０４の識別子とする。どのメータを用いるかは、例えば、計測担当者がネットワーク構成に基づいて判断するものとする。
【００３９】
開始時刻、終了時刻は、計測の開始時間と終了時間である。
【００４０】
レポート間隔は、計測結果収集方法がプッシュ型の場合にはパッシブメータ１０４の計測結果の送信間隔であり、計測結果収集法がプル型の場合には解析サーバ１０２が収集要求を送信して計測結果を収集する間隔である。ここで、プッシュ型は、パッシブメータ１０４が定期的に結果を送信する方法で、プル型は解析サーバ１０２の要求に応答してパッシブメータ１０４が計測結果を送信する方法である。
【００４１】
なお、これらの項目は計測担当者がすべて設定するようにしてもよいし、計測担当者が計測の概要を設定し、あらかじめ定めた規則により計測設定サーバ１０１が具体的な内容を決定するようにしてもよい。
【００４２】
図２において、計測設定サーバ１０１のルール生成部２０２は、計測要求受付部２０１が受け付けた計測要求に基づいて、アクティブメータ１０３、パッシブメータ１０４および解析サーバ１０２が行なうべき処理を定めたルールを作成する。
【００４３】
具体的には、以下のような処理を行なう。
【００４４】
まず、受け付けた計測要求に、要求識別子を一意に割り当てる。また、計測に用いるアクティブメータ１０３、パッシブメータ１０４が行なうべき処理（「計測タスク」と称する）、および、解析サーバ１０２が行なうべき処理（「解析タスク」と称する）を決定し、ルール（それぞれ「計測ルール」「解析ルール」と称する）を作成して、それぞれに一意にタスク識別子を割り当てる。
【００４５】
計測要求で指定されたアクティブメータ１０３に対する計測ルールには、要求識別子、タスク識別子、対象ＷｅｂページのＵＲＬ、開始時刻、解析サーバ１０２のアドレスとポート番号とを含める。なお、本実施例では、アクティブメータ１０３が行なう処理は、対象ＷｅｂページのＵＲＬにリクエストを送り、そのＷｅｂページのＵＲＬ構造を取得するものであるから、開始時刻は、即時とすることができる。
【００４６】
計測要求で指定されたパッシブメータ１０４に対する計測ルールには、タスク識別子、フィルタリング条件、計測種別（遅延、応答時間、可用性等）、開始時刻、終了時刻、さらに収集方法がプッシュ型の場合は解析サーバアドレスとポート番号、レポート間隔を含める。
【００４７】
フィルタリング条件は、キャプチャしたパケットを選別するための条件を指定するもので、例えば、プロトコルタイプとしてＨＴＴＰ、送信元であるアクティブメータ１０３のＩＰアドレス、宛先であるＷｅｂサーバ１０５のＩＰアドレス等とすることができる。ＨＴＴＰトラフィックの計測に関しては、例えば、フィルタリング条件のプロトコルタイプにＨＴＴＰを指定し、その他を指定しない場合は、ＨＴＴＰに関する全トラフィックを計測することになる。
【００４８】
解析サーバ１０２に対する解析ルールには、要求識別子、対象ＷｅｂページのＵＲＬ、計測種別、開始時刻、終了時刻、収集方法がプル型の場合はレポート間隔、さらに、アクティブメータ１０３の識別子とアドレスとポート番号およびアクティブメータ１０３に対するタスク識別子、パッシブメータ１０４の識別子とアドレスとポート番号およびパッシブメータ１０４に対するタスク識別子を含める。
【００４９】
計測設定サーバ１０１のルール生成部２０２は、生成した計測ルールおよび解析ルールをルールデータベース２０４に登録するとともに、ルール設定部２０３に通知する。
【００５０】
ルール設定部２０３は、ルール生成部２０２から通知された計測ルールおよび解析ルールを、対応するアクティブメータ１０３、パッシブメータ１０４、解析サーバ１０２に通知する。
【００５１】
なお、計測設定サーバ１０１は、計測要求以外のデータを受信するためのデータ受信部２０５を備えている。また、計測設定サーバ１０１は、ユーザから計測開始の要求だけでなく、計測の中止、変更要求等も受け付ける。これらについては説明を省略する。
【００５２】
図３はアクティブメータ１０３の機能構成を示すブロック図である。本図において、ルール受付部３０１は、計測設定サーバ１０１から送られた計測ルールを受信する。受信した計測ルールは、ルールテーブル３０５に登録し、タスク実行部３０２に通知する。タスク実行部３０２は計測ルールに含まれる対象ＷｅｂページのＵＲＬに対して計測用リクエストを送信し、Ｗｅｂサーバ１０５からの応答を受信する。
【００５３】
受信した応答のメッセージボディ部（ＨＴＭＬファイル）は、分析部３０３に送られる。分析部３０３では、ＨＴＭＬファイルから、対象Ｗｅｂページに含まれるコンテンツの情報（例えば、所定のタグ情報）を抽出して、Ｗｅｂページを構成するＵＲＬのリストを作成する。作成したＵＲＬリストには、タスク識別子を付して管理する。このとき、対象Ｗｅｂページにスクリプトファイルが含まれており、スクリプト内であるＵＲＬにリクエストを送信する場合には、タスク実行部３０１にそのＵＲＬに対するリクエストを依頼し、その応答について、同様の処理を行う。同一のＵＲＬに対して複数回リクエストを送信する場合は、複数回分を、結果のリストに記録する。
【００５４】
作成したＵＲＬリストは、データ送信部３０４が、計測ルールで指定された解析サーバ１０２に計測結果として送信する。
【００５５】
図４はパッシブメータ１０４の機能構成を示すブロック図である。ルール受付部４０１は、計測設定サーバ１０１から送られた計測ルールを受信する。受信した計測ルールは、ルールテーブル４０６に登録する。
【００５６】
計測ルールにしたがって、開始時刻から終了時刻までの間、キャプチャ部４０２は、ネットワークからパケットを取り込み、タイムスタンプを押す。
【００５７】
フィルタリング部４０３は、キャプチャしたパケットのうち、フィルタリング条件に合致するパケットを選別する。
【００５８】
データ編集部４０４で、必要に応じて選別されたパケットを加工し、加工した結果等を記憶装置上にＨＴＴＰフロー情報として、タスク識別子を付して保存する。加工としては、例えば、レスポンスパケットが複数ある場合に、最初および最終レスポンスの時間を取得することがある。また、レスポンスの状態から応答状態（正常またはエラー）を判断したり、コンテンツサイズを取得すること等がある。
【００５９】
データ送信部４０５は、プッシュ型が指定されている場合にはレポート間隔で定められる時間毎に、プル型が指定されている場合には解析サーバ１０２から要求があった時点で、保存している計測結果を解析サーバ１０２に計測結果として送信する。
【００６０】
なお、パッシブメータ１０４は各種プロトコルに対応し、例えば、トランスポート層のＴＣＰ、ＵＤＰ、上位層のＤＮＳやＨＴＴＰの計測が可能である。
【００６１】
図５は解析サーバ１０２の機能構成を示すブロック図である。解析ルール受付部５０１は、計測設定サーバ１０１から送られた解析ルールを受信してルールデータベース５０４に登録する。計測データ収集部５０２は、計測に用いられたアクティブメータ１０３およびパッシブメータ１０４から送られた計測結果を受信して、計測結果データベース５０５に登録する。解析部５０３は、解析ルールにしたがって、受信した計測結果であるＵＲＬリストおよび計測データを用いて遅延時間等の計測種別に応じた算出処理を行なう。
【００６２】
図６にルールデータベース５０４のデータ構成の一例を示す。ルールデータベース５０４は、計測要求に基づく情報として、要求識別子６０１、対象ＷｅｂページのＵＲＬ６０２、計測種別６０３、開始時刻６０４と終了時刻６０５、レポート間隔６０６、状態６０７を管理する。状態６０７は、その計測要求に基づく処理の状態を示すもので、例えば、初期状態（ＩＮＩＴＩＡＬ）、解析処理実行中（ＡＣＴＩＶＥ）、解析処理を正常終了した状態（ＤＯＮＥ）、異常終了した状態（ＥＲＲＯＲ）のいずれかの値をとるものとする。
【００６３】
また、ルールデータベース５０４は、計測要求に対応したメータが実行する計測ルールの情報を関連付けて、計測タスク情報として管理する。
【００６４】
計測タスク情報は、計測タスク識別子６０８、パッシブメータ１０４の識別子６０９とそのＩＰアドレスおよびポート番号６１０、その計測要求についてのアクティブメータ１０３の計測結果であるＵＲＬリストの識別子６１１、計測タスクの状態を示すタスク状態６１２から構成される。複数のパッシブメータ１０４を使用する計測種別の場合は、計測タスク情報はパッシブメータ１０４毎に上述の計測要求に基づく情報と関連付けて管理する。
【００６５】
計測要求に基づく情報、および、計測タスク情報の計測タスク識別子６０８、パッシブメータ１０４に関する情報６０９、６１０は、解析ルール受付部５０１が解析ルールの受付時に設定する。タスク状態６１２には、例えば、計測タスク実行前の初期状態（ＩＮＩＴＩＡＬ）、タスク実行中（ＡＣＴＩＶＥ）、タスクを正常終了した状態（ＤＯＮＥ）、タスクを異常終了した状態（ＥＲＲＯＲ）のいずれかを、状態に合わせて設定する。ＵＲＬリスト識別子６１１は、アクティブメータ１０３からの計測結果であるＵＲＬリストの受信後に計測データ受信部５０２が任意に設定する。
【００６６】
図７に計測結果データベース５０５のデータ構成の一例を示す。計測結果データベース５０５は、計測要求に基づく測定結果を識別するためのＵＲＬリスト識別子７０１、ＵＲＬリストに含まれるＵＲＬを登録するＵＲＬ７０２、リクエスト送信元であるクライアントのＩＰアドレス７０３とポート番号７０４、リクエストの宛先であるサーバのＩＰアドレス７０５とポート番号７０６、応答状態７０７、計測時間情報としてリクエスト送信時刻７０８、最初のレスポンス受信時刻７０９、最終レスポンス受信時刻７１０、サイズ７１１から構成される。ＵＲＬリスト識別子７０１は、ルールデータベース５０４に登録するＵＲＬリスト識別子６１１と対応し、解析ルールに対して計測結果を関連付けるものである。
【００６７】
解析サーバ１０２は、解析ルール受付部５０１で、計測設定サーバ１０１からの解析ルールを受信し、ルールデータベース５０４に登録する。ここでの状態６０７、および、各計測タスクのタスク状態６１２は「初期状態」とする。
【００６８】
開始時刻になった時点で、解析サーバ１０２は、計測データ収集部５０２で計測結果の受信を開始し、状態６０７を「実行中」にする。また、パッシブメータ１０４からの計測結果を受信した時点で、対応する計測タスク情報のタスク状態６１２を「タスク実行中」にする。
【００６９】
つぎに、解析サーバ１０２の計測データ収集部５０２における処理を図８に示したフロー図を参照して説明する。
【００７０】
ステップＳ８０１で、計測データ収集部５０２が計測結果を受信すると、その計測結果がアクティブメータ１０３から送られたものか、パッシブメータ１０４から送られたものかを判断する（Ｓ８０２）。
【００７１】
計測結果がアクティブメータ１０３から送られてきた場合には、計測結果であるＵＲＬリストに識別子を付すとともに、計測結果データベース５０５に新たなレコードを登録する（Ｓ８０３）。新たなレコードは、ルールデータベース５０４を参照して、計測タスク情報の個数分、すなわち、計測に用いるパッシブメータ１０４の数に対応して登録する。なお、上記のＵＲＬリスト識別子も、計測タスク情報の個数に対応して、計測に用いるパッシブメータ１０４それぞれについて一意的に付すものとする。
【００７２】
新たなレコードのＵＲＬリスト識別子７０１には、付されたＵＲＬ識別子を登録し、ＵＲＬ７０２には、ＵＬＲリストに含まれるＵＲＬを登録する。なお、ＵＲＬ識別子は、ルールデータベース５０４の対応する計測タスク情報のＵＲＬリスト識別子６１１にも登録する。ここで、計測結果データベース５０５のＵＲＬ７０２には、ＷｅｂページのＵＲＬおよびそのＷｅｂページを構成するコンテンツのＵＲＬをすべて登録する。したがって、例えば、ＨＴＭＬファイルｉｎｄｅｘ.ｈｔｍｌで特定されるＷｅｂページが、イメージデータｉｍａｇｅ.ｇｉｆを含んで構成される場合には、計測結果データベース５０５において、一つのＵＲＬリスト識別子７０１に対して、２つのＵＲＬ７０２を登録することになる。
【００７３】
一方、計測結果がパッシブメータ１０４から送られてきた場合には、受信した計測結果に含まれるタスク識別子とから、ルールデータベース５０４を参照し、ＵＲＬリスト識別子６１１が登録済であるか、すなわち、計測結果データベース５０５に計測結果を格納するためのレコードが登録されているかを確認する（Ｓ８０４）。
【００７４】
ＵＲＬリスト識別子６１１が登録されていない場合は、一時的に記憶装置に保存しておき（Ｓ８０９）、その後、計測結果を受信した時点で再度検索する。これは、同じ計測要求に係る計測結果について、パッシブメータ１０４からの計測結果の方を早く受信した場合を考慮するためである。
【００７５】
ＵＲＬリスト識別子６１１が登録されている場合は、対応する計測結果データベース５０５に登録されたＵＲＬ７０２に、受信した計測結果に含まれるＵＲＬ情報と一致するものがあるかどうかを判断する（Ｓ８０５）。
【００７６】
その結果、一致するＵＲＬ７０２がない場合には、計測結果を廃棄する（Ｓ８１０）。
【００７７】
一方、一致するＵＲＬ７０２がある場合には、受信した計測結果に含まれる送信元ＩＰアドレス、宛先ＩＰアドレス等のアドレス情報およびリクエスト送信時刻、コンテンツサイズ等のＨＴＴＰフロー情報を、計測結果データベース５０５の、一致したＵＲＬ７０２に対応するアドレス情報（７０３、７０４、７０５、７０６）、応答状態（７０７）、各時刻情報（７０８、７０９、７１０）、サイズ（７１１）にそれぞれ登録する（Ｓ８０６）。
【００７８】
結果を登録後、ＵＲＬ７０２に登録されている全ＵＲＬについての計測結果をパッシブメータ１０４から収集したかどうかを判断する（Ｓ８０７）。全ＵＲＬについて結果を収集している場合は計測タスク終了とみなし、ルールデータベース５０４のタスク状態６１２を正常終了として、計測タスクの終了を解析部５０３に通知する（Ｓ８０８）。収集していないＵＲＬがある場合には、引き続き計測結果の受信を待つ。なお、一定時間経過後も全ＵＲＬについての結果を収集できない場合は、タスク状態６１２を異常終了とし、計測タスクの終了を解析部５０３に通知する。
【００７９】
解析部５０３は、要求識別子に対する各計測タスクの終了通知の受信後、または終了時刻から一定時間経過後に、計測タスクの状態を見て、正常終了しているかを確認する。正常終了している場合、ルールの状態６０７を正常終了状態とする。そして、ルールデータベース５０４の計測種別６０３に基づいて、計測結果を解析する。解析結果は、例えば、解析サーバ１０２の解析結果を利用する上位アプリケーション等に送信する。
【００８０】
解析部５０３の解析処理としては、例えば、計測種別が応答時間（ＬＡＴＥＮＣＹ）である場合、ＨＴＴＰに関しては、リクエスト送信時刻と最初のレスポンスパケット受信時刻との差分（サーバのＬＡＴＥＮＣＹ）、最初のレスポンスパケット受信時刻と最終レスポンス受信時刻との差分（ダウンロード時間）とそれらを加算したＨＴＴＰ全体の時間を算出する。さらに、パッシブメータ１０４からＨＴＴＰに関連するＤＮＳやＴＣＰコネクションの確立時間の計測結果を得て、ＨＴＴＰの時刻情報と合わせて、対象ＵＲＬに対する全ＬＡＴＡＮＣＹを算出するようにしてもよい。
【００８１】
また、Ｗｅｂページ全体のＬＡＴＥＮＣＹについては、最初のＤＮＳの開始時刻と、全ＵＲＬのうち最後のレスポンスパケット受信時刻との差分、または、ページを構成する全ＵＲＬのＬＡＮＴＥＮＣＹを加算することにより算出することができる。
【００８２】
応答状態７０７がエラーで、計測種別に示された処理を行えない場合、または異常終了のタスクがある場合はルールデータベース５０４の状態６０７を「異常終了」として、解析部５０３における解析処理は行わず、上位アプリケーション等に対して、エラーを通知する。
【００８３】
図９にシステム全体のシーケンス図を示す。まず、計測設定サーバ１０１が計測要求に基づくルールを生成して、解析サーバ１０２に解析ルールを、アクティブメータ１０３とパッシブメータ１０４とに計測ルールを送信する（Ｓ９０１）。
【００８４】
アクティブメータ１０３は、計測ルールにしたがって、計測用リクエストをＷｅｂサーバ１０５に送信し、応答に基づいてＵＲＬリストを作成して解析サーバ１０２に送信する（Ｓ９０２）。
【００８５】
パッシブメータ１０４は、計測ルールにしたがって計測を行い、計測結果を解析サーバ１０２に送信する（Ｓ９０３）。
【００８６】
解析サーバ１０２では、アクティブメータ１０３の計測結果であるＵＲＬリストに、パッシブメータ１０４の計測結果を対応付けて計測結果データベース５０５に登録し、解析ルールで示された計測種別に応じた解析を行なう（Ｓ９０４）。
【００８７】
以上により、アクティブ型の計測装置とパッシブ型の計測装置とを協働させて、Ｗｅｂページの構成を考慮した柔軟な計測を行なえる計測システムを構築することができる。
【００８８】
次に上記実施例の第１の変形例について説明する。図１０は、第１の変形例におけるシステム全体のシーケンスを示す図である。
【００８９】
図９との違いは以下の通りである。すなわち、計測設定サーバ１０１はアクティブメータ１０３にのみ計測ルールを送信する（Ｓ１００１）。アクティブメータ１０３は計測用リクエストをＷｅｂサーバ１０５送信し、応答を受信してＷｅｂページの分析を行なう（Ｓ１００２）。その分析結果を基に、パッシブメータ１０４が使用する計測ルールを作成してパッシブメータ１０４に通知し、解析サーバ１０２が使用する解析ルールを生成してを解析サーバ１０２に通知する（Ｓ１００３）。なお、各サーバおよび各メータの機能構成はそれぞれ前述の実施例と同様とすることができる。
【００９０】
第１の変形例における処理の流れについて説明する。
【００９１】
計測設定サーバ１０１は、計測担当者からの計測要求を受け付けた後、パッシブメータ１０４、解析サーバ１０２に対しては送信を行わず、アクティブメータ１０３に対してのみ計測ルールを送信する。
【００９２】
この場合の計測ルールには、要求識別子、タスク識別子、対象ＷｅｂページのＵＲＬ、開始時刻、解析サーバ１０２のアドレスとポート番号に加えて、使用するパッシブメータ１０４の識別子とアドレスとポート番号、および、上記の例でパッシブメータ１０４に対する計測ルールに含めていた項目、すなわち、計測種別、レポート時間、パッシブメータ１０４で使用するフィルタリング条件等と、メータや解析サーバ毎のタスク識別子を含めるようにする。
【００９３】
アクティブメータ１０３は、ルール受付部３０１で、計測設定サーバ１０１から送られた計測ルールを受信する。受信した計測ルールは、ルールテーブル３０５に登録し、タスク実行部３０２に通知する。タスク実行部３０２は計測ルールに含まれる対象ＷｅｂページのＵＲＬに対して計測用リクエストを送信し、Ｗｅｂサーバ１０５からの応答を受信する。
【００９４】
受信した応答のメッセージボディ部（ＨＴＭＬファイル）は、分析部３０３に送られる。分析部３０３では、ＨＴＭＬファイルから、対象Ｗｅｂページに含まれるコンテンツの情報を抽出して、リスト（ＵＲＬリスト）を作成する。作成したＵＲＬリストには、タスク識別子を付して、データ送信部３０４が、パッシブメータ１０４に送信する。ここで、データ送信部３０４は、ルールテーブル３０５を参照して、計測ルール、解析ルールをそれぞれパッシブメータ１０４、解析サーバ１０２に送信する。
【００９５】
パッシブメータ１０４へ送る計測ルールの内容は、第１の実施例の内容に、作成したＵＲＬリストに含まれる全ＵＲＬをフィルタリング条件として追加したものとなる。
【００９６】
また解析サーバ１０２へ送る解析ルールの内容は、計測設定サーバ１０１から受信した計測ルールに基づくもので、上述の実施例と同様とすることができる。
【００９７】
パッシブメータ１０４は、ルール受付部４０１でアクティブメータ１０３から送信された計測ルールを受信する。本実施例では、フィルタリング条件として、送信元のＩＰアドレスおよび宛先のＩＰアドレスに加え、ＵＲＬが指定されている。フィルタリング部４０３では、このフィルタリング条件に従ったフィルタリングを行い、計測結果を解析サーバ１０２に送信する。
【００９８】
解析サーバ１０２は、計測データ収集部５０２がパッシブメータ１０４からの計測データの収集を開始すると、計測タスク情報ごとに計測結果データベース５０５を割り当て、ＵＲＬリスト識別子７０１を設定するとともに、ＵＲＬ７０２に対応する計測結果を計測結果データベース５０５に登録する。
【００９９】
なお、アクティブメータ１０３は計測結果をパッシブメータ１０４にフィルタリング条件として通知するとともに、前述の実施例と同様に、解析サーバ１０２に対してＵＲＬリストを送信してもよい。この場合、解析サーバ１０２は、アクティブメータ１０３からのＵＲＬリスト受信時に計測結果データベース５０５を計測タスクごとに割り当て、ＵＲＬリストの情報を登録しておき、パッシブメータ１０４からの計測結果を対応する計測結果データベース５０５に登録する。
【０１００】
このように、第１の変形例によれば、上記第１の実施例の効果に加え、パッシブメータ１０４では、対象となるＵＲＬを絞ってフィルタリングすることができるため、計測結果のデータ量が削減され、ネットワークの負荷が軽減するとともに、解析サーバ１０２における解析処理の負荷も軽減することができる。
【０１０１】
つぎに、上記実施例の第２の変形例について説明する。
【０１０２】
図１１は別の変形例におけるシステム全体のシーケンスを示す図である。図９との違いは、以下の通りである。すなわち、計測設定サーバ１０１は、アクティブメータ１０３にのみ計測ルールを送信する（Ｓ１１０１）。アクティブメータ１０３は、計測タスクを実行した結果であるＵＲＬリストを、計測設定サーバ１０１に送信する（Ｓ１１０２）。その後、計測設定サーバ１０１が、ＵＲＬリストの情報を含めた計測ルールおよび解析ルールを生成し、パッシブメータ１０４、解析サーバ１０２に対して送信する（Ｓ１１０３）。
【０１０３】
第２の変形例における処理の流れについて説明する。
【０１０４】
計測設定サーバ１０１は計測担当者からの計測要求受付後に、まず、アクティブメータ１０３に対して計測ルールを送信する。
【０１０５】
アクティブメータ１０３は、計測設定サーバ１０１から受け付けた計測ルールをルールテーブル３０５に登録し、計測ルールにしたがって、計測用リクエストを送信し、応答を受信する。分析部３０３においてＵＲＬリストを作成し、データ送信部３０４が計測設定サーバ１０１に結果結果として送信する。
【０１０６】
計測設定サーバ１０１は、データ受信部２０５でアクティブメータ１０３から計測結果を受信し、ルール生成部２０２に通知する。ルール生成部２０２は、計測担当者からの計測要求に基づいて、パッシブメータ１０４と解析サーバ１０２とが行なうべき処理を定めたルールを作成する。その際、第１の変形例と同様に、パッシブメータ１０４に対するルールに含まれるフィルタリング条件については、作成したＵＲＬリストに含まれる全ＵＲＬを追加したものとなる。解析サーバ１０２に対するルールは、第１の実施例と同様である。
【０１０７】
ルール設定部２０３は、それぞれのルールを、計測ルール、解析ルールとして、パッシブメータ１０４および解析サーバ１０２に送信する。
通知の内容は、解析サーバに対しては、実施例１と同様であり、パッシブメータに対しては、実施例１の内容に、結果の全ＵＲＬをフィルタリング条件として追加したものとなる。
【０１０８】
パッシブメータ１０４は、第１の変形例と同様に、ルール受付部４０１で計測設定サーバ１０１から送信された計測ルールを受信する。ＵＲＬが指定されたフィルタリング条件に従って、フィルタリング部４０３でパケットのフィルタリングを行い、計測結果を解析サーバに送信する。
【０１０９】
解析サーバ１０２は、計測データ収集部５０２がパッシブメータ１０４からの計測データの収集を開始すると、計測タスク情報ごとに計測結果データベース５０５を割り当て、ＵＲＬリスト識別子７０１を設定するとともに、ＵＲＬ７０２に対応する計測結果を計測結果データベース５０５に登録する。
【０１１０】
なお、アクティブメータ１０３は計測結果をパッシブメータ１０４にフィルタリング条件として通知するとともに、前述の実施例と同様に、解析サーバ１０２に対してＵＲＬリストを送信してもよい。この場合、解析サーバ１０２は、アクティブメータ１０３からのＵＲＬリスト受信時に計測結果データベース５０５を計測タスクごとに割り当て、ＵＲＬリストの情報を登録しておき、パッシブメータ１０４からの計測結果を対応する計測結果データベース５０５に登録する。
【０１１１】
このように、第２の変形例によれば、上記第１の実施例の効果に加え、パッシブメータ１０４では、対象となるＵＲＬを絞ってフィルタリングすることができるため、計測結果のデータ量が削減され、ネットワークの負荷が軽減するとともに、解析サーバ１０２における解析処理の負荷も軽減することができる。
【０１１２】
つぎに、上記実施例の第３の変形例として、ＨＴＴＰのヘッダ部に含まれる情報を利用する場合について説明する。これは、ＨＴＴＰのリクエストのＲｅｆｅｒｅｒ属性を利用するもので、この属性には該ＵＲＬを呼び出しているＵＲＬの情報が、Ｗｅｂクライアントによって設定される。例えば、Ｗｅｂページの中で要求されるコンテンツのリクエストには、ページＵＲＬがこのＲｅｆｅｒｅｒ属性に設定されるというものである。この情報は全てのクライアントが必ず設定する必要はなく、計測対象とするクライアントによっては設定されていない場合もある。ここでは、設定されているものとして説明する。
【０１１３】
パッシブメータ１０４は、データ編集部４０４において計測結果を登録する時点で、リクエスト受信時のみリクエストのヘッダ部に含まれるＲｅｆｅｒｅｒ属性の情報を記録する。
【０１１４】
解析サーバ１０２では、計測データ収集部５０２において、アクティブメータ１０３からの結果を収集していない場合に、パッシブメータ１０４からの計測結果を受信すると、計測結果にＲｅｆｅｒ属性が含まれていれば、計測タスク識別子とそのＲｅｆｅｒｅｒ属性情報とがページＵＲＬと一致するかを判断し、一致する場合は、その計測タスク識別子に対応する計測結果データベース５０５のＵＲＬ７０２に追加し、計測結果を登録する。
【０１１５】
Ｗｅｂページを構成する全コンテンツの結果を収集したかどうかについては、その計測タスクについてパッシブメータ１０４からの計測結果が一定時間なかった場合に全結果を収集したとみなして、計測タスクを終了とする。終了した計測タスクについて解析部５０３に通知し、解析部５０３が計測結果を解析する。
【０１１６】
以上により、Ｒｅｆｅｒｅｒ属性を利用して、ＷｅｂページとＷｅｂページを構成するコンテンツとについての計測が可能となる。
【０１１７】
次に本発明の第２の実施例について説明する。本実施例では、２箇所以上に設置したパッシブメータでプロキシサーバ１０８等のゲートウェイを介したトラフィックにおける遅延時間を計測する場合について説明する。
【０１１８】
本実施例におけるネットワーク構成は、図１に示した構成と同様とする。ただし、クライアント側ネットワーク１１１のパッシブメータ１０４は、プロキシサーバ１０８よりもアクティブメータ１０３またはＷｅｂブラウザ等のＷｅｂクライアント側に配置されており、別パッシブメータ１０４は、バックボーンネットワーク１１０またはリバースプロキシ１０９よりもＷｅｂサーバ１０５側のサーバ側ネットワーク１１２に配置されているものとする。本実施例は、特に、クライアント側ネットワーク１１１に接続されたプロキシサーバ１０８、および、サーバ側ネットワーク１１２に接続されたリバースプロキシ１０９の処理を考慮した場合である。
【０１１９】
プロキシサーバ１０８は、アクティブメータやＷｅｂブラウザ等のクライアントからのリクエストを受信時、キャッシュにデータがあるかどうかを判断して、キャッシュにない場合は、バックボーンネットワーク１１０を介して、リバースプロキシ１０９にリクエストを転送する。
【０１２０】
まず、プロキシサーバ１０８は、リクエストをクライアントから受信した順序で転送し、また、リバースプロキシ１０９は、ＵＲＬを変換しない場合について、第１の実施例との相違点を中心に説明する。
【０１２１】
第１の実施例と同様に、計測設定サーバ１０１がパッシブメータ１０４に対して計測ルールを設定する。また、解析サーバ１０２に対しては、第１の実施例における解析ルールの内容に追加して、ネットワークを構成する中継装置（ここではプロキシサーバ１０６、リバースプロキシ１０９とする）のＩＰアドレス、ポート番号を含めて通知する。なお、中継装置のＩＰアドレス、ポート番号は既知であり、例えば、計測設定サーバ１０１があらかじめ保持しているものとする。
【０１２２】
パッシブメータ１０４は、各ＵＲＬへのリクエストとその応答について計測し、結果を解析サーバ１０２に送信する。
【０１２３】
解析サーバ１０２では、受信した解析ルールに、中継装置のＩＰアドレス等の情報が含まれている場合には、それらの情報もルールデータベース５０４に登録しておく。解析部５０３では、計測結果データベース５０６に記録された結果にもとづいて、本実施例の計測種別である遅延時間の算出を行う。
【０１２４】
遅延時間の算出では、まず、ルールデータベース５０４に登録された計測タスク識別子６０８からＵＲＬリスト識別子６１１を抽出する。そして、抽出したＵＲＬリスト識別子をキーにして、計測結果データベース５０５から対応するＨＴＴＰフロー情報を抽出する。これは、計測に用いた複数台のパッシブメータ１０４の計測結果である。解析部５０３は、ＵＲＬ毎に、各パッシブメータ１０４が計測したＨＴＴＰフローの情報を比較して、ＨＴＴＰフローの同定を行い、その時刻差から遅延時間を算出する。
【０１２５】
ここで、クライアント側ネットワーク１１１に配置されたパッシブメータ１０４からの計測結果では、プロキシサーバ１０８を経由するため（上述のように、本実施例では、クライアント側ネットワーク１１１のパッシブメータ１０４は、プロキシサーバ１０８よりもアクティブメータやＷｅｂブラウザ等のクライアント側に配置されている）、送信元は、クライアントのＩＰアドレスとポート番号、宛先がプロキシサーバ１０８のＩＰアドレス、ポート番号となっている。また、バックボーンネットワーク１１０に配置されたパッシブメータ１０４からの計測結果では、送信元がプロキシサーバ１０８のＩＰアドレス、ポート番号、宛先がサーバのＩＰアドレスとポート番号になっているので、同一のＨＴＴＰフローであっても両者は一致しない。
【０１２６】
そこで解析サーバ１０２では、ＨＴＴＰフローの同定には、ＵＲＬと時刻とを比較条件とする。解析部５０３では各パッシブメータ１０４から受信した計測結果のデータのＵＲＬ７０２を比較して同一のものを抽出する。同一のエントリが他にない場合は、同じＨＴＴＰフローと判断する。ＵＲＬ７０２が同一のエントリが複数ある場合には、リクエスト送信時刻７０８を参照して、各パッシブメータ１０４における送信されたリクエストの順番を判断し、同一のＨＴＴＰフローを識別する。
【０１２７】
同一のＨＴＴＰフローと判断したものについては、計測結果のリクエスト送信時刻７０８、または、最初のレスポンスパケットの受信時刻７０９、または、最後のレスポンスパケット７１０の受信時刻から差分を算出し、遅延時間とする。
【０１２８】
つぎに、中継装置によるリクエスト送信順の変更がある場合について説明する。この場合は、解析サーバ１０２が、プロキシサーバ１０８から中継についての情報を取得するようにする。
【０１２９】
プロキシサーバ１０８は、アクティブサーバ１０３やＷｅｂブラウザ等からリクエストを受信した際には、このリクエストの中継情報を記録し、定期的に解析サーバ１０２に送信するようにする。解析サーバ１０２は、パッシブメータ１０４等からの計測結果と同様に、計測データ収集部５０２で中継情報を受信して、計測結果データベース５０５に記録する。
【０１３０】
図１２は、計測結果データベース５０５が記録する中継情報のデータ構成の一例である。本図に示すように中継情報は、受信したリクエストから得られる情報としてＵＲＬ１２０１、リクエストの送信元ＩＰアドレス１２０２とポート番号１２０３、宛先ＩＰアドレス１２０４とポート番号１２０５、さらにリクエストを転送した場合は、転送したリクエストの情報として、転送先ＵＲＬ１２０６、転送元ＩＰアドレス１２０７とポート番号１２０８、転送先のＩＰアドレス１２０９とポート番号１２１０、リクエストを送信した時刻である転送時刻１２１１、キャッシュ状態１２１２から構成される。
【０１３１】
解析部５０３では、ＨＴＴＰフローの同定には、ＵＲＬと時刻とを比較条件とするが、プロキシサーバ１０８によってリクエストの送信順が変更されている場合には、同一のＵＲＬであるＨＴＴＰフローの識別ができない。
【０１３２】
そこで、中継情報を基に、ＩＰアドレス、ポート番号を読み替えて比較するものとする。クライアント側ネットワーク１１１のパッシブメータ１０４から得られた計測結果の対象となるＨＴＴＰフローについて、宛先がプロキシサーバ１０８の場合は、計測結果データベース５０５に登録されたプロキシサーバ１０８の中継情報を参照し、ＵＲＬ１２０１、送信元ＩＰアドレス１２０２、ポート番号１２０３が一致するものを抽出する。そして、計測結果の送信元ＩＰアドレス７０３、ポート番号７０４を、抽出した中継情報の転送元ＩＰアドレス１２０７、ポート番号１２０８に読み替え、宛先ＩＰアドレス７０５、ポート番号７０６を抽出した中継情報の転送先ＩＰアドレス１２０９、ポート番号１２１０に読み替えて、バックボーンネットワーク１１０とサーバ側ネットワーク１１１との中継地点付近に配置されたパッシブメータ１０４の計測結果と比較する。そして、ＵＲＬ、送信元、宛先のＩＰアドレス、ポート番号が全て一致するものを、同一のＨＴＴＰフローと判断し、遅延時間の算出を行う。
【０１３３】
また、プロキシサーバ１０８が、ＵＲＬが同じリクエストを、同一の転送先に、短時間に複数回転送する際に、同じポートを使用して送信すると、バックボーンネットワーク１１０での計測結果に、ＵＲＬ、ＩＰアドレス、ポート番号が一致する計測結果が複数存在することになる。
【０１３４】
この場合には、プロキシサーバ１０８の中継情報の転送時刻から、リクエストの順番を判断し、同一のＨＴＴＰフローを識別するようにする。
【０１３５】
つぎに、中継装置でＵＲＬの変換が行われる場合について説明する。
【０１３６】
クライアント側ネットワーク１１１のパッシブメータ１０４は、プロキシサーバ１０８よりもアクティブメータ１０３等のクライアント側に配置されており、サーバ側ネットワーク１１２のパッシブメータ１０４は、リバースプロキシ１０９よりもＷｅｂサーバ１０５側に配置されているものとする。
【０１３７】
サーバ側ネットワーク１１２には複数のサーバが存在し、リバースプロキシ１０９は各サーバに対してリクエストを転送し、その際、必要に応じてＵＲＬの変更を行うものとする。
【０１３８】
ここで、クライアント側ネットワーク１１１のパッシブメータ１０４からの計測結果では、プロキシサーバ１０８を経由しているため、宛先がプロキシサーバ１０８のＩＰアドレス、ポート番号となっている。またサーバ側ネットワーク１１２のパッシブメータ１０４からの計測結果では、リバースプロキシ１０９を経由しているため、送信元がリバースプロキシ１０９のＩＰアドレス、ポート番号になっている。さらにＵＲＬについても、サーバ側ネットワーク１１１でのＵＲＬと外部に公開するＵＲＬとを変えている場合は、リバースプロキシ１０９でＵＲＬの変換が行われるため、ＵＲＬが異なっている。
【０１３９】
この場合、解析サーバ１０２は、プロキシサーバ１０８とリバースプロキシ１０９とから中継についての情報を取得するようにする。
【０１４０】
リバースプロキシ１０９は、上述の中継装置によるリクエスト送信順の変更がある場合におけるプロキシサーバ１０８と同様に、リクエストを受信した際に、このリクエストの中継情報を記録し、定期的に解析サーバ１０２に送信するようにする。解析サーバ１０２は、計測データ収集部５０２で中継情報を受信して、計測結果データベース５０５に記録する。中継情報のデータ構成は、図１２と同様とすることができる。
【０１４１】
解析サーバ１０２では、プロキシサーバ１０８およびリバースプロキシ１０９からの中継情報を利用して、計測結果のＵＲＬ、ＩＰアドレス、ポート番号を読み替えて比較し、ＨＴＴＰフローの同定を行う。
【０１４２】
解析部５０３では、クライアント側ネットワーク１１１のパッシブメータ１０４で計測された解析の対象となるＨＴＴＰフローを抽出し、宛先がプロキシサーバ１０８の場合は、計測結果データベース５０５に登録されたこのプロキシサーバ１０８の中継情報を参照して、ＵＲＬ１２０１、送信元ＩＰアドレス１２０２、ポート番号１２０３の一致するエントリを検索する。
【０１４３】
条件が一致するエントリがあり、他に一致するエントリがない場合には、その中継情報を抽出し、計測結果の送信元ＩＰアドレス７０３、ポート番号７０４を抽出した中継情報の転送元ＩＰアドレス１２０７、ポート番号１２０８に読み替え、宛先ＩＰアドレス７０５、ポート番号７０６を抽出した中継情報の転送先ＩＰアドレス１２０９、ポート番号１２１０に読み替える。ＵＲＬ７０２についても転送先ＵＲＬ１２０６に読み替える。
【０１４４】
さらに、転送先がリバースプロキシ１０９の場合には、リバースプロキシ１０９の中継情報を参照して、ＵＲＬ、送信元ＩＰアドレス、ポート番号が一致するエントリを検索する。
【０１４５】
条件が一致するエントリがあり、他に一致するエントリがない場合には、その中継情報を抽出し、計測結果の送信元ＩＰアドレス７０３、ポート番号７０４を抽出した中継情報の転送元ＩＰアドレス、ポート番号に読み替え、宛先ＩＰアドレス７０５、ポート番号７０６を抽出した中継情報の転送先ＩＰアドレス、ポート番号に読み替える。ＵＲＬ７０２についても転送先ＵＲＬに読み替える。
【０１４６】
転送先ＩＰアドレスが、プロキシサーバ１０８等のＩＰアドレスに一致しない場合には、転送先がＷｅｂサーバ１０５であると判断し、アドレス等の読み替えを終了する。
【０１４７】
この読み替えた情報とサーバ側ネットワーク１１２のパッシブメータ１０４で計測したＨＴＴＰフローとを比較して、送信元、宛先ＩＰアドレスとポート番号、ＵＲＬがすべて一致する情報を抽出する。さらに、条件の一致する他のフローがないことを確認して、同一のＨＴＴＰフローと判断する。
【０１４８】
条件の一致するＨＴＴＰフローが複数ある場合は、リバースプロキシ１０９の中継情報の転送時刻に基づいてリクエストの順番を判断し、同一のＨＴＴＰフローを識別するようにする。
【０１４９】
同一のＨＴＴＰフローと判断したものについては、計測結果のリクエスト送信時刻、または最初のレスポンスパケットの受信時刻、または最後のレスポンスパケットの受信時刻から差分を算出し、遅延時間とする。
【０１５０】
また、キャッシュ機能を有するプロキシサーバ１０８、リバースプロキシ１０９では、解析サーバ１０２に送信する中継情報にキャッシュ状態１２１２を記録する。キャッシュ状態１２１２には、プロキシサーバ１０８等がリクエストを中継する際、以前の応答の内容を保持しており、リクエストを転送せず、応答を作成してクライアントに送信する場合に“ＨＩＴ”を記録し、以前の応答の内容を保持しておらず、リクエストを転送する場合に“ＭＩＳＳ”を記録する。
【０１５１】
解析サーバ１０２の解析部５０３では、ＨＴＴＰフローの同定のために、計測結果データベース５０５の中継情報を参照する際に、キャッシュ状態１２１２を参照する。
【０１５２】
“ＭＩＳＳ”が記録されている場合は、リクエストが転送されているため、転送先アドレスに変換して、上述の処理を継続する。
【０１５３】
一方、“ＨＩＴ”が記録されている場合は、リクエストが転送されておらず、パッシブメータ１０４からの計測結果には、一致するＨＴＴＰフローはないと判断する。そして、ＨＴＴＰフローの同定のためのアドレス変換処理を中止し、このＨＴＴＰフローの遅延時間は“なし”として解析処理を終了する。
【０１５４】
以上により、プロキシサーバ１０８、リバースプロキシ１０９を経由するＨＴＴＰのトラフィックについても複数箇所でのパッシブメータ１０４の計測結果からＨＴＴＰフローの同定を行って、遅延時間を算出することが可能となる。
【０１５５】
【発明の効果】
以上説明したように、本発明によれば、アクティブ型の計測装置とパッシブ型の計測装置とを協働させて、Ｗｅｂページの構成を考慮した柔軟な計測を行なえる計測システムが提供される。さらに、本発明によれば、中継装置を介したＷｅｂトラフィックについてもコンテンツ単位でのＨＴＴＰフローの同定が可能となり、柔軟な計測を行なえるコンテンツ計測システムが提供される。
【図面の簡単な説明】
【図１】 本発明の第１の実施例におけるネットワークシステム構成図である。
【図２】 本発明の第１の実施例における計測設定サーバの機能構成図である。
【図３】 本発明の第１の実施例におけるアクティブメータの機能構成図である。
【図４】 本発明の第１の実施例におけるパッシブメータの機能構成図である。
【図５】 本発明の第１の実施例における解析サーバの機能構成図である。
【図６】 発明の第１の実施例における解析サーバがルールデータベースに保存するルールデータの一実施構成を表す図である。
【図７】 本発明の第１の実施例における解析サーバが計測結果データベースに保存する計測結果データの一実施構成を表す図である。
【図８】 本発明の第１の実施例における解析サーバの計測データ収集時のフローチャートである。
【図９】 本発明の第１の実施例におけるシステムのシーケンス図である。
【図１０】 本発明の第１実施例の第１の変形例におけるシステムのシーケンス図である。
【図１１】 本発明の第１実施例の第２の変形例におけるシステムのシーケンス図である。
【図１２】 本発明の第２の実施例における解析サーバが計測結果データベースに保存する中継情報データの一実施構成を表す図である。
【符号の説明】
１０１…計測設定サーバ、１０２…解析サーバ、１０３…アクティブメータ、１０４…パッシブメータ、１０５…サーバコンピュータ、１０６…ネットワーク装置、１０７…端末装置、１０８…プロキシサーバ、１０９…リバースプロキシ、１１０…バックボーンネットワーク、１１１…クライアント側ネットワーク、１１２…サーバ側ネットワーク
Claims (7)
- ネットワークを流れるパケットを受信して、設定された計測ルールに基づく計測を行なう１または複数台のパッシブ型計測装置と、
設定された計測ルールに従って、コンテンツ提供サーバに対して計測用リクエストを送信し、その応答に基づいて計測対象となるコンテンツに関する情報を取得するアクティブ型計測装置と、
前記パッシブ型計測装置の計測結果のうち、前記アクティブ型計測装置が取得した情報に対応する計測結果を用いて、設定された解析ルールに基づく算出を行なうことで、コンテンツ提供に関する特性を導出する解析装置と
を備えることを特徴とする計測システム。 - ネットワークを流れるパケットを受信して、設定された計測ルールに基づく計測を行なう１または複数台のパッシブ型計測装置と、
設定された計測ルールに従って、コンテンツ提供サーバに対して計測用リクエストを送信し、その応答に基づいて計測対象となるコンテンツに関する情報を取得するアクティブ型計測装置と、
前記パッシブ型計測装置の計測結果のうち、前記アクティブ型計測装置が取得した情報に対応する計測結果に基づいて、設定された解析ルールに基づく算出を行なうことで、コンテンツ提供に関する特性を導出する解析装置とを備え、
前記アクティブ型計測装置は、
前記設定された計測ルールおよび取得した情報に基づいて、前記パッシブ型計測装置に計測ルールを設定し、
前記設定された計測ルールに基づいて、前記解析装置に解析ルールを設定することを特徴とする計測システム。 - ネットワークを流れるパケットを受信して、設定された計測ルールに基づく計測を行なう１または複数台のパッシブ型計測装置と、
設定された計測ルールに従って、コンテンツ提供サーバに対して計測用リクエストを送信し、その応答に基づいて計測対象となるコンテンツに関する情報を取得するアクティブ型計測装置と、
前記パッシブ型計測装置の計測結果のうち、前記アクティブ型計測装置が取得した情報に対応する計測結果に基づいて、設定された解析ルールに基づく算出を行なうことで、コンテンツ提供に関する特性を導出する解析装置と、
受け付けた計測要求に基づいて、前記アクティブ型計測装置に計測ルールを設定する計測設定装置とを備え、
前記計測設定装置は、
前記計測要求および前記アクティブ型計測装置が取得した情報に基づいて、前記パッシブ型計測装置に計測ルールを設定し、前記解析装置に解析ルールを設定することを特徴とする計測システム。 - 請求項１〜３のいずれか一項に記載の計測システムにおいて、
前記アクティブ型計測装置がコンテンツ提供サーバに対して送信する計測用リクエストは、所定の属性についての情報を含むものであり、
前記パッシブ型計測装置は、リクエストに含まれる属性の情報を記録し、
前記解析装置は、前記パッシブ型計測装置の計測結果に前記属性が含まれていれば、その属性の情報を参照して、コンテンツ提供に関する特性を導出することを特徴とする計測システム。 - 請求項１に記載の計測システムにおいて、
受け付けた計測要求に基づいて、前記パッシブ型計測装置およびアクティブ型計測装置に計測ルールを設定し、前記解析装置に解析ルールを設定する計測設定装置をさらに備えたことを特徴とする計測システム。 - 請求項１〜５のいずれか一項に記載の計測システムにおいて、
前記アクティブ型計測装置が取得するコンテンツに関する情報は、コンテンツのＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）のリストを生成するための情報であることを特徴とする計測システム。 - 請求項１記載の計測システムであって、
前記アクティブ型計測装置とコンテンツ提供サーバ間に設けられ、通信に関する情報を変換して中継する中継装置、をさらに有し、
前記解析装置は、
前記中継装置から取得した通信に関する情報の変換情報と、パッシブ型計測装置から収集した計測結果とから、関連するパケットの集合体であるフローを同定し、ネットワークのトラフィック特性を導出することを特徴とする計測システム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003147802A JP4276895B2 (ja) | 2003-05-26 | 2003-05-26 | 計測システム |
| US10/853,158 US20050044213A1 (en) | 2003-05-26 | 2004-05-26 | Network traffic measurement system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003147802A JP4276895B2 (ja) | 2003-05-26 | 2003-05-26 | 計測システム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004348648A JP2004348648A (ja) | 2004-12-09 |
| JP4276895B2 true JP4276895B2 (ja) | 2009-06-10 |
Family
ID=33534234
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003147802A Expired - Fee Related JP4276895B2 (ja) | 2003-05-26 | 2003-05-26 | 計測システム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US20050044213A1 (ja) |
| JP (1) | JP4276895B2 (ja) |
Families Citing this family (60)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7343413B2 (en) | 2000-03-21 | 2008-03-11 | F5 Networks, Inc. | Method and system for optimizing a network by independently scaling control segments and data flow |
| US7409439B2 (en) * | 2002-12-09 | 2008-08-05 | Sun Microsystems Inc. | Reducing overhead in reverse proxy servers when processing web pages |
| US7466654B1 (en) * | 2005-05-24 | 2008-12-16 | The United States Of America As Represented By The Director, National Security Agency | Method of detecting intermediary communication device |
| JP4881610B2 (ja) * | 2005-11-30 | 2012-02-22 | 株式会社日立製作所 | 測定システム及び管理装置及びその処理分散方法 |
| US7953020B2 (en) * | 2006-05-22 | 2011-05-31 | At&T Intellectual Property Ii, L.P. | Method for implementing and reporting one-way network measurements |
| US8055461B2 (en) * | 2006-09-15 | 2011-11-08 | Itron, Inc. | Distributing metering responses for load balancing an AMR network |
| US9021082B2 (en) * | 2008-01-30 | 2015-04-28 | Case Western Reserve University | Internet measurement system application programming interface |
| US8806053B1 (en) | 2008-04-29 | 2014-08-12 | F5 Networks, Inc. | Methods and systems for optimizing network traffic using preemptive acknowledgment signals |
| JP5253949B2 (ja) * | 2008-09-26 | 2013-07-31 | ブラザー工業株式会社 | 通信装置、および通信プログラム |
| US8730819B2 (en) * | 2009-10-14 | 2014-05-20 | Cisco Teechnology, Inc. | Flexible network measurement |
| US8868961B1 (en) | 2009-11-06 | 2014-10-21 | F5 Networks, Inc. | Methods for acquiring hyper transport timing and devices thereof |
| US10721269B1 (en) | 2009-11-06 | 2020-07-21 | F5 Networks, Inc. | Methods and system for returning requests with javascript for clients before passing a request to a server |
| US9141625B1 (en) | 2010-06-22 | 2015-09-22 | F5 Networks, Inc. | Methods for preserving flow state during virtual machine migration and devices thereof |
| US10015286B1 (en) | 2010-06-23 | 2018-07-03 | F5 Networks, Inc. | System and method for proxying HTTP single sign on across network domains |
| US8908545B1 (en) | 2010-07-08 | 2014-12-09 | F5 Networks, Inc. | System and method for handling TCP performance in network access with driver initiated application tunnel |
| US8347100B1 (en) | 2010-07-14 | 2013-01-01 | F5 Networks, Inc. | Methods for DNSSEC proxying and deployment amelioration and systems thereof |
| US9083760B1 (en) | 2010-08-09 | 2015-07-14 | F5 Networks, Inc. | Dynamic cloning and reservation of detached idle connections |
| US8886981B1 (en) | 2010-09-15 | 2014-11-11 | F5 Networks, Inc. | Systems and methods for idle driven scheduling |
| US8804504B1 (en) | 2010-09-16 | 2014-08-12 | F5 Networks, Inc. | System and method for reducing CPU load in processing PPP packets on a SSL-VPN tunneling device |
| US8959571B2 (en) | 2010-10-29 | 2015-02-17 | F5 Networks, Inc. | Automated policy builder |
| WO2012058643A2 (en) | 2010-10-29 | 2012-05-03 | F5 Networks, Inc. | System and method for on the fly protocol conversion in obtaining policy enforcement information |
| US10135831B2 (en) | 2011-01-28 | 2018-11-20 | F5 Networks, Inc. | System and method for combining an access control system with a traffic management system |
| US9246819B1 (en) | 2011-06-20 | 2016-01-26 | F5 Networks, Inc. | System and method for performing message-based load balancing |
| US9270766B2 (en) | 2011-12-30 | 2016-02-23 | F5 Networks, Inc. | Methods for identifying network traffic characteristics to correlate and manage one or more subsequent flows and devices thereof |
| US10230566B1 (en) | 2012-02-17 | 2019-03-12 | F5 Networks, Inc. | Methods for dynamically constructing a service principal name and devices thereof |
| US9172753B1 (en) | 2012-02-20 | 2015-10-27 | F5 Networks, Inc. | Methods for optimizing HTTP header based authentication and devices thereof |
| US9231879B1 (en) | 2012-02-20 | 2016-01-05 | F5 Networks, Inc. | Methods for policy-based network traffic queue management and devices thereof |
| EP2853074B1 (en) | 2012-04-27 | 2021-03-24 | F5 Networks, Inc | Methods for optimizing service of content requests and devices thereof |
| US9608886B2 (en) | 2012-08-26 | 2017-03-28 | At&T Intellectual Property I, L.P. | Methods, systems, and products for monitoring domain name servers |
| US8706874B2 (en) * | 2012-08-27 | 2014-04-22 | Nvidia Corporation | Remote configuration of a hardware setting on one or more target computing device(s) |
| US10375155B1 (en) | 2013-02-19 | 2019-08-06 | F5 Networks, Inc. | System and method for achieving hardware acceleration for asymmetric flow connections |
| CN104077341B (zh) * | 2013-07-19 | 2016-04-20 | 腾讯科技（北京）有限公司 | 即时通讯中生成关键词自动回复映射关系的方法和装置 |
| CN104298416B (zh) * | 2013-07-19 | 2019-01-29 | 腾讯科技（北京）有限公司 | 即时通讯中自动回复消息的生成方法和装置 |
| US10187317B1 (en) | 2013-11-15 | 2019-01-22 | F5 Networks, Inc. | Methods for traffic rate control and devices thereof |
| US10015143B1 (en) | 2014-06-05 | 2018-07-03 | F5 Networks, Inc. | Methods for securing one or more license entitlement grants and devices thereof |
| US11838851B1 (en) | 2014-07-15 | 2023-12-05 | F5, Inc. | Methods for managing L7 traffic classification and devices thereof |
| US10122630B1 (en) | 2014-08-15 | 2018-11-06 | F5 Networks, Inc. | Methods for network traffic presteering and devices thereof |
| US10182013B1 (en) | 2014-12-01 | 2019-01-15 | F5 Networks, Inc. | Methods for managing progressive image delivery and devices thereof |
| JP6460765B2 (ja) * | 2014-12-09 | 2019-01-30 | キヤノン株式会社 | 情報処理装置、情報処理装置の制御方法、プログラム |
| US11895138B1 (en) | 2015-02-02 | 2024-02-06 | F5, Inc. | Methods for improving web scanner accuracy and devices thereof |
| US10834065B1 (en) | 2015-03-31 | 2020-11-10 | F5 Networks, Inc. | Methods for SSL protected NTLM re-authentication and devices thereof |
| US11350254B1 (en) | 2015-05-05 | 2022-05-31 | F5, Inc. | Methods for enforcing compliance policies and devices thereof |
| US10505818B1 (en) | 2015-05-05 | 2019-12-10 | F5 Networks. Inc. | Methods for analyzing and load balancing based on server health and devices thereof |
| US9923912B2 (en) * | 2015-08-28 | 2018-03-20 | Cisco Technology, Inc. | Learning detector of malicious network traffic from weak labels |
| US11757946B1 (en) | 2015-12-22 | 2023-09-12 | F5, Inc. | Methods for analyzing network traffic and enforcing network policies and devices thereof |
| US10404698B1 (en) | 2016-01-15 | 2019-09-03 | F5 Networks, Inc. | Methods for adaptive organization of web application access points in webtops and devices thereof |
| US11178150B1 (en) | 2016-01-20 | 2021-11-16 | F5 Networks, Inc. | Methods for enforcing access control list based on managed application and devices thereof |
| US10797888B1 (en) | 2016-01-20 | 2020-10-06 | F5 Networks, Inc. | Methods for secured SCEP enrollment for client devices and devices thereof |
| US10791088B1 (en) | 2016-06-17 | 2020-09-29 | F5 Networks, Inc. | Methods for disaggregating subscribers via DHCP address translation and devices thereof |
| US11063758B1 (en) | 2016-11-01 | 2021-07-13 | F5 Networks, Inc. | Methods for facilitating cipher selection and devices thereof |
| US10505792B1 (en) | 2016-11-02 | 2019-12-10 | F5 Networks, Inc. | Methods for facilitating network traffic analytics and devices thereof |
| US10785144B2 (en) * | 2016-12-30 | 2020-09-22 | Equinix, Inc. | Latency equalization |
| US10432733B2 (en) * | 2017-03-03 | 2019-10-01 | Blackberry Limited | Devices and methods for managing a network communication channel between an electronic device and an enterprise entity |
| US10812266B1 (en) | 2017-03-17 | 2020-10-20 | F5 Networks, Inc. | Methods for managing security tokens based on security violations and devices thereof |
| US10972453B1 (en) | 2017-05-03 | 2021-04-06 | F5 Networks, Inc. | Methods for token refreshment based on single sign-on (SSO) for federated identity environments and devices thereof |
| US11343237B1 (en) | 2017-05-12 | 2022-05-24 | F5, Inc. | Methods for managing a federated identity environment using security and access control data and devices thereof |
| US11122042B1 (en) | 2017-05-12 | 2021-09-14 | F5 Networks, Inc. | Methods for dynamically managing user access control and devices thereof |
| US10860703B1 (en) * | 2017-08-17 | 2020-12-08 | Walgreen Co. | Online authentication and security management using device-based identification |
| US11122083B1 (en) | 2017-09-08 | 2021-09-14 | F5 Networks, Inc. | Methods for managing network connections based on DNS data and network policies and devices thereof |
| US11044200B1 (en) | 2018-07-06 | 2021-06-22 | F5 Networks, Inc. | Methods for service stitching using a packet header and devices thereof |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6006260A (en) * | 1997-06-03 | 1999-12-21 | Keynote Systems, Inc. | Method and apparatus for evalutating service to a user over the internet |
| US6449739B1 (en) * | 1999-09-01 | 2002-09-10 | Mercury Interactive Corporation | Post-deployment monitoring of server performance |
| AU2001253176A1 (en) * | 2000-04-06 | 2001-10-23 | Predictive Systems, Inc. | Method and system for website content integrity |
| US7555542B1 (en) * | 2000-05-22 | 2009-06-30 | Internap Network Services Corporation | Method and system for directing requests for content to a content server based on network performance |
| US7016953B2 (en) * | 2000-10-03 | 2006-03-21 | Sun Microsystems, Inc. | HTTP transaction monitor |
| JP2002281086A (ja) * | 2001-03-19 | 2002-09-27 | Kddi Corp | トラヒック監視方法およびシステム |
| US7231555B2 (en) * | 2002-08-22 | 2007-06-12 | Agilent Technologies, Inc. | Method and apparatus to coordinate groups of heterogeneous measurements |
| US7257105B2 (en) * | 2002-10-03 | 2007-08-14 | Cisco Technology, Inc. | L2 method for a wireless station to locate and associate with a wireless network in communication with a Mobile IP agent |
-
2003
- 2003-05-26 JP JP2003147802A patent/JP4276895B2/ja not_active Expired - Fee Related
-
2004
- 2004-05-26 US US10/853,158 patent/US20050044213A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| US20050044213A1 (en) | 2005-02-24 |
| JP2004348648A (ja) | 2004-12-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4276895B2 (ja) | 計測システム | |
| US10027564B2 (en) | Unobtrusive methods and systems for collecting information transmitted over a network | |
| US7277914B2 (en) | Proxy server apparatus and method for providing service using the same | |
| JP4965559B2 (ja) | リソースアドレスリクエスト管理方法及び関連するゲートウェイ装置 | |
| US20090248803A1 (en) | Apparatus and method of analyzing service processing status | |
| US20130007274A1 (en) | Method for Analyzing Browsing and Device for Implementing the Method | |
| WO2015024490A1 (en) | Monitoring nat behaviors through uri dereferences in web browsers | |
| US20110302272A1 (en) | Unobtrusive methods and systems for collecting information transmitted over a network | |
| JP2009140290A (ja) | コンテンツ中継装置、コンテンツ中継システム及びコンテンツ中継方法並びにプログラム | |
| JP5593944B2 (ja) | 判定装置、判定方法及びコンピュータプログラム | |
| KR20110057529A (ko) | 더미요청 태그를 이용한 서버의 응답시간 측정 시스템 및 그 방법 | |
| US10164819B2 (en) | Correlating web traffic events to a web page session | |
| JP5543896B2 (ja) | 仲介サーバと、その仲介サーバによるアクセス解析方法とプログラム | |
| JP2001134544A (ja) | 共通ログ生成方法及び共通ログ分析方法 | |
| JP2006221327A (ja) | 計算機システムおよびストレージ装置 | |
| JP5061372B2 (ja) | ウェブ検索システム、ウェブ検索方法、およびウェブ検索プログラム | |
| JP3908627B2 (ja) | Ｗｅｂページ転送時間推定装置、Ｗｅｂページ転送時間推定プログラム及びＷｅｂページ転送時間推定プログラムを記録したコンピュータ読み取り可能な記録媒体 | |
| JP5396974B2 (ja) | 通信システム、通信装置および通信管理方法 | |
| JP2003140990A (ja) | Ｗｅｂアクセスログ収集システム | |
| JP5851251B2 (ja) | 通信パケット保存装置 | |
| JP3590357B2 (ja) | Ｈｔｔｐサーバ性能データ収集方法及びそのシステム | |
| JP4905388B2 (ja) | データ中継装置、データ中継方法およびデータ中継処理プログラム | |
| JP5993819B2 (ja) | Ｗｅｂ通信構造分析装置及び方法 | |
| TW595158B (en) | Method and system for blocking networked limitative information | |
| US20020046252A1 (en) | Repeater equipment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20051117 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20051117 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20051117 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20060818 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20081125 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090130 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20090224 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090309 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120313 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120313 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130313 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130313 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |