JP2013243534A - 遅延時間評価装置および遅延時間評価方法 - Google Patents

Abstract

【課題】簡易且つ適切にネットワーク遅延時間を測定することを課題とする。
【解決手段】遅延時間評価装置１０は、セッション確立が行われた際に通信が行われたパケットのキャプチャデータを検出し、該キャプチャデータからセッション確立シーケンスを特定する。続いて、遅延時間評価装置１０は、特定されたセッション確立シーケンスのうち、ユーザ端末２０とゲートウェイ４０との間におけるセッション確立シーケンスと、サーバ３０とゲートウェイ４０との間におけるセッション確立シーケンスとを対応付けて管理する。そして、遅延時間評価装置１０は、対応付けられたセッション確立シーケンスにおいて、ユーザ端末２０からサーバ３０へ送信されるパケットの送信時刻および受信時刻と、サーバ３０からユーザ端末２０へ送信されるパケットの送信時刻および受信時刻とを用いて、ユーザ端末２０とサーバ３０との間の遅延時間を算出する。
【選択図】 図１

Description

本発明は、遅延時間評価装置および遅延時間評価方法に関する。

近年、クラウドコンピューティングに代表されるように、データセンタなどにあるサーバ上にアプリケーションやデータなどを配置し、ユーザは遠隔にあるユーザ端末からネットワークを介してサーバ上のアプリケーションを起動してデータ処理などを行う作業形態が増えている。

また、インターネットや通信事業者が提供する公衆ネットワークなどを利用した通信環境により、データセンタや企業内ＬＡＮなどに接続して作業が実施される場合が多く、サービス品質は通信経路上のネットワークの遅延などの品質の影響を受けることになる。

インターネットや公衆ネットワークは、ユーザや企業などの利用者側で品質を管理することができないため、ネットワーク品質を把握するためには、ユーザ端末の地理的な位置や利用時間帯に応じてユーザ端末とサーバとの間のネットワーク遅延時間を測定して、品質を監視することが重要となる。この結果を受けてネットワークの帯域や接続構成、サーバ設定などに対して必要なアクションをとることができる。

このため、ユーザ環境は基本的に汎用ＰＣ（Personal Computer）などのユーザ端末とモデムやＨＧＷ（Home Gate Way）などの接続装置のみで構成されることが多く、簡便な方法でネットワーク遅延時間の測定が可能である必要がある。

このように、ネットワーク遅延時間を測定する方法として、ＩＣＭＰ（Internet Control Message Protocol）エコーによる方法が知られている。このＩＣＭＰエコーによる方法では、ＩＣＭＰエコー要求メッセージの送付とそれに対するＩＣＭＰエコー応答の各時刻を測定して往復遅延時間を算出する。なお、ＩＣＭＰエコーによる方法でネットワーク遅延時間を測定する場合には、通信経路全体を通してＩＣＭＰエコーの疎通が許容されていることが前提である。

また、ネットワーク遅延時間を測定する方法として、パケットキャプチャによる方法が知られている。例えば、専用の装置で測定を行う場合は、測定対象となる装置の近くのスイッチで測定対象装置が接続されるインタフェースを通過するパケットをコピー（ミラーリング設定）し、パケットキャプチャを行う。また、汎用ＰＣで測定を行う場合には、自端末と他の機器との通信を測定する方法としては、自端末とネットワークが接続されているネットワークインタフェースカード（ＮＩＣ）を指定して、Ｗｉｒｅｓｈａｒｋ（登録商標）などのパケットキャプチャツールを用いて、ＮＩＣが送受信するパケットを収集する。

パケットキャプチャによる方法は、送受信パケットを全てあるいはその一部を収集し保存するため、パケットヘッダなどに含まれる情報を用いた詳細な分析が可能である。パケットキャプチャデータの時刻は、測定機器における時刻情報が記録されるため、２拠点間の遅延時間を測定するためには、２つの異なる地点で測定を実施し、測定したパケットキャプチャデータをつき合わせて時間差を求める必要がある。データを付き合わせる方法は、時刻情報をもとに統合する方法と、シーケンス番号をもとに統合する方法との二つの方法に大別される。

まず、時刻情報をもとに統合する方法について説明する。パケットキャプチャデータの時刻情報を用いて、複数のパケットキャプチャデータを時系列順に並べることで統合する機能が、キャプチャデータ分析ツールに具備されている。既存ツールとしては、ＷｉｒｅｓｈａｒｋやＮｅｔＳｃｏｕｔ（登録商標）には複数のキャプチャファイルを統合する機能がある。また、コマンドラインのツールとしてはｍｅｒｇｅｃａｐが同じ機能を持つ。これらは基本的に複数のファイルに含まれているフレームの時刻情報をもとに時間順にフレームを並べ直してデータを統合するものである。したがって、統合するキャプチャデータ間で時刻情報が同期していることが前提となる。

続いて、シーケンス番号をもとに統合する方法について説明する。ＴＣＰヘッダには、シーケンス番号と確認応答番号が含まれており、同じ情報を転送するパケットに関しては同一ＴＣＰセッションであればそれぞれの番号は変わらないため、異なる地点で収集したキャプチャデータをＴＣＰのシーケンス番号を関連づけることで、着目するパケットが２つの地点から発信される時刻と着信する時刻を求め、さらに確認応答番号を対応させることでこれに対する確認応答のパケットが発信する時刻と着信する時刻を求めることで往復遅延時間を導出する方法がある。

