(57)【特許請求の範囲】
【請求項１】
インターネットのWebサイトにアクセスしたときに発生するトラヒックにおける通信構造を分析するWeb通信構造分析装置であって、
前記インターネットに接続されているサイト情報データベースにアクセスしてサイトのURLリストを取得する評価URLリスト取得手段と、
前記URLリストに含まれている各URLに係る各サイトから通信特性情報を取得する通信特性情報取得手段と、
前記インターネットに接続されている位置情報データベースから、前記各サイトを構成する各オブジェクトの配信元の位置情報を取得する位置情報取得手段と、
前記通信特性情報取得手段で取得した前記通信特性情報から分析に必要となるデータを抽出するデータ抽出手段と、
前記データ抽出手段で抽出された前記データをURLのカテゴリに応じて分類するカテゴリ別分類手段と、
前記カテゴリ別分類手段でURLカテゴリに分類されたデータに基づいて、前記各サイトからの１つのWebページ取得時において通信した前記配信元の数、前記各サイトを構成するオブジェクトの配信元の前記位置情報が示す位置と当該Web通信構造分析装置の位置とのユークリッド距離、前記各サイトを構成するオブジェクトの取得に要した時間の少なくとも１つの平均値又は累積分布を前記URLカテゴリごとに算出し、統計データベースに格納する統計データ算出手段と、
を有することを特徴とするWeb通信構造分析装置。
【請求項２】
前記通信特性情報取得手段は、
前記URLリストに基づいて、バッチ処理で通信特性情報取得要求を前記サイトに送信する手段を含む
請求項１記載のWeb通信構造分析装置。
【請求項３】
前記位置情報取得手段は、
前記位置情報として、URLに対応する前記配信元の存在する国名、都市、位置座標を取得する手段を含む
請求項１記載のWeb通信構造分析装置。
【請求項４】
インターネットのWebサイトにアクセスしたときに発生するトラヒックにおける通信構造を分析するWeb通信構造分析装置が、
評価URLリスト取得手段、通信特性情報取得手段、位置情報取得手段、データ抽出手段、カテゴリ別分類手段、統計データ算出手段、統計データベースと、を有する装置において、
前記評価URLリスト取得手段が、前記インターネットに接続されているサイト情報データベースにアクセスしてサイトのURLリストを取得する評価URLリスト取得ステップと、
前記通信特性情報取得手段が、前記URLリストに含まれている各URLに係る各サイトから通信特性情報を取得する通信特性情報取得ステップと、
前記位置情報取得手段が、前記インターネットに接続されている位置情報データベースから、前記各サイトを構成する各オブジェクトの配信元の位置情報を取得する位置情報取得ステップと、
前記データ抽出手段が、前記通信特性情報取得ステップで取得した前記通信特性情報から分析に必要となるデータを抽出するデータ抽出ステップと、
前記カテゴリ別分類手段が、前記データ抽出ステップで抽出された前記データをURLのカテゴリに応じて分類するカテゴリ別分類ステップと、
前記統計データ算出手段が、前記カテゴリ別分類ステップでURLカテゴリに分類されたデータに基づいて、前記各サイトからの１つのWebページ取得時において通信した前記配信元の数、前記各サイトを構成するオブジェクトの配信元の前記位置情報が示す位置と当該Web通信構造分析装置の位置とのユークリッド距離、前記各サイトを構成するオブジェクトの取得に要した時間の少なくとも１つの平均値又は累積分布を前記URLカテゴリごとに算出し、前記統計データベースに格納する統計データ算出ステップと、
を行うことを特徴とするWeb通信構造分析方法。
【請求項５】
前記通信特性情報取得ステップにおいて、
前記URLリストに基づいて、バッチ処理で通信特性情報取得要求を前記サイトに送信する
請求項４記載のWeb通信構造分析方法。
【請求項６】
前記位置情報取得ステップにおいて、
前記位置情報として、URLに対応する前記配信元の存在する国名、都市、位置座標を取得する
請求項４記載のWeb通信構造分析方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Web通信構造分析装置及び方法に係り、特に、インターネットに接続された測定用パーソナルコンピュータ（以下「PC」と記す）において計測し、通信距離や遅延時間等の様々な通信構造を分析するためのWeb通信構造分析装置及び方法に関する。
【背景技術】
【０００２】
近年、インターネットのトラヒックの多くの部分を、Ｗｅｂサービスで用いられるHTTP(Hypertext Transfer Protocol)トラヒックが占めている。例えば、2006年〜2008年の間に日米間のバックボーンリンクで測定されたトラヒックの分析によると、HTTPパケットが約60%を占めている。Webサービスがインターネットの主流サービスであることから、Webトラヒックを適切に制御することが、ユーザの体感品質を向上させ、ネットワーク資源の消費量を抑えるためには重要である。
【０００３】
従来のＷｅｂサイトは静的なテキストや画像といったオブジェクトがサーバに用意され、ＷｅｂブラウザはHTTPを用いてこれら静的オブジェクトを単にダウンロードして表示していた。しかし、近年、クライアントPCからのリクエスト受信時に、サーブレットやJSP(Java Server Pages)のプログラムをサーバ側で実行するか、HTML（Hyper Text Markup Language）の中に埋め込まれたAJAX(Asynchronous Java Script)(登録商標)やDOM(Document Object Model)(登録商標)といったJavaScript（登録商標）をクライアントPC側で実行することで生成される動的オブジェクトの割合が増加している。また、広告を専用のサーバから取得するなど、各オブジェクトの配信元が多元化している。このように一つのＷｅｂサイトを構成するオブジェクトは複雑性を増している。
【０００４】
一方で、67%のユーザは毎週のようにＷｅｂ閲覧時の待ち時間の長さを感じており、17%のユーザはWeb閲覧時に最大でも５秒しか待てないという報告がなされており、複雑性を増すWebトラヒックをいかにして効率的に配信するかが重要な課題となっている。
【０００５】
Webトラヒックを効率的に配信し、ユーザのレスポンス時間を低減する技術として、多数のネットワークに分散配置された多数のキャッシュサーバを用いてWebサイトのオブジェクトを配信するCDN(Contents Delivery Network)が一般的である。現在では、74%のアクセス数上位1,000のサイトがCDNを利用している。CDNは主にAkamai（登録商標）等の大規模コンンテンツプロバイダや、AT&T（登録商標）等のTier-1 ISP(Internet Service Provider)が自身でCDNを運用するケースも増えてきている。キャッシュを用いたオブジェクト配信を行う際には、各オブジェクトをコピーするキャッシュサーバの選択や、キャッシュの容量が不足した場合の削除オブジェクトの選択を適切に行う必要がある。
【０００６】
そのためCDNにおいて、ネットワーク上に分散配置されたキャッシュサーバへオブジェクトを展開する様々な方式が検討されている。最も一般的な方法では、配信要求を受けたキャッシュサーバが要求オブジェクトを保有していない場合（キャッシュミス）に、オリジナルサーバからオブジェクトを取得して自身にキャッシュする。また、キャッシュ容量が不足する場合には、LFU(Least Frequency Used:最もアクセス頻度の低いものを削除)や、LRU(Least Recently Used:最後に要求のあった時点からの経過時間が最大のものを削除)といった置換アルゴリズムを行うアプローチ以外に、各オブジェクトの配置位置を能動的に決めるアプローチ（RPA: Replica Placement Algorithm）も検討されている。例えば、各キャッシュが自立的に各コンテンツの人気度を測定し人気度の高いコンテンツを優先的にキャッシュする方法や、キャッシュ間で保有コンテンツに関する情報を交換してコンテンツ転送に要する総コストが最小となるコンンテンツ配置を貪欲算法で求める方法が提案されている。また、受動的な方法と能動的な方法を組み合わせてキャッシュを展開する方式も提案されている（例えば、非特許文献１参照）。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】M.Butkiewicz, H. V. Madhyastha, and V. Sekar, Understanding Website complexity: Measurements, Metrics, and Implications, ACM IMC 2011.
【発明の概要】
【発明が解決しようとする課題】
【０００８】
jpeg(Joint Photographic Experts Group)、javascript(登録商標)といったオブジェクトの種別や、"Sports"、"Business"といったWebサイトの種類によって、配信要求の発生パターンが異なることが予想されるため、複雑性を増すWebサイトの閲覧に際しては、オブジェクト種別やURLカテゴリの違いを意識したキャッシュ制御を行うことが有効と思われる。しかしながら、上記従来の方式では、オブジェクト種別やURLカテゴリ間でのキャッシュ位置に関する差別化が考慮されていない。
【０００９】
HTTPのトラヒックの分析手法としては、アクティブ測定によるものとパッシブ測定によるものがある。
【００１０】
アクティブ測定は、測定用クライアントPC上でWeb閲覧を行い、発生するHTTPに関するデータを収集する。メリットとしては、計測地点を増やすことで、クライアント位置についての多様な分析が可能なことや、網羅的に多種多様なサイトに対しての評価が可能な点が挙げられる。しかし、デメリットとして、実際のユーザの利用傾向を分析することが困難なことが挙げられる。
【００１１】
一方、パッシブ測定は、ネットワークを流れるトラヒックをキャプチャして、各Web閲覧におけるトラヒックを分離して分析する。実際のユーザの利用傾向を分析可能であることがメリットであるが、反面、パケットをキャプチャできる場所は限られるため、クライアントの位置についての多様な分析が困難なことがデメリットである。
【００１２】
アクティブ測定によるWebトラヒック分析に関する研究としては、Baeza-Yatesらの、２００４年前後に１２カ国で実施したWebクローリングの測定結果から、国ごとのWeb閲覧トラヒックのサイズ、接続グラフの次数等の各種傾向を比較した研究や、Butkiewiczらの、ランダムに選択したWebサイトを９週間にわたり周期的にアクセスし、構成オブジェクト数やアクセスサーバ数等の指標について分析した研究が見られる。
【００１３】
一方、パッシブ測定によるWebトラヒック分析に関する研究としては、Ihmらの、２００６年〜２０１０年の５年間にわたるWebのproxy access logを用いてWebトラヒックの各種指標の変移を分析した研究や、Bentらの、２００４年の１日のパケットキャプチャデータから、WebサイトのCookiee利用頻度等について分析した研究が見られる。また、Gillらは、企業や大学からのWebアクセストラヒックを分析し、Webサービスの利用傾向について明らかにしており、AgerらはCDNやデータセンタ上のコンテンツ配置や、配信元サーバの選択がどのように行われているかを、DNS(Domain Name System)に関する制御パケットの測定と、BGP(Border Gateway Protocol)ルーティングテーブルのスナップショットに基づき識別することを検討している。また、Schneiderらは、パケットキャプチャデータからHTTPやAJAXセッションを抽出し、生成されるトラヒックパターンの差異を分析している。
【００１４】
しかし、これらの研究では、Webサイトにアクセスしたときの、オブジェクトの配信元サーバとクライアントPC間の距離といった、地理的な通信構造については分析されていない。
【００１５】
本発明は、上記の点に鑑みなされたもので、Webサイトアクセス時の通信距離や遅延時間等の通信構造を分析することが可能なWeb通信構造分析装置及び方法を提供することを目的とする。
【課題を解決するための手段】
【００１６】
一態様によれば、インターネットのWebサイトにアクセスしたときに発生するトラヒックにおける通信構造を分析するWeb通信構造分析装置であって、
前記インターネットに接続されているサイト情報データベースにアクセスしてサイトのURLリストを取得する評価URLリスト取得手段と、
前記URLリストに含まれている各URLに係る各サイトから通信特性情報を取得する通信特性情報取得手段と、
前記インターネットに接続されている位置情報データベースから、前記各サイトを構成する各オブジェクトの配信元の位置情報を取得する位置情報取得手段と、
前記通信特性情報取得手段で取得した前記通信特性情報から分析に必要となるデータを抽出するデータ抽出手段と、
前記データ抽出手段で抽出された前記データをURLのカテゴリに応じて分類するカテゴリ別分類手段と、
前記カテゴリ別分類手段でURLカテゴリに分類されたデータに基づいて、前記各サイトからの１つのWebページ取得時において通信した前記配信元の数、前記各サイトを構成するオブジェクトの配信元の前記位置情報が示す位置と当該Web通信構造分析装置の位置とのユークリッド距離、前記各サイトを構成するオブジェクトの取得に要した時間の少なくとも１つの平均値又は累積分布を前記URLカテゴリごとに算出し、統計データベースに格納する統計データ算出手段と、を有するWeb通信構造分析装置が提供される。
【発明の効果】
【００１７】
一態様によれば、インターネットに接続された測定用PC（Web通信構造分析装置）から様々なWebサイトにアクセスしたときに発生するトラヒックを、測定用PCにおいて計測し、通信距離や遅延時間等の様々な通信構造を分析できる。
【図面の簡単な説明】
【００１８】
【図１】本発明の一実施の形態におけるWeb通信構造分析装置の構成図である。
【図２】本発明を適用するシステム構成例である。
【図３】本発明の一実施の形態におけるWeb通信構造分析装置の処理のフローチャートである。
【図４】本発明の一実施の形態におけるHARファイルの例である。
【図５】本発明の一実施の形態におけるオブジェクトの３つの粒度の例である。
【発明を実施するための形態】
【００１９】
以下、図面と共に本発明の実施の形態を説明する。
【００２０】
図１は、本発明の一実施の形態におけるWeb通信構造分析装置の構成を示す。
【００２１】
同図に示すWeb通信構造分析装置１０は、HTTPデーモン１１、URLリストハンドラ１２、HTTPアーカイブ（HAR）ファイル生成部１３、位置情報解決部１４、統計情報抽出部１５を有する。
【００２２】
URLリストハンドラ１２は、人気サイトデータベースからURLリストを取得する。
【００２３】
HARファイル生成部１３は、各種通信情報を含むHARファイルを生成する。
【００２４】
位置情報解決部１４は、サーバやキャッシュの位置情報をGeoIP（登録商標）データベース等のGeoロケーションデータベースに問い合わせることで解決する。
【００２５】
統計情報抽出部１５は、取得したHARファイルや位置情報から、様々な統計データを作成し、統計データベースに格納する。
【００２６】
図２に、本発明を適用するシステム構成例を示す。
【００２７】
通信構造の傾向を分析するためには、可能な限り多様な多数のWebサイトにアクセスすることが望ましい。もし手動で各サイトにアクセスした場合、測定できるサイト数は限られたものとなるため、自動的に多数のサイトにWeb通信構造分析装置１０（測定用PC）からバッチ処理でアクセスする必要がある。バッチ処理はアクセスするURLのリストを与えることで可能となる。URLリストの取得方法としては、Quantcast(登録商標)やAlexa（登録商標）等のWebサイトアクセスランキングの公開情報を用いることが考えられる。そこで、Web通信構造分析装置１０が最初に行うことは、
(1)クエリを第三機関が提供する人気サイト情報DB４に送信する：
(2)クエリに対する応答の形で人気サイトDB４からURLリストを取得する：
二つの処理となる。
【００２８】
URLリストを取得した後は、
(3)URLリストに基づきHTTPリクエストをバッチ処理でWebサーバキャッシュ２に送信する：
(4)Webサーバ・キャッシュ２からのHTTP応答メッセージから生成された通信に関する様々な情報を取得する処理を行う。
【００２９】
HTTP応答メッセージはWebサーバ・キャッシュ２の位置に関する情報を含まれていないため、位置情報をMaxMind（登録商標）等のIPアドレスから位置座標や都市名を取得することが可能なGeoロケーションDB３を用いることで取得する。よって、続く処理として、
(5)HTTP応答メッセージに含まれるサーバのIPアドレス情報をGeoロケーションDB３にクエリ問合せを行う：
(6)その応答として位置情報と都市名を取得する：
という処理を行う。
【００３０】
そして最後に、
(7)取得した通信構造情報から各種統計データを算出する。
【００３１】
図３は、本発明の一実施の形態におけるWeb通信構造分析装置の処理のフローチャートである。
【００３２】
ステップ１）  URLリストハンドラ１２は、人気サイトDB４にアクセスし、任意の件数のアクセス数が上位の任意の件数の評価URLリストを取得する。そして、当該評価URLリストをHTTPデーモン１１に送り、HTTPデーモン１１は、評価URLリストに基づいて、Webサーバ・キャッシュ２からHTTPデータ（通信特性情報）を取得する。また、URLリストハンドラ１２はアクセスしたホスト名を位置情報解決部１４に渡す。位置情報解決部１４は、サーバ・キャッシュ２の位置情報をGeoロケーションDB３に問い合わせることで解決する
ステップ２）  HTTPデーモン１１は、HTTPデータ（通信特性情報）のデータストリームをHARファイル生成部１３に渡す。HARファイル生成部１３は、データストリームからHARファイルを生成し、統計情報抽出部１５に渡す。
【００３３】
ステップ３）  統計情報抽出部１５は、HARファイルからデータを抽出する。
【００３４】
ステップ４）  統計情報抽出部１５は、HARファイルのデータをURLカテゴリ別に分類する。
【００３５】
ステップ５）  統計情報抽出部１５は、URLカテゴリ別に分類されたデータから統計データを導出する。
【００３６】
以下に、上記の各処理について説明する。
【００３７】
＜ステップ1：評価URLリストの生成＞
Web通信構造の傾向を分析するためには、アクセス数の多い、高人気のサイトにアクセスしたときに発生する通信を分析対象とすることが望ましい。ところでQuantcastのWebサイトでは、月間の各サイトのアクセス数を各国のユーザ別に集計することで得た、アクセス数のランキング情報が公開されている。そこで、2013年1月の時点での、米国内からのアクセス数の上位2,297個のサイトを評価対象とした。表１にアクセス数上位２０サイトのURLを例としてまとめる。
【００３８】
【表１】
0005993819.tif 000002
これらQuantastのランキングリストに記載されているURLはすべて各サイトのトップページであるため、トップページにアクセスしたときの通信特性のみが分析対象となる。
【００３９】
＜ステップ２：評価URLアクセス時の通信特性情報（HARファイル）の取得＞
HARファイル生成部１３は、URLリストハンドラ１２で生成された評価URLリストの各URLについて、HTTPデーモン１１からGETのHTTPリクエストを送信した際に発生する通信特性を、HAR(HTTP Archive)ファイルとして取得する。HTTPデーモン１１では、HARファイルは、当該Web通信構造分析装置１０とWebサーバ・キャッシュ２間で転送されるHTTPデータのヘッダ情報から、当該Web通信構造分析装置１０において各オブジェクトのサーバURL、サイズ、取得に要した遅延時間等の各種通信特性を算出し、JSON(JavaScript(登録商標) Object Notation)形式で出力したものである。図４にwww.google.com（"google"は登録商標）にアクセスしたときに取得されたHARファイルの冒頭部分を例として示す。
【００４０】
HARファイルは、NetExportの拡張を施したfirebug(登録商標)を適用したFirefox(登録商標)を用いたり、Googole Chrome(登録商標)のDeveloper Toolsを用いたりすることで取得可能である。しかし個別に手動で各測定ULRにアクセスしてHARファイルを取得すると、評価できるサイト数が非常に限られたものとなる。そこで、本発明では、多数のサイトにアクセスするために、コマンドラインでJavaScriptを実行できるphantomjs(登録商標)上で動作するスクリプトnetwsniff.jsを用いることで、多数のサイトに連続してアクセスし、各々のHARファイルをバッチ処理で取得する。この際に、Web通信構造分析装置１０のローカルキャッシュを無効化することで、全てのオブジェクトをリモートのサーバから取得する。なお、実験では、2,297のサイトの中で67については、30秒以上経過してもオブジェクトが取得できなかったことから、残る2,230のサイトを評価対象とした。
【００４１】
＜ステップ３：HARファイルからのデータ抽出＞
統計情報抽出部１５は、取得した各HARファイルに含まれる各構成オブジェクトの通信特性情報から、分析に必要となるデータを抽出する。具体的には、ホスト名、ホストの位置、オブジェクトサイズ、遅延時間、オブジェクト種別（MIME TYPE）に関する情報を取得するため、例えば、表２に示す各keyに対応するValueをPhyton［登録商標］で抽出する。
【００４２】
【表２】
0005993819.tif 000003
なお、MaxMindの提供するGeoIP API(Application Program Interface)を用いて、URLからサーバの存在する国名・都市名・位置座標を取得する。総遅延時間（オブジェクトの取得に要した時間）は、コネクション接続時間、DNS名前解決時間、TCPコネクション確立時間、HTTPリクエスト転送時間、サーバ応答待ち時間、レスポンス転送時間、SSL/TLSネゴシエーション時間、の７つの要素に分解されてHARファイルに記述されるため、これら遅延要素ごとに所要時間を得ることができる。但し、HTTPリクエスト転送時間は、リクエストパケットを、Web通信構造分析装置１０において送出するのに要する時間であり、サーバ応答待ち時間は、Web通信構造分析装置１０においてリクエストパケットの送出が完了した時点からレスポンスが到着し始めるまでに要した時間であり、レスポンス転送時間は、レスポンスパケットがWeb通信構造分析装置１０に到着し始めてから、その到着が完了するまでに要する時間である。サーバ応答待ち時間はWeb通信構造分析装置１０とサーバ・キャッシュ２間でパケットが転送される時間と、動的オブジェクトの生成等のサーバにおける処理時間とを合わせたものとなる。
【００４３】
実験では、2,230のサイトのうち、データ抽出時にエラーとなった1,015個のURLを除いた1,215個のULRを分析対象とした。
【００４４】
本明細書では、MIME Typeでオブジェクトの種別を判定するが、分析に用いた1,215のサイトから取得されたオブジェクトの中で、415のオブジェクトはMIME Typeに関するデータがなく、また、57のオブジェクトは"unknown"となった。これら472のオブジェクトを除いた他のオブジェクトは39のMIME Typeに分類した。表３に、総オブジェクト数の上位１０のMIME Typeについて、総オブジェクト数と、含有URL数（１つ以上の該当オブジェクトを含むサイト数）をまとめる。
【００４５】
【表３】
0005993819.tif 000004
上位６つのMIME Typeの総オブジェクト数と含有URL数が突出して多いことから、オブジェクト種別の分析を行う再には、これらの６つのMIME Typeを評価対象とした。
【００４６】
＜ステップ４：抽出データのカテゴリ分類＞
統計情報抽出部１５は、Webサイトの種類による通信傾向の違いを分析するため、抽出したデータをURLのカテゴリに応じて分類する。具体的には、AlexaのWebサイトでは、"Arts"や"Business"といったカテゴリ毎に分類されたURLのリストが公開されており、本分類リストに基づき抽出データを各URLカテゴリに分類した。分析に用いた1,215サイト中、597のサイトはAlexaのカテゴリリストに存在せず、残る618のサイトが表４に示す16のカテゴリに分類された。但し、cnn.com（登録商標）が"Arts"と"News"に分類されるなど、複数のカテゴリに重複して分類されたURLが存在するため、表４にまとめたURL数の合計は618よりも多くなっている。重複の多いカテゴリの例を挙げると、"Business"に分類されたサイト中で22.5%は"Regional"にも重複して分類され、"Regional"に分類されたサイトの中で20.2%は"Shopping"にも重複して分類された。
【００４７】
Alexaのサイトでは各カテゴリに対してサブカテゴリが定義されているが、各カテゴリの特色を把握するため、各カテゴリにおいて分類サイト数の上位３つのサブカテゴリ名についても表４にまとめている。"Adult"に分類されたサイトは一つだけであり、統計的な分析が困難なことから、カテゴリごとの分析を行う際には、"adult"を除いた15のカテゴリを分析対象とした。
【００４８】
【表４】
0005993819.tif 000005
＜ステップ５：統計データ算出＞
最後に、統計情報抽出部１５は、URLカテゴリに分類されたHARファイルから抽出した各種データを用いて、異なり数、オブジェクト距離、総遅延時間、の平均値や累積分布を算出する。但し、異なり数とは、１つのWebページ取得時において発生した通信における各Locationのホスト数、各ホストのオブジェクト数を意味する。また、各オブジェクトの配信元サーバの位置座標とWeb通信構造分析装置１０間のユークリッド距離をオブジェクト距離と定義する。一つのURLサイトにアクセスした際には、様々な都市に設置された複数のホストから、各種オブジェクトが取得されてWebブラウザ上に表示あれる。同じ都市（拠点）には複数のホストが設置され、また、各ホストからは複数のオブジェクトが転送されることが予想されるため、図５に示すように、オブジェクトをオブジェクト単体（Obj）、配信ホスト（Hst）、配信元都市（Loc）の３つの粒度で集約することが可能である。但し、Hstは配信元ホスト名が同一のオブジェクトを、Locは配信元ホストが存在する都市が同一のオブジェクトを、各々、一つに集約したときの粒度である。そこで、これらの３つの各粒度でオブジェクトを集約したときの、各種評価指標に関する平均値と累積分布を算出する。
【００４９】
［数値評価］
以下では、上記の本発明についての評価について説明する。
【００５０】
一例として、東京の武蔵野に設置した測定用クライアントPC(Web通信構造分析装置)から、1,215のサイトにアクセスしたときの数値結果を示し、Webブラウジング時の通信パターンの傾向について分析する。なお、測定は2013/1/30(水)の15:30から19:30の時間帯に実施した。
【００５１】
まず、６つのMIME Typeごとの傾向について分析する。６つのMIME Typeのうち、jpeg，png，gif（登録商標）は画像データであり、javascript，html， css(cascading style sheets)はテキストデータである。JavascriptはクライアントPC上で動的なコンテンツを生成したり、ユーザのインタラクティブ操作に対してブラウザの動作を行ったりするために実行されるスクリプトであり、cssは、HTMLやXMLの要素をどのように修飾するかを指示するプログラムである。
【００５２】
表５に、全てのオブジェクト(all)と、６つの各オブジェクト種別に対して、各種評価指標の平均値をまとめる。これらの値は、ホストごとに算出した値を全てのサイトにわたり平均をとったものである。オブジェクトのサイズは、画像オブジェクトが小さく、テキストオブジェクトが大きいが、このことは予想に反する。多くのサイトではアイコン等の小さな画像が様々な場所で表示されることが多く、小さな画像オブジェクトが多数用いられることが多いことと、AJAX等を多用したWebサイトのリッチ化に伴い、オブジェクトの動的生成のためのプログラムが肥大化していることが要因と思われる。画像全体のデータ量は、全体の約32%を占めている。
【００５３】
【表５】
0005993819.tif 000006
ホストあたりのオブジェクト数は、画像オブジェクト（jpeg，png）は多く、テキストオブジェクト（html，javascript）は少ない傾向が、またオブジェクトの平均距離は画像オブジェクトには近く、テキストオブジェクトは遠い傾向が見られる。そして各オブジェクトの取得に要した総遅延時間は、htmlとjpegは大きく、javascriptとgifは小さい傾向がある。サーバ応答待ち時間が総遅延時間の支配要因であるため、総遅延時間は、オブジェクトサイズ、オブジェクト数、距離等との相関性は低い。
【００５４】
次に、15の各URLカテゴリの傾向について分析する。
【００５５】
表６に、全てのオブジェクト（all）と、15の各URLカテゴリに対して、各種評価指標の平均値をまとめる。総データ量とアクセスオブジェクト数は、娯楽系のサイト（Arts，Game，Sports）は大きく、情報収集系のサイト（Business，Computers，Health， Reference）は小さい傾向が見られる。アクセス都市数とアクセスホスト数についても同様の結果が得られた。
【００５６】
【表６】
0005993819.tif 000007
オブジェクトの平均距離は、地域性の高いサイト（Business，News，Sports）やArtsとComputersは近く、地域性の低いサイト（Health，Reference，Science，Society）は遠い傾向がある。また、各オブジェクトの取得に要した総遅延時間は、Science，News，Games，Referenceのサイトが大きい傾向があるが、総データ量、オブジェクト数、距離等のとの相関性は低い。
【００５７】
なお、上記の図１に示すWeb通信構造分析装置１０の構成要素の動作をプログラムとして構築し、Web通信構造分析装置として利用されるコンピュータにインストールして実行させる、または、ネットワークを介して流通させてもよい。
【００５８】
本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。
【符号の説明】
【００５９】
１  インターネット
２  サーバ・キャッシュ
３  GeoロケーションDB（データベース）
４  人気サイトDB(データベース)
５  統計データDB(データベース)
１０  Web通信構造分析装置
１１  HTTPデーモン
１２  URLリストハンドラ
１３  HARファイル生成部
１４  位置情報解決部
１５  統計情報抽出部
【図１】
0005993819.tif 000008
【図２】
0005993819.tif 000009
【図３】
0005993819.tif 000010
【図４】
0005993819.tif 000011
【図５】
0005993819.tif 000012