ユーザ待ち時間推定装置、ユーザ待ち時間推定方法、及びプログラム
【課題】取得データのサイズを軽減し、アプリケーション層等に対して暗号化を行うプロトコルが使用された場合でも、ユーザ待ち時間を推定することを可能とする。
【解決手段】ユーザ待ち時間推定装置において、アプリケーションサーバからユーザ端末に向けて送信された各パケットを取得し記憶手段に格納する手段と、予め定めた時間幅を有するタイムスロット毎のパケット数を算出する手段と、パケット数が検知閾値以上であるタイムスロット群を、抽出タイムスロット群として抽出する手段と、スライディングウィンドウに含まれる抽出タイムスロットの合計時間とウィンドウ時間長とに基づき、パケットが連続して出現した連続区間を識別する手段と、各パケットにおけるTCPヘッダ情報を参照することにより、サーバ処理時間を推定する手段と、連続区間とサーバ処理時間とを結合するし、結合された時間区間を、推定されたユーザ待ち時間として出力する手段とを備える。
【解決手段】ユーザ待ち時間推定装置において、アプリケーションサーバからユーザ端末に向けて送信された各パケットを取得し記憶手段に格納する手段と、予め定めた時間幅を有するタイムスロット毎のパケット数を算出する手段と、パケット数が検知閾値以上であるタイムスロット群を、抽出タイムスロット群として抽出する手段と、スライディングウィンドウに含まれる抽出タイムスロットの合計時間とウィンドウ時間長とに基づき、パケットが連続して出現した連続区間を識別する手段と、各パケットにおけるTCPヘッダ情報を参照することにより、サーバ処理時間を推定する手段と、連続区間とサーバ処理時間とを結合するし、結合された時間区間を、推定されたユーザ待ち時間として出力する手段とを備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クライアント／サーバ型のTCPベースアプリケーションを利用するユーザが、ユーザ端末上で体感する待ち時間を推定するための技術に関するものである。
【背景技術】
【０００２】
クライアント／サーバ型のTCPベースのアプリケーションが広く普及している。当該アプリケーションをユーザが快適に使用するためには、ユーザがユーザ端末に対する操作を行ってから、当該操作に対する結果がユーザ端末の画面上に表示されるまでの時間である待ち時間（以下、これをユーザ待ち時間と呼ぶ）が短いことが好ましい。そのため、アプリケーションの品質を評価するにあたって、ユーザ待ち時間は重要な指標の一つであり、ユーザ待ち時間を適切に推定することが求められている。
【０００３】
ユーザ待ち時間を推定する従来技術としては、事前評価型とインサービス評価型がある。
【０００４】
事前評価型の技術は、実際の利用環境ではなく、擬似的な利用環境を用いて、被験者にアプリケーションを利用してもらい、待ち時間を計測するものである。また、擬似的な利用環境で、擬似クライアントを用いて待ち時間を計測する技術もある。
【０００５】
インサービス評価型の技術としては、サーバに蓄積されたログを解析することによりユーザ待ち時間を推定する技術、サーバとユーザ端末間で送受信される情報を収集、解析し、解析結果からユーザ待ち時間を推定する技術、実際の利用環境で擬似クライアントプログラムをユーザ端末で実行させることにより待ち時間を計測する技術等がある。
【０００６】
なお、先行技術文献として、TCP上でのデータ転送における遅延等の品質を推定する技術を開示した特許文献１がある。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００４−１４０５９６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、従来の事前評価型の技術では、実際にユーザがアプリケーションを利用しているときのユーザ待ち時間を推定することができない。従って、通信ネットワークの状況等に応じて変化する場合があるユーザ待ち時間を適切に推定できない。また、事前評価型の技術では、通信ネットワークの状況等によりユーザ待ち時間が悪化した場合等に、それに対する対応をとるといったことができない。
【０００９】
インサービス評価型の技術を用いることにより、事前評価型の問題を解決できる。しかし、従来のインサービス評価型の技術には次のような問題がある。
まず、サーバに蓄積されたログを解析することによりユーザ待ち時間を推定する技術では、サーバでの処理時間に関わる時間しか推定できず、通信ネットワークに起因するユーザ待ち時間の変化等を把握することができない。
【００１０】
また、擬似クライアントプログラムを用いる技術では、サーバ及び通信ネットワークに測定用のオーバヘッドを生じさせることになり、測定に起因してアプリケーションの品質劣化等が生じてしまう可能性があるという問題がある。
【００１１】
また、サーバとユーザ端末間で送受信される情報を収集、解析する従来の技術では、ユーザ待ち時間を推定するために、ユーザ端末とサーバ間で双方向に送受信される全てのデータを取得する必要があり、取得するべきデータのサイズが非常に大きくなってしまうという問題がある。更に、従来技術では、トランスポート層よりも上位の層までの情報を解析する必要があるため、ＨＴＴＰＳのようなトランスポート層よりも上位の層に対して暗号化を行うプロトコルが使用された場合、取得した情報の解析が不可能となり、ユーザ待ち時間の算出が行えないという問題がある。
【００１２】
本発明は上記の点に鑑みてなされたものであり、ユーザ端末とサーバ間で送受信されるデータを取得することによりユーザ待ち時間を推定する技術において、取得するべきデータのサイズを軽減し、トランスポート層よりも上位の層に対して暗号化を行うプロトコルが使用された場合でも、ユーザ待ち時間を推定することを可能とした技術を提供することを目的とする。
【課題を解決するための手段】
【００１３】
上記の課題を解決するために、本発明は、TCPベースのアプリケーションサービスを提供するアプリケーションサーバに通信ネットワークを介して接続され、前記アプリケーションサービスを利用するユーザ端末におけるユーザ待ち時間を推定するユーザ待ち時間推定装置であって、前記アプリケーションサーバから前記ユーザ端末に向けて送信された各パケットを取得し、当該パケットを取得した時刻の情報とともに、当該パケットを記憶手段に格納するパケット取得手段と、前記パケット取得手段により取得されたパケット群から、予め定めた時間幅を有するタイムスロット毎のパケット数を算出するパケット数集計手段と、前記パケット数集計手段により算出されたタイムスロット毎のパケット数に基づき、パケット数が予め定めた検知閾値以上であるタイムスロット群を、抽出タイムスロット群として抽出する抽出手段と、所定のウィンドウ時間長を有するスライディングウィンドウを定め、スライディングウィンドウに含まれる抽出タイムスロットの合計時間と前記ウィンドウ時間長とに基づき、スライディングウィンドウを時間進行方向にずらしながら、パケットが連続して出現した時間区間である連続区間を識別する連続区間識別手段と、前記パケット取得手段により取得された各パケットにおけるTCPヘッダ情報を参照することにより、前記アプリケーションサーバが前記ユーザ端末にTCPパケットを送信せずに処理を行った時間であるサーバ処理時間を推定するサーバ処理時間推定手段と、前記連続区間識別手段により識別された連続区間と、前記サーバ処理時間推定手段により推定されたサーバ処理時間とが時間的に連続しているか否かを判定し、連続している場合に、前記連続区間と前記サーバ処理時間とを結合する結合処理手段と、前記結合処理手段により結合された時間区間を、推定されたユーザ待ち時間として出力する出力手段とを備えることを特徴とするユーザ待ち時間推定装置として構成される。
【００１４】
前記サーバ処理時間推定手段は、データなしのACKパケットであると識別された対象パケットの次のパケットがデータ付きのTCPパケットであり、なおかつ、当該次のパケットのACK番号が、前記対象パケットのACK番号と同じであると判定した場合に、前記対象パケットの時刻から前記次のパケットの時刻までを前記サーバ処理時間とするように構成できる。
【００１５】
また、前記連続区間識別手段は、ある抽出タイムスロットに対応する連続性判定開始位置から時間進行方向に伸びるスライディングウィンドウに含まれる抽出タイムスロットの合計時間を算出し、前記ウィンドウ時間長に対する前記合計時間の割合が予め定めた閾値以上であるか否かを判定する判定手段と、前記判定手段により、前記ウィンドウ時間長に対する前記合計時間の割合が前記予め定めた閾値以上であると判定された場合に、連続性判定開始位置を次の抽出タイムスロットにずらし、当該ずらした連続性判定開始位置に基づき前記判定手段による処理を行うスライディング手段と、前記判定手段と前記スライディング手段による処理を、前記ウィンドウ時間長に対する前記合計時間の割合が前記予め定めた閾値未満であると判定されるまで繰り返し行い、最初の連続性判定開始位置から、最後に前記合計時間の割合が前記閾値以上であると判定されたスライディングウィンドウの末尾までの時間を前記パケットが連続して出現した時間区間であると決定する手段とを備えるように構成することができる。
【発明の効果】
【００１６】
本発明によれば、アプリケーションサーバからユーザ端末に向けて送信されたパケットを取得することによりユーザ待ち時間を推定できるので、ユーザ端末とサーバ間で双方向に送受信されるパケットを取得しなければならない従来技術に比べて、取得すべきデータ量を削減できる。また、本発明では、トランスポート層よりも上位の層のプロトコルに係るヘッダの内容等を参照する必要がないので、トランスポート層よりも上位の層に対して暗号化を行うプロトコルが使用された場合でも、ユーザ待ち時間を推定することが可能になる。
【００１７】
更に、アプリケーションサーバにおいて、ユーザ端末にTCPパケットを送信せずに処理を行うサーバ処理時間が長くなる場合があったとしても、本発明によれば、サーバ処理時間をパケットのTCPヘッダから推定し、連続区間と結合し、結合された時間区間をユーザ待ち時間と推定するので、より実際に近いユーザ待ち時間を求めることができる。
【図面の簡単な説明】
【００１８】
【図１】本発明の実施の形態に係るシステムの全体構成図である。
【図２】「ユーザ待ち時間」を説明するための図である。
【図３】「ユーザ待ち時間」を説明するための図である。
【図４】ユーザ待ち時間推定装置１の機能構成図である。
【図５】ユーザ待ち時間推定装置１の動作を説明するためのフローチャートである。
【図６】パケット格納部１２に格納されるパケットの例を示す図である。
【図７】パケット格納部１２に格納されるパケットの例を示す図である。
【図８】トラヒック分類部１３により分類されたパケットの例を示す図である。
【図９】パケット数集計部１４により得られた集計結果を示すヒストグラムである。
【図１０】連続区間識別部１５が実行する処理を説明するためのフローチャートである。
【図１１】連続区間識別部１５が実行する処理を説明するための概念図である。
【図１２】連続区間識別部１５が実行する処理を説明するためのフローチャートである。
【図１３】連続区間識別部１５が実行する処理を説明するための概念図である。
【図１４】サーバ処理時間推定部１８が実行する処理を説明するための概念図である。
【図１５】サーバ処理時間推定部１８が実行する処理を説明するためのフローチャートである。
【図１６】マージ処理部１９が実行する処理を説明するための概念図である。
【発明を実施するための形態】
【００１９】
以下、図面を参照して本発明の実施の形態を説明する。
【００２０】
（システム構成）
図１に、本発明の実施の形態に係るユーザ待ち時間推定装置１を含むシステムの全体構成図を示す。
【００２１】
図１に示すように、本実施の形態に係るシステムは、ユーザ待ち時間推定装置１、アプリケーションサーバ２、ユーザ端末３を備え、これらが通信ネットワーク４に接続されて構成されている。
【００２２】
アプリケーションサーバ２は、アプリケーションサービスをユーザ端末３に対して提供するサーバである。アプリケーションサーバ２が提供するアプリケーションサービスは、例えば、Webページ提供サービス、ストレージ系サービス等である。
【００２３】
ユーザ待ち時間推定装置１は、アプリケーションサーバ２と通信を行うユーザ端末３を操作するユーザが体感する待ち時間を推定する装置である。また、ユーザ端末３は、Webブラウザ等を備えた一般的なPC端末である。通信ネットワーク４は、インターネットやLAN等を含むIP（Internet Protocol）によるデータ通信可能なネットワークである。
【００２４】
また、アプリケーションサーバ２とユーザ端末３間で送受信される全てのパケット（ＩＰパケット）をユーザ待ち時間推定装置１が受信できるように通信ネットワーク４が構成されているものとする。例えば、ユーザ待ち時間推定装置１は、通信ネットワーク４内で、アプリケーションサーバ２を接続するLANスイッチのミラーポートに接続される。
【００２５】
ただし、ユーザ待ち時間推定装置１は、必ずしも通信ネットワーク４から直接にパケットを取得しなくてもよい。例えば、通信ネットワーク４から他の装置により取得されたパケットを、当該装置からユーザ待ち時間推定装置１に入力する構成としてもよい。
【００２６】
なお、本実施の形態では、ユーザ端末３とアプリケーションサーバ２間におけるデータ通信のトランスポート層のプロトコルとしてTCP（Transmission Control Protocol）を用いることを前提としている。TCPは、フロー制御等の制御のための通信が頻繁に発生するとともに、要求に対応する応答が必ず発生するので、本発明に係る技術に適しているからである。また、図１では、アプリケーションサーバ２とユーザ端末３がそれぞれ１つづつ示されているが、それぞれ複数台備えられてよいことはいうまでもない。
【００２７】
次に、図２を参照して、本実施の形態に係る"ユーザ待ち時間"について説明する。図２は、アプリケーションサーバ２とユーザ端末３間でのTCPの通信シーケンスの概要を表している図である。
【００２８】
図２に示すように、ユーザがユーザ端末３上で、所望の表示結果を得るための所定の操作（例えば、ブラウザ画面上に表示された特定のボタンをクリックする操作）を行うと、パケットがアプリケーションサーバ２とユーザ端末３間で送受信され、上記操作に対応する結果（例えば、表示されることを期待していたWebページ画面）がユーザ端末３上に表示される。
【００２９】
図３に、ユーザ待ち時間の別の例を示す。図３で示す例は、ストレージ系のアプリケーションの例であり、アプリケーションサーバ２側において、TCPパケットをユーザ端末３に返すことなく行う処理（この例ではデータのHDDへの書き込み処理）にある程度の時間を要する場合の例である。
【００３０】
図３の例では、ユーザによる操作（データのアップロード指示等）を行ってから、アプリケーションサーバ２とユーザ端末３間での連続的なパケットの送受信を経て、アプリケーションサーバ２において上記の書き込み処理が行われて、その後、アプリケーションサーバ２とユーザ端末３間での連続的なパケットの送受信を経て、ユーザ端末３上に、操作に対応する結果（例えば、アップロードが終了したことを示す画面）が表示される。この場合、図３に示す時刻Aから時刻Bまでがユーザ待ち時間となる。本実施の形態の技術では、このような場合のユーザ待ち時間も適切に求めることができる。
【００３１】
本明細書及び特許請求の範囲では、上記のように所定の操作を行った時刻から、当該所定の操作に対応する結果が表示される時刻までをユーザ待ち時間としている。
【００３２】
図４に、本実施の形態に係るユーザ待ち時間推定装置１の機能構成図を示す。図４に示すように、ユーザ待ち時間推定装置１は、入力部１１、パケット格納部１２、トラヒック分類部１３、パケット数集計部１４、連続区間識別部１５、RTT（Round Trip Time）提供部１６、出力部１７、サーバ処理時間推定部１８、及びマージ処理部１９を有する。
【００３３】
各機能部の処理の内容については、後述するシステムの動作説明のところで詳細に説明することとし、以下では各機能部の機能の概要を説明する。
【００３４】
入力部１１は、ユーザ端末３とアプリケーションサーバ２間で送受信されるパケットのうち、アプリケーションサーバ２からユーザ端末３に向かうパケットを通信ネットワーク４等から取得し、各パケットにタイムスタンプ（現在時刻、パケットを取得した時刻）を付してパケット格納部１２に格納する機能部である。
【００３５】
トラヒック分類部１３は、アプリケーションサーバ２からユーザ端末３に向かうパケットを宛先毎に分類する機能部である。パケット数集計部１４は、特定のユーザ端末宛であると識別されたパケット群毎に、予め定めた時間幅（タイムスロット）毎のパケット数を算出する処理を行う機能部である。
【００３６】
連続区間識別部１５は、パケット数集計部１４により得られた予め定めた時間幅毎のパケット数を用いて、所定の時間幅内に一定量以上のパケットが連続して出現しているか否かを識別することにより、ユーザによる待ち時間が継続していると推定できる時間区間である連続区間を求める機能部である。
【００３７】
また、RTT提供部１６は、RTT（Round Trip Time:ユーザ端末３からアプリケーションサーバ２にパケットを送信して、確認応答パケットがアプリケーションサーバ２からユーザ端末３に返されるまでの時間）を取得し、それを連続区間識別部１５及びサーバ処理時間推定部に提供する機能部である。
【００３８】
サーバ処理時間推定部１８は、トラヒック分類部１３により抽出されたパケットにおけるTCPヘッダの情報を参照することにより、ユーザ端末３からアプリケーションサーバ２への処理要求（例えば、データアップロード処理要求）に関するデータ送信完了を把握するとともに、当該処理要求に対応した処理完了の応答を把握することにより、TCPパケットがユーザ端末３に返されることなくアプリケーションサーバ２で実行された処理の時間を推定する機能部である。
【００３９】
マージ処理部１９は、連続区間識別部１５で算出された連続区間と、サーバ処理時間推定部１８で算出されたサーバ処理時間とを結合する機能部である。
【００４０】
出力部１７は、マージ処理部１９により得られた時間区間を、推定されたユーザ待ち時間の情報として出力する機能部である。
【００４１】
ユーザ待ち時間推定装置１は、メモリやハードディスク等の記憶手段及びCPUを備える一般的なコンピュータに、各機能部に対応する処理を行うためのプログラムを搭載することにより実現できる。当該プログラムは、可搬メモリやディスク等の記録媒体から上記コンピュータにインストールしてもよいし、ネットワーク上のサーバから上記コンピュータにダウンロードし、インストールすることとしてもよい。
【００４２】
（システムの動作）
次に、ユーザ待ち時間推定装置１の動作の例を、図５のフローチャートに沿って説明する。まず、ユーザ待ち時間推定装置１の入力部１１は、通信ネットワーク４から、アプリケーションサーバ２を送信元とするパケットを順次取得し、取得した時刻の情報であるタイムスタンプを付してパケット格納部１２に格納する（図５のステップ１）。
【００４３】
ユーザ待ち時間推定装置１は、特定のアプリケーションサーバ２から送信されるパケットを常にパケット格納部１２に格納し、当該アプリケーションサーバ２に関するユーザ待ち時間推定の必要が生じたときに、特定の時間区間に取得されたパケットを解析の対象としてもよいし、ユーザ指示等により特定の時間区間だけパケット収集を行い、そこで収集されたパケットを解析の対象としてもよい。また、常にパケットをパケット格納部１２に格納し、一定時間毎に特定のアプリケーションサーバに関するユーザ待ち時間推定処理を実行することとしてもよい。もちろん、その他の形態を用いてもよい。
【００４４】
パケット格納部１２に格納されるパケットの例を図６（ａ）に示す。例えば、図６（ａ）の第１行目は、送信元IPアドレスがIPアドレス１、送信元ポート番号がポート番号１、宛先IPアドレスがIPアドレス３、宛先ポート番号がポート番号１であるIPパケットが、時刻１に取得され、格納されたことを示している。他の行も同様である。
【００４５】
なお、図６（ａ）では、宛先IPアドレスがIPアドレス３であるIPパケットのみを示しているが、一般には、種々の宛先IPアドレスのIPパケットが取得される。また、パケット格納部１２に格納する対象となるパケットの送信元ＩＰアドレスと宛先ＩＰアドレスとを予め決めている場合には、取得したパケットからＩＰヘッダを除き、TCPヘッダが付されたTCPパケットの形式でパケット格納部１２に格納することとしてもよい。
【００４６】
続いて、図５のステップ２において、トラヒック分類部１３が、パケット格納部１２に格納されたパケットを、宛先ユーザ端末毎に分類する処理を行う。分類にあたって、本実施の形態では、宛先IPアドレスと宛先ポート番号の１つの組が１つの宛先ユーザ端末に対応するものとし、宛先IPアドレスと宛先ポート番号の組毎にパケットを分類する処理を行う。
【００４７】
ただし、NAT経由の通信等の場合に、１つの宛先ユーザ端末に対して、１つの宛先IPアドレスと、連続する複数の宛先ポート番号が割り当てられる場合があることを考慮して、同じ宛先IPアドレスの複数のパケットであって、連続するポート番号を有する複数のパケットが所定の短い時間（例えば０．５秒）内に現れた場合は、それらのパケットは１つのユーザ端末宛のパケットであるとみなしている。
【００４８】
例えば、パケット格納部１２に格納されたパケットが図６（ａ）に示すとおりのものであった場合、宛先IPアドレスは同一なので、トラヒック分類部１３は、図６（ｂ）に示すようにパケットを分類（ソート）する。図６（ｂ）の例において、宛先ポート番号１のIPパケットはユーザ端末A宛てのパケット、宛先ポート番号８のパケットはユーザ端末Aと異なるユーザ端末B宛てのパケットなどとみなすことができる。
【００４９】
また、例えば、パケット格納部１２に格納されたパケットが図７（ａ）に示すようなものであり、時刻１から時刻４までの時間及び時刻５から時刻７までの時間のそれぞれが所定の時間より短い場合、トラヒック分類部１３は、パケットを図７（ｂ）に示すように分類する。図７（ｂ）の例において、宛先ポート番号１〜４のパケットはユーザ端末Ｘ宛てのパケット、宛先ポート番号１０〜１２のパケットはユーザ端末Ｘと異なるユーザ端末Ｙ宛てのパケットとみなすことができる。
【００５０】
なお、以下で説明する処理は、分類されたパケット群のうち、特定の１つのユーザ端末宛のパケットに対する処理であるものとする。また、分類がなされたパケットは、パケット格納部１２に格納してもよいし、パケット格納部１２以外のメモリ等の記憶手段に格納してもよい。
【００５１】
また、宛先ユーザ端末毎に分類されたパケットを取得する方法は、上記の方法に限られるわけではなく、結果として、宛先ユーザ端末毎に分類されたパケットを取得できるのであればどのような手段を用いてもよい。
【００５２】
次に、図５のステップ３において、ユーザ待ち時間推定装置１のパケット数集計部１４は、分類されたパケットについて、予め定めた時間幅（Ｗで表し、タイムスロットとも呼ぶ）毎の個数を算出する処理を行う。
【００５３】
例えば、トラヒック分類部１３により、図８に示すパケットが、アプリケーションサーバ２からユーザ端末３宛（ＩＰアドレス３及び宛先ポート番号１０で識別されるユーザ端末）のパケットとして抽出されたものとする。また、例えば、タイムスロットの大きさＷとして０．１秒（以下、時間の単位は秒であるとする）を使用するものとする。
【００５４】
この場合、パケット数集計部１４は、時刻０から時刻０．１の間のタイムスロットのパケット数を３として求め、時刻０．１から時刻０．２の間のタイムスロットのパケット数を４として求める。他のタイムスロットでも同様である。このようにして算出した結果から、図９に示すヒストグラムが得られる。
【００５５】
＜連続区間識別部１５の動作＞
続いて、図５のステップ４において、連続区間識別部１５が、パケット数集計部１４により得られたタイムスロット毎のパケット数に基づき、ユーザ待ち時間が継続していると推定することができるパケットの連続区間を識別する処理を行う。
【００５６】
本実施の形態では、連続区間識別部１５は、ユーザ端末３からアプリケーションサーバ２にパケットが送信されてから、確認応答パケットがアプリケーションサーバ２からユーザ端末３に返されるまでの時間であるRTTを利用して連続区間を識別することもできるし、RTTを利用しないで連続区間を識別することもできる。RTTを利用するかしないかは、例えば、アプリケーションサーバ２の位置（国内か外国か等）や、通信ネットワーク４の状態等で判断し、ユーザによりRTTを利用するかしないかを設定することができる。
【００５７】
―――RTTを利用しない場合―――
まず、RTTを利用しない場合の処理について、図１０のフローチャート、及び、図１１に示す処理の概念図を用いて説明する。
【００５８】
なお、以下の処理の前提として、タイムスロットにおけるパケット数の閾値である検知閾値と、スライディングウィンドウの時間長さＬと、連続性判定閾値Ｓとが予め連続区間識別部１５に入力され、メモリ等に保持されているものとする。
【００５９】
まず、図１０のステップ１０において、連続区間識別部１５は、パケット数が検知閾値以上の全てのタイムスロットを抽出する。ここで、検知閾値は、０以上の整数である。検知閾値は、対象とする通信（ユーザによる操作に起因する通信）以外の通信に係るパケットを、ユーザ待ち時間推定において検知しないようにするために設けられるものである。また、各タイムスロットは、その開始時間位置と終了時間位置で識別される情報である。ステップ１０の処理は、図１１において、パケット数が点線と重なるか、点線を越えているタイムスロットを抽出する処理に相当する。以下、ここで抽出されたタイムスロットを、抽出タイムスロットと呼ぶ。
【００６０】
次に、図１０のステップ２０において、連続区間識別部１５は、複数の抽出タイムスロットのうちの、後述する連続性判定開始位置になったことがない抽出タイムスロットの中で、時間的に最初に位置する抽出タイムスロットの開始位置（時刻Ｔとする）を特定する。
【００６１】
そして、連続区間識別部１５は、連続区間識別のためにスライディングウィンドウをずらす時間長さを示す変数であるＣを初期化（Ｃ＝０とする）する（ステップ３０）。続いて、連続区間識別部１５は、上記抽出タイムスロットの開始位置である時刻Ｔから始まるスライディングウィンドウに含まれる抽出タイムスロットの合計の時間長さを求め、スライディングウィンドウの時間長さLに対する当該抽出タイムスロットの合計の時間長さの割合Ｒを求める（ステップ４０）。以下では、スライディングウィンドウの開始位置を連続性判定開始位置と呼ぶことにする。
【００６２】
ステップ４０において、タイムスロットの時間幅がＷであり、連続性判定開始位置から始まるスライディングウィンドウの時間長さＬの中に、抽出タイムスロット（パケット数が検知閾値以上のタイムスロット）がＭ個含まれるとした場合、抽出タイムスロットの合計の時間長さはＷ×Ｍであるから、Ｒ＝Ｗ×Ｍ／Ｌとなる。また、図１１の場合について、タイムスロットの幅を０．１、各スライディングウィンドウの長さを１とすると、スライディングウィンドウＡの中に、８個の抽出タイムスロットが含まれるから、Ｒ＝０．１×８／１＝０．８となる。
【００６３】
続いて、連続区間識別部１５は、Ｒが連続性判定閾値Ｓ以上であるか否かを判定する（ステップ５０）。本実施の形態において、Ｓは、０から１の間の定数であり、例えばＳ＝０．５である。
【００６４】
ステップ５０において、Ｒが連続性判定閾値Ｓ以上であると判定された場合、連続区間識別部１５は、連続性判定開始位置を、時間進行方向において次に位置する抽出タイムスロットの開始位置とする。また、連続性判定開始位置をずらした長さ（前の連続性判定開始位置から次の連続性判定開始位置までの時間）をＫとし、Ｃ＝Ｃ＋Ｋとする（ステップ６０）。その後、ステップ４０に戻る。
【００６５】
また、ステップ５０において、Ｒが連続性判定閾値Ｓ以上でないと判定された場合、連続区間識別部１５は、ステップ７０に進み、Ｃ＝Ｃ−Ｋとするとともに、ＴからＴ＋Ｃ＋Ｌの区間を連続区間としてメモリ等の記憶手段に記録し、ステップ２０に戻る。ただし、ステップ５０の判定処理において、一度もＹｅｓの判定がされずに最初からＮｏと判定された場合には、ステップ７０を経ずにステップ２０に戻る。ステップ２０において、現在の連続性開始判定位置の次の抽出タイムスロットの開始位置がＴとなり、それ以降の処理が繰り返される。ここで、次の抽出タイムスロットが存在しなければ処理を終了する（ステップ８０）。
【００６６】
上記の処理の概念を図１１を参照して説明する。図１１の例では、スライディングウィンドウの時間長さがタイムスロット１０個分の長さであり、連続性判定閾値Ｓ＝１／２＝０．５であるものとする。つまり、この場合、スライディングウィンドウ内に、５個以上の抽出タイムスロットが含まれる場合に、ステップ５０においてＹＥＳと判定される。
【００６７】
図１１の例では、点線よりパケット数の多いタイムスロットがまず抽出される。そして、スライディングウィンドウＡの開始位置Tが最初の連続性判定開始位置となり、スライディングウィンドウＡには、８個の抽出タイムスロットが含まれるので、ステップ５０においてＹＥＳと判定され、連続性判定開始位置がスライディングウィンドウＢの開始位置までずらされ、同様の判定処理及び連続性判定開始位置をずらす処理等が繰り返される。
【００６８】
図１１の例では、スライディングウィンドウＥには、５個の抽出タイムスロットが含まれるが、スライディングウィンドウＦには、４個の抽出タイムスロットしか含まれず、ここではステップ５０の判定はＮｏになる。従って、スライディングウィンドウＡの開始位置Ｔから、スライディングウィンドウEの終了位置（Ｔ＋Ｃ＋Ｌ）までの時間区間が、ユーザ待ち時間に対応する連続区間であるとして記憶手段に記録されることになる。
【００６９】
上述した本実施の形態における技術を用いることにより、安定したネットワーク環境において、ユーザ待ち時間に対応する連続区間を適切に推定することが可能となる。TCPパケットを用いる場合において、TCPヘッダの中の情報から、データ転送開始及び終了を判定することにより、ユーザ待ち時間に対応する連続区間を推定することも考えられるが、ユーザ待ち時間の中で、TCP上でのデータ転送開始及び終了が連続的に複数回発生する場合があるので、TCPヘッダの中の情報からでは、適切にユーザ待ち時間を推定することはできない。
【００７０】
本実施の形態のように、TCPベースのアプリケーションサーバ２からユーザ端末３に送信されるパケットが、ある程度の短い時間間隔で連続的に発生している場合はユーザの待ちが継続していると判定する手法により、より適切にユーザ待ち時間を推定することが可能になる。
【００７１】
上記の例において、タイムスロットの時間幅W、スライディングウィンドウの時間長さL、及び、連続性判定閾値Ｓについては、実験等により適切な値を定めればよいが、安定したネットワーク環境での一例として、タイムスロットの時間幅Wとして０．１を用い、スライディングウィンドウの時間長さLとしてタイムスロット１０個分である１を用い、連続性判定閾値Ｓとして１／２を用いることにより、良好な結果が得られている。
【００７２】
−−−RTTを利用する場合―――
次に、RTTを利用する場合の連続区間の識別処理のフローチャートを図１２に示す。以下では、RTTを利用しない場合との相違点を中心に説明する。
【００７３】
RTTを利用しない場合は、スライディングウィンドウの時間長さＬとして予め定めた長さを用いていたのに対し、RTTを利用する場合の処理は、図１２のステップ３５において、スライディングウィンドウの長さＬをRTTに基づき算出し、それ以降の処理において、RTTに基づき求めたＬを用いて連続区間を判定している。その他の処理については図１０の場合と同じである。より詳細には以下のとおりである。
【００７４】
本実施の形態では、入力部１１は、RTTを求めるためのデータとして、アプリケーションサーバ２からユーザ端末３に向かうパケットの他に、ユーザ端末３からプリケーションサーバ２に向かうパケットのうちの一部のパケットを取得してパケット格納部１２に格納することができる。RTT提供部１６は、パケット格納部１２に格納されたデータを参照することにより、例えば、シーケンス番号で送信パケットとそれに対応する応答パケットを識別し、所定の時間毎のRTTを算出することができる。なお、TCPパケットからRTTを算出すること自体は従来技術である。もちろん、RTT提供部１６は、その他の方法でRTTを算出することとしてもよい。例えば、ユーザ待ち時間推定装置１の外部にある装置でRTTを取得し、その装置からRTTを受信することとしてもよい。
【００７５】
ステップ３５において、連続区間識別部１５は、RTT提供部１６から、連続性判定開始位置に最も近い時刻に対応するRTTを取得する。ここでRTTをＴＲと表すと、連続区間識別部１５は、Ｌ＝（ＴＲ＋Ｗ）×Ｎ（Ｎは自然数）としてＬを求める。例えば、ＴＲ＝０．０１、Ｗ＝０．１、Ｎ＝１０であるとすると、Ｌ＝０．１１×１０＝１．１となる。また、例えば、Ｒ＝０．０５、Ｗ＝０．１、Ｎ＝１０であるとすると、Ｌ＝０．１５×１０＝１．５となる。
【００７６】
ＲＴＴを用いる場合の処理の概念を図１３を用いて説明する。図１３において、（Ａ）で示される部分は、Ｌ＝１．１の場合であり、（Ｂ）で示される部分は、Ｌ＝１．５の場合を示している。図１３に示すとおり、スライディングウィンドウの長さＬをＲＴＴに応じて伸ばすことにより、ＲＴＴの影響でパケットの出現間隔が間延びする場合であっても、適切に連続区間（ユーザ待ち時間が継続していると推定できる区間）を識別できる。
【００７７】
＜サーバ処理時間推定部１８の動作＞
続いて、サーバ処理時間推定部１８により、サーバ処理時間推定処理が実行される（図５のステップ５）。まず、サーバ処理時間推定部１８による処理の概要を、図１４に示す概念図を用いて説明する。
【００７８】
TCPの通信では、ユーザ端末３からアプリケーションサーバ２に対するデータ（この例ではサーバ２に対する処理要求に係るデータ）の送信が完了した場合に、アプリケーションサーバ２からユーザ端末３に対して、データの受信が完了したことを示すTCPパケットであるデータなしのACKパケット（TCPヘッダのACKフラグがONであるパケット）が送信される。このACKパケットには、ユーザ端末３から受信したデータに対応するACK番号（図１４の例では１００）が含まれている。このACK番号は、これ以降、ユーザ端末３からデータを受信しない限り変化しない番号である。
【００７９】
ACKパケット送信の後、アプリケーションサーバ２ではデータ書き込み等の処理が行われ、この時間区間では、ユーザ端末３に対してパケットは送信されない。また、アプリケーションサーバ２が高負荷の状態にある場合には、この時間区間は長くなる。
【００８０】
アプリケーションサーバ２での処理が終了すると、アプリケーションサーバ２は、処理が終了したことを示すデータを載せたTCPパケットをユーザ端末３に送信する。
【００８１】
データなしのACKパケットを送信した以降、この時点までで、アプリケーションサーバ２はユーザ端末３からデータを受信していないので、このTCPパケットのACK番号は、データなしのACKパケットにおけるACK番号と同じ１００である。
【００８２】
以上の処理内容から、アプリケーションサーバ２からユーザ端末３に対して、データなしのACKパケットが送信された時刻から、アプリケーションサーバ２からユーザ端末３に対して、データ付きのTCPパケットであって、ACK番号が、上記ACKパケットと同じパケットが送信された時刻までの時間が、アプリケーションサーバ２による処理時間であると推定できる。
【００８３】
本実施の形態では、以上の原理を利用して、アプリケーションサーバ２による処理時間を推定している。もちろん、TCPヘッダから判定可能な方法であれば、上記以外の方法を用いてサーバ処理時間を推定してもよい。
【００８４】
以下、図１５のフローチャートを参照して、サーバ処理時間推定部１８の処理を説明する。
【００８５】
まず、サーバ処理時間推定部１８は、トラヒック分類部１３により抽出されたパケット群（例：図８）を取得する（ステップ１００）。取得したパケット群の各パケットについて１つづつ、時刻の進む順番に、以下の処理が実行されることになる。
【００８６】
サーバ処理時間推定部１８は、処理対象のパケット（＝着目しているパケット）の時刻に対応する閾値を算出する（ステップ１０１）。ここでは、例えば、処理対象のパケットに対応するRTTをRTT提供部１６から取得し、それを閾値とする。もちろん、予め定めた固定値を閾値としてもよい。
【００８７】
次に、サーバ処理時間推定部１８は、処理対象のパケットと、当該パケットの次のパケットとの間の時間間隔が閾値以上か否かを判定する（ステップ１０２）。ここでの判定結果がNoであれば、処理対象のパケットを次のパケットとして、ステップ１０１に戻る（ステップ２０１、２０２）。パケット間の時間間隔が閾値未満といった小さい値であれば、連続区間識別部１５による処理により、連続であると判定される蓋然性が高いからである。
【００８８】
ステップ１０２において、パケット間の時間間隔が閾値以上であると判定された場合、サーバ処理時間推定部１８は、処理対象のパケットがデータなしのACKパケットであるかどうかの判定を行う（ステップ１０３）。ここでの判定結果がNoであれば、処理対象のパケットを次のパケットとして、ステップ１０１に戻る。
【００８９】
ステップ１０３での判定結果がYesである場合、サーバ処理時間推定部１８は、処理対象のパケットの次のパケットが、データ付きのTCPパケットであり、かつ、処理対象のパケットのACK番号と同じACK番号を有するかどうかの判定を行う（ステップ１０４）。ここでの判定結果がNoであれば、処理対象のパケットを次のパケットとして、ステップ１０１に戻る。
【００９０】
ステップ１０４での判定結果がＹｅｓである場合、サーバ処理時間推定部１８は、処理対象のパケットと、当該パケットの次のパケットとの間の時間間隔をサーバ処理時間として算出し、当該サーバ処理時間を、処理対象のパケットの時刻と、当該パケットの次のパケットの時刻とともに、メモリ等の記憶手段に記録する（ステップ１０５）。そして、次のパケットを処理対象のパケットとして、ステップ１０１に戻る。全てのパケットの処理が終了すれば、サーバ処理時間推定処理を終了する（ステップ２０１、２０３）。
【００９１】
＜マージ処理部１９の処理＞
サーバ処理時間推定処理が終了した後、マージ処理部１９は、連続区間識別部１５により得られた連続区間群と、サーバ処理時間推定部１８により得られたサーバ処理時間群とを参照し、各サーバ処理時間に関して、サーバ処理時間と時間的に連続している連続区間が存在するか否かをチェックし、存在する場合に、サーバ処理時間と連続区間とを結合（マージ）し、結合された時間区間を、推定されたユーザ待ち時間として出力部１７に渡す処理を行う（図５のステップ６）。また、マージ処理部１９は、サーバ処理時間と結合されない連続区間に関しては、当該連続区間そのものを推定されたユーザ待ち時間として出力部１７に渡す。
【００９２】
この処理を、図１６を参照してより具体的に説明する。図１６は、パケット数集計部１４により集計された結果のヒストグラムを表す図である。図１６の例において、連続区間識別部１５により、連続区間Ａ（開始時刻ＳＡ、終了時刻ＥＡとする）と連続区間Ｂ（開始時刻ＳＢ、終了時刻ＥＢとする）が識別されたものとする。更に、サーバ処理時間推定部１８により、サーバ処理時間Ｃ（開始時刻ＳＣ、終了時刻ＥＣ）が推定されたものとする。
【００９３】
マージ処理部１９は、サーバ処理時間Ｃの開始時刻ＳＣと一致するか、又は、開始時刻ＳＣとの差の絶対値が所定の閾値以下である終了時刻を持つ連続区間を、連続区間識別部１５により得られた連続区間群を参照して検索し、連続区間Ａを抽出する。また、マージ処理部１９は、サーバ処理時間Ｃの終了時刻ＥＣと一致するか、又は、終了時刻ＥＣとの差の絶対値が所定の閾値以下である開始時刻を持つ連続区間を、連続区間識別部１５により得られた連続区間群を参照して検索し、連続区間Ｂを抽出する。
【００９４】
そして、マージ処理部１９は、連続区間Ａ、サーバ処理時間Ｃ、及び連続区間Ｂを結合した時間区間（連続区間Ａの開始時刻ＳＡから連続区間Ｂの終了時刻ＥＢまでの時間区間）をユーザ待ち時間として出力部１７に渡す。
【００９５】
仮に、連続区間Ｂが検出されずに、連続区間Ａとサーバ処理時間Ｃが結合された場合は、連続区間Ａの開始時刻ＳＡからサーバ処理時間Ｃの終了時刻ＥＣまでの時間区間が、ユーザ待ち時間として出力部１７に渡される。また、仮に、連続区間Ａが検出されずに、サーバ処理時間Ｃと連続区間Ｂとが結合された場合は、サーバ処理時間Ｃの開始時刻ＳＣから連続区間Ｂの終了時刻ＥＢまでの時間区間が、ユーザ待ち時間として出力部１７に渡される。また、いずれのサーバ処理時間も、連続区間Ａと連続区間Ｂに結合されなかった場合には、マージ処理部１９は、連続区間Ａと連続区間Ｂのそれぞれをユーザ待ち時間として出力部１７に渡す。
【００９６】
その後は、出力部１７が、マージ処理部１９からの結果を出力する（図５のステップ７）。例えば、出力部１７は、ユーザ待ち時間情報として、対象となっているアプリケーションサーバ２のIPアドレス及びポート番号、ユーザ端末３に対応するIPアドレス及びポート番号、及び、推定されたユーザ待ち時間の開始時刻と終了時刻を出力する。また、ユーザ端末３に対応するIPアドレス及びポート番号から、ユーザ端末もしくはユーザの名前を識別可能である場合には、ユーザ端末もしくはユーザの名前を出力してもよい。
【００９７】
出力部１７から出力された情報は、例えば、ネットワーク管理者の端末に転送され、表示される。
【００９８】
（実施の形態の効果について）
上記のように、本実施の形態で説明した技術によれば、アプリケーションサーバ２からユーザ端末３に向けて送信されたパケットを取得することによりユーザ待ち時間を推定できるので、ユーザ端末とサーバ間で双方向に送受信されるパケットを取得しなければならない従来技術に比べて、取得すべきデータ量を削減できる。また、本実施の形態の技術では、トランスポート層よりも上位の層のプロトコルに係るヘッダの内容等を参照する必要がないので、トランスポート層よりも上位の層に対して暗号化を行うプロトコルが使用された場合でも、ユーザ待ち時間を推定することが可能になる。
【００９９】
また、本実施の形態の技術では、RTTに応じてスライディングウィンドウの時間長さを変更することが可能なので、通信ネットワークの状況に応じたユーザ待ち時間を推定できる。
【０１００】
更に、アプリケーションサーバ２がストレージ系アプリケーションサーバである場合や、アプリケーションサーバ２が高負荷となる場合のように、ユーザ端末３にTCPパケットを送信せずに処理を行うサーバ処理時間が長くなる場合があったとしても、本実施の形態の技術によれば、サーバ処理時間をパケットのTCPヘッダから推定し、連続区間と結合し、結合された時間区間をユーザ待ち時間と推定するので、より実際に近いユーザ待ち時間を求めることができる。
【０１０１】
本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。
【符号の説明】
【０１０２】
１ ユーザ待ち時間推定装置
２ アプリケーションサーバ
３ ユーザ端末
４ 通信ネットワーク
１１ 入力部
１２ パケット格納部
１３ トラヒック分類部
１４ パケット数集計部
１５ 連続区間識別部
１６ RTT提供部
１７ 出力部
１８ サーバ処理時間推定部
１９ マージ処理部
【技術分野】
【０００１】
本発明は、クライアント／サーバ型のTCPベースアプリケーションを利用するユーザが、ユーザ端末上で体感する待ち時間を推定するための技術に関するものである。
【背景技術】
【０００２】
クライアント／サーバ型のTCPベースのアプリケーションが広く普及している。当該アプリケーションをユーザが快適に使用するためには、ユーザがユーザ端末に対する操作を行ってから、当該操作に対する結果がユーザ端末の画面上に表示されるまでの時間である待ち時間（以下、これをユーザ待ち時間と呼ぶ）が短いことが好ましい。そのため、アプリケーションの品質を評価するにあたって、ユーザ待ち時間は重要な指標の一つであり、ユーザ待ち時間を適切に推定することが求められている。
【０００３】
ユーザ待ち時間を推定する従来技術としては、事前評価型とインサービス評価型がある。
【０００４】
事前評価型の技術は、実際の利用環境ではなく、擬似的な利用環境を用いて、被験者にアプリケーションを利用してもらい、待ち時間を計測するものである。また、擬似的な利用環境で、擬似クライアントを用いて待ち時間を計測する技術もある。
【０００５】
インサービス評価型の技術としては、サーバに蓄積されたログを解析することによりユーザ待ち時間を推定する技術、サーバとユーザ端末間で送受信される情報を収集、解析し、解析結果からユーザ待ち時間を推定する技術、実際の利用環境で擬似クライアントプログラムをユーザ端末で実行させることにより待ち時間を計測する技術等がある。
【０００６】
なお、先行技術文献として、TCP上でのデータ転送における遅延等の品質を推定する技術を開示した特許文献１がある。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００４−１４０５９６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、従来の事前評価型の技術では、実際にユーザがアプリケーションを利用しているときのユーザ待ち時間を推定することができない。従って、通信ネットワークの状況等に応じて変化する場合があるユーザ待ち時間を適切に推定できない。また、事前評価型の技術では、通信ネットワークの状況等によりユーザ待ち時間が悪化した場合等に、それに対する対応をとるといったことができない。
【０００９】
インサービス評価型の技術を用いることにより、事前評価型の問題を解決できる。しかし、従来のインサービス評価型の技術には次のような問題がある。
まず、サーバに蓄積されたログを解析することによりユーザ待ち時間を推定する技術では、サーバでの処理時間に関わる時間しか推定できず、通信ネットワークに起因するユーザ待ち時間の変化等を把握することができない。
【００１０】
また、擬似クライアントプログラムを用いる技術では、サーバ及び通信ネットワークに測定用のオーバヘッドを生じさせることになり、測定に起因してアプリケーションの品質劣化等が生じてしまう可能性があるという問題がある。
【００１１】
また、サーバとユーザ端末間で送受信される情報を収集、解析する従来の技術では、ユーザ待ち時間を推定するために、ユーザ端末とサーバ間で双方向に送受信される全てのデータを取得する必要があり、取得するべきデータのサイズが非常に大きくなってしまうという問題がある。更に、従来技術では、トランスポート層よりも上位の層までの情報を解析する必要があるため、ＨＴＴＰＳのようなトランスポート層よりも上位の層に対して暗号化を行うプロトコルが使用された場合、取得した情報の解析が不可能となり、ユーザ待ち時間の算出が行えないという問題がある。
【００１２】
本発明は上記の点に鑑みてなされたものであり、ユーザ端末とサーバ間で送受信されるデータを取得することによりユーザ待ち時間を推定する技術において、取得するべきデータのサイズを軽減し、トランスポート層よりも上位の層に対して暗号化を行うプロトコルが使用された場合でも、ユーザ待ち時間を推定することを可能とした技術を提供することを目的とする。
【課題を解決するための手段】
【００１３】
上記の課題を解決するために、本発明は、TCPベースのアプリケーションサービスを提供するアプリケーションサーバに通信ネットワークを介して接続され、前記アプリケーションサービスを利用するユーザ端末におけるユーザ待ち時間を推定するユーザ待ち時間推定装置であって、前記アプリケーションサーバから前記ユーザ端末に向けて送信された各パケットを取得し、当該パケットを取得した時刻の情報とともに、当該パケットを記憶手段に格納するパケット取得手段と、前記パケット取得手段により取得されたパケット群から、予め定めた時間幅を有するタイムスロット毎のパケット数を算出するパケット数集計手段と、前記パケット数集計手段により算出されたタイムスロット毎のパケット数に基づき、パケット数が予め定めた検知閾値以上であるタイムスロット群を、抽出タイムスロット群として抽出する抽出手段と、所定のウィンドウ時間長を有するスライディングウィンドウを定め、スライディングウィンドウに含まれる抽出タイムスロットの合計時間と前記ウィンドウ時間長とに基づき、スライディングウィンドウを時間進行方向にずらしながら、パケットが連続して出現した時間区間である連続区間を識別する連続区間識別手段と、前記パケット取得手段により取得された各パケットにおけるTCPヘッダ情報を参照することにより、前記アプリケーションサーバが前記ユーザ端末にTCPパケットを送信せずに処理を行った時間であるサーバ処理時間を推定するサーバ処理時間推定手段と、前記連続区間識別手段により識別された連続区間と、前記サーバ処理時間推定手段により推定されたサーバ処理時間とが時間的に連続しているか否かを判定し、連続している場合に、前記連続区間と前記サーバ処理時間とを結合する結合処理手段と、前記結合処理手段により結合された時間区間を、推定されたユーザ待ち時間として出力する出力手段とを備えることを特徴とするユーザ待ち時間推定装置として構成される。
【００１４】
前記サーバ処理時間推定手段は、データなしのACKパケットであると識別された対象パケットの次のパケットがデータ付きのTCPパケットであり、なおかつ、当該次のパケットのACK番号が、前記対象パケットのACK番号と同じであると判定した場合に、前記対象パケットの時刻から前記次のパケットの時刻までを前記サーバ処理時間とするように構成できる。
【００１５】
また、前記連続区間識別手段は、ある抽出タイムスロットに対応する連続性判定開始位置から時間進行方向に伸びるスライディングウィンドウに含まれる抽出タイムスロットの合計時間を算出し、前記ウィンドウ時間長に対する前記合計時間の割合が予め定めた閾値以上であるか否かを判定する判定手段と、前記判定手段により、前記ウィンドウ時間長に対する前記合計時間の割合が前記予め定めた閾値以上であると判定された場合に、連続性判定開始位置を次の抽出タイムスロットにずらし、当該ずらした連続性判定開始位置に基づき前記判定手段による処理を行うスライディング手段と、前記判定手段と前記スライディング手段による処理を、前記ウィンドウ時間長に対する前記合計時間の割合が前記予め定めた閾値未満であると判定されるまで繰り返し行い、最初の連続性判定開始位置から、最後に前記合計時間の割合が前記閾値以上であると判定されたスライディングウィンドウの末尾までの時間を前記パケットが連続して出現した時間区間であると決定する手段とを備えるように構成することができる。
【発明の効果】
【００１６】
本発明によれば、アプリケーションサーバからユーザ端末に向けて送信されたパケットを取得することによりユーザ待ち時間を推定できるので、ユーザ端末とサーバ間で双方向に送受信されるパケットを取得しなければならない従来技術に比べて、取得すべきデータ量を削減できる。また、本発明では、トランスポート層よりも上位の層のプロトコルに係るヘッダの内容等を参照する必要がないので、トランスポート層よりも上位の層に対して暗号化を行うプロトコルが使用された場合でも、ユーザ待ち時間を推定することが可能になる。
【００１７】
更に、アプリケーションサーバにおいて、ユーザ端末にTCPパケットを送信せずに処理を行うサーバ処理時間が長くなる場合があったとしても、本発明によれば、サーバ処理時間をパケットのTCPヘッダから推定し、連続区間と結合し、結合された時間区間をユーザ待ち時間と推定するので、より実際に近いユーザ待ち時間を求めることができる。
【図面の簡単な説明】
【００１８】
【図１】本発明の実施の形態に係るシステムの全体構成図である。
【図２】「ユーザ待ち時間」を説明するための図である。
【図３】「ユーザ待ち時間」を説明するための図である。
【図４】ユーザ待ち時間推定装置１の機能構成図である。
【図５】ユーザ待ち時間推定装置１の動作を説明するためのフローチャートである。
【図６】パケット格納部１２に格納されるパケットの例を示す図である。
【図７】パケット格納部１２に格納されるパケットの例を示す図である。
【図８】トラヒック分類部１３により分類されたパケットの例を示す図である。
【図９】パケット数集計部１４により得られた集計結果を示すヒストグラムである。
【図１０】連続区間識別部１５が実行する処理を説明するためのフローチャートである。
【図１１】連続区間識別部１５が実行する処理を説明するための概念図である。
【図１２】連続区間識別部１５が実行する処理を説明するためのフローチャートである。
【図１３】連続区間識別部１５が実行する処理を説明するための概念図である。
【図１４】サーバ処理時間推定部１８が実行する処理を説明するための概念図である。
【図１５】サーバ処理時間推定部１８が実行する処理を説明するためのフローチャートである。
【図１６】マージ処理部１９が実行する処理を説明するための概念図である。
【発明を実施するための形態】
【００１９】
以下、図面を参照して本発明の実施の形態を説明する。
【００２０】
（システム構成）
図１に、本発明の実施の形態に係るユーザ待ち時間推定装置１を含むシステムの全体構成図を示す。
【００２１】
図１に示すように、本実施の形態に係るシステムは、ユーザ待ち時間推定装置１、アプリケーションサーバ２、ユーザ端末３を備え、これらが通信ネットワーク４に接続されて構成されている。
【００２２】
アプリケーションサーバ２は、アプリケーションサービスをユーザ端末３に対して提供するサーバである。アプリケーションサーバ２が提供するアプリケーションサービスは、例えば、Webページ提供サービス、ストレージ系サービス等である。
【００２３】
ユーザ待ち時間推定装置１は、アプリケーションサーバ２と通信を行うユーザ端末３を操作するユーザが体感する待ち時間を推定する装置である。また、ユーザ端末３は、Webブラウザ等を備えた一般的なPC端末である。通信ネットワーク４は、インターネットやLAN等を含むIP（Internet Protocol）によるデータ通信可能なネットワークである。
【００２４】
また、アプリケーションサーバ２とユーザ端末３間で送受信される全てのパケット（ＩＰパケット）をユーザ待ち時間推定装置１が受信できるように通信ネットワーク４が構成されているものとする。例えば、ユーザ待ち時間推定装置１は、通信ネットワーク４内で、アプリケーションサーバ２を接続するLANスイッチのミラーポートに接続される。
【００２５】
ただし、ユーザ待ち時間推定装置１は、必ずしも通信ネットワーク４から直接にパケットを取得しなくてもよい。例えば、通信ネットワーク４から他の装置により取得されたパケットを、当該装置からユーザ待ち時間推定装置１に入力する構成としてもよい。
【００２６】
なお、本実施の形態では、ユーザ端末３とアプリケーションサーバ２間におけるデータ通信のトランスポート層のプロトコルとしてTCP（Transmission Control Protocol）を用いることを前提としている。TCPは、フロー制御等の制御のための通信が頻繁に発生するとともに、要求に対応する応答が必ず発生するので、本発明に係る技術に適しているからである。また、図１では、アプリケーションサーバ２とユーザ端末３がそれぞれ１つづつ示されているが、それぞれ複数台備えられてよいことはいうまでもない。
【００２７】
次に、図２を参照して、本実施の形態に係る"ユーザ待ち時間"について説明する。図２は、アプリケーションサーバ２とユーザ端末３間でのTCPの通信シーケンスの概要を表している図である。
【００２８】
図２に示すように、ユーザがユーザ端末３上で、所望の表示結果を得るための所定の操作（例えば、ブラウザ画面上に表示された特定のボタンをクリックする操作）を行うと、パケットがアプリケーションサーバ２とユーザ端末３間で送受信され、上記操作に対応する結果（例えば、表示されることを期待していたWebページ画面）がユーザ端末３上に表示される。
【００２９】
図３に、ユーザ待ち時間の別の例を示す。図３で示す例は、ストレージ系のアプリケーションの例であり、アプリケーションサーバ２側において、TCPパケットをユーザ端末３に返すことなく行う処理（この例ではデータのHDDへの書き込み処理）にある程度の時間を要する場合の例である。
【００３０】
図３の例では、ユーザによる操作（データのアップロード指示等）を行ってから、アプリケーションサーバ２とユーザ端末３間での連続的なパケットの送受信を経て、アプリケーションサーバ２において上記の書き込み処理が行われて、その後、アプリケーションサーバ２とユーザ端末３間での連続的なパケットの送受信を経て、ユーザ端末３上に、操作に対応する結果（例えば、アップロードが終了したことを示す画面）が表示される。この場合、図３に示す時刻Aから時刻Bまでがユーザ待ち時間となる。本実施の形態の技術では、このような場合のユーザ待ち時間も適切に求めることができる。
【００３１】
本明細書及び特許請求の範囲では、上記のように所定の操作を行った時刻から、当該所定の操作に対応する結果が表示される時刻までをユーザ待ち時間としている。
【００３２】
図４に、本実施の形態に係るユーザ待ち時間推定装置１の機能構成図を示す。図４に示すように、ユーザ待ち時間推定装置１は、入力部１１、パケット格納部１２、トラヒック分類部１３、パケット数集計部１４、連続区間識別部１５、RTT（Round Trip Time）提供部１６、出力部１７、サーバ処理時間推定部１８、及びマージ処理部１９を有する。
【００３３】
各機能部の処理の内容については、後述するシステムの動作説明のところで詳細に説明することとし、以下では各機能部の機能の概要を説明する。
【００３４】
入力部１１は、ユーザ端末３とアプリケーションサーバ２間で送受信されるパケットのうち、アプリケーションサーバ２からユーザ端末３に向かうパケットを通信ネットワーク４等から取得し、各パケットにタイムスタンプ（現在時刻、パケットを取得した時刻）を付してパケット格納部１２に格納する機能部である。
【００３５】
トラヒック分類部１３は、アプリケーションサーバ２からユーザ端末３に向かうパケットを宛先毎に分類する機能部である。パケット数集計部１４は、特定のユーザ端末宛であると識別されたパケット群毎に、予め定めた時間幅（タイムスロット）毎のパケット数を算出する処理を行う機能部である。
【００３６】
連続区間識別部１５は、パケット数集計部１４により得られた予め定めた時間幅毎のパケット数を用いて、所定の時間幅内に一定量以上のパケットが連続して出現しているか否かを識別することにより、ユーザによる待ち時間が継続していると推定できる時間区間である連続区間を求める機能部である。
【００３７】
また、RTT提供部１６は、RTT（Round Trip Time:ユーザ端末３からアプリケーションサーバ２にパケットを送信して、確認応答パケットがアプリケーションサーバ２からユーザ端末３に返されるまでの時間）を取得し、それを連続区間識別部１５及びサーバ処理時間推定部に提供する機能部である。
【００３８】
サーバ処理時間推定部１８は、トラヒック分類部１３により抽出されたパケットにおけるTCPヘッダの情報を参照することにより、ユーザ端末３からアプリケーションサーバ２への処理要求（例えば、データアップロード処理要求）に関するデータ送信完了を把握するとともに、当該処理要求に対応した処理完了の応答を把握することにより、TCPパケットがユーザ端末３に返されることなくアプリケーションサーバ２で実行された処理の時間を推定する機能部である。
【００３９】
マージ処理部１９は、連続区間識別部１５で算出された連続区間と、サーバ処理時間推定部１８で算出されたサーバ処理時間とを結合する機能部である。
【００４０】
出力部１７は、マージ処理部１９により得られた時間区間を、推定されたユーザ待ち時間の情報として出力する機能部である。
【００４１】
ユーザ待ち時間推定装置１は、メモリやハードディスク等の記憶手段及びCPUを備える一般的なコンピュータに、各機能部に対応する処理を行うためのプログラムを搭載することにより実現できる。当該プログラムは、可搬メモリやディスク等の記録媒体から上記コンピュータにインストールしてもよいし、ネットワーク上のサーバから上記コンピュータにダウンロードし、インストールすることとしてもよい。
【００４２】
（システムの動作）
次に、ユーザ待ち時間推定装置１の動作の例を、図５のフローチャートに沿って説明する。まず、ユーザ待ち時間推定装置１の入力部１１は、通信ネットワーク４から、アプリケーションサーバ２を送信元とするパケットを順次取得し、取得した時刻の情報であるタイムスタンプを付してパケット格納部１２に格納する（図５のステップ１）。
【００４３】
ユーザ待ち時間推定装置１は、特定のアプリケーションサーバ２から送信されるパケットを常にパケット格納部１２に格納し、当該アプリケーションサーバ２に関するユーザ待ち時間推定の必要が生じたときに、特定の時間区間に取得されたパケットを解析の対象としてもよいし、ユーザ指示等により特定の時間区間だけパケット収集を行い、そこで収集されたパケットを解析の対象としてもよい。また、常にパケットをパケット格納部１２に格納し、一定時間毎に特定のアプリケーションサーバに関するユーザ待ち時間推定処理を実行することとしてもよい。もちろん、その他の形態を用いてもよい。
【００４４】
パケット格納部１２に格納されるパケットの例を図６（ａ）に示す。例えば、図６（ａ）の第１行目は、送信元IPアドレスがIPアドレス１、送信元ポート番号がポート番号１、宛先IPアドレスがIPアドレス３、宛先ポート番号がポート番号１であるIPパケットが、時刻１に取得され、格納されたことを示している。他の行も同様である。
【００４５】
なお、図６（ａ）では、宛先IPアドレスがIPアドレス３であるIPパケットのみを示しているが、一般には、種々の宛先IPアドレスのIPパケットが取得される。また、パケット格納部１２に格納する対象となるパケットの送信元ＩＰアドレスと宛先ＩＰアドレスとを予め決めている場合には、取得したパケットからＩＰヘッダを除き、TCPヘッダが付されたTCPパケットの形式でパケット格納部１２に格納することとしてもよい。
【００４６】
続いて、図５のステップ２において、トラヒック分類部１３が、パケット格納部１２に格納されたパケットを、宛先ユーザ端末毎に分類する処理を行う。分類にあたって、本実施の形態では、宛先IPアドレスと宛先ポート番号の１つの組が１つの宛先ユーザ端末に対応するものとし、宛先IPアドレスと宛先ポート番号の組毎にパケットを分類する処理を行う。
【００４７】
ただし、NAT経由の通信等の場合に、１つの宛先ユーザ端末に対して、１つの宛先IPアドレスと、連続する複数の宛先ポート番号が割り当てられる場合があることを考慮して、同じ宛先IPアドレスの複数のパケットであって、連続するポート番号を有する複数のパケットが所定の短い時間（例えば０．５秒）内に現れた場合は、それらのパケットは１つのユーザ端末宛のパケットであるとみなしている。
【００４８】
例えば、パケット格納部１２に格納されたパケットが図６（ａ）に示すとおりのものであった場合、宛先IPアドレスは同一なので、トラヒック分類部１３は、図６（ｂ）に示すようにパケットを分類（ソート）する。図６（ｂ）の例において、宛先ポート番号１のIPパケットはユーザ端末A宛てのパケット、宛先ポート番号８のパケットはユーザ端末Aと異なるユーザ端末B宛てのパケットなどとみなすことができる。
【００４９】
また、例えば、パケット格納部１２に格納されたパケットが図７（ａ）に示すようなものであり、時刻１から時刻４までの時間及び時刻５から時刻７までの時間のそれぞれが所定の時間より短い場合、トラヒック分類部１３は、パケットを図７（ｂ）に示すように分類する。図７（ｂ）の例において、宛先ポート番号１〜４のパケットはユーザ端末Ｘ宛てのパケット、宛先ポート番号１０〜１２のパケットはユーザ端末Ｘと異なるユーザ端末Ｙ宛てのパケットとみなすことができる。
【００５０】
なお、以下で説明する処理は、分類されたパケット群のうち、特定の１つのユーザ端末宛のパケットに対する処理であるものとする。また、分類がなされたパケットは、パケット格納部１２に格納してもよいし、パケット格納部１２以外のメモリ等の記憶手段に格納してもよい。
【００５１】
また、宛先ユーザ端末毎に分類されたパケットを取得する方法は、上記の方法に限られるわけではなく、結果として、宛先ユーザ端末毎に分類されたパケットを取得できるのであればどのような手段を用いてもよい。
【００５２】
次に、図５のステップ３において、ユーザ待ち時間推定装置１のパケット数集計部１４は、分類されたパケットについて、予め定めた時間幅（Ｗで表し、タイムスロットとも呼ぶ）毎の個数を算出する処理を行う。
【００５３】
例えば、トラヒック分類部１３により、図８に示すパケットが、アプリケーションサーバ２からユーザ端末３宛（ＩＰアドレス３及び宛先ポート番号１０で識別されるユーザ端末）のパケットとして抽出されたものとする。また、例えば、タイムスロットの大きさＷとして０．１秒（以下、時間の単位は秒であるとする）を使用するものとする。
【００５４】
この場合、パケット数集計部１４は、時刻０から時刻０．１の間のタイムスロットのパケット数を３として求め、時刻０．１から時刻０．２の間のタイムスロットのパケット数を４として求める。他のタイムスロットでも同様である。このようにして算出した結果から、図９に示すヒストグラムが得られる。
【００５５】
＜連続区間識別部１５の動作＞
続いて、図５のステップ４において、連続区間識別部１５が、パケット数集計部１４により得られたタイムスロット毎のパケット数に基づき、ユーザ待ち時間が継続していると推定することができるパケットの連続区間を識別する処理を行う。
【００５６】
本実施の形態では、連続区間識別部１５は、ユーザ端末３からアプリケーションサーバ２にパケットが送信されてから、確認応答パケットがアプリケーションサーバ２からユーザ端末３に返されるまでの時間であるRTTを利用して連続区間を識別することもできるし、RTTを利用しないで連続区間を識別することもできる。RTTを利用するかしないかは、例えば、アプリケーションサーバ２の位置（国内か外国か等）や、通信ネットワーク４の状態等で判断し、ユーザによりRTTを利用するかしないかを設定することができる。
【００５７】
―――RTTを利用しない場合―――
まず、RTTを利用しない場合の処理について、図１０のフローチャート、及び、図１１に示す処理の概念図を用いて説明する。
【００５８】
なお、以下の処理の前提として、タイムスロットにおけるパケット数の閾値である検知閾値と、スライディングウィンドウの時間長さＬと、連続性判定閾値Ｓとが予め連続区間識別部１５に入力され、メモリ等に保持されているものとする。
【００５９】
まず、図１０のステップ１０において、連続区間識別部１５は、パケット数が検知閾値以上の全てのタイムスロットを抽出する。ここで、検知閾値は、０以上の整数である。検知閾値は、対象とする通信（ユーザによる操作に起因する通信）以外の通信に係るパケットを、ユーザ待ち時間推定において検知しないようにするために設けられるものである。また、各タイムスロットは、その開始時間位置と終了時間位置で識別される情報である。ステップ１０の処理は、図１１において、パケット数が点線と重なるか、点線を越えているタイムスロットを抽出する処理に相当する。以下、ここで抽出されたタイムスロットを、抽出タイムスロットと呼ぶ。
【００６０】
次に、図１０のステップ２０において、連続区間識別部１５は、複数の抽出タイムスロットのうちの、後述する連続性判定開始位置になったことがない抽出タイムスロットの中で、時間的に最初に位置する抽出タイムスロットの開始位置（時刻Ｔとする）を特定する。
【００６１】
そして、連続区間識別部１５は、連続区間識別のためにスライディングウィンドウをずらす時間長さを示す変数であるＣを初期化（Ｃ＝０とする）する（ステップ３０）。続いて、連続区間識別部１５は、上記抽出タイムスロットの開始位置である時刻Ｔから始まるスライディングウィンドウに含まれる抽出タイムスロットの合計の時間長さを求め、スライディングウィンドウの時間長さLに対する当該抽出タイムスロットの合計の時間長さの割合Ｒを求める（ステップ４０）。以下では、スライディングウィンドウの開始位置を連続性判定開始位置と呼ぶことにする。
【００６２】
ステップ４０において、タイムスロットの時間幅がＷであり、連続性判定開始位置から始まるスライディングウィンドウの時間長さＬの中に、抽出タイムスロット（パケット数が検知閾値以上のタイムスロット）がＭ個含まれるとした場合、抽出タイムスロットの合計の時間長さはＷ×Ｍであるから、Ｒ＝Ｗ×Ｍ／Ｌとなる。また、図１１の場合について、タイムスロットの幅を０．１、各スライディングウィンドウの長さを１とすると、スライディングウィンドウＡの中に、８個の抽出タイムスロットが含まれるから、Ｒ＝０．１×８／１＝０．８となる。
【００６３】
続いて、連続区間識別部１５は、Ｒが連続性判定閾値Ｓ以上であるか否かを判定する（ステップ５０）。本実施の形態において、Ｓは、０から１の間の定数であり、例えばＳ＝０．５である。
【００６４】
ステップ５０において、Ｒが連続性判定閾値Ｓ以上であると判定された場合、連続区間識別部１５は、連続性判定開始位置を、時間進行方向において次に位置する抽出タイムスロットの開始位置とする。また、連続性判定開始位置をずらした長さ（前の連続性判定開始位置から次の連続性判定開始位置までの時間）をＫとし、Ｃ＝Ｃ＋Ｋとする（ステップ６０）。その後、ステップ４０に戻る。
【００６５】
また、ステップ５０において、Ｒが連続性判定閾値Ｓ以上でないと判定された場合、連続区間識別部１５は、ステップ７０に進み、Ｃ＝Ｃ−Ｋとするとともに、ＴからＴ＋Ｃ＋Ｌの区間を連続区間としてメモリ等の記憶手段に記録し、ステップ２０に戻る。ただし、ステップ５０の判定処理において、一度もＹｅｓの判定がされずに最初からＮｏと判定された場合には、ステップ７０を経ずにステップ２０に戻る。ステップ２０において、現在の連続性開始判定位置の次の抽出タイムスロットの開始位置がＴとなり、それ以降の処理が繰り返される。ここで、次の抽出タイムスロットが存在しなければ処理を終了する（ステップ８０）。
【００６６】
上記の処理の概念を図１１を参照して説明する。図１１の例では、スライディングウィンドウの時間長さがタイムスロット１０個分の長さであり、連続性判定閾値Ｓ＝１／２＝０．５であるものとする。つまり、この場合、スライディングウィンドウ内に、５個以上の抽出タイムスロットが含まれる場合に、ステップ５０においてＹＥＳと判定される。
【００６７】
図１１の例では、点線よりパケット数の多いタイムスロットがまず抽出される。そして、スライディングウィンドウＡの開始位置Tが最初の連続性判定開始位置となり、スライディングウィンドウＡには、８個の抽出タイムスロットが含まれるので、ステップ５０においてＹＥＳと判定され、連続性判定開始位置がスライディングウィンドウＢの開始位置までずらされ、同様の判定処理及び連続性判定開始位置をずらす処理等が繰り返される。
【００６８】
図１１の例では、スライディングウィンドウＥには、５個の抽出タイムスロットが含まれるが、スライディングウィンドウＦには、４個の抽出タイムスロットしか含まれず、ここではステップ５０の判定はＮｏになる。従って、スライディングウィンドウＡの開始位置Ｔから、スライディングウィンドウEの終了位置（Ｔ＋Ｃ＋Ｌ）までの時間区間が、ユーザ待ち時間に対応する連続区間であるとして記憶手段に記録されることになる。
【００６９】
上述した本実施の形態における技術を用いることにより、安定したネットワーク環境において、ユーザ待ち時間に対応する連続区間を適切に推定することが可能となる。TCPパケットを用いる場合において、TCPヘッダの中の情報から、データ転送開始及び終了を判定することにより、ユーザ待ち時間に対応する連続区間を推定することも考えられるが、ユーザ待ち時間の中で、TCP上でのデータ転送開始及び終了が連続的に複数回発生する場合があるので、TCPヘッダの中の情報からでは、適切にユーザ待ち時間を推定することはできない。
【００７０】
本実施の形態のように、TCPベースのアプリケーションサーバ２からユーザ端末３に送信されるパケットが、ある程度の短い時間間隔で連続的に発生している場合はユーザの待ちが継続していると判定する手法により、より適切にユーザ待ち時間を推定することが可能になる。
【００７１】
上記の例において、タイムスロットの時間幅W、スライディングウィンドウの時間長さL、及び、連続性判定閾値Ｓについては、実験等により適切な値を定めればよいが、安定したネットワーク環境での一例として、タイムスロットの時間幅Wとして０．１を用い、スライディングウィンドウの時間長さLとしてタイムスロット１０個分である１を用い、連続性判定閾値Ｓとして１／２を用いることにより、良好な結果が得られている。
【００７２】
−−−RTTを利用する場合―――
次に、RTTを利用する場合の連続区間の識別処理のフローチャートを図１２に示す。以下では、RTTを利用しない場合との相違点を中心に説明する。
【００７３】
RTTを利用しない場合は、スライディングウィンドウの時間長さＬとして予め定めた長さを用いていたのに対し、RTTを利用する場合の処理は、図１２のステップ３５において、スライディングウィンドウの長さＬをRTTに基づき算出し、それ以降の処理において、RTTに基づき求めたＬを用いて連続区間を判定している。その他の処理については図１０の場合と同じである。より詳細には以下のとおりである。
【００７４】
本実施の形態では、入力部１１は、RTTを求めるためのデータとして、アプリケーションサーバ２からユーザ端末３に向かうパケットの他に、ユーザ端末３からプリケーションサーバ２に向かうパケットのうちの一部のパケットを取得してパケット格納部１２に格納することができる。RTT提供部１６は、パケット格納部１２に格納されたデータを参照することにより、例えば、シーケンス番号で送信パケットとそれに対応する応答パケットを識別し、所定の時間毎のRTTを算出することができる。なお、TCPパケットからRTTを算出すること自体は従来技術である。もちろん、RTT提供部１６は、その他の方法でRTTを算出することとしてもよい。例えば、ユーザ待ち時間推定装置１の外部にある装置でRTTを取得し、その装置からRTTを受信することとしてもよい。
【００７５】
ステップ３５において、連続区間識別部１５は、RTT提供部１６から、連続性判定開始位置に最も近い時刻に対応するRTTを取得する。ここでRTTをＴＲと表すと、連続区間識別部１５は、Ｌ＝（ＴＲ＋Ｗ）×Ｎ（Ｎは自然数）としてＬを求める。例えば、ＴＲ＝０．０１、Ｗ＝０．１、Ｎ＝１０であるとすると、Ｌ＝０．１１×１０＝１．１となる。また、例えば、Ｒ＝０．０５、Ｗ＝０．１、Ｎ＝１０であるとすると、Ｌ＝０．１５×１０＝１．５となる。
【００７６】
ＲＴＴを用いる場合の処理の概念を図１３を用いて説明する。図１３において、（Ａ）で示される部分は、Ｌ＝１．１の場合であり、（Ｂ）で示される部分は、Ｌ＝１．５の場合を示している。図１３に示すとおり、スライディングウィンドウの長さＬをＲＴＴに応じて伸ばすことにより、ＲＴＴの影響でパケットの出現間隔が間延びする場合であっても、適切に連続区間（ユーザ待ち時間が継続していると推定できる区間）を識別できる。
【００７７】
＜サーバ処理時間推定部１８の動作＞
続いて、サーバ処理時間推定部１８により、サーバ処理時間推定処理が実行される（図５のステップ５）。まず、サーバ処理時間推定部１８による処理の概要を、図１４に示す概念図を用いて説明する。
【００７８】
TCPの通信では、ユーザ端末３からアプリケーションサーバ２に対するデータ（この例ではサーバ２に対する処理要求に係るデータ）の送信が完了した場合に、アプリケーションサーバ２からユーザ端末３に対して、データの受信が完了したことを示すTCPパケットであるデータなしのACKパケット（TCPヘッダのACKフラグがONであるパケット）が送信される。このACKパケットには、ユーザ端末３から受信したデータに対応するACK番号（図１４の例では１００）が含まれている。このACK番号は、これ以降、ユーザ端末３からデータを受信しない限り変化しない番号である。
【００７９】
ACKパケット送信の後、アプリケーションサーバ２ではデータ書き込み等の処理が行われ、この時間区間では、ユーザ端末３に対してパケットは送信されない。また、アプリケーションサーバ２が高負荷の状態にある場合には、この時間区間は長くなる。
【００８０】
アプリケーションサーバ２での処理が終了すると、アプリケーションサーバ２は、処理が終了したことを示すデータを載せたTCPパケットをユーザ端末３に送信する。
【００８１】
データなしのACKパケットを送信した以降、この時点までで、アプリケーションサーバ２はユーザ端末３からデータを受信していないので、このTCPパケットのACK番号は、データなしのACKパケットにおけるACK番号と同じ１００である。
【００８２】
以上の処理内容から、アプリケーションサーバ２からユーザ端末３に対して、データなしのACKパケットが送信された時刻から、アプリケーションサーバ２からユーザ端末３に対して、データ付きのTCPパケットであって、ACK番号が、上記ACKパケットと同じパケットが送信された時刻までの時間が、アプリケーションサーバ２による処理時間であると推定できる。
【００８３】
本実施の形態では、以上の原理を利用して、アプリケーションサーバ２による処理時間を推定している。もちろん、TCPヘッダから判定可能な方法であれば、上記以外の方法を用いてサーバ処理時間を推定してもよい。
【００８４】
以下、図１５のフローチャートを参照して、サーバ処理時間推定部１８の処理を説明する。
【００８５】
まず、サーバ処理時間推定部１８は、トラヒック分類部１３により抽出されたパケット群（例：図８）を取得する（ステップ１００）。取得したパケット群の各パケットについて１つづつ、時刻の進む順番に、以下の処理が実行されることになる。
【００８６】
サーバ処理時間推定部１８は、処理対象のパケット（＝着目しているパケット）の時刻に対応する閾値を算出する（ステップ１０１）。ここでは、例えば、処理対象のパケットに対応するRTTをRTT提供部１６から取得し、それを閾値とする。もちろん、予め定めた固定値を閾値としてもよい。
【００８７】
次に、サーバ処理時間推定部１８は、処理対象のパケットと、当該パケットの次のパケットとの間の時間間隔が閾値以上か否かを判定する（ステップ１０２）。ここでの判定結果がNoであれば、処理対象のパケットを次のパケットとして、ステップ１０１に戻る（ステップ２０１、２０２）。パケット間の時間間隔が閾値未満といった小さい値であれば、連続区間識別部１５による処理により、連続であると判定される蓋然性が高いからである。
【００８８】
ステップ１０２において、パケット間の時間間隔が閾値以上であると判定された場合、サーバ処理時間推定部１８は、処理対象のパケットがデータなしのACKパケットであるかどうかの判定を行う（ステップ１０３）。ここでの判定結果がNoであれば、処理対象のパケットを次のパケットとして、ステップ１０１に戻る。
【００８９】
ステップ１０３での判定結果がYesである場合、サーバ処理時間推定部１８は、処理対象のパケットの次のパケットが、データ付きのTCPパケットであり、かつ、処理対象のパケットのACK番号と同じACK番号を有するかどうかの判定を行う（ステップ１０４）。ここでの判定結果がNoであれば、処理対象のパケットを次のパケットとして、ステップ１０１に戻る。
【００９０】
ステップ１０４での判定結果がＹｅｓである場合、サーバ処理時間推定部１８は、処理対象のパケットと、当該パケットの次のパケットとの間の時間間隔をサーバ処理時間として算出し、当該サーバ処理時間を、処理対象のパケットの時刻と、当該パケットの次のパケットの時刻とともに、メモリ等の記憶手段に記録する（ステップ１０５）。そして、次のパケットを処理対象のパケットとして、ステップ１０１に戻る。全てのパケットの処理が終了すれば、サーバ処理時間推定処理を終了する（ステップ２０１、２０３）。
【００９１】
＜マージ処理部１９の処理＞
サーバ処理時間推定処理が終了した後、マージ処理部１９は、連続区間識別部１５により得られた連続区間群と、サーバ処理時間推定部１８により得られたサーバ処理時間群とを参照し、各サーバ処理時間に関して、サーバ処理時間と時間的に連続している連続区間が存在するか否かをチェックし、存在する場合に、サーバ処理時間と連続区間とを結合（マージ）し、結合された時間区間を、推定されたユーザ待ち時間として出力部１７に渡す処理を行う（図５のステップ６）。また、マージ処理部１９は、サーバ処理時間と結合されない連続区間に関しては、当該連続区間そのものを推定されたユーザ待ち時間として出力部１７に渡す。
【００９２】
この処理を、図１６を参照してより具体的に説明する。図１６は、パケット数集計部１４により集計された結果のヒストグラムを表す図である。図１６の例において、連続区間識別部１５により、連続区間Ａ（開始時刻ＳＡ、終了時刻ＥＡとする）と連続区間Ｂ（開始時刻ＳＢ、終了時刻ＥＢとする）が識別されたものとする。更に、サーバ処理時間推定部１８により、サーバ処理時間Ｃ（開始時刻ＳＣ、終了時刻ＥＣ）が推定されたものとする。
【００９３】
マージ処理部１９は、サーバ処理時間Ｃの開始時刻ＳＣと一致するか、又は、開始時刻ＳＣとの差の絶対値が所定の閾値以下である終了時刻を持つ連続区間を、連続区間識別部１５により得られた連続区間群を参照して検索し、連続区間Ａを抽出する。また、マージ処理部１９は、サーバ処理時間Ｃの終了時刻ＥＣと一致するか、又は、終了時刻ＥＣとの差の絶対値が所定の閾値以下である開始時刻を持つ連続区間を、連続区間識別部１５により得られた連続区間群を参照して検索し、連続区間Ｂを抽出する。
【００９４】
そして、マージ処理部１９は、連続区間Ａ、サーバ処理時間Ｃ、及び連続区間Ｂを結合した時間区間（連続区間Ａの開始時刻ＳＡから連続区間Ｂの終了時刻ＥＢまでの時間区間）をユーザ待ち時間として出力部１７に渡す。
【００９５】
仮に、連続区間Ｂが検出されずに、連続区間Ａとサーバ処理時間Ｃが結合された場合は、連続区間Ａの開始時刻ＳＡからサーバ処理時間Ｃの終了時刻ＥＣまでの時間区間が、ユーザ待ち時間として出力部１７に渡される。また、仮に、連続区間Ａが検出されずに、サーバ処理時間Ｃと連続区間Ｂとが結合された場合は、サーバ処理時間Ｃの開始時刻ＳＣから連続区間Ｂの終了時刻ＥＢまでの時間区間が、ユーザ待ち時間として出力部１７に渡される。また、いずれのサーバ処理時間も、連続区間Ａと連続区間Ｂに結合されなかった場合には、マージ処理部１９は、連続区間Ａと連続区間Ｂのそれぞれをユーザ待ち時間として出力部１７に渡す。
【００９６】
その後は、出力部１７が、マージ処理部１９からの結果を出力する（図５のステップ７）。例えば、出力部１７は、ユーザ待ち時間情報として、対象となっているアプリケーションサーバ２のIPアドレス及びポート番号、ユーザ端末３に対応するIPアドレス及びポート番号、及び、推定されたユーザ待ち時間の開始時刻と終了時刻を出力する。また、ユーザ端末３に対応するIPアドレス及びポート番号から、ユーザ端末もしくはユーザの名前を識別可能である場合には、ユーザ端末もしくはユーザの名前を出力してもよい。
【００９７】
出力部１７から出力された情報は、例えば、ネットワーク管理者の端末に転送され、表示される。
【００９８】
（実施の形態の効果について）
上記のように、本実施の形態で説明した技術によれば、アプリケーションサーバ２からユーザ端末３に向けて送信されたパケットを取得することによりユーザ待ち時間を推定できるので、ユーザ端末とサーバ間で双方向に送受信されるパケットを取得しなければならない従来技術に比べて、取得すべきデータ量を削減できる。また、本実施の形態の技術では、トランスポート層よりも上位の層のプロトコルに係るヘッダの内容等を参照する必要がないので、トランスポート層よりも上位の層に対して暗号化を行うプロトコルが使用された場合でも、ユーザ待ち時間を推定することが可能になる。
【００９９】
また、本実施の形態の技術では、RTTに応じてスライディングウィンドウの時間長さを変更することが可能なので、通信ネットワークの状況に応じたユーザ待ち時間を推定できる。
【０１００】
更に、アプリケーションサーバ２がストレージ系アプリケーションサーバである場合や、アプリケーションサーバ２が高負荷となる場合のように、ユーザ端末３にTCPパケットを送信せずに処理を行うサーバ処理時間が長くなる場合があったとしても、本実施の形態の技術によれば、サーバ処理時間をパケットのTCPヘッダから推定し、連続区間と結合し、結合された時間区間をユーザ待ち時間と推定するので、より実際に近いユーザ待ち時間を求めることができる。
【０１０１】
本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。
【符号の説明】
【０１０２】
１ ユーザ待ち時間推定装置
２ アプリケーションサーバ
３ ユーザ端末
４ 通信ネットワーク
１１ 入力部
１２ パケット格納部
１３ トラヒック分類部
１４ パケット数集計部
１５ 連続区間識別部
１６ RTT提供部
１７ 出力部
１８ サーバ処理時間推定部
１９ マージ処理部
【特許請求の範囲】
【請求項１】
TCPベースのアプリケーションサービスを提供するアプリケーションサーバに通信ネットワークを介して接続され、前記アプリケーションサービスを利用するユーザ端末におけるユーザ待ち時間を推定するユーザ待ち時間推定装置であって、
前記アプリケーションサーバから前記ユーザ端末に向けて送信された各パケットを取得し、当該パケットを取得した時刻の情報とともに、当該パケットを記憶手段に格納するパケット取得手段と、
前記パケット取得手段により取得されたパケット群から、予め定めた時間幅を有するタイムスロット毎のパケット数を算出するパケット数集計手段と、
前記パケット数集計手段により算出されたタイムスロット毎のパケット数に基づき、パケット数が予め定めた検知閾値以上であるタイムスロット群を、抽出タイムスロット群として抽出する抽出手段と、
所定のウィンドウ時間長を有するスライディングウィンドウを定め、スライディングウィンドウに含まれる抽出タイムスロットの合計時間と前記ウィンドウ時間長とに基づき、スライディングウィンドウを時間進行方向にずらしながら、パケットが連続して出現した時間区間である連続区間を識別する連続区間識別手段と、
前記パケット取得手段により取得された各パケットにおけるTCPヘッダ情報を参照することにより、前記アプリケーションサーバが前記ユーザ端末にTCPパケットを送信せずに処理を行った時間であるサーバ処理時間を推定するサーバ処理時間推定手段と、
前記連続区間識別手段により識別された連続区間と、前記サーバ処理時間推定手段により推定されたサーバ処理時間とが時間的に連続しているか否かを判定し、連続している場合に、前記連続区間と前記サーバ処理時間とを結合する結合処理手段と、
前記結合処理手段により結合された時間区間を、推定されたユーザ待ち時間として出力する出力手段と
を備えることを特徴とするユーザ待ち時間推定装置。
【請求項２】
前記サーバ処理時間推定手段は、データなしのACKパケットであると識別された対象パケットの次のパケットがデータ付きのTCPパケットであり、なおかつ、当該次のパケットのACK番号が、前記対象パケットのACK番号と同じであると判定した場合に、前記対象パケットの時刻から前記次のパケットの時刻までを前記サーバ処理時間とすることを特徴とする請求項１に記載のユーザ待ち時間推定装置。
【請求項３】
前記連続区間識別手段は、
ある抽出タイムスロットに対応する連続性判定開始位置から時間進行方向に伸びるスライディングウィンドウに含まれる抽出タイムスロットの合計時間を算出し、前記ウィンドウ時間長に対する前記合計時間の割合が予め定めた閾値以上であるか否かを判定する判定手段と、
前記判定手段により、前記ウィンドウ時間長に対する前記合計時間の割合が前記予め定めた閾値以上であると判定された場合に、連続性判定開始位置を次の抽出タイムスロットにずらし、当該ずらした連続性判定開始位置に基づき前記判定手段による処理を行うスライディング手段と、
前記判定手段と前記スライディング手段による処理を、前記ウィンドウ時間長に対する前記合計時間の割合が前記予め定めた閾値未満であると判定されるまで繰り返し行い、最初の連続性判定開始位置から、最後に前記合計時間の割合が前記閾値以上であると判定されたスライディングウィンドウの末尾までの時間を前記パケットが連続して出現した時間区間であると決定する手段と
を備えることを特徴とする請求項１又は２に記載のユーザ待ち時間推定装置。
【請求項４】
前記スライディングウィンドウのウィンドウ時間長を、前記通信ネットワークにおけるRTTに基づき算出する算出手段を備えることを特徴とする請求項１ないし３のうちいずれか１項に記載のユーザ待ち時間推定装置。
【請求項５】
前記算出手段は、予め定めた時間長に、前記RTTの値を加えることにより得た値から、前記スライディングウィンドウのウィンドウ時間長を算出することを特徴とする請求項４に記載のユーザ待ち時間推定装置。
【請求項６】
TCPベースのアプリケーションサービスを提供するアプリケーションサーバに通信ネットワークを介して接続され、前記アプリケーションサービスを利用するユーザ端末におけるユーザ待ち時間を推定するユーザ待ち時間推定装置が実行するユーザ待ち時間推定方法であって、
前記アプリケーションサーバから前記ユーザ端末に向けて送信された各パケットを取得し、当該パケットを取得した時刻の情報とともに、当該パケットを記憶手段に格納するパケット取得ステップと、
前記パケット取得ステップにより取得されたパケット群から、予め定めた時間幅を有するタイムスロット毎のパケット数を算出するパケット数集計ステップと、
前記パケット数集計ステップにより算出されたタイムスロット毎のパケット数に基づき、パケット数が予め定めた検知閾値以上であるタイムスロット群を、抽出タイムスロット群として抽出する抽出ステップと、
所定のウィンドウ時間長を有するスライディングウィンドウを定め、スライディングウィンドウに含まれる抽出タイムスロットの合計時間と前記ウィンドウ時間長とに基づき、スライディングウィンドウを時間進行方向にずらしながら、パケットが連続して出現した時間区間である連続区間を識別する連続区間識別ステップと、
前記パケット取得ステップにより取得された各パケットにおけるTCPヘッダ情報を参照することにより、前記アプリケーションサーバが前記ユーザ端末にTCPパケットを送信せずに処理を行った時間であるサーバ処理時間を推定するサーバ処理時間推定ステップと、
前記連続区間識別ステップにより識別された連続区間と、前記サーバ処理時間推定ステップにより推定されたサーバ処理時間とが時間的に連続しているか否かを判定し、連続している場合に、前記連続区間と前記サーバ処理時間とを結合する結合処理ステップと、
前記結合処理ステップにより結合された時間区間を、推定されたユーザ待ち時間として出力する出力ステップと
を備えることを特徴とするユーザ待ち時間推定方法。
【請求項７】
コンピュータを、TCPベースのアプリケーションサービスを提供するアプリケーションサーバに通信ネットワークを介して接続され、前記アプリケーションサービスを利用するユーザ端末におけるユーザ待ち時間を推定するユーザ待ち時間推定装置として機能させるためのプログラムであって、コンピュータを、
前記アプリケーションサーバから前記ユーザ端末に向けて送信された各パケットを取得し、当該パケットを取得した時刻の情報とともに、当該パケットを記憶手段に格納するパケット取得手段、
前記パケット取得手段により取得されたパケット群から、予め定めた時間幅を有するタイムスロット毎のパケット数を算出するパケット数集計手段、
前記パケット数集計手段により算出されたタイムスロット毎のパケット数に基づき、パケット数が予め定めた検知閾値以上であるタイムスロット群を、抽出タイムスロット群として抽出する抽出手段、
所定のウィンドウ時間長を有するスライディングウィンドウを定め、スライディングウィンドウに含まれる抽出タイムスロットの合計時間と前記ウィンドウ時間長とに基づき、スライディングウィンドウを時間進行方向にずらしながら、パケットが連続して出現した時間区間である連続区間を識別する連続区間識別手段、
前記パケット取得手段により取得された各パケットにおけるTCPヘッダ情報を参照することにより、前記アプリケーションサーバが前記ユーザ端末にTCPパケットを送信せずに処理を行った時間であるサーバ処理時間を推定するサーバ処理時間推定手段、
前記連続区間識別手段により識別された連続区間と、前記サーバ処理時間推定手段により推定されたサーバ処理時間とが時間的に連続しているか否かを判定し、連続している場合に、前記連続区間と前記サーバ処理時間とを結合する結合処理手段、
前記結合処理手段により結合された時間区間を、推定されたユーザ待ち時間として出力する出力手段と、
として機能させるためのプログラム。
【請求項１】
TCPベースのアプリケーションサービスを提供するアプリケーションサーバに通信ネットワークを介して接続され、前記アプリケーションサービスを利用するユーザ端末におけるユーザ待ち時間を推定するユーザ待ち時間推定装置であって、
前記アプリケーションサーバから前記ユーザ端末に向けて送信された各パケットを取得し、当該パケットを取得した時刻の情報とともに、当該パケットを記憶手段に格納するパケット取得手段と、
前記パケット取得手段により取得されたパケット群から、予め定めた時間幅を有するタイムスロット毎のパケット数を算出するパケット数集計手段と、
前記パケット数集計手段により算出されたタイムスロット毎のパケット数に基づき、パケット数が予め定めた検知閾値以上であるタイムスロット群を、抽出タイムスロット群として抽出する抽出手段と、
所定のウィンドウ時間長を有するスライディングウィンドウを定め、スライディングウィンドウに含まれる抽出タイムスロットの合計時間と前記ウィンドウ時間長とに基づき、スライディングウィンドウを時間進行方向にずらしながら、パケットが連続して出現した時間区間である連続区間を識別する連続区間識別手段と、
前記パケット取得手段により取得された各パケットにおけるTCPヘッダ情報を参照することにより、前記アプリケーションサーバが前記ユーザ端末にTCPパケットを送信せずに処理を行った時間であるサーバ処理時間を推定するサーバ処理時間推定手段と、
前記連続区間識別手段により識別された連続区間と、前記サーバ処理時間推定手段により推定されたサーバ処理時間とが時間的に連続しているか否かを判定し、連続している場合に、前記連続区間と前記サーバ処理時間とを結合する結合処理手段と、
前記結合処理手段により結合された時間区間を、推定されたユーザ待ち時間として出力する出力手段と
を備えることを特徴とするユーザ待ち時間推定装置。
【請求項２】
前記サーバ処理時間推定手段は、データなしのACKパケットであると識別された対象パケットの次のパケットがデータ付きのTCPパケットであり、なおかつ、当該次のパケットのACK番号が、前記対象パケットのACK番号と同じであると判定した場合に、前記対象パケットの時刻から前記次のパケットの時刻までを前記サーバ処理時間とすることを特徴とする請求項１に記載のユーザ待ち時間推定装置。
【請求項３】
前記連続区間識別手段は、
ある抽出タイムスロットに対応する連続性判定開始位置から時間進行方向に伸びるスライディングウィンドウに含まれる抽出タイムスロットの合計時間を算出し、前記ウィンドウ時間長に対する前記合計時間の割合が予め定めた閾値以上であるか否かを判定する判定手段と、
前記判定手段により、前記ウィンドウ時間長に対する前記合計時間の割合が前記予め定めた閾値以上であると判定された場合に、連続性判定開始位置を次の抽出タイムスロットにずらし、当該ずらした連続性判定開始位置に基づき前記判定手段による処理を行うスライディング手段と、
前記判定手段と前記スライディング手段による処理を、前記ウィンドウ時間長に対する前記合計時間の割合が前記予め定めた閾値未満であると判定されるまで繰り返し行い、最初の連続性判定開始位置から、最後に前記合計時間の割合が前記閾値以上であると判定されたスライディングウィンドウの末尾までの時間を前記パケットが連続して出現した時間区間であると決定する手段と
を備えることを特徴とする請求項１又は２に記載のユーザ待ち時間推定装置。
【請求項４】
前記スライディングウィンドウのウィンドウ時間長を、前記通信ネットワークにおけるRTTに基づき算出する算出手段を備えることを特徴とする請求項１ないし３のうちいずれか１項に記載のユーザ待ち時間推定装置。
【請求項５】
前記算出手段は、予め定めた時間長に、前記RTTの値を加えることにより得た値から、前記スライディングウィンドウのウィンドウ時間長を算出することを特徴とする請求項４に記載のユーザ待ち時間推定装置。
【請求項６】
TCPベースのアプリケーションサービスを提供するアプリケーションサーバに通信ネットワークを介して接続され、前記アプリケーションサービスを利用するユーザ端末におけるユーザ待ち時間を推定するユーザ待ち時間推定装置が実行するユーザ待ち時間推定方法であって、
前記アプリケーションサーバから前記ユーザ端末に向けて送信された各パケットを取得し、当該パケットを取得した時刻の情報とともに、当該パケットを記憶手段に格納するパケット取得ステップと、
前記パケット取得ステップにより取得されたパケット群から、予め定めた時間幅を有するタイムスロット毎のパケット数を算出するパケット数集計ステップと、
前記パケット数集計ステップにより算出されたタイムスロット毎のパケット数に基づき、パケット数が予め定めた検知閾値以上であるタイムスロット群を、抽出タイムスロット群として抽出する抽出ステップと、
所定のウィンドウ時間長を有するスライディングウィンドウを定め、スライディングウィンドウに含まれる抽出タイムスロットの合計時間と前記ウィンドウ時間長とに基づき、スライディングウィンドウを時間進行方向にずらしながら、パケットが連続して出現した時間区間である連続区間を識別する連続区間識別ステップと、
前記パケット取得ステップにより取得された各パケットにおけるTCPヘッダ情報を参照することにより、前記アプリケーションサーバが前記ユーザ端末にTCPパケットを送信せずに処理を行った時間であるサーバ処理時間を推定するサーバ処理時間推定ステップと、
前記連続区間識別ステップにより識別された連続区間と、前記サーバ処理時間推定ステップにより推定されたサーバ処理時間とが時間的に連続しているか否かを判定し、連続している場合に、前記連続区間と前記サーバ処理時間とを結合する結合処理ステップと、
前記結合処理ステップにより結合された時間区間を、推定されたユーザ待ち時間として出力する出力ステップと
を備えることを特徴とするユーザ待ち時間推定方法。
【請求項７】
コンピュータを、TCPベースのアプリケーションサービスを提供するアプリケーションサーバに通信ネットワークを介して接続され、前記アプリケーションサービスを利用するユーザ端末におけるユーザ待ち時間を推定するユーザ待ち時間推定装置として機能させるためのプログラムであって、コンピュータを、
前記アプリケーションサーバから前記ユーザ端末に向けて送信された各パケットを取得し、当該パケットを取得した時刻の情報とともに、当該パケットを記憶手段に格納するパケット取得手段、
前記パケット取得手段により取得されたパケット群から、予め定めた時間幅を有するタイムスロット毎のパケット数を算出するパケット数集計手段、
前記パケット数集計手段により算出されたタイムスロット毎のパケット数に基づき、パケット数が予め定めた検知閾値以上であるタイムスロット群を、抽出タイムスロット群として抽出する抽出手段、
所定のウィンドウ時間長を有するスライディングウィンドウを定め、スライディングウィンドウに含まれる抽出タイムスロットの合計時間と前記ウィンドウ時間長とに基づき、スライディングウィンドウを時間進行方向にずらしながら、パケットが連続して出現した時間区間である連続区間を識別する連続区間識別手段、
前記パケット取得手段により取得された各パケットにおけるTCPヘッダ情報を参照することにより、前記アプリケーションサーバが前記ユーザ端末にTCPパケットを送信せずに処理を行った時間であるサーバ処理時間を推定するサーバ処理時間推定手段、
前記連続区間識別手段により識別された連続区間と、前記サーバ処理時間推定手段により推定されたサーバ処理時間とが時間的に連続しているか否かを判定し、連続している場合に、前記連続区間と前記サーバ処理時間とを結合する結合処理手段、
前記結合処理手段により結合された時間区間を、推定されたユーザ待ち時間として出力する出力手段と、
として機能させるためのプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【公開番号】特開２０１１−１４２４７４（Ｐ２０１１−１４２４７４Ａ）
【公開日】平成２３年７月２１日（２０１１．７．２１）
【国際特許分類】
【出願番号】特願２０１０−１５８７（Ｐ２０１０−１５８７）
【出願日】平成２２年１月６日（２０１０．１．６）
【出願人】（３９９０３５７６６）エヌ・ティ・ティ・コミュニケーションズ株式会社 (321)
【Ｆターム（参考）】
【公開日】平成２３年７月２１日（２０１１．７．２１）
【国際特許分類】
【出願日】平成２２年１月６日（２０１０．１．６）
【出願人】（３９９０３５７６６）エヌ・ティ・ティ・コミュニケーションズ株式会社 (321)
【Ｆターム（参考）】
[ Back to top ]