この往復遅延時間は、サーバ処理時間が含まれるが、サーバ処理時間は処理内容やデータサイズに依存し、パケット毎に変動が大きいため、往復遅延時間の変動に大きく影響することとなり、ネットワーク遅延時間を把握することが難しくなる。ネットワーク遅延時間を測定するためにサーバでの処理時間が比較的軽いＴＣＰセッション確立時の3-way handshakeなどを抽出して往復遅延時間を求めることが多い。ただし、ＴＣＰのシーケンス番号を突き合わせてデータを対応づけさせるには、ユーザ端末からサーバまでの経路にわたって１つのＴＣＰセッションで張られている必要がある。これにより、同じ情報を転送するパケットに関してはＴＣＰヘッダのシーケンス番号が同一のものとなるため、キャプチャデータ間でパケット送受信のイベントの対応付けが可能となる。

なお、ＩＣＭＰエコーの要求と応答やＴＣＰの3-way handshakeのようなサーバ処理時間を無視できるような処理に着目することができないネットワーク環境である場合には、サーバ処理時間の影響を除外するために、サーバ処理時間が含まれる往復遅延時間ではなく、片道遅延時間を求める必要がある。この場合には、２つの異なる地点で収集したキャプチャデータの発着時刻の差分から片道遅延時間を求めるために、２つの異なる地点におけるデータの時刻を同期させて、データの時刻情報のずれを補正する必要がある。

特開２００６−３５２５２７号公報 特開２００４−８８２８９号公報 特開２００８−１１８２７０号公報 特開２００９−２６０７０６号公報

しかしながら、上記した従来の技術では、簡易且つ適切にネットワーク遅延時間を測定することができないという課題があった。例えば、上記したＩＣＭＰエコーを用いて往復遅延時間を測定する方法に関しては、インターネットや公衆ネットワークを介して遠隔にあるユーザ端末からデータセンタや社内ＬＡＮなどのセキュアな環境にあるサーバへアクセスするネットワーク環境においては、セキュリティ確保の観点からＴＣＰポートを閉じてアクセス制御を行っており、ユーザ端末からサーバまでの疎通ができず、適切にネットワーク遅延時間を測定することができない。

また、上記した時刻情報をもとに２つのパケットキャプチャデータを統合する方法に関しては、異なる地点で測定するパケットキャプチャデータを同期させるために、測定装置の時刻が同期していなければならず、特別な装置や環境が必要となる。ユーザが専用装置や特別な環境を必要な都度、用意することは難しく、異なる地点で測定するパケットキャプチャデータの時刻を同期させることも困難である。したがって、パケットキャプチャツールに具備されているデータ統合機能が適用できない場合が多く、適切にネットワーク遅延時間を測定することができない。

また，ＴＣＰシーケンス番号を使って２つのパケットキャプチャデータを対応させる方法では、ユーザ端末からサーバまでが１つのＴＣＰセッションで張られていることが条件となる。しかし、遠隔にあるユーザ端末から公衆ネットワークを介してデータセンタや企業のＬＡＮのようなセキュアなネットワーク環境に接続する場合は、データセンタや企業ＬＡＮの入り口でセキュリティ確保のためにネットワーク接続を分断するゲートウェイを設置することが一般的である。また、インターネットや公衆ネットワークではデータを暗号化することが一般的である。例えば、クラウドコンピューティングの一つの形態であるＤａａＳ（Desktop as a Service）サービスでは，外部から企業ＬＡＮ内のサーバに接続するために企業ＬＡＮと外部との接続にリバースプロキシサーバを設置し、ユーザ端末とプロキシサーバ間およびプロキシサーバとサーバ間のそれぞれで別々にＴＣＰセッションを張り、その上でさらにユーザ端末とプロキシサーバ間ではＴＬＳｖ１などのデータ暗号化のためのプロトコルを利用したセッションを張ることがある。

このような接続形態はＤａａＳサービスに限らず、遠隔からサーバへのアクセスにおいては通常、利用される接続形態であるが、この場合はユーザ端末とサーバ間での通信が複数のＴＣＰセッションに分かれており、同じ情報を転送するパケットであってもＴＣＰのシーケンス番号が異なってくる。さらに、往復遅延時間に含まれるサーバ処理時間の影響を少なくするために、ＴＣＰセッション確立時の3-way handshakeなどを対象として往復遅延時間を測定することが一般的であるが、ユーザ端末とサーバ間の通信経路においてＴＣＰセッションが分かれてしまう場合はこのような方法が適用できない。このため、適切にネットワーク遅延時間を測定することができない。

なお、Ｗｅｂ３階層構成のような複数サーバ間での通信がある場合、トランザクションを把握するために複数個所でのパケットキャプチャを一元的に制御するために各キャプチャ箇所にエージェントをインストールして同時キャプチャを実現しているツールが存在する。ただし、エージェントのインストールが前提であり、また管理できるエージェントにも制限がある。エージェントのインストールによって、サーバ本来の目的とするサービス提供に影響を与える可能性があるため、測定や監視の目的のためにエージェントをインストールすることができない場合が多い。また、インターネットや公衆ネットワークを越えてエージェントを制御することができない場合が多い。

そこで、この発明は、上述した従来技術の課題を解決するためになされたものであり、簡易且つ適切にネットワーク遅延時間を測定することを目的とする。

上述した課題を解決し、目的を達成するため、本願に開示する遅延時間評価装置は、第一の装置と中継装置との間で通信されたパケット、及び、第二の装置と中継装置との間で通信されたパケットそれぞれのキャプチャデータを収集する収集部と、前記収集部によって収集されたキャプチャデータのうち、セッション確立が行われた際に通信が行われたパケットのキャプチャデータを検出し、該キャプチャデータからセッション確立シーケンスを特定する特定部と、前記特定部によって特定されたセッション確立シーケンスのうち、第一の装置と中継装置との間における第一のセッション確立シーケンスと、第二の装置と中継装置との間における第二のセッション確立シーケンスとを対応付けて管理する管理部と、前記管理部によって対応付けられた前記第一のセッション確立シーケンスと前記第二のセッション確立シーケンスとにおいて、前記第一の装置から前記第二の装置へ送信されるパケットの送信時刻および受信時刻と、前記第二の装置から前記第一の装置へ送信されるパケットの送信時刻および受信時刻とを取得する取得部と、前記取得部によって取得された前記第一の装置から前記第二の装置へ送信されるパケットの送信時刻および受信時刻と、前記第二の装置から前記第一の装置へ送信されるパケットの送信時刻および受信時刻とを用いて、前記第一の装置と前記第二の装置との間の通信にかかる時間である遅延時間を算出する算出部と、を備えることを特徴とする。

