オペレーティングシステムの判定が可能な装置及び方法
【課題】パケットの遅延原因が単純に遅延したものかロスによる再送を行ったため遅延したものかの識別を行うこと。
【解決手段】現パケットが持つべきシーケンス番号である次回シーケンス番号と現パケットのシーケンス番号とを比較し、前パケットの識別子と現パケットの識別子とを比較し、次回シーケンス番号と現パケットのシーケンス番号が一致し、且つ前パケットの識別子と現パケットの識別子が連続しているときに単なる遅延であると判定し、前パケットの識別子と現パケットの識別子が連続していないときに再送による遅延であると判定する。
【解決手段】現パケットが持つべきシーケンス番号である次回シーケンス番号と現パケットのシーケンス番号とを比較し、前パケットの識別子と現パケットの識別子とを比較し、次回シーケンス番号と現パケットのシーケンス番号が一致し、且つ前パケットの識別子と現パケットの識別子が連続しているときに単なる遅延であると判定し、前パケットの識別子と現パケットの識別子が連続していないときに再送による遅延であると判定する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パケットの遅延原因を判定するパケットキャプチャ装置に関する。
【背景技術】
【０００２】
システムの運用保守に際し、パケットの遅延が起きている場合に、問題を解決するには、その原因を的確に把握する必要がある。問題解決のために、具体的には、パケットの送信者がパケットの送信を遅延させたことが原因でパケット到着が遅延したのか、または、ネットワーク内でパケットがロスしたことが原因でパケットの送信者が再送信したために結果としてパケット到着が遅延したのかを知る必要がある。
【０００３】
従来、IP（Internet Protocol）より上位レイヤのプロトコルのうち、TCP（Transmission Control Protocol）等の再送手順を持つプロトコルに関して、パケットロスを識別する方法としては、単調増加するシーケンス番号を手がかりに、シーケンス番号が連続していればパケットロスは発生していないと判断していた。
【０００４】
よって、シーケンス番号が連続する場合にはロスとしては認識されず、前回受信したパケットからのパケット到着が遅延するケースにおいては、どのような場合でも送信ホストが単純に送信に時間がかかったと判断していた。
【０００５】
特許文献１には、シーケンス番号をもとに、パケット到着の時系列的な情報から、再送信と正常送信を識別する技術が記載されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００５−２１０５１５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、TCPなどIPレイヤよりも上位のレイヤで再送手順を持つプロトコルでは、一般にはパケットがロスした後に、ロスを回復するためのパケットを再送している。仮に送信ホストと計測装置の間でパケットがロスし送信ホストが再送した場合でも、計測装置ではシーケンス番号が連続していることが観測できるため、ロスとは識別せずに単なる遅延と判断してしまうという問題があった。
【０００８】
このように従来の方法では、ＴＣＰヘッダのシーケンス番号の連続性から、ロスか遅延かを判断しているため、遅延の原因を正しく判断することが出来なかった。
【０００９】
本発明の課題は、パケットの遅延の原因が単純に遅延したものか再送を行ったため遅延したのかを正しく識別する装置を提供することである。
【課題を解決するための手段】
【００１０】
開示のパケットキャプチャ装置は、受信したパケットのヘッダに記述されているＩＤ値およびシーケンス番号を取得する取得部と、前回受信したパケットのＩＤ値である前回ＩＤ値および次回受信するパケットが持つべきシーケンス番号である次回シーケンス番号を記憶する記憶部と、前記受信したパケットの遅延原因が単なる遅延かロスに伴う再送による遅延かを判定する検出部と、を備え、前記検出部は、前記次回シーケンス番号と前記今回取得したパケットのシーケンス番号とを比較し、前記前回ＩＤ値と今回受信したパケットのＩＤ値とを比較し、前記次回シーケンス番号と前記今回受信したパケットのシーケンス番号が一致し、且つ前記前回ＩＤ値と前記今回受信したパケットのＩＤ値が連続しているときに単なる遅延であると判定し、前記前回ＩＤ値と前記今回受信したパケットのＩＤ値が連続していないときに再送による遅延であると判定することを特徴とする。
【発明の効果】
【００１１】
開示の装置によれば、パケットの遅延の原因が単純に遅延したものか再送を行ったため遅延したものかの識別を行うことが出来る。
【図面の簡単な説明】
【００１２】
【図１】本発明の第１の実施の形態に係るシステムの構成図である。
【図２】本発明の第１の実施の形態に係るパケットキャプチャ装置の構成図である。
【図３】通信状態テーブルの例である。
【図４】モニタ結果テーブルの例である。
【図５】本発明の実施の形態の識別方法のフローチャートである。
【図６】第２の実施の形態に係るシステムの構成図である。
【図７】本発明の第２の実施の形態に係るパケットキャプチャ装置の構成図である。
【図８】モニタ結果テーブルの例である。
【図９】連続開始ＩＤテーブルの例である。
【図１０】本発明の第２の実施の形態に係る識別方法のフローチャートである。
【図１１】第３の実施の形態に係るシステムの構成図である
【図１２】本発明の第３の実施の形態に係るパケットキャプチャ装置の構成図である。
【図１３】モニタ結果テーブルの例である。
【図１４】ＯＳ種別テーブルの例を示す図である。
【図１５】本発明の第３の実施の形態の識別方法のフローチャートである。
【発明を実施するための形態】
【００１３】
以下、図面を参照しながら、本発明の実施の形態を説明する。
（第１の実施の形態）
図１は、本発明の第１の実施の形態に係るシステムの構成図である。
【００１４】
本発明の実施の形態のシステムは、パケットキャプチャ装置１０１、送信ホスト１０２、受信ホスト１０３、タップ１０４を備える。
タップ１０４は、送信ホスト１０２と受信ホスト１０３の間に配置される。
パケットキャプチャ装置１０１は、タップ１０４と接続し、送信ホスト１０２および受信ホスト１０３はそれぞれネットワークを介してタップ１０４と接続している。
【００１５】
送信ホスト１０２が受信ホスト１０３にパケットを送信すると、送信ホスト１０２と受信ホスト１０３の間にあるタップ１０４は該パケットをパケットキャプチャ装置１０１に分岐させる。そして、パケットキャプチャ装置１０１は、パケットを受信する。
【００１６】
図２は、本発明の第１の実施の形態のパケットキャプチャ装置の構成図である。
パケットキャプチャ装置２０１は、入力部２０２、処理部２１０、記憶部２２０、および出力部２０３を備える。
【００１７】
入力部２０２は、パケットが入力されるインタフェースである。入力部２０２は、受信したパケットや情報を処理部２１０に送信する。
処理部２１０は、パケット情報取得部２１１、パケットロス・遅延検出部２１２、およびモニタ結果出力部２１３を備える。
【００１８】
パケット情報取得部２１１は、IPヘッダおよびＴＣＰヘッダの情報からＴＣＰのセッションＩＤを作成する。また、作成したＴＣＰセッションＩＤ、シーケンス番号や識別子などのＩＰヘッダおよびＴＣＰヘッダに記述された情報、およびパケットの受信時刻等をパケットロス・遅延検出部２１２に送信する。シーケンス番号は、ＴＣＰヘッダに記述されており、送信するデータの順序を送信先ホストに通知するために使う番号である。送信先ホストでは、この番号によってデータの順番を正しく並べ替えたり、ロスしたデータの再送要求を出したりすることができる。シーケンス番号により、データがデータ全体の中のどの位置のデータなのかが分かる。
【００１９】
識別子は、ＩＰヘッダに記述されており、パケットを送信するごとにインクリメントされる。
パケットロス・遅延検出部２１２は、通信状態記憶部２２１に格納されている情報およびパケット情報取得部２１１からの情報をもとに、パケットが単に遅延したのかロスによる再送があったのかを判定する。また、パケットの総遅延時間やロス数、パケットの受信時刻や識別子などの各種情報を通信状態記憶部２２１およびモニタ結果記憶部２２２に書き込む。
【００２０】
モニタ結果出力部２１３は、モニタ結果記憶部２２２に格納されているモニタ結果テーブルの情報の一部もしくは全てを取得して、出力部２０３に送信する。例えば、特定のセッションIDの値やセッションIDの上位24bitなどでマスクするフィルタ条件に基づき、記憶されている統計情報を抽出し、出力部２０３に送信しても良い。
【００２１】
記憶部２２０は、通信状態記憶部２２１およびモニタ結果記憶部２２２を備える。
通信状態記憶部２２１は、図３に示すような通信状態テーブルを格納する。
通信状態テーブルは、項目として、送信元アドレス、ＴＣＰセッションＩＤ、前回受信時刻、次回ＳＥＱ、および前回ＩＤ値を有する。
【００２２】
送信元アドレスは、送信ホストのＩＰアドレスである。
ＴＣＰセッションＩＤは、パケットのＴＣＰヘッダの送信元アドレス(SA)、送信元ポート番号(SP)、宛先アドレス(DA)、および宛先ポート(DP)から生成される値である。
前回受信時刻は、前回受信したパケットの受信時刻である。
【００２３】
次回ＳＥＱは、前回受信したパケットのシーケンス番号に前回受信したパケットのTCPのペイロードサイズを足したもので、次に受信するパケットが持つことを期待されているパケットのシーケンス番号である。
【００２４】
前回ＩＤ値は、前回受信したパケットのＩＰヘッダの識別子（ＩＤ値）である。
モニタ結果記憶部２２２は、図４に示すようなモニタ結果テーブルを格納する。
モニタ結果テーブルは、項目として、送信元アドレス、ＴＣＰセッションＩＤ、パケット送信数、ロス数、ロス率、および総遅延時間を有する。
【００２５】
送信元アドレスは、送信ホストのＩＰアドレスである。
ＴＣＰセッションＩＤは、パケットのＴＣＰヘッダの送信元アドレス(SA)、送信元ポート番号(SP)、宛先アドレス(DA)、および宛先ポート(DP)から生成される値である。
【００２６】
パケット送信数は、送信元ホストが送信したパケットのうちパケットキャプチャ装置が受信したパケットの数である。
ロス数は、ロスしたパケットの数である。
【００２７】
ロス率は、ロス数をパケット送信数で割り、１００を掛けた値であり、パケットの送信におけるロスの割合を示す。
総遅延時間（ミリ秒）は、遅延原因が単なる遅延であるパケットの遅延時間の合計を示す。
【００２８】
出力部２０３は、モニタ結果を出力するインタフェースある。例えば、ネットワーク管理者に統計情報を表示するためのモニタやネットワーク管理装置(NMS)に送信するための通信プロトコルをサポートするネットワークインタフェースである。
【００２９】
図５は、本発明の第１の実施の形態の識別方法のフローチャートである。
ステップＳ５０１において、入力部２０２はパケットを受信し、パケット情報取得部２１１にパケットを送信する。尚、今回受信したパケットを現パケット、今回受信したパケットの一つ前に受信したパケットを前パケット、今回受信したパケットの次に受信するパケットを次パケットと呼ぶ。
【００３０】
ステップＳ５０２において、パケット情報取得部２１１は、IPヘッダに記述されている送信元アドレス（SA）と宛先アドレス（DA）並びにＴＣＰヘッダに記述されている送信元ポート番号（SP）と宛先ポート番号（DP）からＴＣＰのセッションＩＤを作成する。
【００３１】
また、パケット情報取得部２１１は、TCPヘッダのシーケンス番号（SEQ）およびIPヘッダの識別子（ＩＤ値）を取得する。そして、セッションＩＤ、シーケンス番号、および識別子を1組としてパケットロス・遅延検出部２１２へ送信する。
また、パケット情報取得部２１１は、パケットを受信した時刻（パケット受信時刻）をパケットロス・遅延検出部２１２へ送信する。
【００３２】
ステップＳ５０３において、パケットロス・遅延検出部２１２は、パケットロス・遅延検出部２１２が受信した送信元アドレスおよびセッションＩＤをキーとして、通信状態テーブルを検索し、該当するエントリがあるか（すなわち、同じ送信元アドレスおよびセッションＩＤの組を持つエントリがあるか）判定する。該当するエントリがある場合はステップＳ５０４に進み、該当するエントリがない場合はステップＳ５０９に進む。セッションＩＤは送信元アドレスと送信先アドレスが逆の場合も同一のセッションＩＤが生成される。そこで、送信元アドレスも検索のためのキーとして使用することで、区別可能としている。
【００３３】
ステップＳ５０４において、パケットロス・遅延検出部２１２は、通信状態テーブルを参照し、通信状態テーブルから該当エントリの前回受信時刻、次回ＳＥＱ、および前回ＩＤ値を取得する。
【００３４】
パケットロス・遅延検出部２１２は、PRV_IDを前回ID値、CUR_IDを現パケットの識別子、PRV_Tを前回受信時刻、CUR_Tを現パケットの受信時刻、SEQを現パケットのシーケンス番号とする。
【００３５】
ステップＳ５０５において、パケットロス・遅延検出部２１２は、次回ＳＥＱとＳＥＱを比較し、同じ場合はステップＳ５０６に進み、異なる場合はステップＳ５１２に進む。
ステップＳ５０６において、パケットロス・遅延検出部２１２は、CUR_ID（現パケットの識別子）とPRV_ID（前回ＩＤ値（前パケットの識別子））に１を加算した値を比較し、同じ場合は単なる遅延であると判断しステップＳ５０７に進み、異なる場合はロスによる再送による遅延であると判断しステップＳ５０８に進む。
【００３６】
ステップＳ５０７において、パケットロス・遅延検出部２１２は、現パケットの受信時刻(CUR_T)から前回受信時刻(PRV_T)を引いた値をモニタ結果テーブルの該当エントリの総遅延時間に加算し、モニタ結果テーブルに書き込む。
【００３７】
ステップＳ５０８において、パケットロス・遅延検出部２１２は、今回のロス数をCUR_ID（現パケットの識別子）−PRV_ID（前回ＩＤ値（前パケットの識別子））−１で算出し、今回のロス数を現在のモニタ結果テーブルのロス数に加算し、モニタ結果テーブルに書き込む。
【００３８】
ステップＳ５０９において、パケットロス・遅延検出部２１２は、通信状態テーブルに新規エントリを作成する。
ステップＳ５１０において、パケットロス・遅延検出部２１２は、ＳＥＱ（現パケットのシーケンス番号）に現パケットのＴＣＰデータ長（ペイロードサイズ）を加算したものを次回SEQ（次に受信するパケットに期待されるシーケンス番号）として算出し、次回ＳＥＱを通信状態テーブルに書き込む。
【００３９】
ステップＳ５１１において、パケットロス・遅延検出部２１２は、前回受信時刻(PRV_T)を現パケットの受信時刻(CUR_T)、前回ＩＤ値（PRV_ID）を現パケットのＩＤ値（CUR_ID）として、通信状態テーブルに書き込む。また、パケット送信数に１を加算して、新たなパケット送信数とし、モニタ結果テーブルに書き込む。
【００４０】
次に遅延とロスの判断の具体例を示す。
以下の具体例において、通信状態記憶部２２１およびモニタ結果記憶部２２２には、それぞれ図３の通信状態テーブルおよび図４のモニタ結果テーブルが格納されているとする。
【００４１】
最初に遅延と判断される場合の例を示す。
先ず、新たにパケットを受信する（ステップＳ５０１）。
パケット情報取得部２１１は、新たに受信したパケット（現パケット）のＴＣＰヘッダおよびＩＰヘッダからＴＣＰセッションＩＤを作成する（ステップＳ５０２）。パケット情報取得部２１１は、TCPヘッダのシーケンス番号（SEQ）およびIPヘッダの識別子（ＩＤ）を取得する。そして、セッションＩＤ、シーケンス番号、および識別子を1組としてパケットロス・遅延検出部２１２へ送信する。また、パケットを受信した時刻（パケット受信時刻）をパケットロス・遅延検出部２１２へ送信する。
【００４２】
今回受信したパケットでは、送信元アドレス＝α、セッションID＝A、シーケンス番号（ＳＥＱ）=680、識別子（ID値）＝336が取得されたものとする。
通信状態テーブルをセッションID「A」と送信元アドレス「α」をキーに検索する（ステップＳ５０３）と、通信状態テーブルの１行目に該当エントリが存在するので、次回ＳＥＱとして680、前回ID値として335を取得する（ステップＳ５０４）。また、PRV_IDを前回ID値、CUR_IDを現パケットの識別子、PRV_Tを前回受信時刻、CUR_Tを現パケットの受信時刻、SEQを現パケットのシーケンス番号とする（ステップＳ５０４）。
【００４３】
次回SＥＱとＳＥＱとを比較する（ステップＳ５０５）と、共に６８０で同一である。
次にCUR_ID（＝３３６）とPRV_ID（＝３３５）に１を足したものを比較する（ステップＳ５０６）と、共に３３６で同一である。
【００４４】
次回ＳＥＱ（＝680）とＳＥＱ（＝680）とが同一であり、かつ現パケットの識別子（＝336）は前回ID値（＝335）から連続して増加しているため、現パケットは遅延であると判断する。
【００４５】
モニタ結果テーブルの総遅延時間に現パケットの受信時刻から前回受信時刻を引いた値を加算した値が書き込まれる（ステップＳ５０７）。
次に受信するパケットに期待されるシーケンス番号（次回ＳＥＱ）を算出し、通信状態テーブルに書き込む（ステップＳ５１０）。
【００４６】
前回受信時刻(PRV_T)を現パケットの受信時刻(CUR_T)、前回ＩＤ値（PRV_ID）を現パケットのＩＤ値（CUR_ID）として、通信状態テーブルに書き込む。また、パケット送信数に1を加算した値がモニタ結果テーブルに書き込まれ、パケット送信数は31となる（ステップＳ５１１）。
【００４７】
次にロスと判断される場合の例を示す。
先ず、新たにパケットを受信する（ステップＳ５０１）。
パケット情報取得部２１１は、新たに受信したパケット（現パケット）のＴＣＰヘッダおよびＩＰヘッダからＴＣＰセッションＩＤを作成する（ステップＳ５０２）。パケット情報取得部２１１は、TCPヘッダのシーケンス番号（SEQ）およびIPヘッダの識別子（ＩＤ）を取得する。そして、セッションＩＤ、シーケンス番号、および識別子を1組としてパケットロス・遅延検出部２１２へ送信する。また、パケットを受信した時刻（パケット受信時刻）をパケットロス・遅延検出部２１２へ送信する。
【００４８】
今回受信したパケットでは、送信元アドレス＝α、セッションID＝A、シーケンス番号（ＳＥＱ）=680、識別子（ID値）＝337が取得されたものとする。
通信状態テーブルをセッションID「A」と送信元アドレス「α」をキーに検索する（ステップＳ５０３）と、通信状態テーブルの１行目に該当エントリが存在するので、次回ＳＥＱとして680、前回ID値として335を取得する（ステップＳ５０４）。また、PRV_IDを前回ID値、CUR_IDを現パケットの識別子、PRV_Tを前回受信時刻、CUR_Tを現パケットの受信時刻、SEQを現パケットのシーケンス番号とする（ステップＳ５０４）。
【００４９】
次回SＥＱとＳＥＱとを比較する（ステップＳ５０５）と、共に６８０で同一である。
次にCUR_ID（＝３３７）とPRV_ID（＝３３５）に１を足したものを比較する（ステップＳ５０６）と、これらは異なっている。
【００５０】
次回ＳＥＱ（＝680）とＳＥＱ（＝680）とが同一であるが、現パケットの識別子（＝337）は前回ID値（＝335）から連続して増加していないため、現パケットは再送されたパケット、すなわち遅延原因はロスによる再送であると判断する（ステップＳ５０６）。
【００５１】
ロス数を算出すると、現パケットのＩＤ値−前回ＩＤ値−１＝３３７−３３５−１＝１となる。そして、モニタ結果テーブルの現在のロス数0に今回算出したロス数１を加算した値、すなわち、１を書き込む（ステップＳ５０８）。
【００５２】
次に受信するパケットに期待されるシーケンス番号（次回ＳＥＱ）を算出し、通信状態テーブルに書き込む（ステップＳ５１０）。
前回受信時刻(PRV_T)を現パケットの受信時刻(CUR_T)、前回ＩＤ値（PRV_ID）を現パケットのＩＤ値（CUR_ID）として、通信状態テーブルに書き込む。また、パケット送信数に1を加算した値をモニタ結果テーブルに書き込み、パケット送信数は31となる（ステップＳ５１１）。
【００５３】
（第２の実施の形態）
第２の実施の形態では、１つの送信ホストが複数の受信ホストにパケットを送信している場合を説明する。
【００５４】
図６は、第２の実施の形態に係るシステムの構成図および概念図である。
本発明の第２の実施の形態のシステムは、パケットキャプチャ装置６０１、送信ホスト６０２、受信ホスト６０３−ｎ（ｎ＝１〜３）、タップ６０４を備える。
【００５５】
タップ６０４は、送信ホスト６０２と受信ホスト６０３の間に配置される。
パケットキャプチャ装置６０１はタップ６０４と接続し、送信ホスト６０２および受信ホスト６０３はそれぞれネットワークを介してタップ６０４と接続している。
【００５６】
送信ホスト６０２が受信ホスト６０３にパケットを送信すると、送信ホスト１０２と受信ホスト６０３の間にあるタップ６０４は該パケットをパケットキャプチャ装置６０１に分岐させる。そして、パケットキャプチャ装置６０１は、パケットを受信する。
尚、受信ホスト６０３−６１０３−２、６０３−３のＩＰアドレスはそれぞれＡ、Ｂ、Ｃとする。
【００５７】
図６では、パケット６１１、パケット６１２、パケット６１３、パケット６１４の順で送信ホスト６０２から送信されている。パケット６１１、パケット６１２、パケット６１３、およびパケット６１４は、それぞれ受信ホスト６０３−１、受信ホスト６０３−２、受信ホスト６０３−３、および受信ホスト６０３−１に送信されている。
また、Ｓｅｑはパケットのシーケンス番号であり、ＩＤは識別子である。
【００５８】
受信ホスト６０３−１に対しては、ロス無くパケットが送信されているが、パケット６１１とパケット６１４の送信の間に他の受信ホストに対してパケットを送信しているため、パケット６１１の識別子（１００）とパケット６１４の識別子（１０３）は連続していない。この場合、第１の実施の形態の識別方法を用いると、実際にはロスが無いが、ロスと判断されてしまう。第２の実施の形態では、このような場合でも、パケット６１４が遅延であると判断する。
【００５９】
第２の実施の形態では、送信ホストが複数の受信ホストにパケットを送信していて、同一のＴＣＰセッションに対して識別子が連続していない場合でも、正しく判定できるようにする。
【００６０】
図７は、本発明の第２の実施の形態に係るパケットキャプチャ装置の構成図である。
パケットキャプチャ装置７０１は、入力部７０２、処理部７１０、記憶部７２０、および出力部７０３を備える。
【００６１】
入力部７０２は、パケットが入力されるインタフェースである。入力部７０２は、受信したパケットや情報を処理部に送信する。
処理部７１０は、パケット情報取得部７１１、パケットロス・遅延検出部７１２、およびモニタ結果出力部７１３を備える。
【００６２】
パケット情報取得部７１１は、IPヘッダおよびＴＣＰヘッダの情報からＴＣＰのセッションＩＤを作成する。また、作成したＴＣＰセッションＩＤ、シーケンス番号や識別子などのＩＰヘッダおよびＴＣＰヘッダに記述された情報、およびパケットの受信時刻等をパケットロス・遅延検出部７１２に送信する。
【００６３】
パケットロス・遅延検出部７１２は、通信状態記憶部７２１に格納されている情報およびパケット情報取得部７１１からの情報をもとに、パケットが遅延かロスかを判定する。また、パケットの総遅延時間やロス数、パケットの受信時刻や識別子などの各種情報を通信状態記憶部７２１、モニタ結果記憶部７２２、および連続開始ＩＤ記憶部７２３に書き込む。
【００６４】
モニタ結果出力部７１３は、モニタ結果記憶部７２２に格納されているモニタ結果テーブルの情報の一部もしくは全てを取得して、出力部７０３に送信する。例えば、特定のセッションIDの値やセッションIDの上位24bitなどでマスクするフィルタ条件に基づき、記憶されている統計情報を抽出し、出力部２０３に送信しても良い。
【００６５】
記憶部７２０は、通信状態記憶部７２１、モニタ結果記憶部７２２、および連続開始ＩＤ記憶部７２３を備える。
通信状態記憶部７２１は、図３に示すような通信状態テーブルを格納する。
通信状態テーブルは、第１の実施の形態と同様である。
【００６６】
モニタ結果記憶部７２２は、図８に示すようなモニタ結果テーブルを格納する。
モニタ結果テーブルは、項目として、送信元アドレス、ＴＣＰセッションＩＤ、パケット送信数、判断不能回数、および総遅延時間を有する。
【００６７】
送信元アドレス、ＴＣＰセッションＩＤ、パケット送信数、および総遅延時間に関しては、第１の実施の形態と同様である。
判断不能回数は、遅延であるかロスであるかの判断が出来なかった回数を示す。
【００６８】
連続開始ＩＤ記憶部７２３は、図９に示すような連続開始ＩＤテーブルを備える。連続開始ＩＤテーブルは、項目として、送信元アドレス、連続開始ＩＤ値、直前ＩＤ値、増加数を有する。
【００６９】
送信元アドレスは、送信ホストのＩＰアドレスである。
連続開始ＩＤ値は、ロス無くパケットを送信しているときの最初のパケットのＩＰヘッダの識別子（ＩＤ値）である。
【００７０】
直前ＩＤ値は、送信元ホストが前回送信したパケットのＩＰヘッダの識別子（ＩＤ値）である。
増加数は、パケットがロス無く連続しているとみなすことが出来る範囲である。
【００７１】
例えば、１行目のエントリを参照すると、送信元アドレスはα、連続開始ＩＤ値は１、直前ＩＤ値は３３５である。これにより、送信元アドレスがαの送信ホストは、識別子（ＩＤ値）が１のパケットから識別子（ＩＤ値）が３３５である直前のパケットまで、ロス無く連続して送信していることがわかる。
【００７２】
図９は、本発明の第２の実施の形態に係る識別方法のフローチャートである。
ステップＳ１００１において、入力部２０２はパケットを受信し、パケット情報取得部にパケットを送信する。
【００７３】
ステップＳ１００２において、パケット情報取得部７１１は、ＴＣＰヘッダまたはIPヘッダに記述されている、送信元アドレス(SA)、送信元ポート番号(SP)、宛先アドレス(DA)、および宛先ポート番号(DP)からＴＣＰのセッションＩＤを作成する。
【００７４】
また、パケット情報取得部７１１は、TCPヘッダのシーケンス番号（SEQ）およびIPヘッダの識別子（ＩＤ）を取得する。そして、セッションＩＤ、シーケンス番号、および識別子を1組としてパケットロス・遅延検出部７１２へ送信する。
【００７５】
ステップＳ１００３において、パケットロス・遅延検出部７１２は、通信状態テーブルを参照し、パケットロス・遅延検出部７１２が受信したセッションＩＤおよび送信元アドレスの組と同じセッションＩＤおよび送信元アドレスの組が通信状態テーブルにあるか判定する。
【００７６】
同じセッションＩＤおよび送信元アドレスの組がある場合ステップＳ１００４に進み、同じセッションＩＤおよび送信元アドレスの組がない場合ステップＳ１００６に進む。
ステップＳ１００４において、パケットロス・遅延検出部７１２は、送信元アドレスが連続開始ＩＤテーブルに存在するかチェックし、送信元アドレスが存在した場合はステップＳ１００５に進み、存在しない場合はステップＳ１００７に進む。
【００７７】
ステップＳ１００５において、CON_IDを連続開始ＩＤテーブルの該当エントリの連続開始ＩＤ値、L_IDを連続開始ＩＤテーブルの該当エントリの直前ＩＤ値、CUR_IDを現パケットのＩＰヘッダのＩＤ値とする。
【００７８】
ステップＳ１００６において、パケットロス・遅延検出部７１２は、パケット通信状態テーブルに新規エントリを作成する。
ステップＳ１００７において、パケットロス・遅延検出部７１２は、連続開始ＩＤテーブルに新規エントリを作成する。
【００７９】
ステップＳ１００８において、パケットロス・遅延検出部７１２は、連続開始ＩＤテーブルの該当エントリの連続開始ＩＤ値および直前ＩＤ値を現パケットのＩＰヘッダのID値とし、連続開始ＩＤテーブルに書き込む。
【００８０】
ステップＳ１００９において、パケットロス・遅延検出部７１２は、通信状態テーブルを参照し、通信状態テーブルから当該セッションＩＤの前回受信時刻、次回ＳＥＱ、および前回ＩＤ値を取得する。
【００８１】
パケットロス・遅延検出部７１２は、PRV_IDを前回ID値、PRV_Tを前回受信時刻、CUR_Tを現パケットの受信時刻、SEQを現パケットのシーケンス番号とする。
ステップＳ１０１０において、パケットロス・遅延検出部７１２は、次回ＳＥＱとＳＥＱを比較し、同じ場合はステップＳ１０１１に進み、異なる場合は遅延とロスの識別が出来ないのでステップＳ１０１７に進み、テーブルの更新処理を行う。
【００８２】
ステップＳ１０１１において、パケットロス・遅延検出部７１２は、現パケットのID値（CUR_ID）と直前ID値（L_ID）に定数Nを加算したものを比較する。CUR_IDがL_ID＋Ｎ以下である場合はステップＳ１０１２に進み、CUR_IDがL_ID＋Ｎより大きい場合はステップＳ１０１４に進む。ステップＳ１０１１では、CUR_IDがL_IDよりＮ以下しか増加していない場合は、ＩＤ値は連続しているとみなしている。
【００８３】
ステップＳ１０１２において、パケットロス・遅延検出部７１２は、該当エントリの連続開始ID値（CON_ID）と前パケットのID値（PRV_ID）を比較する。CON_IDがPRV_ID以下の場合は、遅延であると判定してステップＳ１０１３に進み、CON_IDがPRV_IDより大きい場合はステップＳ１０１５に進む。
【００８４】
ステップＳ１０１３において、受信時刻から前回受信時刻を減算した値をモニタ結果テーブルの総遅延時間に加算する。
ステップＳ１０１４において、連続開始ＩＤテーブルの該当エントリの連続開始ＩＤ値に現パケットのＩＤ値（CUR_ID）を書き込む。ステップＳ１０１４では、CUR_IDがL_ID+Nより大きいので、それ以前のＩＤ値は連続していないとみなし、連続開始ＩＤ値が現パケットのＩＤ値で更新される。
【００８５】
ステップＳ１０１５において、パケットロス・遅延検出部７１２は、ＩＤ値が連続していないので、遅延かロスか判断不能であると判断し、モニタ結果テーブルの判断不能回数に１加算する。
【００８６】
ステップＳ１０１６において、現パケットのシーケンス番号に現パケットのデータ長（ペイロードサイズ）を加算したものを次パケットに期待されるシーケンス番号（次回SEQ）として算出し、次回ＳＥＱを通信状態テーブルに書き込む。
【００８７】
ステップＳ１０１７において、通信状態テーブルの前回受信時刻に現パケットの受信時刻、前回ＩＤ値に現パケットのＩＤ値をそれぞれ書き込む。また、モニタ結果テーブルのパケット送信数に１加算する。また、連続開始ＩＤテーブルの該当エントリの直前ＩＤ値に現パケットのＩＤ値を書き込む。
【００８８】
次に第２の実施の形態の具体例について述べる。
以下の具体例において、通信状態記憶部７２１、モニタ結果記憶部７２２、および連続開始ＩＤ記憶部７２３には、それぞれ図３の通信状態テーブル、図８のモニタ結果テーブル、および図９の連続開始ＩＤテーブルが格納されているとする。
【００８９】
先ず、新たにパケットを受信する（ステップＳ１００１）。
パケット情報取得部７１１は、新たに受信したパケット（現パケット）のＴＣＰヘッダおよびＩＰヘッダからＴＣＰセッションＩＤを作成する（ステップＳ１００２）。パケット情報取得部７１１は、TCPヘッダのシーケンス番号（SEQ）およびIPヘッダの識別子（ＩＤ値）を取得する。そして、セッションＩＤ、シーケンス番号、および識別子を1組としてパケットロス・遅延検出部７１２へ送信する。また、パケットを受信した時刻（パケット受信時刻）をパケットロス・遅延検出部７１２へ送信する。
【００９０】
今回受信したパケットでは、送信元アドレス＝α、セッションID＝Ｂ、シーケンス番号（ＳＥＱ）=421、識別子（ID値）＝336が取得されたものとする。
通信状態テーブルをセッションID「Ｂ」と送信元アドレス「α」をキーに検索する（ステップＳ１００３）と、通信状態テーブルの２行目に該当エントリが存在する。
【００９１】
連続開始ＩＤテーブル送信元アドレス「α」をキーに検索する（ステップＳ１００４）と、連続開始テーブルの１行目に該当エントリが存在する。
CON_IDを連続開始ＩＤテーブルの該当エントリの連続開始ＩＤ値（１）、L_IDを連続開始ＩＤテーブルの該当エントリの直前ＩＤ値（３３５）、CUR_IDを現パケットのＩＰヘッダの識別子（ＩＤ値）（３３６）とする（ステップＳ１００５）。また、連続開始ＩＤテーブルから増加数Ｎとして１を取得する。
【００９２】
次回ＳＥＱとして421、前回ID値として211を取得する（ステップＳ１００９）。また、PRV_IDを前回ID値（２１１）、PRV_Tを前回受信時刻、CUR_Tを現パケットの受信時刻、SEQを現パケットのシーケンス番号（４２１）とする（ステップＳ１１０９）。
【００９３】
次回SＥＱとＳＥＱとを比較する（ステップＳ１０１０）と、共に４２１で同一である。
CON_ID（３３６）とL_ID（３３５）に増加数Ｎ（１）を加算したものを比較すると（ステップＳ１０１１）、CON_IDはL_ID+N以下である。
CON_ID（１）とPRV_ID（２１１）を比較すると（ステップＳ１０１２）、CON_IDはPRV_ID以下である。
【００９４】
以上から、現パケットのＩＤ値は連続しているとみなし、ロスによる再送は無く、パケットは単に遅延していると判断する。
以下、モニタ結果テーブル、通信状態テーブル、および連続開始ＩＤテーブルの更新を行う（ステップＳ１０１３、Ｓ１０１６、Ｓ１０１７）。
第２の実施形態のパケットキャプチャ装置によれば、送信元ホストが複数の送信先ホストと通信している場合でも、遅延を識別することが出来る。
【００９５】
（第３の実施の形態）
第３の実施の形態においては、送信元ホストがＬｉｎｕｘ（登録商標）などの特定のＯＳ（Operation System）の場合を説明する。
図１１は、本発明の第３の実施の形態のシステム構成図および概念図である。
【００９６】
本発明の第３の実施の形態のシステムは、パケットキャプチャ装置１１０１、送信ホスト１１０２、受信ホスト１１０３−ｎ（ｎ＝１〜３）、タップ１１０４を備える。
タップ１１０４は、送信ホスト１１０２と受信ホスト１１０３の間に配置される。
【００９７】
パケットキャプチャ装置１１０１はタップ１１０４と接続し、送信ホスト１１０２および受信ホスト１１０３はそれぞれネットワークを介してタップ１１０４と接続している。
送信ホスト１１０２が受信ホスト１１０３にパケットを送信すると、送信ホスト１０２と受信ホスト１１０３の間にあるタップ１１０４は該パケットをパケットキャプチャ装置１１０１に分岐させる。そして、パケットキャプチャ装置１１０１は、パケットを受信する。
尚、受信ホスト１１０３−１、１１０３−２、１１０３−３のＩＰアドレスはそれぞれＡ、Ｂ、Ｃとする。
【００９８】
図１１では、パケット１１１１、パケット１１１２、パケット１１１３、パケット１１１４の順で送信ホスト１１０２から送信されている。パケット１１１１、パケット１１１２、パケット１１１３、およびパケット１１１４は、それぞれ受信ホスト１１０３−１、受信ホスト１１０３−２、受信ホスト１１０３−３、および受信ホスト１１０３−１に送信されている。
【００９９】
また、Ｓｅｑはパケットのシーケンス番号であり、ＩＤは識別子である。
送信ホスト１１０１が例えばLinux（登録商標）等の特定のＯＳ（Operation System）を使用している場合は、ＩＰヘッダの識別子（ID値）はTCPコネクション毎にランダムな値から開始され、１パケット送信毎に１ずつ増加するが、送信ホストに共通する値ではない。
【０１００】
受信ホスト１１０３−１に送信されたパケット１１１１の識別子は１００であり、受信ホスト１１０３−２に送信されたパケット１１１２の識別子は５００であり、受信ホスト１１０３−３に送信されたパケット１１１３の識別子は１０００である。
【０１０１】
このように、ＴＣＰセッションごとに異なる識別子が初期値として与えられる。受信ホスト１１０３−１に送信されるパケット１１１４の識別子は１０１であり、同じＴＣＰセッションに対するパケット１１１１に対して識別子は連続している。
【０１０２】
この性質を利用すれば、同一のTCPセッションに属するパケットであれば、必ず識別子は１ずつ増加することが断定できるので、これをロスと遅延の識別に利用する。
識別子が同一のTCPセッションに属するパケットに対して必ず１ずつ増加すれば、第１の実施の形態の識別方法（図５のフローチャート）が利用できる。
それ以外の場合は、第２の実施の形態の識別方法（図９のフローチャート）を利用する。
【０１０３】
第３の実施の形態のパケットキャプチャ装置１１０１は、第１の実施の形態のパケットキャプチャ装置２０１および第２のパケットキャプチャ装置７０１の両方の機能を有し、適宜使い分けている。
どちらの識別方法を使用するかは、送信ホストのＯＳの種別により判断する。
【０１０４】
図１２は、本発明の第３の実施の形態のパケットキャプチャ装置の構成図である。
パケットキャプチャ装置１２０１は、入力部１２０２、出力部１２０３、処理部１２１０、および記憶部１２２０を備える。
【０１０５】
入力部１２０２は、パケットが入力されるインタフェースである。入力部２０２は、受信したパケットや情報を処理部に送信する。
処理部１２１０は、パケットのヘッダの情報の取得、取得した情報に基づく遅延の原因の識別、結果の送信などの処理を行う。
【０１０６】
出力部１２０３は、モニタ結果を出力するインタフェースであり、ネットワーク管理者に統計情報を表示するための画面であってもよく、ネットワーク管理装置(NMS)に送信するための通信プロトコルをサポートするネットワークインタフェースであってもよい良い。
処理部１２１０は、パケット情報取得部１２１１、パケットロス・遅延検出部１２１２、およびモニタ結果出力部１２１３を備える。
【０１０７】
パケット情報取得部１２１１は、IPヘッダおよびＴＣＰヘッダの情報からＴＣＰのセッションＩＤを作成する。また、作成したＴＣＰセッションＩＤ、シーケンス番号や識別子などのＩＰヘッダおよびＴＣＰヘッダに記述された情報、およびパケットの受信時刻等をパケットロス・遅延検出部１２１２に送信する。
【０１０８】
パケットロス・遅延検出部１２１２は、通信状態記憶部１２２１に格納されている情報およびパケット情報取得部１２１１からの情報をもとに、ＯＳ種別の識別やパケットが遅延かロスかを判定する。また、パケットの総遅延時間やロス数、パケットの受信時刻や識別子などの各種情報を通信状態記憶部１２２１、モニタ結果記憶部１２２２、連続開始ＩＤ記憶部１２２３、およびＯＳ種別記憶部１２２４に書き込む。
【０１０９】
モニタ結果出力部１２１３は、モニタ結果記憶部１２２２に格納されているモニタ結果テーブルの情報の一部もしくは全てを取得して、出力部１２０３に送信する。例えば、特定のセッションIDの値やセッションIDの上位24bitなどでマスクするフィルタ条件に基づき、記憶されている統計情報を抽出し、出力部１２０３に送信しても良い。
【０１１０】
記憶部１２２０は、通信状態記憶部１２２１、モニタ結果記憶部１２２２、連続開始ＩＤ記憶部１２２３、およびＯＳ種別記憶部１２２４を備える。
通信状態記憶部１２２１は、図３に示すような通信状態テーブルを備える。通信状態テーブルについては、第２の実施の形態と同様である。
【０１１１】
モニタ結果記憶部１２２２は、図１３に示すようなモニタ結果テーブルを備える。モニタ結果テーブルは、項目として、送信元アドレス、ＴＣＰセッションＩＤ、パケット送信数、ロス数、ロス率、総遅延時間、および判断不能回数を有する。
【０１１２】
送信元アドレス、ＴＣＰセッションＩＤ、パケット送信数、ロス数、ロス率、および総遅延時間に関しては、第１の実施の形態と同様である。また、判断不能回数に関しては、第２の実施の形態と同様である。
【０１１３】
連続開始ＩＤ記憶部１２２３は、図９に示すような連続開始ＩＤテーブルを備える。連続開始ＩＤテーブルについては、第２の実施の形態と同様である。
ＯＳ種別記憶部１２２４は、図１４に示すようなＯＳ種別テーブルを備える。
ＯＳ種別テーブルは、項目として、送信元アドレスとＯＳタイプを有する。送信元アドレスには、送信ホストのＩＰアドレスが格納される。ＯＳタイプには、送信ホストのＯＳの種類が格納される。
【０１１４】
ＯＳ種別テーブルには、送信元アドレスとＯＳタイプが対応するように格納されている。
ＯＳタイプＢは、ＴＣＰセッションごとに異なる識別子を与え、同一のTCPセッションに属するパケットに対して識別子を１ずつ増加させるＯＳであり、例えばLinuxが該当する。ＯＳタイプＡは、ＴＣＰセッションごとに異なる識別子を与えないＯＳである。
【０１１５】
図１５は、第３の実施の形態の識別方法のフローチャートである。
ステップＳ１５０１において、パケットを受信する。
ステップＳ１５０２において、受信したパケットがSYN/ACKパケットかどうか判定する。SYN/ACKパケットの場合はステップＳ１５０３に進み、SYN/ACKパケットでない場合はステップＳ１５０４に進む。
【０１１６】
SYN/ACKパケットとは、ＴＣＰコネクションの確立時に使用されるパケットである。
ＴＣＰコネクションの確立手順は、先ずクライアントが接続要求（SYNパケット）をサーバに送信する。サーバは、接続要求に対する応答（SYN/ACKパケット）をクライアントに送信する。クライアントは、SYN/ACKパケットに対して、ACKパケットをサーバに送信する。ＴＣＰコネクションは上記手順により確立される。
【０１１７】
SYN/ACKパケットかどうかは、ＴＣＰヘッダのSYNフラグおよびACKフラグが１であるかをチェックすることで行う。SYNフラグおよびACKフラグが１であれば、SYN/ACKパケットであると判断する。
【０１１８】
ステップＳ１５０３において、パケットのＩＰヘッダの識別子（ＩＤ値）が０であるか判定し、０である場合はステップＳ１５０７に進み、０でない場合はステップＳ１５０９に進む。ＴＣＰセッションごとに異なる識別子を与え、同一のTCPセッションに属するパケットに対して識別子を１ずつ増加させるＯＳでは、SYN/ACKパケットの識別子は、０である。したがって、ステップＳ１５０３では、SYN/ACKパケットの識別子により、ＯＳの種別を識別している。
【０１１９】
ステップＳ１５０４において、パケットのＩＰヘッダの送信元アドレスをキーとしてＯＳ種別テーブルを検索する。
ステップＳ１５０５において、ステップＳ１５０４での検索の結果、ＯＳ種別テーブルに該当するエントリがない場合はステップＳ１５０６に進み、該当するエントリがある場合はステップＳ１５１０に進む。
ステップＳ１５０６において、ＯＳ種別テーブルに新規エントリを作成する。
【０１２０】
ステップＳ１５０７において、ＯＳタイプをＢとし、ＯＳ種別テーブルに書き込む。
ステップＳ１５０８において、図５のステップＳ５０２に進む。パケットキャプチャ装置１２０１は、ステップＳ５０２以降の処理を行い、図５のＥＮＤに到達したら、ステップＳ１５０８に戻り、終了する。このとき、入力部１２０２、出力部１２０３、パケット情報取得部１２１１、パケットロス・遅延検出部１２１２、モニタ結果出力部１２１３、通信状態記憶部１２２１、およびモニタ結果記憶部１２２２は、それぞれ第１の実施の形態の入力部２０２、出力部２０３、パケット情報取得部２１１、パケットロス・遅延検出部２１２、モニタ結果出力部２１３、通信状態記憶部２２１、およびモニタ結果記憶部２２２に対応する。
【０１２１】
ステップＳ１５０９において、ＯＳタイプをＡとし、ＯＳ種別テーブルに書き込む。
ステップＳ１５１０において、ＯＳ種別テーブルを参照し、パケットの送信元ホストのＯＳのタイプを判定し、タイプがＡである場合はステップＳ１５１１に進み、Ａでない（Ｂである）場合はステップＳ１５０８に進む。
【０１２２】
ステップＳ１５１１において、図１０のステップＳ１００２に進む。パケットキャプチャ装置１２０１は、ステップＳ１００２以降の処理を行い、図５のＥＮＤに到達したら、ステップＳ１５０８に戻り、終了する。このとき、入力部１２０２、出力部１２０３、パケット情報取得部１２１１、パケットロス・遅延検出部１２１２、モニタ結果出力部１２１３、通信状態記憶部１２２１、モニタ結果記憶部１２２２、および連続開始ＩＤ記憶部１２２３は、それぞれ第２の実施の形態の入力部７０２、出力部７０３、パケット情報取得部７１１、パケットロス・遅延検出部７１２、モニタ結果出力部７１３、通信状態記憶部７２１、モニタ結果記憶部７２２、および連続開始ＩＤ記憶部７２３に対応する。
【０１２３】
第３の実施の形態のパケットキャプチャ装置によれば、ＯＳの種類を識別することで、送信ホストのＯＳに応じた識別方法を用いることが出来る。それにより正しく識別できる可能性が高くなる。
【０１２４】
以上、本発明を実施例により説明したが、本発明は上記実施例に限定されるものではなく、本発明の範囲内で種々の変形及び改良が可能であることは言うまでもない。
【符号の説明】
【０１２５】
１０１ パケットキャプチャ装置
１０２ 送信ホスト
１０３ 受信ホスト
１０４ タップ
２０１ パケットキャプチャ装置
２０２ 入力部
２０３ 出力部
２１０ 処理部
２１１ パケット情報取得部
２１２ パケットロス・遅延検出部
２１３ モニタ結果出力部
２２０ 記憶部
２２１ 通信状態記憶部
２２２ モニタ結果記憶部
７０１ パケットキャプチャ装置
７０２ 入力部
７０３ 出力部
７１０ 処理部
７１１ パケット情報取得部
７１２ パケットロス・遅延検出部
７１３ モニタ結果出力部
７２０ 記憶部
７２１ 通信状態記憶部
７２２ モニタ結果記憶部
７２３ 連続開始ＩＤ記憶部
１２０１ パケットキャプチャ装置
１２０２ 入力部
１２０３ 出力部
１２１０ 処理部
１２１１ パケット情報取得部
１２１２ パケットロス・遅延検出部
１２１３ モニタ結果出力部
１２２０ 記憶部
１２２１ 通信状態記憶部
１２２２ モニタ結果記憶部
１２２３ 連続開始ＩＤ記憶部
１２２４ ＯＳ種別記憶部
【技術分野】
【０００１】
本発明は、パケットの遅延原因を判定するパケットキャプチャ装置に関する。
【背景技術】
【０００２】
システムの運用保守に際し、パケットの遅延が起きている場合に、問題を解決するには、その原因を的確に把握する必要がある。問題解決のために、具体的には、パケットの送信者がパケットの送信を遅延させたことが原因でパケット到着が遅延したのか、または、ネットワーク内でパケットがロスしたことが原因でパケットの送信者が再送信したために結果としてパケット到着が遅延したのかを知る必要がある。
【０００３】
従来、IP（Internet Protocol）より上位レイヤのプロトコルのうち、TCP（Transmission Control Protocol）等の再送手順を持つプロトコルに関して、パケットロスを識別する方法としては、単調増加するシーケンス番号を手がかりに、シーケンス番号が連続していればパケットロスは発生していないと判断していた。
【０００４】
よって、シーケンス番号が連続する場合にはロスとしては認識されず、前回受信したパケットからのパケット到着が遅延するケースにおいては、どのような場合でも送信ホストが単純に送信に時間がかかったと判断していた。
【０００５】
特許文献１には、シーケンス番号をもとに、パケット到着の時系列的な情報から、再送信と正常送信を識別する技術が記載されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００５−２１０５１５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、TCPなどIPレイヤよりも上位のレイヤで再送手順を持つプロトコルでは、一般にはパケットがロスした後に、ロスを回復するためのパケットを再送している。仮に送信ホストと計測装置の間でパケットがロスし送信ホストが再送した場合でも、計測装置ではシーケンス番号が連続していることが観測できるため、ロスとは識別せずに単なる遅延と判断してしまうという問題があった。
【０００８】
このように従来の方法では、ＴＣＰヘッダのシーケンス番号の連続性から、ロスか遅延かを判断しているため、遅延の原因を正しく判断することが出来なかった。
【０００９】
本発明の課題は、パケットの遅延の原因が単純に遅延したものか再送を行ったため遅延したのかを正しく識別する装置を提供することである。
【課題を解決するための手段】
【００１０】
開示のパケットキャプチャ装置は、受信したパケットのヘッダに記述されているＩＤ値およびシーケンス番号を取得する取得部と、前回受信したパケットのＩＤ値である前回ＩＤ値および次回受信するパケットが持つべきシーケンス番号である次回シーケンス番号を記憶する記憶部と、前記受信したパケットの遅延原因が単なる遅延かロスに伴う再送による遅延かを判定する検出部と、を備え、前記検出部は、前記次回シーケンス番号と前記今回取得したパケットのシーケンス番号とを比較し、前記前回ＩＤ値と今回受信したパケットのＩＤ値とを比較し、前記次回シーケンス番号と前記今回受信したパケットのシーケンス番号が一致し、且つ前記前回ＩＤ値と前記今回受信したパケットのＩＤ値が連続しているときに単なる遅延であると判定し、前記前回ＩＤ値と前記今回受信したパケットのＩＤ値が連続していないときに再送による遅延であると判定することを特徴とする。
【発明の効果】
【００１１】
開示の装置によれば、パケットの遅延の原因が単純に遅延したものか再送を行ったため遅延したものかの識別を行うことが出来る。
【図面の簡単な説明】
【００１２】
【図１】本発明の第１の実施の形態に係るシステムの構成図である。
【図２】本発明の第１の実施の形態に係るパケットキャプチャ装置の構成図である。
【図３】通信状態テーブルの例である。
【図４】モニタ結果テーブルの例である。
【図５】本発明の実施の形態の識別方法のフローチャートである。
【図６】第２の実施の形態に係るシステムの構成図である。
【図７】本発明の第２の実施の形態に係るパケットキャプチャ装置の構成図である。
【図８】モニタ結果テーブルの例である。
【図９】連続開始ＩＤテーブルの例である。
【図１０】本発明の第２の実施の形態に係る識別方法のフローチャートである。
【図１１】第３の実施の形態に係るシステムの構成図である
【図１２】本発明の第３の実施の形態に係るパケットキャプチャ装置の構成図である。
【図１３】モニタ結果テーブルの例である。
【図１４】ＯＳ種別テーブルの例を示す図である。
【図１５】本発明の第３の実施の形態の識別方法のフローチャートである。
【発明を実施するための形態】
【００１３】
以下、図面を参照しながら、本発明の実施の形態を説明する。
（第１の実施の形態）
図１は、本発明の第１の実施の形態に係るシステムの構成図である。
【００１４】
本発明の実施の形態のシステムは、パケットキャプチャ装置１０１、送信ホスト１０２、受信ホスト１０３、タップ１０４を備える。
タップ１０４は、送信ホスト１０２と受信ホスト１０３の間に配置される。
パケットキャプチャ装置１０１は、タップ１０４と接続し、送信ホスト１０２および受信ホスト１０３はそれぞれネットワークを介してタップ１０４と接続している。
【００１５】
送信ホスト１０２が受信ホスト１０３にパケットを送信すると、送信ホスト１０２と受信ホスト１０３の間にあるタップ１０４は該パケットをパケットキャプチャ装置１０１に分岐させる。そして、パケットキャプチャ装置１０１は、パケットを受信する。
【００１６】
図２は、本発明の第１の実施の形態のパケットキャプチャ装置の構成図である。
パケットキャプチャ装置２０１は、入力部２０２、処理部２１０、記憶部２２０、および出力部２０３を備える。
【００１７】
入力部２０２は、パケットが入力されるインタフェースである。入力部２０２は、受信したパケットや情報を処理部２１０に送信する。
処理部２１０は、パケット情報取得部２１１、パケットロス・遅延検出部２１２、およびモニタ結果出力部２１３を備える。
【００１８】
パケット情報取得部２１１は、IPヘッダおよびＴＣＰヘッダの情報からＴＣＰのセッションＩＤを作成する。また、作成したＴＣＰセッションＩＤ、シーケンス番号や識別子などのＩＰヘッダおよびＴＣＰヘッダに記述された情報、およびパケットの受信時刻等をパケットロス・遅延検出部２１２に送信する。シーケンス番号は、ＴＣＰヘッダに記述されており、送信するデータの順序を送信先ホストに通知するために使う番号である。送信先ホストでは、この番号によってデータの順番を正しく並べ替えたり、ロスしたデータの再送要求を出したりすることができる。シーケンス番号により、データがデータ全体の中のどの位置のデータなのかが分かる。
【００１９】
識別子は、ＩＰヘッダに記述されており、パケットを送信するごとにインクリメントされる。
パケットロス・遅延検出部２１２は、通信状態記憶部２２１に格納されている情報およびパケット情報取得部２１１からの情報をもとに、パケットが単に遅延したのかロスによる再送があったのかを判定する。また、パケットの総遅延時間やロス数、パケットの受信時刻や識別子などの各種情報を通信状態記憶部２２１およびモニタ結果記憶部２２２に書き込む。
【００２０】
モニタ結果出力部２１３は、モニタ結果記憶部２２２に格納されているモニタ結果テーブルの情報の一部もしくは全てを取得して、出力部２０３に送信する。例えば、特定のセッションIDの値やセッションIDの上位24bitなどでマスクするフィルタ条件に基づき、記憶されている統計情報を抽出し、出力部２０３に送信しても良い。
【００２１】
記憶部２２０は、通信状態記憶部２２１およびモニタ結果記憶部２２２を備える。
通信状態記憶部２２１は、図３に示すような通信状態テーブルを格納する。
通信状態テーブルは、項目として、送信元アドレス、ＴＣＰセッションＩＤ、前回受信時刻、次回ＳＥＱ、および前回ＩＤ値を有する。
【００２２】
送信元アドレスは、送信ホストのＩＰアドレスである。
ＴＣＰセッションＩＤは、パケットのＴＣＰヘッダの送信元アドレス(SA)、送信元ポート番号(SP)、宛先アドレス(DA)、および宛先ポート(DP)から生成される値である。
前回受信時刻は、前回受信したパケットの受信時刻である。
【００２３】
次回ＳＥＱは、前回受信したパケットのシーケンス番号に前回受信したパケットのTCPのペイロードサイズを足したもので、次に受信するパケットが持つことを期待されているパケットのシーケンス番号である。
【００２４】
前回ＩＤ値は、前回受信したパケットのＩＰヘッダの識別子（ＩＤ値）である。
モニタ結果記憶部２２２は、図４に示すようなモニタ結果テーブルを格納する。
モニタ結果テーブルは、項目として、送信元アドレス、ＴＣＰセッションＩＤ、パケット送信数、ロス数、ロス率、および総遅延時間を有する。
【００２５】
送信元アドレスは、送信ホストのＩＰアドレスである。
ＴＣＰセッションＩＤは、パケットのＴＣＰヘッダの送信元アドレス(SA)、送信元ポート番号(SP)、宛先アドレス(DA)、および宛先ポート(DP)から生成される値である。
【００２６】
パケット送信数は、送信元ホストが送信したパケットのうちパケットキャプチャ装置が受信したパケットの数である。
ロス数は、ロスしたパケットの数である。
【００２７】
ロス率は、ロス数をパケット送信数で割り、１００を掛けた値であり、パケットの送信におけるロスの割合を示す。
総遅延時間（ミリ秒）は、遅延原因が単なる遅延であるパケットの遅延時間の合計を示す。
【００２８】
出力部２０３は、モニタ結果を出力するインタフェースある。例えば、ネットワーク管理者に統計情報を表示するためのモニタやネットワーク管理装置(NMS)に送信するための通信プロトコルをサポートするネットワークインタフェースである。
【００２９】
図５は、本発明の第１の実施の形態の識別方法のフローチャートである。
ステップＳ５０１において、入力部２０２はパケットを受信し、パケット情報取得部２１１にパケットを送信する。尚、今回受信したパケットを現パケット、今回受信したパケットの一つ前に受信したパケットを前パケット、今回受信したパケットの次に受信するパケットを次パケットと呼ぶ。
【００３０】
ステップＳ５０２において、パケット情報取得部２１１は、IPヘッダに記述されている送信元アドレス（SA）と宛先アドレス（DA）並びにＴＣＰヘッダに記述されている送信元ポート番号（SP）と宛先ポート番号（DP）からＴＣＰのセッションＩＤを作成する。
【００３１】
また、パケット情報取得部２１１は、TCPヘッダのシーケンス番号（SEQ）およびIPヘッダの識別子（ＩＤ値）を取得する。そして、セッションＩＤ、シーケンス番号、および識別子を1組としてパケットロス・遅延検出部２１２へ送信する。
また、パケット情報取得部２１１は、パケットを受信した時刻（パケット受信時刻）をパケットロス・遅延検出部２１２へ送信する。
【００３２】
ステップＳ５０３において、パケットロス・遅延検出部２１２は、パケットロス・遅延検出部２１２が受信した送信元アドレスおよびセッションＩＤをキーとして、通信状態テーブルを検索し、該当するエントリがあるか（すなわち、同じ送信元アドレスおよびセッションＩＤの組を持つエントリがあるか）判定する。該当するエントリがある場合はステップＳ５０４に進み、該当するエントリがない場合はステップＳ５０９に進む。セッションＩＤは送信元アドレスと送信先アドレスが逆の場合も同一のセッションＩＤが生成される。そこで、送信元アドレスも検索のためのキーとして使用することで、区別可能としている。
【００３３】
ステップＳ５０４において、パケットロス・遅延検出部２１２は、通信状態テーブルを参照し、通信状態テーブルから該当エントリの前回受信時刻、次回ＳＥＱ、および前回ＩＤ値を取得する。
【００３４】
パケットロス・遅延検出部２１２は、PRV_IDを前回ID値、CUR_IDを現パケットの識別子、PRV_Tを前回受信時刻、CUR_Tを現パケットの受信時刻、SEQを現パケットのシーケンス番号とする。
【００３５】
ステップＳ５０５において、パケットロス・遅延検出部２１２は、次回ＳＥＱとＳＥＱを比較し、同じ場合はステップＳ５０６に進み、異なる場合はステップＳ５１２に進む。
ステップＳ５０６において、パケットロス・遅延検出部２１２は、CUR_ID（現パケットの識別子）とPRV_ID（前回ＩＤ値（前パケットの識別子））に１を加算した値を比較し、同じ場合は単なる遅延であると判断しステップＳ５０７に進み、異なる場合はロスによる再送による遅延であると判断しステップＳ５０８に進む。
【００３６】
ステップＳ５０７において、パケットロス・遅延検出部２１２は、現パケットの受信時刻(CUR_T)から前回受信時刻(PRV_T)を引いた値をモニタ結果テーブルの該当エントリの総遅延時間に加算し、モニタ結果テーブルに書き込む。
【００３７】
ステップＳ５０８において、パケットロス・遅延検出部２１２は、今回のロス数をCUR_ID（現パケットの識別子）−PRV_ID（前回ＩＤ値（前パケットの識別子））−１で算出し、今回のロス数を現在のモニタ結果テーブルのロス数に加算し、モニタ結果テーブルに書き込む。
【００３８】
ステップＳ５０９において、パケットロス・遅延検出部２１２は、通信状態テーブルに新規エントリを作成する。
ステップＳ５１０において、パケットロス・遅延検出部２１２は、ＳＥＱ（現パケットのシーケンス番号）に現パケットのＴＣＰデータ長（ペイロードサイズ）を加算したものを次回SEQ（次に受信するパケットに期待されるシーケンス番号）として算出し、次回ＳＥＱを通信状態テーブルに書き込む。
【００３９】
ステップＳ５１１において、パケットロス・遅延検出部２１２は、前回受信時刻(PRV_T)を現パケットの受信時刻(CUR_T)、前回ＩＤ値（PRV_ID）を現パケットのＩＤ値（CUR_ID）として、通信状態テーブルに書き込む。また、パケット送信数に１を加算して、新たなパケット送信数とし、モニタ結果テーブルに書き込む。
【００４０】
次に遅延とロスの判断の具体例を示す。
以下の具体例において、通信状態記憶部２２１およびモニタ結果記憶部２２２には、それぞれ図３の通信状態テーブルおよび図４のモニタ結果テーブルが格納されているとする。
【００４１】
最初に遅延と判断される場合の例を示す。
先ず、新たにパケットを受信する（ステップＳ５０１）。
パケット情報取得部２１１は、新たに受信したパケット（現パケット）のＴＣＰヘッダおよびＩＰヘッダからＴＣＰセッションＩＤを作成する（ステップＳ５０２）。パケット情報取得部２１１は、TCPヘッダのシーケンス番号（SEQ）およびIPヘッダの識別子（ＩＤ）を取得する。そして、セッションＩＤ、シーケンス番号、および識別子を1組としてパケットロス・遅延検出部２１２へ送信する。また、パケットを受信した時刻（パケット受信時刻）をパケットロス・遅延検出部２１２へ送信する。
【００４２】
今回受信したパケットでは、送信元アドレス＝α、セッションID＝A、シーケンス番号（ＳＥＱ）=680、識別子（ID値）＝336が取得されたものとする。
通信状態テーブルをセッションID「A」と送信元アドレス「α」をキーに検索する（ステップＳ５０３）と、通信状態テーブルの１行目に該当エントリが存在するので、次回ＳＥＱとして680、前回ID値として335を取得する（ステップＳ５０４）。また、PRV_IDを前回ID値、CUR_IDを現パケットの識別子、PRV_Tを前回受信時刻、CUR_Tを現パケットの受信時刻、SEQを現パケットのシーケンス番号とする（ステップＳ５０４）。
【００４３】
次回SＥＱとＳＥＱとを比較する（ステップＳ５０５）と、共に６８０で同一である。
次にCUR_ID（＝３３６）とPRV_ID（＝３３５）に１を足したものを比較する（ステップＳ５０６）と、共に３３６で同一である。
【００４４】
次回ＳＥＱ（＝680）とＳＥＱ（＝680）とが同一であり、かつ現パケットの識別子（＝336）は前回ID値（＝335）から連続して増加しているため、現パケットは遅延であると判断する。
【００４５】
モニタ結果テーブルの総遅延時間に現パケットの受信時刻から前回受信時刻を引いた値を加算した値が書き込まれる（ステップＳ５０７）。
次に受信するパケットに期待されるシーケンス番号（次回ＳＥＱ）を算出し、通信状態テーブルに書き込む（ステップＳ５１０）。
【００４６】
前回受信時刻(PRV_T)を現パケットの受信時刻(CUR_T)、前回ＩＤ値（PRV_ID）を現パケットのＩＤ値（CUR_ID）として、通信状態テーブルに書き込む。また、パケット送信数に1を加算した値がモニタ結果テーブルに書き込まれ、パケット送信数は31となる（ステップＳ５１１）。
【００４７】
次にロスと判断される場合の例を示す。
先ず、新たにパケットを受信する（ステップＳ５０１）。
パケット情報取得部２１１は、新たに受信したパケット（現パケット）のＴＣＰヘッダおよびＩＰヘッダからＴＣＰセッションＩＤを作成する（ステップＳ５０２）。パケット情報取得部２１１は、TCPヘッダのシーケンス番号（SEQ）およびIPヘッダの識別子（ＩＤ）を取得する。そして、セッションＩＤ、シーケンス番号、および識別子を1組としてパケットロス・遅延検出部２１２へ送信する。また、パケットを受信した時刻（パケット受信時刻）をパケットロス・遅延検出部２１２へ送信する。
【００４８】
今回受信したパケットでは、送信元アドレス＝α、セッションID＝A、シーケンス番号（ＳＥＱ）=680、識別子（ID値）＝337が取得されたものとする。
通信状態テーブルをセッションID「A」と送信元アドレス「α」をキーに検索する（ステップＳ５０３）と、通信状態テーブルの１行目に該当エントリが存在するので、次回ＳＥＱとして680、前回ID値として335を取得する（ステップＳ５０４）。また、PRV_IDを前回ID値、CUR_IDを現パケットの識別子、PRV_Tを前回受信時刻、CUR_Tを現パケットの受信時刻、SEQを現パケットのシーケンス番号とする（ステップＳ５０４）。
【００４９】
次回SＥＱとＳＥＱとを比較する（ステップＳ５０５）と、共に６８０で同一である。
次にCUR_ID（＝３３７）とPRV_ID（＝３３５）に１を足したものを比較する（ステップＳ５０６）と、これらは異なっている。
【００５０】
次回ＳＥＱ（＝680）とＳＥＱ（＝680）とが同一であるが、現パケットの識別子（＝337）は前回ID値（＝335）から連続して増加していないため、現パケットは再送されたパケット、すなわち遅延原因はロスによる再送であると判断する（ステップＳ５０６）。
【００５１】
ロス数を算出すると、現パケットのＩＤ値−前回ＩＤ値−１＝３３７−３３５−１＝１となる。そして、モニタ結果テーブルの現在のロス数0に今回算出したロス数１を加算した値、すなわち、１を書き込む（ステップＳ５０８）。
【００５２】
次に受信するパケットに期待されるシーケンス番号（次回ＳＥＱ）を算出し、通信状態テーブルに書き込む（ステップＳ５１０）。
前回受信時刻(PRV_T)を現パケットの受信時刻(CUR_T)、前回ＩＤ値（PRV_ID）を現パケットのＩＤ値（CUR_ID）として、通信状態テーブルに書き込む。また、パケット送信数に1を加算した値をモニタ結果テーブルに書き込み、パケット送信数は31となる（ステップＳ５１１）。
【００５３】
（第２の実施の形態）
第２の実施の形態では、１つの送信ホストが複数の受信ホストにパケットを送信している場合を説明する。
【００５４】
図６は、第２の実施の形態に係るシステムの構成図および概念図である。
本発明の第２の実施の形態のシステムは、パケットキャプチャ装置６０１、送信ホスト６０２、受信ホスト６０３−ｎ（ｎ＝１〜３）、タップ６０４を備える。
【００５５】
タップ６０４は、送信ホスト６０２と受信ホスト６０３の間に配置される。
パケットキャプチャ装置６０１はタップ６０４と接続し、送信ホスト６０２および受信ホスト６０３はそれぞれネットワークを介してタップ６０４と接続している。
【００５６】
送信ホスト６０２が受信ホスト６０３にパケットを送信すると、送信ホスト１０２と受信ホスト６０３の間にあるタップ６０４は該パケットをパケットキャプチャ装置６０１に分岐させる。そして、パケットキャプチャ装置６０１は、パケットを受信する。
尚、受信ホスト６０３−６１０３−２、６０３−３のＩＰアドレスはそれぞれＡ、Ｂ、Ｃとする。
【００５７】
図６では、パケット６１１、パケット６１２、パケット６１３、パケット６１４の順で送信ホスト６０２から送信されている。パケット６１１、パケット６１２、パケット６１３、およびパケット６１４は、それぞれ受信ホスト６０３−１、受信ホスト６０３−２、受信ホスト６０３−３、および受信ホスト６０３−１に送信されている。
また、Ｓｅｑはパケットのシーケンス番号であり、ＩＤは識別子である。
【００５８】
受信ホスト６０３−１に対しては、ロス無くパケットが送信されているが、パケット６１１とパケット６１４の送信の間に他の受信ホストに対してパケットを送信しているため、パケット６１１の識別子（１００）とパケット６１４の識別子（１０３）は連続していない。この場合、第１の実施の形態の識別方法を用いると、実際にはロスが無いが、ロスと判断されてしまう。第２の実施の形態では、このような場合でも、パケット６１４が遅延であると判断する。
【００５９】
第２の実施の形態では、送信ホストが複数の受信ホストにパケットを送信していて、同一のＴＣＰセッションに対して識別子が連続していない場合でも、正しく判定できるようにする。
【００６０】
図７は、本発明の第２の実施の形態に係るパケットキャプチャ装置の構成図である。
パケットキャプチャ装置７０１は、入力部７０２、処理部７１０、記憶部７２０、および出力部７０３を備える。
【００６１】
入力部７０２は、パケットが入力されるインタフェースである。入力部７０２は、受信したパケットや情報を処理部に送信する。
処理部７１０は、パケット情報取得部７１１、パケットロス・遅延検出部７１２、およびモニタ結果出力部７１３を備える。
【００６２】
パケット情報取得部７１１は、IPヘッダおよびＴＣＰヘッダの情報からＴＣＰのセッションＩＤを作成する。また、作成したＴＣＰセッションＩＤ、シーケンス番号や識別子などのＩＰヘッダおよびＴＣＰヘッダに記述された情報、およびパケットの受信時刻等をパケットロス・遅延検出部７１２に送信する。
【００６３】
パケットロス・遅延検出部７１２は、通信状態記憶部７２１に格納されている情報およびパケット情報取得部７１１からの情報をもとに、パケットが遅延かロスかを判定する。また、パケットの総遅延時間やロス数、パケットの受信時刻や識別子などの各種情報を通信状態記憶部７２１、モニタ結果記憶部７２２、および連続開始ＩＤ記憶部７２３に書き込む。
【００６４】
モニタ結果出力部７１３は、モニタ結果記憶部７２２に格納されているモニタ結果テーブルの情報の一部もしくは全てを取得して、出力部７０３に送信する。例えば、特定のセッションIDの値やセッションIDの上位24bitなどでマスクするフィルタ条件に基づき、記憶されている統計情報を抽出し、出力部２０３に送信しても良い。
【００６５】
記憶部７２０は、通信状態記憶部７２１、モニタ結果記憶部７２２、および連続開始ＩＤ記憶部７２３を備える。
通信状態記憶部７２１は、図３に示すような通信状態テーブルを格納する。
通信状態テーブルは、第１の実施の形態と同様である。
【００６６】
モニタ結果記憶部７２２は、図８に示すようなモニタ結果テーブルを格納する。
モニタ結果テーブルは、項目として、送信元アドレス、ＴＣＰセッションＩＤ、パケット送信数、判断不能回数、および総遅延時間を有する。
【００６７】
送信元アドレス、ＴＣＰセッションＩＤ、パケット送信数、および総遅延時間に関しては、第１の実施の形態と同様である。
判断不能回数は、遅延であるかロスであるかの判断が出来なかった回数を示す。
【００６８】
連続開始ＩＤ記憶部７２３は、図９に示すような連続開始ＩＤテーブルを備える。連続開始ＩＤテーブルは、項目として、送信元アドレス、連続開始ＩＤ値、直前ＩＤ値、増加数を有する。
【００６９】
送信元アドレスは、送信ホストのＩＰアドレスである。
連続開始ＩＤ値は、ロス無くパケットを送信しているときの最初のパケットのＩＰヘッダの識別子（ＩＤ値）である。
【００７０】
直前ＩＤ値は、送信元ホストが前回送信したパケットのＩＰヘッダの識別子（ＩＤ値）である。
増加数は、パケットがロス無く連続しているとみなすことが出来る範囲である。
【００７１】
例えば、１行目のエントリを参照すると、送信元アドレスはα、連続開始ＩＤ値は１、直前ＩＤ値は３３５である。これにより、送信元アドレスがαの送信ホストは、識別子（ＩＤ値）が１のパケットから識別子（ＩＤ値）が３３５である直前のパケットまで、ロス無く連続して送信していることがわかる。
【００７２】
図９は、本発明の第２の実施の形態に係る識別方法のフローチャートである。
ステップＳ１００１において、入力部２０２はパケットを受信し、パケット情報取得部にパケットを送信する。
【００７３】
ステップＳ１００２において、パケット情報取得部７１１は、ＴＣＰヘッダまたはIPヘッダに記述されている、送信元アドレス(SA)、送信元ポート番号(SP)、宛先アドレス(DA)、および宛先ポート番号(DP)からＴＣＰのセッションＩＤを作成する。
【００７４】
また、パケット情報取得部７１１は、TCPヘッダのシーケンス番号（SEQ）およびIPヘッダの識別子（ＩＤ）を取得する。そして、セッションＩＤ、シーケンス番号、および識別子を1組としてパケットロス・遅延検出部７１２へ送信する。
【００７５】
ステップＳ１００３において、パケットロス・遅延検出部７１２は、通信状態テーブルを参照し、パケットロス・遅延検出部７１２が受信したセッションＩＤおよび送信元アドレスの組と同じセッションＩＤおよび送信元アドレスの組が通信状態テーブルにあるか判定する。
【００７６】
同じセッションＩＤおよび送信元アドレスの組がある場合ステップＳ１００４に進み、同じセッションＩＤおよび送信元アドレスの組がない場合ステップＳ１００６に進む。
ステップＳ１００４において、パケットロス・遅延検出部７１２は、送信元アドレスが連続開始ＩＤテーブルに存在するかチェックし、送信元アドレスが存在した場合はステップＳ１００５に進み、存在しない場合はステップＳ１００７に進む。
【００７７】
ステップＳ１００５において、CON_IDを連続開始ＩＤテーブルの該当エントリの連続開始ＩＤ値、L_IDを連続開始ＩＤテーブルの該当エントリの直前ＩＤ値、CUR_IDを現パケットのＩＰヘッダのＩＤ値とする。
【００７８】
ステップＳ１００６において、パケットロス・遅延検出部７１２は、パケット通信状態テーブルに新規エントリを作成する。
ステップＳ１００７において、パケットロス・遅延検出部７１２は、連続開始ＩＤテーブルに新規エントリを作成する。
【００７９】
ステップＳ１００８において、パケットロス・遅延検出部７１２は、連続開始ＩＤテーブルの該当エントリの連続開始ＩＤ値および直前ＩＤ値を現パケットのＩＰヘッダのID値とし、連続開始ＩＤテーブルに書き込む。
【００８０】
ステップＳ１００９において、パケットロス・遅延検出部７１２は、通信状態テーブルを参照し、通信状態テーブルから当該セッションＩＤの前回受信時刻、次回ＳＥＱ、および前回ＩＤ値を取得する。
【００８１】
パケットロス・遅延検出部７１２は、PRV_IDを前回ID値、PRV_Tを前回受信時刻、CUR_Tを現パケットの受信時刻、SEQを現パケットのシーケンス番号とする。
ステップＳ１０１０において、パケットロス・遅延検出部７１２は、次回ＳＥＱとＳＥＱを比較し、同じ場合はステップＳ１０１１に進み、異なる場合は遅延とロスの識別が出来ないのでステップＳ１０１７に進み、テーブルの更新処理を行う。
【００８２】
ステップＳ１０１１において、パケットロス・遅延検出部７１２は、現パケットのID値（CUR_ID）と直前ID値（L_ID）に定数Nを加算したものを比較する。CUR_IDがL_ID＋Ｎ以下である場合はステップＳ１０１２に進み、CUR_IDがL_ID＋Ｎより大きい場合はステップＳ１０１４に進む。ステップＳ１０１１では、CUR_IDがL_IDよりＮ以下しか増加していない場合は、ＩＤ値は連続しているとみなしている。
【００８３】
ステップＳ１０１２において、パケットロス・遅延検出部７１２は、該当エントリの連続開始ID値（CON_ID）と前パケットのID値（PRV_ID）を比較する。CON_IDがPRV_ID以下の場合は、遅延であると判定してステップＳ１０１３に進み、CON_IDがPRV_IDより大きい場合はステップＳ１０１５に進む。
【００８４】
ステップＳ１０１３において、受信時刻から前回受信時刻を減算した値をモニタ結果テーブルの総遅延時間に加算する。
ステップＳ１０１４において、連続開始ＩＤテーブルの該当エントリの連続開始ＩＤ値に現パケットのＩＤ値（CUR_ID）を書き込む。ステップＳ１０１４では、CUR_IDがL_ID+Nより大きいので、それ以前のＩＤ値は連続していないとみなし、連続開始ＩＤ値が現パケットのＩＤ値で更新される。
【００８５】
ステップＳ１０１５において、パケットロス・遅延検出部７１２は、ＩＤ値が連続していないので、遅延かロスか判断不能であると判断し、モニタ結果テーブルの判断不能回数に１加算する。
【００８６】
ステップＳ１０１６において、現パケットのシーケンス番号に現パケットのデータ長（ペイロードサイズ）を加算したものを次パケットに期待されるシーケンス番号（次回SEQ）として算出し、次回ＳＥＱを通信状態テーブルに書き込む。
【００８７】
ステップＳ１０１７において、通信状態テーブルの前回受信時刻に現パケットの受信時刻、前回ＩＤ値に現パケットのＩＤ値をそれぞれ書き込む。また、モニタ結果テーブルのパケット送信数に１加算する。また、連続開始ＩＤテーブルの該当エントリの直前ＩＤ値に現パケットのＩＤ値を書き込む。
【００８８】
次に第２の実施の形態の具体例について述べる。
以下の具体例において、通信状態記憶部７２１、モニタ結果記憶部７２２、および連続開始ＩＤ記憶部７２３には、それぞれ図３の通信状態テーブル、図８のモニタ結果テーブル、および図９の連続開始ＩＤテーブルが格納されているとする。
【００８９】
先ず、新たにパケットを受信する（ステップＳ１００１）。
パケット情報取得部７１１は、新たに受信したパケット（現パケット）のＴＣＰヘッダおよびＩＰヘッダからＴＣＰセッションＩＤを作成する（ステップＳ１００２）。パケット情報取得部７１１は、TCPヘッダのシーケンス番号（SEQ）およびIPヘッダの識別子（ＩＤ値）を取得する。そして、セッションＩＤ、シーケンス番号、および識別子を1組としてパケットロス・遅延検出部７１２へ送信する。また、パケットを受信した時刻（パケット受信時刻）をパケットロス・遅延検出部７１２へ送信する。
【００９０】
今回受信したパケットでは、送信元アドレス＝α、セッションID＝Ｂ、シーケンス番号（ＳＥＱ）=421、識別子（ID値）＝336が取得されたものとする。
通信状態テーブルをセッションID「Ｂ」と送信元アドレス「α」をキーに検索する（ステップＳ１００３）と、通信状態テーブルの２行目に該当エントリが存在する。
【００９１】
連続開始ＩＤテーブル送信元アドレス「α」をキーに検索する（ステップＳ１００４）と、連続開始テーブルの１行目に該当エントリが存在する。
CON_IDを連続開始ＩＤテーブルの該当エントリの連続開始ＩＤ値（１）、L_IDを連続開始ＩＤテーブルの該当エントリの直前ＩＤ値（３３５）、CUR_IDを現パケットのＩＰヘッダの識別子（ＩＤ値）（３３６）とする（ステップＳ１００５）。また、連続開始ＩＤテーブルから増加数Ｎとして１を取得する。
【００９２】
次回ＳＥＱとして421、前回ID値として211を取得する（ステップＳ１００９）。また、PRV_IDを前回ID値（２１１）、PRV_Tを前回受信時刻、CUR_Tを現パケットの受信時刻、SEQを現パケットのシーケンス番号（４２１）とする（ステップＳ１１０９）。
【００９３】
次回SＥＱとＳＥＱとを比較する（ステップＳ１０１０）と、共に４２１で同一である。
CON_ID（３３６）とL_ID（３３５）に増加数Ｎ（１）を加算したものを比較すると（ステップＳ１０１１）、CON_IDはL_ID+N以下である。
CON_ID（１）とPRV_ID（２１１）を比較すると（ステップＳ１０１２）、CON_IDはPRV_ID以下である。
【００９４】
以上から、現パケットのＩＤ値は連続しているとみなし、ロスによる再送は無く、パケットは単に遅延していると判断する。
以下、モニタ結果テーブル、通信状態テーブル、および連続開始ＩＤテーブルの更新を行う（ステップＳ１０１３、Ｓ１０１６、Ｓ１０１７）。
第２の実施形態のパケットキャプチャ装置によれば、送信元ホストが複数の送信先ホストと通信している場合でも、遅延を識別することが出来る。
【００９５】
（第３の実施の形態）
第３の実施の形態においては、送信元ホストがＬｉｎｕｘ（登録商標）などの特定のＯＳ（Operation System）の場合を説明する。
図１１は、本発明の第３の実施の形態のシステム構成図および概念図である。
【００９６】
本発明の第３の実施の形態のシステムは、パケットキャプチャ装置１１０１、送信ホスト１１０２、受信ホスト１１０３−ｎ（ｎ＝１〜３）、タップ１１０４を備える。
タップ１１０４は、送信ホスト１１０２と受信ホスト１１０３の間に配置される。
【００９７】
パケットキャプチャ装置１１０１はタップ１１０４と接続し、送信ホスト１１０２および受信ホスト１１０３はそれぞれネットワークを介してタップ１１０４と接続している。
送信ホスト１１０２が受信ホスト１１０３にパケットを送信すると、送信ホスト１０２と受信ホスト１１０３の間にあるタップ１１０４は該パケットをパケットキャプチャ装置１１０１に分岐させる。そして、パケットキャプチャ装置１１０１は、パケットを受信する。
尚、受信ホスト１１０３−１、１１０３−２、１１０３−３のＩＰアドレスはそれぞれＡ、Ｂ、Ｃとする。
【００９８】
図１１では、パケット１１１１、パケット１１１２、パケット１１１３、パケット１１１４の順で送信ホスト１１０２から送信されている。パケット１１１１、パケット１１１２、パケット１１１３、およびパケット１１１４は、それぞれ受信ホスト１１０３−１、受信ホスト１１０３−２、受信ホスト１１０３−３、および受信ホスト１１０３−１に送信されている。
【００９９】
また、Ｓｅｑはパケットのシーケンス番号であり、ＩＤは識別子である。
送信ホスト１１０１が例えばLinux（登録商標）等の特定のＯＳ（Operation System）を使用している場合は、ＩＰヘッダの識別子（ID値）はTCPコネクション毎にランダムな値から開始され、１パケット送信毎に１ずつ増加するが、送信ホストに共通する値ではない。
【０１００】
受信ホスト１１０３−１に送信されたパケット１１１１の識別子は１００であり、受信ホスト１１０３−２に送信されたパケット１１１２の識別子は５００であり、受信ホスト１１０３−３に送信されたパケット１１１３の識別子は１０００である。
【０１０１】
このように、ＴＣＰセッションごとに異なる識別子が初期値として与えられる。受信ホスト１１０３−１に送信されるパケット１１１４の識別子は１０１であり、同じＴＣＰセッションに対するパケット１１１１に対して識別子は連続している。
【０１０２】
この性質を利用すれば、同一のTCPセッションに属するパケットであれば、必ず識別子は１ずつ増加することが断定できるので、これをロスと遅延の識別に利用する。
識別子が同一のTCPセッションに属するパケットに対して必ず１ずつ増加すれば、第１の実施の形態の識別方法（図５のフローチャート）が利用できる。
それ以外の場合は、第２の実施の形態の識別方法（図９のフローチャート）を利用する。
【０１０３】
第３の実施の形態のパケットキャプチャ装置１１０１は、第１の実施の形態のパケットキャプチャ装置２０１および第２のパケットキャプチャ装置７０１の両方の機能を有し、適宜使い分けている。
どちらの識別方法を使用するかは、送信ホストのＯＳの種別により判断する。
【０１０４】
図１２は、本発明の第３の実施の形態のパケットキャプチャ装置の構成図である。
パケットキャプチャ装置１２０１は、入力部１２０２、出力部１２０３、処理部１２１０、および記憶部１２２０を備える。
【０１０５】
入力部１２０２は、パケットが入力されるインタフェースである。入力部２０２は、受信したパケットや情報を処理部に送信する。
処理部１２１０は、パケットのヘッダの情報の取得、取得した情報に基づく遅延の原因の識別、結果の送信などの処理を行う。
【０１０６】
出力部１２０３は、モニタ結果を出力するインタフェースであり、ネットワーク管理者に統計情報を表示するための画面であってもよく、ネットワーク管理装置(NMS)に送信するための通信プロトコルをサポートするネットワークインタフェースであってもよい良い。
処理部１２１０は、パケット情報取得部１２１１、パケットロス・遅延検出部１２１２、およびモニタ結果出力部１２１３を備える。
【０１０７】
パケット情報取得部１２１１は、IPヘッダおよびＴＣＰヘッダの情報からＴＣＰのセッションＩＤを作成する。また、作成したＴＣＰセッションＩＤ、シーケンス番号や識別子などのＩＰヘッダおよびＴＣＰヘッダに記述された情報、およびパケットの受信時刻等をパケットロス・遅延検出部１２１２に送信する。
【０１０８】
パケットロス・遅延検出部１２１２は、通信状態記憶部１２２１に格納されている情報およびパケット情報取得部１２１１からの情報をもとに、ＯＳ種別の識別やパケットが遅延かロスかを判定する。また、パケットの総遅延時間やロス数、パケットの受信時刻や識別子などの各種情報を通信状態記憶部１２２１、モニタ結果記憶部１２２２、連続開始ＩＤ記憶部１２２３、およびＯＳ種別記憶部１２２４に書き込む。
【０１０９】
モニタ結果出力部１２１３は、モニタ結果記憶部１２２２に格納されているモニタ結果テーブルの情報の一部もしくは全てを取得して、出力部１２０３に送信する。例えば、特定のセッションIDの値やセッションIDの上位24bitなどでマスクするフィルタ条件に基づき、記憶されている統計情報を抽出し、出力部１２０３に送信しても良い。
【０１１０】
記憶部１２２０は、通信状態記憶部１２２１、モニタ結果記憶部１２２２、連続開始ＩＤ記憶部１２２３、およびＯＳ種別記憶部１２２４を備える。
通信状態記憶部１２２１は、図３に示すような通信状態テーブルを備える。通信状態テーブルについては、第２の実施の形態と同様である。
【０１１１】
モニタ結果記憶部１２２２は、図１３に示すようなモニタ結果テーブルを備える。モニタ結果テーブルは、項目として、送信元アドレス、ＴＣＰセッションＩＤ、パケット送信数、ロス数、ロス率、総遅延時間、および判断不能回数を有する。
【０１１２】
送信元アドレス、ＴＣＰセッションＩＤ、パケット送信数、ロス数、ロス率、および総遅延時間に関しては、第１の実施の形態と同様である。また、判断不能回数に関しては、第２の実施の形態と同様である。
【０１１３】
連続開始ＩＤ記憶部１２２３は、図９に示すような連続開始ＩＤテーブルを備える。連続開始ＩＤテーブルについては、第２の実施の形態と同様である。
ＯＳ種別記憶部１２２４は、図１４に示すようなＯＳ種別テーブルを備える。
ＯＳ種別テーブルは、項目として、送信元アドレスとＯＳタイプを有する。送信元アドレスには、送信ホストのＩＰアドレスが格納される。ＯＳタイプには、送信ホストのＯＳの種類が格納される。
【０１１４】
ＯＳ種別テーブルには、送信元アドレスとＯＳタイプが対応するように格納されている。
ＯＳタイプＢは、ＴＣＰセッションごとに異なる識別子を与え、同一のTCPセッションに属するパケットに対して識別子を１ずつ増加させるＯＳであり、例えばLinuxが該当する。ＯＳタイプＡは、ＴＣＰセッションごとに異なる識別子を与えないＯＳである。
【０１１５】
図１５は、第３の実施の形態の識別方法のフローチャートである。
ステップＳ１５０１において、パケットを受信する。
ステップＳ１５０２において、受信したパケットがSYN/ACKパケットかどうか判定する。SYN/ACKパケットの場合はステップＳ１５０３に進み、SYN/ACKパケットでない場合はステップＳ１５０４に進む。
【０１１６】
SYN/ACKパケットとは、ＴＣＰコネクションの確立時に使用されるパケットである。
ＴＣＰコネクションの確立手順は、先ずクライアントが接続要求（SYNパケット）をサーバに送信する。サーバは、接続要求に対する応答（SYN/ACKパケット）をクライアントに送信する。クライアントは、SYN/ACKパケットに対して、ACKパケットをサーバに送信する。ＴＣＰコネクションは上記手順により確立される。
【０１１７】
SYN/ACKパケットかどうかは、ＴＣＰヘッダのSYNフラグおよびACKフラグが１であるかをチェックすることで行う。SYNフラグおよびACKフラグが１であれば、SYN/ACKパケットであると判断する。
【０１１８】
ステップＳ１５０３において、パケットのＩＰヘッダの識別子（ＩＤ値）が０であるか判定し、０である場合はステップＳ１５０７に進み、０でない場合はステップＳ１５０９に進む。ＴＣＰセッションごとに異なる識別子を与え、同一のTCPセッションに属するパケットに対して識別子を１ずつ増加させるＯＳでは、SYN/ACKパケットの識別子は、０である。したがって、ステップＳ１５０３では、SYN/ACKパケットの識別子により、ＯＳの種別を識別している。
【０１１９】
ステップＳ１５０４において、パケットのＩＰヘッダの送信元アドレスをキーとしてＯＳ種別テーブルを検索する。
ステップＳ１５０５において、ステップＳ１５０４での検索の結果、ＯＳ種別テーブルに該当するエントリがない場合はステップＳ１５０６に進み、該当するエントリがある場合はステップＳ１５１０に進む。
ステップＳ１５０６において、ＯＳ種別テーブルに新規エントリを作成する。
【０１２０】
ステップＳ１５０７において、ＯＳタイプをＢとし、ＯＳ種別テーブルに書き込む。
ステップＳ１５０８において、図５のステップＳ５０２に進む。パケットキャプチャ装置１２０１は、ステップＳ５０２以降の処理を行い、図５のＥＮＤに到達したら、ステップＳ１５０８に戻り、終了する。このとき、入力部１２０２、出力部１２０３、パケット情報取得部１２１１、パケットロス・遅延検出部１２１２、モニタ結果出力部１２１３、通信状態記憶部１２２１、およびモニタ結果記憶部１２２２は、それぞれ第１の実施の形態の入力部２０２、出力部２０３、パケット情報取得部２１１、パケットロス・遅延検出部２１２、モニタ結果出力部２１３、通信状態記憶部２２１、およびモニタ結果記憶部２２２に対応する。
【０１２１】
ステップＳ１５０９において、ＯＳタイプをＡとし、ＯＳ種別テーブルに書き込む。
ステップＳ１５１０において、ＯＳ種別テーブルを参照し、パケットの送信元ホストのＯＳのタイプを判定し、タイプがＡである場合はステップＳ１５１１に進み、Ａでない（Ｂである）場合はステップＳ１５０８に進む。
【０１２２】
ステップＳ１５１１において、図１０のステップＳ１００２に進む。パケットキャプチャ装置１２０１は、ステップＳ１００２以降の処理を行い、図５のＥＮＤに到達したら、ステップＳ１５０８に戻り、終了する。このとき、入力部１２０２、出力部１２０３、パケット情報取得部１２１１、パケットロス・遅延検出部１２１２、モニタ結果出力部１２１３、通信状態記憶部１２２１、モニタ結果記憶部１２２２、および連続開始ＩＤ記憶部１２２３は、それぞれ第２の実施の形態の入力部７０２、出力部７０３、パケット情報取得部７１１、パケットロス・遅延検出部７１２、モニタ結果出力部７１３、通信状態記憶部７２１、モニタ結果記憶部７２２、および連続開始ＩＤ記憶部７２３に対応する。
【０１２３】
第３の実施の形態のパケットキャプチャ装置によれば、ＯＳの種類を識別することで、送信ホストのＯＳに応じた識別方法を用いることが出来る。それにより正しく識別できる可能性が高くなる。
【０１２４】
以上、本発明を実施例により説明したが、本発明は上記実施例に限定されるものではなく、本発明の範囲内で種々の変形及び改良が可能であることは言うまでもない。
【符号の説明】
【０１２５】
１０１ パケットキャプチャ装置
１０２ 送信ホスト
１０３ 受信ホスト
１０４ タップ
２０１ パケットキャプチャ装置
２０２ 入力部
２０３ 出力部
２１０ 処理部
２１１ パケット情報取得部
２１２ パケットロス・遅延検出部
２１３ モニタ結果出力部
２２０ 記憶部
２２１ 通信状態記憶部
２２２ モニタ結果記憶部
７０１ パケットキャプチャ装置
７０２ 入力部
７０３ 出力部
７１０ 処理部
７１１ パケット情報取得部
７１２ パケットロス・遅延検出部
７１３ モニタ結果出力部
７２０ 記憶部
７２１ 通信状態記憶部
７２２ モニタ結果記憶部
７２３ 連続開始ＩＤ記憶部
１２０１ パケットキャプチャ装置
１２０２ 入力部
１２０３ 出力部
１２１０ 処理部
１２１１ パケット情報取得部
１２１２ パケットロス・遅延検出部
１２１３ モニタ結果出力部
１２２０ 記憶部
１２２１ 通信状態記憶部
１２２２ モニタ結果記憶部
１２２３ 連続開始ＩＤ記憶部
１２２４ ＯＳ種別記憶部
【特許請求の範囲】
【請求項１】
接続要求に応じて送信された応答パケットのヘッダ情報に含まれるＩＤ値が０であるか否かに応じて、該応答パケットを送信した送信ホストは、同一セッション内におけるパケットの送信毎に、パケットのヘッダ情報に含まれるＩＤ値を順にインクリメントするタイプのオペレーションシステムであるか否かのオペレーションシステムのタイプを判定する判定手段、
を備えたことを特徴とするオペレーティングシステムの判定が可能な装置。
【請求項２】
オペレーティングシステムの判定が可能な装置が実行するオペレーティングシステムの判定方法であって、
接続要求に応じて送信された応答パケットのヘッダ情報に含まれるＩＤ値が０であるか否かに応じて、該応答パケットを送信した送信ホストは、同一セッション内におけるパケットの送信毎に、パケットのヘッダ情報に含まれるＩＤ値を順にインクリメントするタイプのオペレーションシステムであるか否かのオペレーションシステムのタイプを判定するオペレーティングシステムの判定方法。
【請求項１】
接続要求に応じて送信された応答パケットのヘッダ情報に含まれるＩＤ値が０であるか否かに応じて、該応答パケットを送信した送信ホストは、同一セッション内におけるパケットの送信毎に、パケットのヘッダ情報に含まれるＩＤ値を順にインクリメントするタイプのオペレーションシステムであるか否かのオペレーションシステムのタイプを判定する判定手段、
を備えたことを特徴とするオペレーティングシステムの判定が可能な装置。
【請求項２】
オペレーティングシステムの判定が可能な装置が実行するオペレーティングシステムの判定方法であって、
接続要求に応じて送信された応答パケットのヘッダ情報に含まれるＩＤ値が０であるか否かに応じて、該応答パケットを送信した送信ホストは、同一セッション内におけるパケットの送信毎に、パケットのヘッダ情報に含まれるＩＤ値を順にインクリメントするタイプのオペレーションシステムであるか否かのオペレーションシステムのタイプを判定するオペレーティングシステムの判定方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【公開番号】特開２０１１−１５５７０６（Ｐ２０１１−１５５７０６Ａ）
【公開日】平成２３年８月１１日（２０１１．８．１１）
【国際特許分類】
【出願番号】特願２０１１−１０９６４７（Ｐ２０１１−１０９６４７）
【出願日】平成２３年５月１６日（２０１１．５．１６）
【分割の表示】特願２００８−２７７４７２（Ｐ２００８−２７７４７２）の分割
【原出願日】平成２０年１０月２８日（２００８．１０．２８）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成２３年８月１１日（２０１１．８．１１）
【国際特許分類】
【出願日】平成２３年５月１６日（２０１１．５．１６）
【分割の表示】特願２００８−２７７４７２（Ｐ２００８−２７７４７２）の分割
【原出願日】平成２０年１０月２８日（２００８．１０．２８）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]