遅延時間評価装置は、簡易且つ適切にネットワーク遅延時間を測定することができるという効果を奏する。

図１は、第一の実施の形態に係る遅延時間評価装置を含む通信ネットワークシステムの構成を示すブロック図である。 図２は、ＴＣＰヘッダフォーマットを示す図である。 図３は、ＴＣＰセッション確立シーケンスを説明する図である。 図４は、セッション確立シーケンスの対応付け処理を説明するための図である。 図５は、時刻補正値と片道遅延時間の算出処理を説明する図である。 図６は、第一の実施の形態に係る遅延時間評価装置の処理手順を説明するためのフローチャートである。 図７は、ＴＬＳｖ１セッション確立シーケンスを説明する図である。 図８は、時刻補正して統合したＤａａＳサービス利用時のエンド・ツー・エンドシーケンスを説明する図である。 図９は、第二の実施の形態に係る遅延時間評価装置の処理手順を説明するためのフローチャートである。 図１０は、遅延時間評価プログラムを実行するコンピュータを示す図である。

以下に添付図面を参照して、この発明に係る遅延時間評価装置および遅延時間評価方法の実施形態を説明する。なお、この遅延時間評価装置および遅延時間評価方法の実施形態の記載によりこの発明が限定されるものではない。

（第１の実施形態）
以下の実施形態では、第１の実施形態に係る通信システム、遅延時間評価装置の構成および処理の流れを順に説明し、最後に第１の実施形態による効果を説明する。

［通信ネットワークシステム、遅延時間評価装置の構成］
最初に、図１を用いて、遅延時間評価装置を含む通信ネットワークシステム１００の構成を説明する。図１は、第一の実施の形態に係る遅延時間評価装置を含む通信ネットワークシステムの構成を示すブロック図である。図１に示すように、この通信ネットワークシステム１００は、遅延時間評価装置１０、ユーザ端末２０、サーバ３０、ゲートウェイ４０および測定装置６０を有し、ユーザ端末２０とゲートウェイ４０とは、インターネット（または、公衆ネットワーク）５０を介して接続されている。

通信ネットワークシステム１００では、遠隔地点にあるユーザ端末２０とサーバ間のエンド・ツー・エンドの経路上にあるゲートウェイ４０においてＴＣＰセッションが終端されるようなネットワーク構成において、ユーザ端末２０とサーバ３０側のＬＡＮ環境（サーバファーム）に設置した測定装置６０においてパケットキャプチャを行う。

また、サーバ３０側の測定には、サーバ３０に接続するスイッチにおいてポートミラーリングによりサーバ３０が送受信するパケットのキャプチャリングを行う。なお、サーバファーム内は高速なＬＡＮ環境でありネットワーク遅延は小さく、無視できるものとする。

また、図１に示すように、通信ネットワークシステム１００では、ユーザ端末２０とゲートウェイ４０との間でＴＣＰセッションが確立されており、また、サーバ３０とゲートウェイ４０間でもＴＣＰセッションが確立されている。

また、図１に示すように、遅延時間評価装置１０は、収集部１１と、抽出部１２と、管理部１３と、取得部１４と、算出部１５、作成部１６とを有し、ユーザ端末２０及び測定装置６０と接続されている。以下にこれらの各部の処理を説明する。

収集部１１は、ユーザ端末２０とゲートウェイ４０との間で通信されたパケットのキャプチャデータをユーザ端末から収集し、サーバ３０とゲートウェイ４０との間で通信されたパケットのキャプチャデータを測定装置６０から収集する。

抽出部１２は、収集部１１によって収集されたキャプチャデータのうち、セッション確立が行われた際に通信が行われたパケットのキャプチャデータを抽出し、該キャプチャデータからセッション確立シーケンスを特定する。具体的には、抽出部１２は、収集したパケットキャプチャデータをダンプし、パケットキャプチャデータ中のセッション確立部分を抽出し、セッション確立部分を解析して、ＴＣＰセッションが確立されたシーケンスを特定する。

ここで、図２を用いて、ＴＣＰヘッダのフォーマットについて説明する。図２は、ＴＣＰヘッダフォーマットを示す図である。図２に示すように、ＴＣＰヘッダには、送信元ポート番号、宛先ポート番号、シーケンス番号、確認応答番号等が含まれる。このうち、ＴＣＰヘッダの中から、セッション確立部分として、ＳＹＮフラグ（図２の例では、「ＳＹＮ」と記載）、ＡＣＫフラグ（図２の例では、「ＡＣＫ」と記載）を検出し、ＳＹＮフラグのオン／オフと、ＡＣＫフラグのオン／オフをチェックすることで、３ウェイ−ハンドシェイク（3-way handshake）が行われたＴＣＰセッション確立シーケンスを特定することができる。

ここで、図３を用いて、ＴＣＰセッション確立シーケンスについて説明する。図３は、ＴＣＰセッション確立シーケンスを説明する図である。図３に示すように、ＴＣＰコネクションの確立を要求する装置ＡがＴＣＰヘッダ内のＳＹＮ（Synchronize：同期）フラグをＯＮにしたＳＹＮパケットを装置Ｂに対して送信すると、ＳＹＮパケットを受信した装置Ｂは、かかるＳＹＮパケットの応答としてＳＹＮフラグおよびＡＣＫ（Acknowledge：確認）フラグをＯＮにしたＡＣＫパケットを装置Ａに対して送信する。

続いて、ＡＣＫパケットを受信した装置Ａは、かかるＡＣＫパケットの応答としてＡＣＫパケットを装置Ｂに対して送信する。このようにして、３ウェイ−ハンドシェイクと呼ばれるＴＣＰコネクションの確立手順が完了する。このように、ＴＣＰコネクションを確立する際の手順において、ＳＹＮフラグがオン、ＳＹＮフラグおよびＡＣＫフラグがオン、ＡＣＫフラグがオンになることが事前に決まっているので、ＴＣＰセッション確立シーケンスを特定することが可能となる。

図３では、装置Ａと装置Ｂとの２装置間で行われるＴＣＰセッション確立を例にして説明した。図１の通信システム１００の例では、この２装置として、ユーザ端末２０とゲートウェイ４０との間、及び、ゲートウェイ４０とサーバ３０との間でＴＣＰセッションが確立することとなる。このため、ユーザ端末２０とゲートウェイ４０間、及び、ゲートウェイ４０とサーバ３０間でセッションは分けられることになるが、両者は独立ではなく、通信開始にあたってユーザ側からのセッション確立要求を受けてユーザ端末２０とゲートウェイ４０間のセッションが確立するとともに、ゲートウェイ４０ではユーザからの要求に対応して、サーバ３０に対してセッション確立要求を送り、ゲートウェイ４０とサーバ３０間のセッションを確立する。

管理部１３は、特定部１２によって特定されたセッション確立シーケンスのうち、ユーザ装置２０とゲートウェイ４０との間におけるセッション確立シーケンスと、サーバ３０とゲートウェイ４０との間におけるセッション確立シーケンスとを対応付けて管理する。ここで、図４の例を用いて、セッション確立シーケンスの対応付け処理について説明する。図４は、セッション確立シーケンスの対応付け処理を説明するための図である。図４に示すように、管理部１３は、ユーザ端末２０とゲートウェイ４０間およびゲートウェイ４０とサーバ３０間のセッションを対応づけて管理する。

ここで、パケットキャプチャにおいて着目している発着ノードのＩＰアドレスでフィルタリングすれば、セッション確立イベントも限定されるため、双方のパケットキャプチャデータから得たセッション確立シーケンスについても起動の関連性を対応づけることができる。

取得部１４は、管理部１３によって対応付けられた二つのセッション確立シーケンスにおいて、ユーザ装置２０からサーバ３０へ送信されるパケットの送信時刻および受信時刻と、サーバ３０からユーザ装置２０へ送信されるパケットの送信時刻および受信時刻とを取得する。

ここで、上記した図４の例を用いて具体的に説明すると、取得部１４は、ユーザ端末２０でのパケットキャプチャデータにおいて、セッション確立後にユーザ端末２０から送付される最初のパケットの送信時刻（図４の時刻ａ_４）と、サーバ３０でのパケットキャプチャデータにおいて、ユーザ端末２０側ゲートウェイ４０からサーバ３０に送られるパケットが到着する時刻（図４の時刻ｂ_４）を取得して、記録する。

ユーザ側の要求を契機に連動して両セッションが確立された後にユーザ端末２０からサーバ３０へと上位アプリケーションのデータが送信される。セッション確立後はゲートウェイ４０においては上位レイヤのプロトコルを処理することなくアプリケーションデータの転送に専念するため、処理は比較的軽く、処理時間は短く変動は小さい。

ユーザ側から送信される最初のアプリケーションデータを運ぶパケットは、セッション確立後に始めて疎通するパケットであるので、両パケットキャプチャデータにおいて特定が可能であり、ここではこのパケットに着目して、ユーザ端末２０からの発信時刻とサーバファームでの着信時刻を取得して、記録する。

次に、取得部１４は、最初のアプリケーションデータ受信後、サーバ３０からユーザ端末２０向けゲートウェイ４０に送信される最初のパケットについても両パケットキャプチャデータから特定でき、同様にサーバファームからの発信時刻（図５のｂ_５）およびユーザ端末２０での受信時刻（図４のａ_５）を取得して、記録する。

なお、この時点ではユーザ端末２０で収集したパケットキャプチャの時刻とサーバ３０で収集したパケットキャプチャデータの時刻は同期しておらず、発生した事象の前後関係に対して記録した時刻が逆転している可能性がある。

算出部１５は、取得部１４によって取得されたユーザ端末２０からサーバ３０へ送信されるパケットの送信時刻および受信時刻と、サーバ３０からユーザ端末２０へ送信されるパケットの送信時刻および受信時刻とを用いて、ユーザ端末２０とサーバ３０との間の通信にかかる時間である遅延時間を算出する。例えば、算出部１５は、取得部１４が記録した時刻情報と、中間点でデータ転送のための処理時間が等しいという前提のもとで定式化した数式を用いて、両キャプチャ間の時刻のずれと片道遅延時間を算出する。

ここで、図５を用いて、時刻補正値と片道遅延時間の算出処理について説明する。図５は、時刻補正値と片道遅延時間の算出処理を説明する図である。ここで、ユーザ端末２０で収集したパケットキャプチャデータの時刻に対する、サーバ３０で収集したパケットキャプチャデータの時刻の遅れを時刻補正値Δとする。サーバ３０でのパケットキャプチャデータの時刻の方が進んでいる場合は、時刻補正値Δが負の値をとることになるので、このように一般性を失うことなく２つのデータを同期させるための時刻補正値としてΔとすることができる。

また、ここではユーザ端末２０からゲートウェイ４０経由でサーバ３０へと転送される時間と、サーバ３０からゲートウェイ４０経由でユーザ端末２０に転送される時間は等しいことを前提としている。サーバ３０内あるいはユーザ端末２０内での処理時間は処理内容やデータ量に大きく依存するが、ネットワーク遅延は比較的安定していると考えて、このような前提としている。

このため、図５に示すように、片道遅延時間ＮＤ１と片道遅延時間ＮＤ２とが等しいと仮定して、算出部１５は、「Δ＝（ａ４−ｂ４＋ａ５−ｂ５）／２」の数式を用いて、時刻補正値Δを算出する。

また、図５に示すように、片道遅延時間ＮＤ１と片道遅延時間ＮＤ２とが等しいと仮定して、算出部１５は、「ＮＤ＝（−ａ４＋ｂ４＋ａ５−ｂ５）／２」の数式を用いて、片道遅延時間ＮＤを算出する。なお、算出部１５は、図５に示すように、ユーザ端末２０からサーバ３０への片道遅延時間ＮＤ１について、「（ｂ４＋Δ）−ａ４＝ＮＤ１」の算出式を用いて算出してもよいし、サーバ３０からユーザ端末２０への片道遅延時間ＮＤ２について、「ａ５−（ｂ５＋Δ）＝ＮＤ２」の数式を用いて、算出してもよい。

このように、ＴＣＰセッションの確立は相互に連携して動作するという性質を利用し、それぞれのパケットキャプチャデータからセッション確立シーケンスを抽出し、それらを対応させることで、エンド・ツー・エンドでアプリケーションデータの送信を開始する時点を見つけ、ユーザ端末２０とサーバ３０間で着目するパケットの発信時刻と着信時刻を双方向で記録して、これを用いた容易な演算により時刻補正値と片道遅延時間を算出する。

作成部１６は、算出部１５によって算出された時刻補正値Δを用いて時刻補正を行い、同期させた２つのキャプチャデータを組み合わせて、ユーザ端末とサーバ間でのシーケンス図を作成する。

このように、遅延時間評価装置１０は、ユーザ端末２０で収集したパケットキャプチャデータの時刻を基準とした場合の、サーバ３０で収集したパケットキャプチャデータの時間の補正を行うことができ、ユーザ端末２０とサーバ３０間のエンド・ツー・エンドのシーケンス図を表示することができる。

［遅延時間評価装置による処理］
次に、図６を用いて、第１の実施形態に係る遅延時間評価装置１０による処理を説明する。図６は、第１の実施形態に係る遅延時間評価装置１０の処理動作を示すフローチャートである。

図６に示すように、遅延時間評価装置１０の収集部１１は、ユーザ端末２０及び測定装置６０からパケットキャプチャデータを収集する（ステップＳ１０１）。そして、抽出部１２は、収集したパケットキャプチャデータをダンプし（ステップＳ１０２）、ＴＣＰヘッダからシーケンスを解析して、パケットキャプチャデータ中のセッション確立部分を抽出する（ステップＳ１０３）。具体的には、抽出部１２は、収集したパケットキャプチャデータをダンプし、ＴＣＰヘッダからシーケンスを解析して、パケットキャプチャデータ中のセッション確立部分を抽出した後、セッション確立部分を解析して、ＴＣＰセッションが確立されたシーケンスを特定する。

そして、管理部１３は、ユーザ端末２０とゲートウェイ４０間およびゲートウェイ４０とサーバ３０間のセッションを対応づける（ステップＳ１０４）。続いて、取得部１４は、セッション確立後に、ユーザ端末２０からサーバ３０へ送付される最初のパケットの送信時刻（例えば、図５に示すａ４に相当）と、ユーザ端末２０側ゲートウェイ４０からサーバ３０に送られるパケットの受信時刻（例えば、図５に示すｂ４に相当）を記録する（ステップＳ１０５）。

その後、取得部１４は、サーバ３０側でデータ受信後に次に送信される、サーバ３０からユーザ端末２０向けアプリケーションデータ（パケット）の送信時刻（例えば、図５に示すｂ５に相当）および受信時刻（例えば、図５に示すａ５に相当）を記録する（ステップＳ１０６）。

そして、算出部１５は、時刻補正値と片道遅延時間を算出する（ステップＳ１０７）。具体的には、算出部１５は、片道遅延時間ＮＤ１と片道遅延時間ＮＤ２とが等しいと仮定して、「Δ＝（ａ４−ｂ４＋ａ５−ｂ５）／２」の算出式を用いて、時刻補正値Δを算出する。また、同様に、片道遅延時間ＮＤ１と片道遅延時間ＮＤ２とが等しいと仮定して、算出部１５は、「ＮＤ＝（−ａ４＋ｂ４＋ａ５−ｂ５）／２」の算出式を用いて、片道遅延時間ＮＤを算出する。

その後、作成部１６は、ユーザ端末側の送信時刻および着信時刻（例えば、図５に示すａ４、ａ５に相当）と時刻補正したサーバ側の送信時刻および着信時刻（例えば、図５に示すｂ４＋Δ、ｂ５＋Δに相当）を連結して、エンド・ツー・エンドのシーケンス図を作成する（ステップＳ１０８）。

[第１の実施形態の効果]
上述してきたように、第１の実施形態に係る遅延時間評価装置１０は、ユーザ端末２０とゲートウェイ４０との間で通信されたパケット、及び、サーバ３０とゲートウェイ４０との間で通信されたパケットそれぞれのキャプチャデータを収集する。そして、収集されたキャプチャデータのうち、セッション確立に関する情報を解析して、セッション確立が行われた際に通信が行われたパケットのキャプチャデータを検出し、該キャプチャデータからセッション確立シーケンスを特定する。続いて、遅延時間評価装置１０は、特定されたセッション確立シーケンスのうち、ユーザ端末２０とゲートウェイ４０との間におけるセッション確立シーケンスと、サーバ３０とゲートウェイ４０との間におけるセッション確立シーケンスとを対応付けて管理する。そして、遅延時間評価装置１０は、対応付けられたセッション確立シーケンスにおいて、ユーザ端末２０からサーバ３０へ送信されるパケットの送信時刻および受信時刻と、サーバ３０からユーザ端末２０へ送信されるパケットの送信時刻および受信時刻とを取得する。その後、遅延時間評価装置１０は、取得されたユーザ端末２０からサーバ３０へ送信されるパケットの送信時刻および受信時刻と、サーバ３０からユーザ端末２０へ送信されるパケットの送信時刻および受信時刻とを用いて、ユーザ端末２０とサーバ３０との間の通信にかかる時間である遅延時間を算出する。これにより、簡易且つ適切にネットワーク遅延時間を測定することが可能となる。

また、第１の実施形態によれば、遅延時間を算出するとともに、ユーザ端末２０からサーバ３０へ送信されるパケットの送信時刻および受信時刻と、サーバ３０からユーザ端末２０へ送信されるパケットの送信時刻および受信時刻とを用いて、ユーザ端末２０とゲートウェイ４０との間で通信されたパケットのキャプチャデータと、サーバ３０とゲートウェイ４０との間で通信されたパケットキャプチャデータとの時刻のずれを算出する。これにより、異なる地点で収集したパケットキャプチャデータに対して特別の装置を導入することなく時刻のずれを補正することが可能である。

また、第１の実施形態によれば、セッション確立に関する情報として、ＳＹＮフラグおよびＡＣＫフラグを解析して、セッション確立が行われた際に通信が行われたパケットのキャプチャデータを検出し、該キャプチャデータからセッション確立シーケンスを特定する。このため、ＴＣＰヘッダにおける既存のフラグを用いて、セッション確立が行われた際に通信が行われたパケットのキャプチャデータを検出することが可能である。

このように、例えば、第１の実施形態に係る遅延時間評価装置１０では、エンド・ツー・エンドの通信においてネットワークに起因する遅延時間を算出することができる。また、ＴＣＰセッションが途中で終端されて別れてしまうような場合にも、キャプチャデータの時刻合わせや片道遅延時間の算出が可能となり、エンド・ツー・エンドでトランザクション処理のシーケンス図を表示することができようになる。また、従来は、途中の区間ごとの遅延時間までしかわからなかったが、遠隔ユーザがサーバを利用する際のネットワーク品質を評価することができ、性能管理機能の向上をもたらすことができる。

（第２の実施形態）
ところで、上記の第１の実施形態で説明した処理手順を、クラウドコンピューティング環境の一形態であり、ユーザはサーバファーム上の仮想デスクトップクライアントを利用して，ユーザ端末の機能やリソースを使うことなく遠隔から作業をすることができるＤａａＳ（Desktop as a Service）サービス提供環境に適用してもよい。以下で説明する第２の実施形態では、ＤａａＳサービス提供環境において、遅延時間評価処理を行う場合について説明する。

ＤａａＳサービスでは、ユーザは外部接続（サーバファームの設置拠点外からの接続）による利用が多くなるが、業務データなど高いセキュリティ要件の情報をやり取りするために、ＴＬＳｖ１などを使って暗号化するのが一般的である。

ＴＬＳｖ１は、ＲＦＣ２２４６で規定されたプロトコルであり、セッション確立までにＨａｎｄｓｈａｋｅプロトコルが処理される。ユーザ端末とゲートウェイ間およびゲートウェイとサーバ間でそれぞれ前述のようにＴＣＰセッションが確立された後、ＴＬＳｖ１のセッションの確立処理が動作し、セッション確立後にユーザ端末とサーバ間でアプリケーションデータの通信が行われる。

このため、ＴＬＳｖ１が適用される場合は、遅延時間評価装置は、上記の第１の実施形態と同様に、パケットキャプチャデータを収集し、バイナリデータをダンプした後に、ＴＣＰセッション確立部分の抽出を行うとともに、ＴＬＳｖ１セッションを解析してセッション確立部分を抽出する処理を行う。

ここで、図７を用いて、ＴＬＳｖ１セッション確立シーケンスについて説明する。図７は、ＴＬＳｖ１セッション確立シーケンスを説明する図である。図７に示すように、コネクションの確立を要求する装置ＡがＣｌｉｅｎｔ Ｈｅｌｌｏを装置Ｂに送信すると、Ｃｌｉｅｎｔ Ｈｅｌｌｏを受信した装置Ｂは、Ｓｅｒｖｅｒ Ｈｅｌｌｏ、Ｃｅｒｔｉｆｉｃａｔｅ、Ｓｅｒｖｅｒ Ｋｅｙ Ｅｘｃｈａｎｇｅ、Ｓｅｒｖｅｒ Ｈｅｌｌｏ Ｄｏｎｅを装置Ａに対して送信する。

そして、装置Ａは、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ、Ｆｉｎｉｓｈｅｄを装置Ｂに対して送信する。続いて、装置Ｂは、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ、Ｆｉｎｉｓｈｅｄを装置Ａに対して送信する。これにより、ＴＣＬｖ１セッションの確立手順が完了する。

このようなＴＬＳｖ１のセッション確立シーケンスは、ＲＦＣ２２４６で規定されており、パケットキャプチャデータを分析すると暗号化されている部分を除くとパケット解析ツールでＴＬＳｖ１セッションの確立部分を把握することができる。

このように、ＴＣＰセッション確立部分の抽出を行うとともに、ＴＬＳｖ１セッションを解析してセッション確立部分を抽出することで、ＴＣＰセッションおよびＴＬＳｖ１セッションがユーザ端末とゲートウェイ間、ゲートウェイとサーバ間にそれぞれ張られるケースに対しても、２つのパケットキャプチャデータの時刻補正値と片道遅延時間を求めることができる。

その後、遅延時間評価装置は、図８に例示するように、時刻補正して統合したＤａａＳサービス利用時のエンド・ツー・エンドシーケンスを作成する。図８は、時刻補正して統合したＤａａＳサービス利用時のエンド・ツー・エンドシーケンスを説明する図である。図８に例示するように、遠隔にあるユーザ端末からＤａａＳサービスを利用した時に、ユーザ端末およびサーバファームの測定装置で収集したパケットキャプチャデータに対するユーザ端末２０とサーバ３０との間のエンド・ツー・エンドのシーケンス図が作成される。なお、図８には、具体的な時刻データの値が記載されているが、この値は一例に過ぎず、この値に限定されるものではない。

このように、第２の実施形態に係る遅延時間評価装置は、ＴＬＳｖ１が適用される場合は、ＴＣＰセッション確立部分の抽出を行うとともに、ＴＬＳｖ１セッションを解析してセッション確立部分を抽出する処理を行うので、第１の実施形態と同様にセッション確立後のパケットのやり取りに着目して、キャプチャデータの時刻合わせや片道遅延時間の算出が可能となる。

［複数の計算結果を平均］
なお、上述したように、異なる地点で収集したパケットキャプチャデータの時刻のずれの補正と片道遅延時間を算出することができるが、実際には測定時のネットワークの使用状況やゲートウェイの処理負荷、パケットサイズなどの影響を受けるため、ある特定のパケットの発着時刻を分析した結果には誤差の影響を受ける可能性がある。そこで、算出する計算結果の精度を上げるために、複数回の算出を行い、得られた数値の平均をとることが考えられる。

ここで、図９を用いて、複数回の算出を行い、得られた数値の平均をとる変形例の遅延時間評価装置による処理を説明する。図９は、変形例の遅延時間評価装置の処理動作を示すフローチャートである。セッション確立シーケンスの対応づけと時刻補正値と片道遅延時間の数値計算の部分を予め設定した回数Ｎだけ実施して計算結果の平均をとる手順を示したものである。なお、計算を繰り返す場合には、前回の計算で着目したパケットの次の発信パケットに着目する方法と、再度セッション確立部分の抽出から行う方法の２種類がある。

図９に示すように、遅延時間評価装置は、第１の実施形態と同様に、ユーザ端末２０及び測定装置６０からパケットキャプチャデータを収集する（ステップＳ２０１）。ここで、初期化として、ｎ＝１をセットする。そして、抽出部１２は、収集したパケットキャプチャデータをダンプし（ステップＳ２０２）、ＴＣＰセッション確立部分を抽出する（ステップＳ２０３）。そして、遅延時間評価装置は、ＴＬＳｖ１セッション確立部分を抽出する（ステップＳ２０４）。

そして、遅延時間評価装置は、ユーザ端末２０とゲートウェイ４０間およびゲートウェイ４０とサーバ３０間のセッションを対応づける（ステップＳ２０５）。続いて、遅延時間評価装置は、セッション確立後に、ユーザ端末２０からサーバ３０へ送付される最初のパケットの送信時刻と、ユーザ端末２０側ゲートウェイ４０からサーバ３０に送られるパケットの受信時刻を記録する（ステップＳ２０６）。

その後、遅延時間評価装置は、サーバ３０側でデータ受信後に次に送信される、サーバ３０からユーザ端末２０向けアプリケーションデータ（パケット）の送信時刻および受信時刻を記録する（ステップＳ２０７）。

そして、遅延時間評価装置は、時刻補正値と片道遅延時間を算出する（ステップＳ２０８）。そして、遅延時間評価装置は、Ｎ≦ｎであるか否かを判別し（ステップＳ２０９）、Ｎ≦ｎでない場合には、ｎに「１」を加算し（ステップＳ２１０）、ステップＳ２０５に戻る。また、Ｎ≦ｎである場合には、遅延時間評価装置は、時刻補正値と片道遅延時間の平均を算出し（ステップＳ２１１）、ユーザ端末側の送信時刻および着信時刻と時刻補正したサーバ側の送信時刻および着信時刻を連結して、エンド・ツー・エンドのシーケンス図を作成する（ステップＳ２１２）。

このように、遅延時間評価装置が、所定の回数だけ、時刻補正値と片道遅延時間を算出する処理を繰り返し行い、複数の時刻補正値と片道遅延時間の平均を算出するので、より適切に時刻補正値と片道遅延時間を算出することが可能である。

［システム構成］
また、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。

［プログラム］
また、上記実施形態において説明した遅延時間評価装置が実行する処理をコンピュータが実行可能な言語で記述したプログラムを作成することもできる。例えば、実施形態１に係る遅延時間評価装置１０が実行する処理をコンピュータが実行可能な言語で記述した遅延時間評価プログラムを作成することもできる。この場合、コンピュータが遅延時間評価プログラムを実行することにより、上記実施形態と同様の効果を得ることができる。さらに、かかる遅延時間評価プログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録され遅延時間評価プログラムをコンピュータに読み込ませて実行することにより上記実施形態１と同様の処理を実現してもよい。以下に、図１に示した遅延時間評価装置１０と同様の機能を実現する遅延時間評価プログラムを実行するコンピュータの一例を説明する。

図１０は、遅延時間評価プログラムを実行するコンピュータ１０００を示す図である。図１０に例示するように、コンピュータ１０００は、例えば、メモリ１０１０と、ＣＰＵ１０２０と、ハードディスクドライブインタフェース１０３０と、ディスクドライブインタフェース１０４０と、シリアルポートインタフェース１０５０と、ビデオアダプタ１０６０と、ネットワークインタフェース１０７０とを有し、これらの各部はバス１０８０によって接続される。

メモリ１０１０は、図１０に例示するように、ＲＯＭ（Read Only Memory）１０１１及びＲＡＭ１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic Input Output System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、図１０に例示するように、ハードディスクドライブ１０３１に接続される。ディスクドライブインタフェース１０４０は、図１０に例示するように、ディスクドライブ１０４１に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブに挿入される。シリアルポートインタフェース１０５０は、図１０に例示するように、例えばマウス１０５１、キーボード１０５２に接続される。ビデオアダプタ１０６０は、図１０に例示するように、例えばディスプレイ１０６１に接続される。

ここで、図１０に例示するように、ハードディスクドライブ１０３１は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３、プログラムデータ１０９４を記憶する。すなわち、上記の遅延時間評価プログラムは、コンピュータ１０００によって実行される指令が記述されたプログラムモジュールとして、例えばハードディスクドライブ１０３１に記憶される。

また、上記実施形態で説明した各種データは、プログラムデータとして、例えばメモリ１０１０やハードディスクドライブ１０３１に記憶される。そして、ＣＰＵ１０２０が、メモリ１０１０やハードディスクドライブ１０３１に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出し、各種手順を実行する。

なお、遅延時間評価プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０３１に記憶される場合に限られず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、遅延時間評価プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ネットワーク（ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）等）を介して接続された他のコンピュータに記憶され、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。

１０ 遅延時間評価装置
１１ 収集部
１２ 抽出部
１３ 管理部
１４ 取得部
１５ 算出部
１６ 作成部
２０ ユーザ端末
３０ サーバ
４０ ゲートウェイ
５０ インターネット
１００ 通信ネットワークシステム

Claims (5)

1. 第一の装置と中継装置との間で通信されたパケット、及び、第二の装置と中継装置との間で通信されたパケットそれぞれのキャプチャデータを収集する収集部と、
   前記収集部によって収集されたキャプチャデータのうち、セッション確立に関する情報を解析して、セッション確立が行われた際に通信が行われたパケットのキャプチャデータを検出し、該キャプチャデータからセッション確立シーケンスを特定する特定部と、
   前記特定部によって特定されたセッション確立シーケンスのうち、第一の装置と中継装置との間における第一のセッション確立シーケンスと、第二の装置と中継装置との間における第二のセッション確立シーケンスとを対応付けて管理する管理部と、
   前記管理部によって対応付けられた前記第一のセッション確立シーケンスと前記第二のセッション確立シーケンスとにおいて、前記第一の装置から前記第二の装置へ送信されるパケットの送信時刻および受信時刻と、前記第二の装置から前記第一の装置へ送信されるパケットの送信時刻および受信時刻とを取得する取得部と、
   前記取得部によって取得された前記第一の装置から前記第二の装置へ送信されるパケットの送信時刻および受信時刻と、前記第二の装置から前記第一の装置へ送信されるパケットの送信時刻および受信時刻とを用いて、前記第一の装置と前記第二の装置との間の通信にかかる時間である遅延時間を算出する算出部と、
   を備えることを特徴とする遅延時間評価装置。
2. 前記算出部は、前記遅延時間を算出するとともに、前記取得部によって取得された前記第一の装置から前記第二の装置へ送信されるパケットの送信時刻および受信時刻と、前記第二の装置から前記第一の装置へ送信されるパケットの送信時刻および受信時刻とを用いて、第一の装置と中継装置との間で通信されたパケットのキャプチャデータと、第二の装置と中継装置との間で通信されたパケットキャプチャデータとの時刻のずれを算出することを特徴とする請求項１に記載の遅延時間評価装置。
3. 前記特定部は、セッション確立に関する情報として、同期フラグおよび確認フラグを解析して、セッション確立が行われた際に通信が行われたパケットのキャプチャデータを検出し、該キャプチャデータからセッション確立シーケンスを特定することを特徴とする請求項１または２に記載の遅延時間評価装置。
4. 前記算出部は、所定の回数だけ、前記遅延時間を算出する処理を繰り返し行い、複数の遅延時間の平均を算出することを特徴とする請求項１〜３のいずれか一つに記載の遅延時間評価装置。
5. 遅延時間を算出する遅延時間評価装置で実行される遅延時間評価方法であって、
   第一の装置と中継装置との間で通信されたパケット、及び、第二の装置と中継装置との間で通信されたパケットそれぞれのキャプチャデータを収集する収集工程と、
   前記収集工程によって収集されたキャプチャデータのうち、セッション確立に関する情報を解析して、セッション確立が行われた際に通信が行われたパケットのキャプチャデータを検出し、該キャプチャデータからセッション確立シーケンスを特定する特定工程と、
   前記特定工程によって特定されたセッション確立シーケンスのうち、第一の装置と中継装置との間における第一のセッション確立シーケンスと、第二の装置と中継装置との間における第二のセッション確立シーケンスとを対応付けて管理する管理工程と、
   前記管理工程によって対応付けられた前記第一のセッション確立シーケンスと前記第二のセッション確立シーケンスとにおいて、前記第一の装置から前記第二の装置へ送信されるパケットの送信時刻および受信時刻と、前記第二の装置から前記第一の装置へ送信されるパケットの送信時刻および受信時刻とを取得する取得工程と、
   前記取得工程によって取得された前記第一の装置から前記第二の装置へ送信されるパケットの送信時刻および受信時刻と、前記第二の装置から前記第一の装置へ送信されるパケットの送信時刻および受信時刻とを用いて、前記第一の装置と前記第二の装置との間の通信にかかる時間である遅延時間を算出する算出工程と、
   を含んだことを特徴とする遅延時間評価方法。

Images