JP6015509B2 - パケット解析プログラム、パケット解析方法、パケット解析装置、およびパケット解析システム - Google Patents

パケット解析プログラム、パケット解析方法、パケット解析装置、およびパケット解析システム Download PDF

Info

Publication number
JP6015509B2
JP6015509B2 JP2013057038A JP2013057038A JP6015509B2 JP 6015509 B2 JP6015509 B2 JP 6015509B2 JP 2013057038 A JP2013057038 A JP 2013057038A JP 2013057038 A JP2013057038 A JP 2013057038A JP 6015509 B2 JP6015509 B2 JP 6015509B2
Authority
JP
Japan
Prior art keywords
packet
data packet
data
captured
connection
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2013057038A
Other languages
English (en)
Other versions
JP2014183483A (ja
Inventor
飯塚　史之
史之 飯塚
祐士 野村
祐士 野村
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2013057038A priority Critical patent/JP6015509B2/ja
Priority to US14/147,060 priority patent/US9282017B2/en
Publication of JP2014183483A publication Critical patent/JP2014183483A/ja
Application granted granted Critical
Publication of JP6015509B2 publication Critical patent/JP6015509B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0823—Errors, e.g. transmission errors
    • H04L43/0847—Transmission error
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/04—Processing captured monitoring data, e.g. for logfile generation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0823—Errors, e.g. transmission errors
    • H04L43/0829—Packet loss
    • H04L43/0835—One way packet loss
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/12—Network monitoring probes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/16—Threshold monitoring

Description

本発明は、パケット解析に関する。
ネットワーク品質の監視のためや、監査証跡（audit trail）の記録のためなど、何らかの目的のために、パケットキャプチャ（packet capture）が行われることがある。例えば、２つ以上のネットワークポートと１つ以上のミラーポートを有するネットワーク装置（例えばスイッチやルータなど）が利用されてもよい。この場合、ネットワークポートから送信されるパケット、および／またはネットワークポートで受信されるパケットは、複製（copy）されてミラーポートから出力され、ミラーポートに接続された装置においてキャプチャされる。また、ポートミラーリングによってパケットを複製する代わりに、ネットワークタップを利用してパケットの信号を物理層で分岐する技法が、パケットをキャプチャするために使われてもよい。
キャプチャされたパケットは、目的に応じて適宜解析されてもよい。例えば、解析により、パケットロスの回数やパケット再送の回数などが検出されてもよい。また、パケットロスの回数やパケット再送の回数などに基づいて、ネットワーク品質が判定されてもよい。
例えば、あるパケット解析方法は、ネットワークを通過するパケットをモニタあるいはキャプチャした結果得られる通信内容を、解析する方法である。当該パケット解析方法は、再送手順を持つプロトコルのシーケンスを解析するにあたり、パケットロスの後に再送されたパケットなのか、ネットワーク内で順序反転が発生して到着順序が入れ替わったパケットなのかを、正確に識別することを目的とする。当該パケット解析方法は、具体的には、以下の工程を有する。
・ネットワーク層のパケットヘッダから、送信元あるいは宛先のアドレス情報を取得する工程。
・ネットワーク層のパケットヘッダから、送信元あるいは宛先のアドレス情報ごとに送信のたびに単調増加する値が設定される識別子を、取得する工程。
・送信元あるいは宛先のアドレス情報に対応させて前回のパケットの識別子を保持した記憶部から、今回のパケットのアドレス情報に対応する識別子を、検索して取得する工程。
・取得した前回のパケットの識別子と今回のパケットの識別子とを比較し、今回のパケットの識別子が小さい場合に「順序反転が発生している」と判断する工程。
特開２００９−１８２４３０号公報
発明者が研究したところ、ある種の条件下では以下のような誤判断が起こり得るということを突き止めた。誤判断は、パケット解析の精度を悪化させる要因である。
・キャプチャに失敗したパケットが実際には存在しないにもかかわらず、パケット解析の結果、「１つ以上のパケットのキャプチャが失敗した」と誤判断されてしまうことが起こり得る。
・実際にはネットワーク上でパケットが再送されていないにもかかわらず、キャプチャされたあるパケットが、パケット解析の結果、「再送されたパケットだ」と誤判断されてしまうことも起こり得る。
本発明は、１つの側面では、パケット解析における誤判断を減らすことで、パケット解析の精度を高めることを目的とする。
一態様によるパケット解析プログラムは、コンピュータに、以下のような処理を実行させる。
当該処理は、第１の通信プロトコルと第２の通信プロトコルにしたがって第１の装置と第２の装置の間で送受信される個々のパケットをキャプチャすることを含む。ここで、前記第１の通信プロトコルは、識別用の数値を各パケットに割り当てる通信プロトコルである。また、前記第２の通信プロトコルは、前記第１の通信プロトコルより上位の層で定義されるコネクション指向の通信プロトコルである。
前記第１の装置から送信された第１のデータパケットに対して前記第２の装置から送信された確認応答パケットがキャプチャされた時点では、前記第１のデータパケットがキャプチャされていない場合があり得る。以下では、前記第２の通信プロトコルによるコネクション上で前記第２の装置が前記第１の装置から次に受信すると期待するデータパケットの識別用に前記確認応答パケットが含む数値を、第１の数値ということにする。また、前記第１の装置から送信されて前記確認応答パケットの後にキャプチャされた第２のデータパケットが前記コネクション上での識別用に含む数値を、第２の数値ということにする。
さて、前記確認応答パケットがキャプチャされた時点では前記第１のデータパケットがキャプチャされておらず、かつ、前記第１の数値よりも前記第２の数値の方が前の順序を示す場合があり得る。前記処理は、当該場合に第３の数値と第４の数値との差に基づき、キャプチャされた前記第２のデータパケットが前記確認応答パケットより遅れてキャプチャされた前記第１のデータパケットなのか否かを判断することを含む。
前記第３の数値は、前記第１の通信プロトコルにより前記第２のデータパケットに割り当てられた数値である。また、前記第４の数値は、前記第１の装置から送信されて前記確認応答パケットより前にキャプチャされたデータパケットの中では最も遅くキャプチャされた前回データパケットに前記第１の通信プロトコルにより割り当てられた数値である。
パケット解析における誤判断が減るので、パケット解析の精度が高まる。
データパケットの再送と、キャプチャ過程でのデータパケットとＡＣＫパケットの順序逆転との判別について説明する図である。 キャプチャ過程でのパケット間の順序の逆転を例示する図である。 パケットの流れを例示する図である。 キャプチャの過程でパケット間の順序が逆転する例を示す図である。 比較例において順序の逆転に起因して起こり得る誤判断について説明する図である。 誤判断が防止される例を示す図である。 システム構成図である。 コンピュータのハードウェア構成図である。 コネクション管理テーブルの例を示す図である。 解析情報テーブルの例を示す図である。 ネットワーク監視装置が行う処理のフローチャート（その１）である。 ネットワーク監視装置が行う処理のフローチャート（その２）である。 ネットワーク監視装置が行う処理のフローチャート（その３）である。 ネットワーク監視装置が行う処理のフローチャート（その４）である。
以下、実施形態について、図面を参照しながら詳細に説明する。まず、実施形態の概要について図１を参照して説明する。次に、図２〜６を参照して、実施形態における、より具体的な動作シーケンスについて説明する。その後、装置の構成について図７〜８を参照して説明し、データの具体例について図９〜１０を参照して説明する。さらに、図１１〜１４のフローチャートを参照して、実施形態のネットワーク監視装置が行う処理について説明する。最後に、他の実施形態についても説明する。
図１は、データパケットの再送と、キャプチャ過程でのデータパケットと確認応答（acknowledgment）パケットの順序逆転との判別について説明する図である。図１には、動作例Ｅ１とＥ２が例示されている。動作例Ｅ１は、データパケットの再送が起きる例であり、動作例Ｅ２は、キャプチャ過程でデータパケットと確認応答パケットの順序逆転が起きる例である。
パケットには、ペイロードとして送信対象のデータを含むデータパケットと、データパケットに対する確認応答である確認応答パケットがある。以下では確認応答パケットを「ＡＣＫパケット」ともいう。また、詳しくは後述するように、「ある１つのパケットが、データパケットでもあり、かつ、別のデータパケットに対するＡＣＫパケットでもある」という場合もある。
動作例Ｅ１とＥ２の詳細について説明する前に、まず、パケットキャプチャの概要について説明する。
図１において、第１の装置１はコンピュータであり、第２の装置２もコンピュータである。コンピュータの種類は、スマートフォン、タブレット端末、ＰＣ（Personal Computer）、ワークステーション、サーバなど、任意である。
第１の装置１と第２の装置２の間では、第１の通信プロトコルと、第１の通信プロトコルよりも上位の層で定義される第２の通信プロトコルにしたがって、個々のパケットが送受信される。
なお、ここでは、第２の通信プロトコルのＰＤＵ（Protocol Data Unit）をペイロードとして含む第１の通信プロトコルのＰＤＵを、「パケット」と呼んでいる。以下の説明において、「パケット」という用語は、第１と第２の通信プロトコルを限定する趣旨のものではないし、第１と第２の通信プロトコルのレイヤを限定する趣旨のものでもない。
第１の通信プロトコルは、識別用の数値を各パケットに割り当てるが、コネクションレスな（connectionless）通信プロトコルである。より具体的には、識別用の数値は、複数のパケットの送信に応じて、シーケンシャルに変化する（換言すれば、単調増加または単調減少する）。第２の通信プロトコルは、具体的には、コネクション指向の（connection-oriented）通信プロトコルであり、再送手順を有する。ある観点によれば、第１の通信プロトコルはステートレスな（stateless）通信プロトコルであり、第２の通信プロトコルはステートフルな（stateful）通信プロトコルである。
以下では説明の便宜上、第２の通信プロトコルのＰＤＵの中にデータペイロードが含まれるパケットを、「データパケット」ということにする。あるデータパケットが何らかの理由により再送される場合、元のデータパケットのコネクション上の順序と、元のデータパケットを再送するための再送データパケットのコネクション上の順序は、同じである。
しかし、再送データパケットに対して第１の通信プロトコルにより識別用に割り当てられる数値は、元のデータパケットに対して第１の通信プロトコルにより識別用に割り当てられる数値とは異なる。なぜなら、第１の通信プロトコルは、コネクション指向の第２の通信プロトコルよりも下位の層で定義される、コネクションレスなプロトコルだからである。詳しくは後述するように、本実施形態では、「第１の通信プロトコルにより識別用に割り当てられる数値が、コネクション上の順序（すなわちコネクション上のデータストリームにおける順序）とは独立している」という性質が利用される。
例えば、第１の通信プロトコルは、ＩＰ（Internet Protocol）であってもよく、より具体的には、ＩＰバージョン４であってもよい。ＩＰバージョン４のヘッダには、各パケットを識別するための数値であるＩＤ（identification）が含まれる。
また、第２の通信プロトコルは、例えば、ＴＣＰ（Transmission Control Protocol）であってもよい。つまり、第１の装置１と第２の装置２の間で送受信される各パケットは、ＴＣＰセグメントをペイロードとして含むＩＰパケットであってもよい。
あるデータパケットが再送される場合、ＴＣＰコネクション上の順序（つまり、ＴＣＰコネクション上のデータストリームにおける順序）は、元のデータパケットと再送データパケットで同じである。しかし、元のデータパケットのＩＰヘッダ中のＩＤは、再送データパケットのＩＰヘッダ中のＩＤとは異なる。
さて、パケット解析装置３は、第１の装置１と第２の装置２の間で送受信される個々のパケットをキャプチャする。具体的には、パケット解析装置３は、第１の装置１と第２の装置２の間の通信路の途中に設けられる。第１の装置１から第２の装置２に向けて送信されたパケットは、通信路上の通過点４で取り出され、パケット解析装置３にキャプチャされる。第２の装置２から第１の装置１に向けて送信されたパケットは、通信路上の通過点５で取り出され、パケット解析装置３にキャプチャされる。
例えば、通過点４と５は、２つ以上のネットワークポートと１つ以上のミラーポートを有する１台のネットワーク装置（例えばスイッチやルータなど）における、ある２つのネットワークポートであってもよい。
この場合、第１の装置１から送信されたパケットは、通過点４に相当するネットワークポートで受信され、当該ネットワークポートからミラーポートに複製され、ミラーポートからパケット解析装置３に出力され、パケット解析装置３においてキャプチャされる。また、第１の装置１から送信されたパケットは、通過点４に相当するネットワークポートで受信された後、通過点５に相当するネットワークポートからも出力され、第２の装置２に向けて送信される。
同様に、第２の装置２から送信されたパケットは、通過点５に相当するネットワークポートで受信され、当該ネットワークポートからミラーポートに複製され、ミラーポートからパケット解析装置３に出力され、パケット解析装置３においてキャプチャされる。また、第２の装置２から送信されたパケットは、通過点５に相当するネットワークポートで受信された後、通過点４に相当するネットワークポートからも出力され、第１の装置１に向けて送信される。
なお、ネットワーク装置は、第１の装置１から受信したパケットと第２の装置２から受信したパケットの双方を、１つのミラーポートに複製してもよい。換言すれば、ネットワーク装置は、複数のネットワークポートで受信した複数のトラフィックを、１つのミラーポートに集約（aggregate）してもよい。この場合、パケット解析装置３は、当該１つのミラーポートと接続される。
あるいは、ネットワーク装置は、第１の装置１から受信したパケットを第１のミラーポートに複製し、第２の装置２から受信したパケットを第２のミラーポートに複製してもよい。この場合、パケット解析装置３は、第１と第２のミラーポートの双方と接続される。つまり、この場合、パケット解析装置３は、少なくとも２つの通信インタフェイスを有し、２つの通信インタフェイスを介して受信したパケットを記憶するための共通のバッファを有する。
別の例として、パケットのミラーリングを行うスイッチやルータなどの装置の代わりに、ネットワークタップが使われてもよい。ネットワークタップは、パケットの信号（具体的には電気信号または光信号）を物理層で分岐させる（split）。ネットワークタップも、ネットワーク装置の１種である。
例えば、通過点４と５は、２台のネットワークタップそれぞれの入力ポートであってもよい。そして、パケット解析装置３は、２つの通信インタフェイスを介して、それら２台のネットワークタップそれぞれのモニタポートと接続されていてもよい。この場合、パケット解析装置３は、２つの通信インタフェイスを介して受信したパケットを記憶するためのバッファを有する。
より具体的には、この場合、第１の装置１から送信されたパケットが、通過点４に相当する入力ポートで受信されると、パケットの信号は、物理層で電気的または光学的に分岐させられる。その結果、分岐した一方の信号は、ネットワークタップを通過して第２の装置２へと送信され、分岐した他方の信号は、ネットワークタップのモニタポートからパケット解析装置３に出力される。よって、パケット解析装置３は、第１の装置１から第２の装置２へ向けて送信されたパケットを、ネットワークタップを介してキャプチャすることができる。
同様に、第２の装置２から送信されたパケットが、通過点５に相当する入力ポートで受信されると、パケットの信号が分岐させられる。その結果、分岐した一方の信号は、ネットワークタップを通過して第１の装置１へと送信され、分岐した他方の信号は、ネットワークタップのモニタポートからパケット解析装置３に出力される。よって、パケット解析装置３は、第２の装置２から第１の装置１へ向けて送信されたパケットを、ネットワークタップを介してキャプチャすることができる。
また、ネットワークタップには様々な種類のものがある。例えば、通過点４と５は、複数の入力ポートと複数のモニタポートを有する１台のネットワークタップの２つの入力ポートであってもよい。この場合、パケット解析装置３は、少なくとも２つの通信インタフェイスを有し、２つの通信インタフェイスは、上記２つの入力ポートに対応する２つのモニタポートと接続される。また、パケット解析装置３は、２つの通信インタフェイスを介して受信したパケットを記憶するためのバッファを有する。
この場合、第１の装置１から送信されたパケットが、通過点４に相当する第１の入力ポートで受信されると、パケットの信号が分岐させられる。その結果、一方の信号は、ネットワークタップを通過して第２の装置２へと送信され、他方の信号は、第１の入力ポートに対応する第１のモニタポートから、パケット解析装置３に出力される。よって、パケット解析装置３は、第１の装置１から第２の装置２へ向けて送信されたパケットを、ネットワークタップの第１のモニタポートを介してキャプチャすることができる。
同様に、第２の装置２から送信されたパケットが、通過点５に相当する第２の入力ポートで受信されると、パケットの信号が分岐させられる。その結果、一方の信号は、ネットワークタップを通過して第１の装置１へと送信され、他方の信号は、第２の入力ポートに対応する第２のモニタポートからパケット解析装置３に出力される。よって、パケット解析装置３は、第２の装置２から第１の装置１へ向けて送信されたパケットを、ネットワークタップの第２のモニタポートを介してキャプチャすることができる。
あるいは、複数の入力ポートで受信した複数のトラフィックを１つのモニタポートに集約するタイプのネットワークタップが使われてもよい。この場合、パケット解析装置３は、上記１つのモニタポートに接続される。
この場合、第１の装置１から送信されたパケットが、通過点４に相当する第１の入力ポートで受信されると、パケットの信号が分岐させられる。その結果、一方の信号は、ネットワークタップを通過して第２の装置２へと送信され、他方の信号は、上記１つのモニタポートからパケット解析装置３に出力される。よって、パケット解析装置３は、第１の装置１から第２の装置２へ向けて送信されたパケットを、ネットワークタップを介してキャプチャすることができる。
同様に、第２の装置２から送信されたパケットが、通過点５に相当する第２の入力ポートで受信されると、ケットの信号が分岐させられる。その結果、一方の信号は、ネットワークタップを通過して第１の装置１へと送信され、他方の信号は、上記１つのモニタポートからパケット解析装置３に出力される。よって、パケット解析装置３は、第２の装置２から第１の装置１へ向けて送信されたパケットを、ネットワークタップを介してキャプチャすることができる。
上記のように、パケット解析装置３が具体的にどのようにしてパケットをキャプチャするかは、実施形態に応じて様々であってよい。いずれにせよ、パケット解析装置３は、第１の装置１と第２の装置２の間で送受信される個々のパケットを通信路上でキャプチャすることができる。
パケット解析装置３は、キャプチャしたパケットを適宜の目的に応じて解析する。例えば、第１の装置１と第２の装置２の間のネットワークの品質を監視するために、パケット解析装置３はパケットをキャプチャおよび解析してもよい。つまり、パケット解析装置３は、具体的にはネットワーク監視装置であってもよい。例えば、パケット解析装置３は、以下のような種々の回数を推定してもよい。
・第１の装置１と第２の装置２の間のネットワーク上でパケットが消失した回数（以下「ネットワークロス数」ともいう）。
・第１の装置１または第２の装置２からパケットが再送された回数（以下「再送回数」ともいう）。
・第１の装置１から第２の装置２へ、または第２の装置２から第１の装置１へ、パケットが成功裡に送信されたにもかかわらず、パケット解析装置３がパケットのキャプチャに失敗した回数（以下「キャプチャロス数」ともいう）。
しかしながら、発明者が研究したところ、「ある種の条件下では以下のような誤判断（misjudgment）が起こり得る」ということを突き止めた。
・キャプチャに失敗したパケットが実際には存在しないにもかかわらず、パケット解析の結果、「１つ以上のパケットのキャプチャが失敗した」と誤判断され得る。つまり、キャプチャロス数が過大に推定され得る。
・実際にはネットワーク上でパケットが再送されていないにもかかわらず、キャプチャされたあるパケットが、パケット解析の結果、「再送されたパケットだ」と誤判断され得る。つまり、再送回数が過大に推定され得る。また、場合によっては、再送の原因としてパケットの消失が想定されるため、ネットワークロス数も過大に推定され得る。
具体的には、ネットワーク管理者が経験的に予想するネットワークロス数および／または再送回数よりも多めにネットワークロス数および／または再送回数が検出される場合について、発明者は鋭意研究した。その結果、発明者は、上記のような誤判断が起こり得ることを突き止めた。
また、発明者は、上記のような誤判断が起こり得る条件についても検討した。その結果、発明者は、以下のような知見を得た。
・少なくとも以下の第１の条件が成り立つ（hold true）場合に、上記のような誤判断が起こり得る。
・さらに第２〜第５の条件のうち１つ以上が成り立つ場合に、上記のような誤判断がより起こりやすくなる。
・環境によっては、第１〜第５の条件がすべて成り立つ場合もあり、そのような場合には特に、上記のような誤判断が起こりやすい。
さて、第１の条件は、「２台の装置間の通信路上を、互いに逆向きの２つの方向に流れるパケットが、キャプチャ過程で１つのストリームに集約される」という条件である。より具体的には、第１の条件は、「２つの方向の間での順序関係が保存されることが保証されないやり方で、２つの方向に流れるパケットが、キャプチャ過程で１つのストリームに集約される」という条件である。例えば、以下のような場合はいずれも、この第１の条件が成り立つ。
・スイッチやルータなどのネットワーク装置の複数のネットワークポートで受信されたパケットが、１つのミラーポートに複製（つまりミラーリング）される場合。より具体的には、ネットワークポート間での受信順序は考慮されない（つまり、ミラーポートへの出力順序に関して、ネットワークポート間で受信順序に基づく調停は行われない）場合。
・ネットワークタップの複数の入力ポートで受信されたパケットが、１つのモニタポートに集約されて出力される場合。より具体的には、入力ポート間での受信順序は考慮されない（つまり、モニタポートへの出力順序に関して、入力ポート間で受信順序に基づく調停は行われない）場合。
・スイッチやルータなどのネットワーク装置が有する複数のミラーポート、または、ネットワークタップが有する複数のモニタポートからの出力が、１つの共通のバッファにキューイングされ（enqueued）、バッファからパケットが順にキャプチャされる場合。より具体的には、バッファへのパケットのキューイングの順序に関する複数のポート間での調停が行われない場合。
第２の条件は、スイッチやルータなどのネットワーク装置の処理能力が低い、という条件である。第２の条件は、ネットワークタップによる信号の分岐ではなく、ポートミラーリングが使われる場合に関連する条件である。
受動的な装置であるネットワークタップとは異なり、ポートミラーリング機能を有するネットワーク装置では、能動素子が使われる。つまり、ポートミラーリング機能を有するネットワーク装置では、汎用的なプロセッサまたはＡＳＩＣ（Application-Specific Integrated Circuit）などの回路が、物理層より上位の層でパケットを複製する処理を実行する。第２の条件は、より具体的には、「複製処理を行う回路の処理能力が低い」という条件である。
なお、ネットワーク装置の処理能力（より具体的には複製処理を行う回路の能力）が低いほど、ネットワークポートで受信されたパケットをミラーポートに複製するのにかかる時間も長い。つまり、第２の条件は、別の観点から換言すれば、パケットの複製にかかる時間が長い、という条件である。
第３の条件は、第１の装置１と第２の装置２の間のＲＴＴ（Round-Trip Time）が短い、という条件である。第３の条件は、別の観点から換言すれば、データパケットが送信されてからＡＣＫパケットが送信されるまでの時間が短い、という条件である。第３の条件が成り立つ場合、先に送信されたデータパケットが通過点４を通過してから、ＡＣＫパケットが通過点５を通過するまでの時間が短い。よって、データパケットとＡＣＫパケットがほぼ同時にキャプチャされる蓋然性も高く、そのため、キャプチャ過程での順序逆転も生じやすい。
第４の条件は、第１の装置１と第２の装置２の間で単位時間あたりに送受信されるデータパケットの数が多い、という条件である。より詳しくは、第４の条件は、第１の装置１から第２の装置２へ単位時間あたりに送受信されるデータパケットの数が多いか、または、第２の装置２から第１の装置１へ単位時間あたりに送受信されるデータパケットの数が多い、という条件である。
第５の条件は、個々のデータパケットのサイズが大きい、という条件である。例えば、大量のデータがバースト的に送信される場合には、第４の条件と第５の条件がともに成り立つことが多い。
なお、第２〜第５の条件に関しては、上記のとおり「処理能力が低い」・「時間が長い」・「ＲＴＴが短い」・「データパケットの数が多い」・「サイズが大きい」といった相対的な表現を用いて説明した。このように相対的な表現を用いた理由は２つある。
１つ目の理由は、第２〜第５の条件は、誤判断の起きやすさに影響する変数についての条件だからである。例えば、第２の条件を例にとって説明すると、ネットワーク装置の処理能力が低いほど、上記の誤判断が起きやすい。よって、誤判断が起きる確率についての許容範囲に応じて、望ましい処理能力も異なる。
２つ目の理由は、第２〜第５の条件が互いに関連しているからである。例えば、ＲＴＴとデータパケットのサイズが一定だとして、誤判断が起きる確率を許容範囲内に抑えるためには、単位時間あたりに送受信されるデータパケットの数に応じて、ネットワーク装置の望ましい処理能力も異なる。また、ＲＴＴの長さと複製処理にかかる時間の長さの組み合わせに応じて、誤判断が起きる確率も異なる。もちろん、これ以外の組み合わせでも、第２〜第５の条件は互いに関連している。
いずれにせよ、第１の条件が成り立つ場合には上記の誤判断が生じる可能性がある。そして、誤判断が生じる蓋然性は、第１の条件に加えて第２〜第５の条件がさらに成り立つ場合に高まる。本実施形態のパケット解析装置３は、１つの側面では、上記のごとき誤判断を減らすことでパケット解析の精度を高めることを目的とする。
具体的には、本実施形態のパケット解析装置３は、図１の動作例Ｅ１に示すような再送と、図１の動作例Ｅ２に示すような順序逆転を判別することで、上記のような誤判断を減らす。以下、動作例Ｅ１とＥ２について説明し、その後、パケット解析装置３がいかにして誤判断を避けるかについて説明する。
動作例Ｅ１では、データパケットＤ１が再送される。説明の便宜上、再送されたデータパケットＤ１を図１では「再送パケットＲ１」と示している。
動作例Ｅ１において、データパケットＤ１に先立つデータパケットＤ０は、ステップＳ１１で第１の装置１から送信され、ステップＳ１２において通過点４で複製されるかまたは分岐させられる。よって、データパケットＤ０は、ステップＳ１３に示すように通過点５を通って第２の装置２に到達する一方で、時刻Ｔ１にパケット解析装置３によりキャプチャされる。
第２の装置２は、データパケットＤ０の受信に応じて、データパケットＤ０の受信を通知するためのＡＣＫパケットを送信してもよい。しかし、第２の装置２は、ＡＣＫパケットによる通信オーバヘッドを減らすために、ＡＣＫパケットの送信を遅延させてもよい。
例えば、第１の装置１と第２の装置２の間では、上記のとおり、第１の通信プロトコルとしてＩＰが利用されてもよく、第２の通信プロトコルとしてＴＣＰが利用されてもよい。多くのＴＣＰの実装では、遅延確認応答（delayed acknowledgement）と呼ばれる仕組みが実装されている。第２の装置２は、ＴＣＰの遅延確認応答の仕組みにしたがい、以下のいずれかの条件が成立するまで、データパケットＤ０に対するＡＣＫパケットの送信を遅延させてもよい。
・第２の装置２が第１の装置１からデータパケットＤ０の次のデータパケットを受信する。
・第２の装置２から第１の装置１に送信する新たなデータパケットが発生する。
・所定の時間（例えば２００ミリ秒）が経過する。
図１の動作例Ｅ１では、データパケットＤ０の受信から所定の時間が経過するよりも前に、第２の装置２がデータパケットＤ１を受信するものとする。
具体的には、データパケットＤ１は、ステップＳ２１において第１の装置１から送信され、ステップＳ２２において通過点４で複製されるかまたは分岐させられる。データパケットＤ１は、通過点４から第２の装置２へ向けて送信され、ステップＳ２３に示すように通過点５を通って、第２の装置２に到達する。このように、データパケットＤ１は、データパケットＤ０と同様に、成功裡に第２の装置２において受信される。
しかし、動作例Ｅ１では、パケット解析装置３は、データパケットＤ０のキャプチャには成功するが、データパケットＤ１のキャプチャには失敗してしまう。
例えば、ポートミラーリングにより通過点４でデータパケットＤ１が複製される場合、ミラーポート用に設けられたバッファがオーバフローする可能性がある。バッファオーバフローの結果として、データパケットＤ１がパケット解析装置３に到達しない可能性がある。
別の可能性として、複製されるかまたは分岐させられたデータパケットＤ１が、パケット解析装置３に成功裡に到達したにもかかわらず、パケット解析装置３においてデータパケットＤ１が消失してしまう（lost）可能性もある。例えば、パケット解析装置３の通信インタフェイスが備える受信バッファが、オーバフローする可能性もある。あるいは、パケット解析装置３は、上記のとおり、２つ以上の通信インタフェイスを介して受信したデータパケットをキューイングするための１つのバッファを有していてもよいが、当該バッファがオーバフローする可能性もある。
いずれにしろ、動作例Ｅ１では、何らかの理由によりデータパケットＤ１のキャプチャロスが生じる。他方、第２の装置２は、上記のとおりデータパケットＤ１を成功裡に受信している。したがって、第２の装置２は、ステップＳ３１でＡＣＫパケットＡ１を送信する。ＡＣＫパケットＡ１は、第２の装置２がデータパケットＤ１を受信したことを示す。動作例Ｅ１の例では、ＡＣＫパケットＡ１は、第２の装置２がデータパケットＤ０を受信したことも示している。
もちろん、第２の装置２は、データパケットＤ０の受信に応じて不図示のＡＣＫパケットを送信し、データパケットＤ１の受信に応じてＡＣＫパケットＡ１を送信してもよい。以下の議論は、第２の装置２がデータパケットＤ０とＤ１それぞれに対してＡＣＫパケットを送信する場合にも、第２の装置２が遅延確認応答の仕組みにより、データパケットＤ１の受信まで待ってから１つのＡＣＫパケットＡ１を送信する場合にも、共通である。
第２の装置２から送信されたＡＣＫパケットＡ１は、ステップＳ３２において通過点５で複製されるかまたは分岐させられる。よって、ＡＣＫパケットＡ１は、ステップＳ３３に示すように通過点４を通って第１の装置１に到達する一方で、時刻Ｔ２にパケット解析装置３によりキャプチャされる。
ところで、上記のとおり第２の通信プロトコル（例えばＴＣＰ）は、コネクション指向のプロトコルであり、再送手順を有する。動作例Ｅ１では、第１の装置１は、ＡＣＫパケットＡ１を受信するよりも前にタイムアウトしてしまうものとする。なお、動作例Ｅ１ではＡＣＫパケットＡ１が第１の装置１に成功裡に到達しているが、ＡＣＫパケットＡ１が通過点４と第１の装置１の間の通信路上で消失してしまう場合も、同様に、第１の装置１がタイムアウトする。
ＡＣＫパケットＡ１の受信前にタイムアウトすると、第１の装置１は、ステップＳ４１に示すように再送パケットＲ１を送信する。上記のとおり、再送パケットＲ１は、データパケットＤ１の再送用のデータパケットである。
再送パケットＲ１は、ステップＳ４２において通過点４で複製されるかまたは分岐させられる。よって、再送パケットＲ１は、ステップＳ４３に示すように通過点５を通って第２の装置２に到達する一方で、時刻Ｔ３にパケット解析装置３によりキャプチャされる。
なお、図１では、ＡＣＫパケットＡ１が再送パケットＲ１より先に通過点４を通過している。しかし、再送パケットＲ１がＡＣＫパケットＡ１より先に通過点４を通過する場合もあり得る。ＡＣＫパケットＡ１と再送パケットＲ１のどちらが先に通過点４を通過するかは、パケット解析装置３にとっては無関係である。また、ステップＳ４１での再送パケットＲ１の送信は、タイムアウト以外の理由によるものであってもよい。
以上のように、動作例Ｅ１では、データパケットＤ１のキャプチャロスと再送が生じる。そして、動作例Ｅ１においては、パケット解析装置３は、以下の順に３つのパケットをキャプチャする。
・時刻Ｔ１にデータパケットＤ０をキャプチャする。
・次に、時刻Ｔ２にＡＣＫパケットＡ１（すなわち、パケット解析装置３がまだキャプチャしていないデータパケットに対するＡＣＫパケット）をキャプチャする。
・その次に、時刻Ｔ３に再送パケットＲ１をキャプチャする。
他方、動作例Ｅ２では、再送が生じない。代わりに、動作例Ｅ２では、データパケットＤ１がＡＣＫパケットＡ１より先に送信されるにもかかわらず、ＡＣＫパケットＡ１の方がデータパケットＤ１より先にパケット解析装置３にキャプチャされるという、順序の逆転が生じる。具体的には以下のとおりである。
動作例Ｅ２において、データパケットＤ１に先立つデータパケットＤ０は、ステップＳ５１で第１の装置１から送信され、ステップＳ５２において通過点４で複製されるかまたは分岐させられる。よって、データパケットＤ０は、ステップＳ５３に示すように通過点５を通って第２の装置２に到達する一方で、時刻Ｔ４にパケット解析装置３にキャプチャされる。
第２の装置２は、データパケットＤ０の受信に応じてＡＣＫパケットを送信してもよい。しかし、動作例Ｅ１と同様に、第２の装置２は動作例Ｅ２でもＡＣＫパケットの送信を遅延させるものとする。以下の議論は、第２の装置２がデータパケットＤ０とＤ１それぞれに対してＡＣＫパケットを送信する場合にも、第２の装置２が遅延確認応答の仕組みにより、データパケットＤ１の受信まで待ってから１つのＡＣＫパケットＡ１を送信する場合にも、共通である。
また、データパケットＤ１は、ステップＳ６１において第１の装置１から送信され、ステップＳ６２において通過点４で複製されるかまたは分岐させられる。データパケットＤ１は、通過点４から第２の装置２へ向けて送信され、ステップＳ６３に示すように通過点５を通って、第２の装置２に到達する。このように、データパケットＤ１は、データパケットＤ０と同様に、成功裡に第２の装置２において受信される。
一方、動作例Ｅ２では、動作例Ｅ１とは異なりキャプチャロスは生じず、パケット解析装置３は、データパケットＤ１のキャプチャにも成功するものとする。しかし、何らかの理由により、データパケットＤ１が通過点４を通過してからパケット解析装置３にキャプチャされるまでに比較的長い時間がかかってしまう場合がある。その結果、パケット解析装置３は、データパケットＤ１をキャプチャする前に、データパケットＤ１に対するＡＣＫパケットＡ１をキャプチャしてしまう可能性がある。具体的には、以下のとおりである。
第２の装置２は、データパケットＤ１の受信に応じて、ステップＳ７１でＡＣＫパケットＡ１を送信し、ＡＣＫパケットＡ１は、ステップＳ７２において通過点５で複製されるかまたは分岐させられる。よって、ＡＣＫパケットＡ１は、ステップＳ７３に示すように通過点４を通って第１の装置１に到達する一方で、時刻Ｔ５にはパケット解析装置３によりキャプチャされる。そして、時刻Ｔ５よりも後の時刻Ｔ６になってからやっと、パケット解析装置３はデータパケットＤ１をキャプチャする。
以上のように、動作例Ｅ２では、データパケットＤ１とＡＣＫパケットＡ１の間で、送信順序とキャプチャ順序の逆転が生じる。つまり、先に送信されたデータパケットＤ１がＡＣＫパケットＡ１より遅くキャプチャされ、後から送信されたＡＣＫパケットＡ１がデータパケットＤ１より早くキャプチャされる。このような逆転が生じる場合、パケット解析装置３は、以下の順に３つのパケットをキャプチャする。
・時刻Ｔ４にデータパケットＤ０をキャプチャする。
・次に、時刻Ｔ５にＡＣＫパケットＡ１（すなわち、パケット解析装置３がまだキャプチャしていないデータパケットに対するＡＣＫパケット）をキャプチャする。
・その次に、時刻Ｔ６にデータパケットＤ１をキャプチャする。
ここで、パケット解析装置３に着目して動作例Ｅ１とＥ２を比較すると、動作例Ｅ１とＥ２は以下の２点で共通である。
第１の共通点は、パケット解析装置３が、パケット解析装置３自身はまだキャプチャしていないデータパケットに対するＡＣＫパケットをキャプチャする、という点である。具体的には、動作例Ｅ１では、パケット解析装置３は時刻Ｔ２でＡＣＫパケットＡ１をキャプチャし、動作例Ｅ２では、パケット解析装置３は時刻Ｔ５でＡＣＫパケットＡ１をキャプチャする。
第２の共通点は、第２の装置２がＡＣＫパケットＡ１の送信後、次に第１の装置１から受信することを期待しているデータパケットに先行するデータパケットを、パケット解析装置３は、ＡＣＫパケットＡ１のキャプチャ後にキャプチャする、という点である。つまり、第２の装置２にとってはＡＣＫパケットＡ１の送信前に受信済みのデータパケットを、パケット解析装置３は、ＡＣＫパケットＡ１をキャプチャしたよりも後になってからキャプチャする。具体的には、動作例Ｅ１では、パケット解析装置３は時刻Ｔ３で再送パケットＲ１をキャプチャし、動作例Ｅ２では、パケット解析装置３は時刻Ｔ６にデータパケットＤ１をキャプチャする。
なお、上記の「第２の装置２がＡＣＫパケットＡ１の送信後、次に第１の装置１から受信することを期待しているデータパケット」は、パケット解析装置３がキャプチャしたＡＣＫパケットＡ１に含まれる情報により指し示される。
ここで、動作例Ｅ１とＥ２のいずれにおいても、第２の装置２は、ＡＣＫパケットＡ１を送信するより前に既にデータパケットＤ１を受信していることに注意されたい。このことに注意すると、第２の装置２が第１の装置１から次に受信することを期待するデータパケットは、コネクション上の順序がデータパケットＤ１より後のデータパケットである。つまり、データパケットＤ１自体や、データパケットＤ１の再送用のパケットである再送パケットＲ１は、第２の装置２が第１の装置１から次に受信することを期待するデータパケットに対して、コネクション上の順序において先行するデータパケットである。
このように、パケット解析装置３が、まだキャプチャしていないデータパケットに対するＡＣＫパケットをキャプチャした後に、データパケットを受信する場合、後から受信したデータパケットが再送パケットである可能性がある。つまり、パケット解析装置３がＡＣＫパケットの後から受信したデータパケットが、第２の装置２が第１の装置１から次に受信することを期待するデータパケットに先行するデータパケットの場合、動作例Ｅ１のように、キャプチャロスと再送が生じた可能性がある。
しかし、動作例Ｅ２から分かるように、必ずしもいつもキャプチャロスと再送が生じているとは限らない。データパケットとＡＣＫパケットの間で、キャプチャ過程において順序逆転が生じている場合もあり得る。
よって、パケット解析装置３は、動作例Ｅ１のようにキャプチャロスと再送が生じた場合と、動作例Ｅ２のように順序逆転が生じた場合を正確に判別することが望ましい。正確な判別により誤判断が減る。そして、誤判断が減ると、例えば再送率やネットワークロス率などの、ネットワーク品質に関する指標の推定値の精度も向上する。
ところで、動作例Ｅ２のような順序逆転は、上記の第１の条件が成立する場合に起こり得る。また、第１の条件に加えて、第２〜第５の条件のうちの１つ以上がさらに成立する場合に、動作例Ｅ２のような順序逆転が特によく起こり得る。
例えば、第１の装置１と第２の装置２の間のＲＴＴが短いと、通過点４に相当するネットワークポートからミラーポートへのデータパケットＤ１の複製が完了する前に、データパケットＤ１が第２の装置２に到着する可能性がある。さらに、ＡＣＫパケットＡ１が第２の装置２から送信され、通過点５に相当するネットワークポートからミラーポートへ複製されてもまだ、データパケットＤ１の複製が完了していない可能性もある。
例えば、第１の装置１と第２の装置２以外の不図示の第３の装置がさらに存在してもよく、第１の装置１と第３の装置との間のトラフィックも通過点４を通ってもよい。第１の装置１から第３の装置へのトラフィックが非常に多い場合、通過点４に相当するネットワークポートからミラーポートへ複製する対象のパケットが大量にバッファに溜る可能性がある。その結果、通過点４に相当するネットワークポートからミラーポートへの複製には、比較的長い時間がかかる可能性がある。他方、通過点５に相当するネットワークポートからミラーポートへの複製は、短時間で済んでしまうかもしれない。その結果、動作例Ｅ２のように、ＡＣＫパケットＡ１がデータパケットＤ１より先にパケット解析装置３にキャプチャされる可能性がある。
例えば、サイズの大きなデータパケットが、単位時間あたりに多数、第１の装置１から第２の装置２へと送信される場合も、上記例示の場合と同様、通過点４に相当するネットワークポートからミラーポートへのデータパケットの複製を行う回路の処理負荷は重い。よって、この場合、通過点４に相当するネットワークポートからミラーポートへのデータパケットの複製は遅延しがちである。また、複製処理を行う回路の処理能力が低い場合は特に、ミラーポートへのデータパケットの複製は大幅に遅延しがちである。このような遅延は、データパケットＤ１とＡＣＫパケットＡ１のキャプチャ順の逆転を招く一因である。
以上の例示から分かるように、第１の条件に加えて、第２〜第５の条件のうちの１つ以上がさらに成立する場合に、動作例Ｅ２のような順序逆転が特によく起こり得る。
ここで、仮に、動作例Ｅ１のようにキャプチャロスと再送が生じた場合と、動作例Ｅ２のように順序逆転が生じた場合が判別されないとすれば、動作例Ｅ２のような順序逆転も、誤って、「キャプチャロスおよび再送の発生」と判断されてしまうであろう。つまり、２つの場合を区別しないタイプのパケット解析装置が仮に使われるとすると、第１の条件が成立する環境（特に、第２〜第５の条件のうちの１つ以上がさらに成立する環境）において、誤判断の確率が高まってしまう。
本実施形態のパケット解析装置３は、そのような誤判断を減らすように工夫されたものである。本実施形態のパケット解析装置３によれば、動作例Ｅ１のようにキャプチャロスと再送が生じた場合と、動作例Ｅ２のように順序逆転が生じた場合が、満足のいく精度で判別され得る。なお、パケット解析装置３は、ＡＳＩＣなどの専用ハードウェア回路を用いて実現されてもよいが、プログラムを実行する汎用的なコンピュータにより実現されてもよい。
具体的には、パケット解析装置３は、以下のような処理を行うことで、動作例Ｅ１のようにキャプチャロスと再送が生じた場合と、動作例Ｅ２のように順序逆転が生じた場合を判別する。
あるＡＣＫパケットが、第１の装置１から送信された第１のデータパケットを第２の装置２が受信したことを示しており、かつ、第２の装置２から送信されるものとする。このようなＡＣＫパケットをパケット解析装置３がキャプチャしたとき、パケット解析装置３は、「上記第１のデータパケットをパケット解析装置３が既にキャプチャしているか否か」を判断する。パケット解析装置３には、このような判断を実行する第１の判断手段が含まれ、例えば後述の検出部４４は、第１の判断手段の一例である。
例えば、動作例Ｅ１とＥ２のいずれにおいても、ＡＣＫパケットＡ１は、データパケットＤ１を第２の装置２が受信したことを示しており、かつ、第２の装置２から送信される。
よって、パケット解析装置３は、動作例Ｅ１の時刻Ｔ２においてＡＣＫパケットＡ１をキャプチャすると、「パケット解析装置３がデータパケットＤ１を既にキャプチャしているか否か」を判断する。その結果、パケット解析装置３は、「パケット解析装置３はまだデータパケットＤ１をキャプチャしていない」と判断する。
同様に、パケット解析装置３は、動作例Ｅ２の時刻Ｔ５においてＡＣＫパケットＡ１をキャプチャすると、「パケット解析装置３がデータパケットＤ１を既にキャプチャしているか否か」を判断する。その結果、パケット解析装置３は、「パケット解析装置３はまだデータパケットＤ１をキャプチャしていない」と判断する。
もちろん、以上のような判断の結果、パケット解析装置３が「パケット解析装置３は上記第１のデータパケットを既にキャプチャしていた」と判断する場合もあり得る。この場合は、パケット解析装置３は、単に、キャプチャ済みの第１のデータパケットに対するＡＣＫパケットを正常にキャプチャしただけである。つまり、この場合、第１のデータパケットと、それに対するＡＣＫパケットは、正常にネットワーク上を流れ、順にパケット解析装置３にキャプチャされる。
逆に、上記の判断の結果、パケット解析装置３が「パケット解析装置３はまだ上記第１のデータパケットをキャプチャしていなかった」と判断する場合もある。ここで、「ＡＣＫパケットがキャプチャされた」ということは、「第１のデータパケット自体は第１の装置１と第２の装置２の通信路上で消失していない」ということの証左である。なぜなら、パケット解析装置３がキャプチャしたＡＣＫパケットは、上記のとおり「第１の装置１から送信された第１のデータパケットを第２の装置２が受信した」と示しているからである。よって、この場合、以下の２通りの可能性が考えられる。
・例えば動作例Ｅ１のように、第１のデータパケット自体は第２の装置２に成功裡に到達したが、第１のデータパケットのキャプチャにパケット解析装置３が失敗した、という可能性（すなわち、第１のデータパケットのキャプチャロスが生じた、という可能性）。
・例えば動作例Ｅ２のように、第１のデータパケットとＡＣＫパケットの間で、キャプチャ過程において順序の逆転が生じているため、第１のデータパケットがまだパケット解析装置３にキャプチャされていない、という可能性。
そこで、パケット解析装置３は、上記２通りの可能性を判別するための処理を行う。具体的には、上記ＡＣＫパケットの受信に応じた上記の判断の結果、パケット解析装置３が、「パケット解析装置３はまだ上記第１のデータパケットをキャプチャしていなかった」と判断した場合、パケット解析装置３は以下のように動作する。
すなわち、パケット解析装置３は、第１の装置１から送信された第２のデータパケットを、上記判断のトリガとなった上記ＡＣＫパケットの後にさらにキャプチャしたとき、以下の第１の数値と第２の数値を比較する。パケット解析装置３には、このような比較を実行する比較手段が含まれ、例えば後述の検出部４４は、比較手段の一例でもある。
第１の数値は、第２の通信プロトコルによる１つのコネクション上で、第２の装置２が第１の装置１から次に受信することを期待するデータパケットを識別するための数値であり、上記ＡＣＫパケットにより示される。また、第２の数値は、第２のデータパケットをコネクション上で識別するために第２のデータパケット自体に含められている。
例えば、動作例Ｅ１では、パケット解析装置３が、時刻Ｔ２にＡＣＫパケットＡ１をキャプチャした後に、時刻Ｔ３に再送パケットＲ１をキャプチャする。よって、動作例Ｅ１では、上記第２のデータパケットは、具体的には再送パケットＲ１である。
また、動作例Ｅ１では、第１の数値は、ＡＣＫパケットＡ１により示される数値である。より具体的には、動作例Ｅ１では、第１の数値は、第２の装置２が第１の装置１からデータパケットＤ１の次に受信することを期待するデータパケットを識別するための数値である。例えば、第２の通信プロトコルがＴＣＰである場合、第１の数値は、ＡＣＫパケットＡ１のＴＣＰヘッダ内のＡＣＫ番号（acknowledgement number）であってもよい。
そして、動作例Ｅ１では、第２の数値は、再送パケットＲ１をコネクション上で識別するために再送パケットＲ１自体に含められている。ここで、上記のとおり、第２の通信プロトコルは、コネクション指向であり、再送手順を有する。そして、再送パケットＲ１は、再送手順にしたがって再送されたパケットであるから、再送パケットＲ１とデータパケットＤ１のペイロードは同じである。また、再送パケットＲ１は、再送手順にしたがって再送されたパケットであるから、再送パケットＲ１をコネクション上で識別するための第２の数値は、データパケットＤ１をコネクション上で識別するための数値と同じである。例えば、第２の通信プロトコルがＴＣＰである場合、第２の数値は、再送パケットＲ１のＴＣＰヘッダ内のシーケンス番号（sequence number）であってもよい。
このように、動作例Ｅ１では、再送パケットＲ１に含まれる第２の数値は、データパケットＤ１をコネクション上で識別するための数値と等しい。そのため、第２の数値が示す上記コネクション上の順序は、ＡＣＫパケットＡ１に含まれる第１の数値が示す順序よりも早い。
一方、動作例Ｅ２では、パケット解析装置３が、時刻Ｔ５にＡＣＫパケットＡ１をキャプチャした後に、時刻Ｔ６にデータパケットＤ１をキャプチャする。よって、動作例Ｅ２では、上記第２のデータパケットは、具体的にはデータパケットＤ１である。
動作例Ｅ２でも動作例Ｅ１と同様に、第１の数値は、第２の装置２が第１の装置１からデータパケットＤ１の次に受信することを期待するデータパケットを識別するための数値である。例えば、上記のとおり、第１の数値は、ＡＣＫパケットＡ１のＴＣＰヘッダ内のＡＣＫ番号であってもよい。
また、動作例Ｅ２では、第２の数値は、データパケットＤ１をコネクション上で識別するためにデータパケットＤ１自体に含められている数値である。例えば、第２の通信プロトコルがＴＣＰである場合、第２の数値は、データパケットＤ１のＴＣＰヘッダ内のシーケンス番号であってもよい。
以上より、動作例Ｅ２においても動作例Ｅ１と同様に、第２の数値が示す上記コネクション上の順序は、第１の数値が示す順序よりも早い。
ここで、動作例Ｅ１について説明したとおり、データパケットＤ１をコネクション上で識別する数値と、再送パケットＲ１をコネクション上で識別する数値は同じである。よって、以上のような第１の数値と第２の数値の比較だけでは、動作例Ｅ１のようにキャプチャロスと再送が起こる場合と、動作例Ｅ２のようにキャプチャ過程で順序逆転が起こる場合とが判別されない。
別の観点から述べれば、第２の通信プロトコル（例えばＴＣＰ）にしたがって、再送パケットＲ１にはデータパケットＤ１と同じ数値が割り当てられるからこそ、「再送パケットＲ１がデータパケットＤ１の再送である」ということが示される。その結果として、コネクション指向の通信が実現される。そのため、コネクション指向の第２の通信プロトコルで使われる制御情報（例えば第１の数値や第２の数値）を用いるだけでは、キャプチャロスと再送が起こる場合と、順序逆転が起こる場合とを判別するのには不十分なのである。
なお、比較の結果として、「第２の数値が示すコネクション上の順序と、第１の数値が示すコネクション上の順序が等しい」と判明する場合もあり得る。この場合は、期待どおりに後続のデータパケットが第２の装置２に向けて送信されており、通信状況は正常である。
また、第２の数値が示すコネクション上の順序の方が、第１の数値が示すコネクション上の順序より遅い場合もあり得る。この場合は、例えば、「期待される次のデータパケットのネットワークロスまたはキャプチャロスが生じ、次のデータパケットよりもさらに後のデータパケットがキャプチャされた」といった可能性がある。パケット解析装置３は、この種のネットワークロスまたはキャプチャロスを、例えば公知の手法に基づいて検出してもよい。
さて、上記のとおり、コネクション指向の第２の通信プロトコルで使われる情報を用いるだけでは、キャプチャロスと再送が起こる場合と、順序逆転が起こる場合とを判別するのに不十分である。そこで、パケット解析装置３は、これら２つの場合を判別するために、第１の通信プロトコルで使われる制御情報を利用する。
上記のように、第１の通信プロトコルは、第２の通信プロトコルよりも下位の層で定義されるコネクションレスなプロトコルである。よって、第２の通信プロトコルにより割り当てられる数値では区別されないデータパケットＤ１と再送パケットＲ１も、第１の通信プロトコルによる制御情報では区別され得る。
そこで、第２の数値が示すコネクション上の順序が、第１の数値が示すコネクション上の順序よりも早い場合、パケット解析装置３は、以下の第３の数値と第４の数値の差に基づく判断を行う。パケット解析装置３には、このような判断を実行する第２の判断手段も含まれ、例えば後述の検出部４４は、第２の判断手段の一例でもある。
第３の数値は、第１の通信プロトコルにしたがって、第１の装置１により、上記第２のデータパケットに対して識別用に割り当てられている数値である。例えば、第１の通信プロトコルがＩＰバージョン４である場合、第３の数値は、キャプチャされた第２のデータパケットのＩＰヘッダ中のＩＤであってもよい。
また、説明の便宜上、第１の装置１から送信されて、上記ＡＣＫパケットよりも前にパケット解析装置３によりキャプチャされたデータパケットの中では、最も遅くパケット解析装置３にキャプチャされたデータパケットのことを、「前回データパケット」という。第４の数値は、前回データパケットに対して、第１の通信プロトコルにしたがって第１の装置１により識別用に割り当てられている数値である。例えば、第１の通信プロトコルがＩＰバージョン４である場合、第４の数値は、前回データパケットのＩＰヘッダ中のＩＤであってもよい。
つまり、第３の数値と第４の数値は、いずれも、コネクションレスな第１の通信プロトコルにしたがって割り当てられる識別番号である。換言すれば、第３の数値と第４の数値は、コネクション上のパケット間の順序とは独立に割り当てられる。
例えば、動作例Ｅ１では、第３の数値は、第２のデータパケットに相当する再送パケットＲ１（すなわち時刻Ｔ３にキャプチャされたデータパケット）に対して、第１の通信プロトコルにしたがって割り当てられている識別番号である。また、動作例Ｅ１では、前回データパケットは、時刻Ｔ２でのＡＣＫパケットＡ１のキャプチャの前にキャプチャされたデータパケット中の最後のものである。つまり、動作例Ｅ１での前回データパケットは、データパケットＤ０である。よって、動作例Ｅ１では、第４の数値は、データパケットＤ０に対して第１の通信プロトコルにしたがって割り当てられている識別番号である。
他方、動作例Ｅ２では、第３の数値は、第２のデータパケットに相当するデータパケットＤ１（すなわち時刻Ｔ６にキャプチャされたデータパケット）に対して、第１の通信プロトコルにしたがって割り当てられている識別番号である。また、動作例Ｅ２では、前回データパケットは、時刻Ｔ５でのＡＣＫパケットＡ１のキャプチャの前にキャプチャされたデータパケット中の最後のものである。つまり、動作例Ｅ２での前回データパケットは、データパケットＤ０である。よって、動作例Ｅ２では、第４の数値は、データパケットＤ０に対して第１の通信プロトコルにしたがって割り当てられている識別番号である。
ここで、動作例Ｅ１では、パケット解析装置３がデータパケットＤ０の次にキャプチャしたデータパケットは、再送パケットＲ１であるが、第１の装置１からは、実際には、データパケットＤ０と再送パケットＲ１の間に、データパケットＤ１が送信されている。つまり、動作例Ｅ１では、第１の装置１が第１の通信プロトコルにしたがって再送パケットＲ１に識別番号を割り当てる前に、少なくとも１つは、データパケットＤ１用に識別番号が消費されている。
そのため、動作例Ｅ１では、キャプチャされたデータパケットの中では、データパケットＤ０と再送パケットＲ１が、キャプチャ順において隣接するにもかかわらず、データパケットＤ０と再送パケットＲ１の識別番号は、隣接しない。換言すれば、動作例Ｅ１のようにキャプチャロスと再送が起きる場合は、第３の数値と第４の数値の差は、前回データパケットのキャプチャから上記ＡＣＫパケットのキャプチャまでの間に生じた、データパケットのキャプチャロスの回数よりも、大きい。
それに対し、動作例Ｅ２では、パケット解析装置３がデータパケットＤ０の次にキャプチャしたデータパケットは、データパケットＤ１であり、かつ、第１の装置１がデータパケットＤ０の次に送信したデータパケットも、データパケットＤ１である。よって、もし仮に、データパケットＤ０の送信からデータパケットＤ１の送信までの間には、第１の装置１がパケットを送信していなければ、データパケットＤ０とＤ１の識別番号は隣接する。
もちろん、第１の装置１は、データパケットＤ０の送信からデータパケットＤ１の送信までの間に、例えば以下に例示するような何らかのパケットを１つ以上送信する可能性がある。
・第２の通信プロトコルによる、第１の装置１と第２の装置２の間の他のコネクション上での、第２の装置２宛のパケット。
・第２の通信プロトコル以外のプロトコルによる、第２の装置２宛のパケット。
・第２の装置２以外の他の装置宛のパケット。
このように第１の装置１がデータパケットＤ０とＤ１の間に何らかのパケットを１つ以上送信する場合、第３の数値と第４の数値は隣接しない。つまり、この場合、第３の数値と第４の数値の差は、データパケットＤ０とＤ１の間に送信されたパケットの数に応じた値である。
しかし、第３の数値と第４の数値の差が大きければ、動作例Ｅ２のような順序逆転が起きた蓋然性よりも、動作例Ｅ１のようなキャプチャロスと再送が起きた蓋然性の方が高い。逆に、第３の数値と第４の数値の差が小さければ、キャプチャロスと再送が起きた蓋然性よりも、順序逆転が起きた蓋然性の方が高い。よって、パケット解析装置３は、第３の数値と第４の数値の差に基づく判断を行うことで、ある程度の高い信頼性をもって、２つの場合を判別することができる。
つまり、パケット解析装置３は、「キャプチャされた上記第２のデータパケットが、上記ＡＣＫパケットよりも遅れてパケット解析装置３にキャプチャされた上記第１のデータパケットであるのか否か」を、第３の数値と第４の数値の差に基づいて判断する。
例えば、動作例Ｅ２は、「第２のデータパケットとして時刻Ｔ６にキャプチャされたデータパケットＤ１が、実は第１のデータパケットに対するＡＣＫパケットＡ１よりも遅れてパケット解析装置３にキャプチャされた第１のデータパケットである」という例である。パケット解析装置３は、第３の数値と第４の数値の差に基づいて、「第２のデータパケットは、遅れてキャプチャされた第１のデータパケットである」と判断することができる。つまり、パケット解析装置３は、データパケットＤ１とＤ０の識別番号の差が小さいことから、「第２のデータパケットは、遅れてキャプチャされた第１のデータパケットである」と判断することができる。
他方、動作例Ｅ１では、第２のデータパケットとして時刻Ｔ３にキャプチャされた再送パケットＲ１は、第１のデータパケット（すなわち、第２の装置２において受信されたことがＡＣＫパケットＡ１により示されているデータパケットＤ１）そのものではない。パケット解析装置３は、第３の数値と第４の数値の差に基づいて、「第２のデータパケットは、遅れてキャプチャされた第１のデータパケットではない」と判断することも可能である。つまり、パケット解析装置３は、再送パケットＲ１の識別番号とデータパケットＤ０の識別番号の差が大きいことから、「第２のデータパケットは、遅れてキャプチャされた第１のデータパケットではない」と判断することができる。
なお、以上の説明においては、第３の数値と第４の数値の差に関して、「大きい」・「小さい」という相対的な表現を用いている。しかし、当該差に基づく判断は、具体的には、可変の閾値に基づく判断であることが好ましい。
より具体的には、第３の数値と第４の数値との差が閾値以下の場合に、パケット解析装置３は、「キャプチャされた第２のデータパケットは、実は、ＡＣＫパケットよりも遅れてキャプチャされた第１のデータパケットである」と判断してもよい。当該閾値は、具体的には、第１の数値と、前回データパケットをコネクション上で識別するために前回データパケットに含められている第５の数値に応じて決まる値である。
例えば、第２の通信プロトコルがＴＣＰである場合、上記のとおり第１の数値はＴＣＰヘッダ内のＡＣＫ番号である。また、第５の数値は、前回データパケットのＴＣＰヘッダ内のシーケンス番号である。上記閾値は、第１の数値としてのＡＣＫ番号と第５の数値としてのシーケンス番号とに基づいて決められてもよい。
より好ましくは、上記閾値は、第１の数値と第５の数値だけでなく、さらに以下の２つの値にも基づいて決められてもよい。
・前回データパケットのサイズ（より詳しくは、前回データパケットのうち、第２の通信プロトコルにとってのペイロードのサイズ）。
・コネクション上で第１の装置１から第２の装置２へ送信される複数のデータパケットのサイズ（より詳しくは、データパケットのうち、第２の通信プロトコルにとってのペイロードのサイズ）に関する、サイズ値。
例えば、第２の通信プロトコルがＴＣＰの場合、第５の数値と前回データパケットのサイズの和から、「コネクション上を流れるデータストリーム内のどのオクテットまでがキャプチャ済みか」という範囲が判明する。また、第２の通信プロトコルがＴＣＰの場合、第１の数値は、ＡＣＫパケットにより示されるＡＣＫ番号であり、第２の装置２が次に受信を期待するオクテットの位置を示す。よって、第１の数値と、第５の数値と、前回データパケットのサイズから、未キャプチャのオクテットの範囲も判明するし、未キャプチャのオクテット数も算出可能である。
上記閾値は、未キャプチャのオクテット数をサイズ値で割った商であってもよいし、その商を切り上げた整数であってもよい。例えば、サイズ値は、コネクション上で第１の装置１から第２の装置２へ送信される複数のデータパケットのサイズから得られる統計値であってもよい。より具体的には、サイズ値は、コネクション上で第１の装置１から第２の装置２へ送信される複数のデータパケットの中での相対比較において所定の基準以上に長いペイロード長であってもよい。
所定の基準は、例えば、「ペイロードが長い方から上位Ｘ１％以内の長さ」や「ペイロードが長い方から上位Ｘ２位以内の長さ」などの基準であってもよい（ただし、Ｘ１とＸ２は予め決められた値とする）。例えば、Ｘ２＝１の場合、サイズ値は、コネクション上で第１の装置１から第２の装置２へ送信される複数のデータパケットの中で最長のペイロード長である。
パケット解析装置３は、実際にキャプチャした複数のデータパケットからサイズ値を求めてもよい。あるいは、データパケットの最長のペイロード長が、コネクションを確立する（establish）際のネゴシエーションにより（あるいは仕様により）予め決められている場合は、パケット解析装置３は、予め決められたサイズ値を利用してもよい。
例えば、ＴＣＰでは、コネクション確立の際にＭＳＳ（Maximum Segment Size）が決められる場合が多い。パケット解析装置３は、ＴＣＰヘッダのオプションフィールド中にＭＳＳの指定を含むＳＹＮパケットまたはＳＹＮ／ＡＣＫパケットをキャプチャすることにより、ＭＳＳを認識してもよい。パケット解析装置３は、認識したＭＳＳをサイズ値として使ってもよい。
なお、サイズ値に関する上記の「複数のデータパケット」は、実施形態に応じて適宜決められてよい。例えば、「複数のデータパケット」は以下のどちらであってもよい。
・コネクションが確立してから今までに、コネクション上で第１の装置１から第２の装置２に送信され、かつ、パケット解析装置３がキャプチャに成功した、すべてのデータパケット。
・コネクション上で第１の装置１から第２の装置２に送信され、かつ、直近の所定期間以内（例えば、直近のＸ３分以内）にパケット解析装置３によりキャプチャされた、すべてのデータパケット（ただし、Ｘ３は予め決められた値とする）。
例えば、第２の通信プロトコルがＴＣＰである場合、第１の数値は、ＡＣＫ番号であり、第２の装置２が次に受信を期待するデータパケットのＴＣＰペイロードの先頭オクテットを示す。また、第２の通信プロトコルがＴＣＰである場合、第５の数値は、シーケンス番号であり、前回データパケットのＴＣＰペイロードの先頭オクテットを示す。サイズ値は、例えば、コネクション上で第１の装置１から第２の装置２へ向けて送信され、パケット解析装置３によりキャプチャされたすべてのデータパケットの中で、最長のＴＣＰペイロードの長さでもよい。
例えば、パケット解析装置３は、第５の数値と前回データパケットのサイズの和を、第１の数値から引くことで、パケット解析装置３がキャプチャに失敗したと推定される１つ以上のデータパケットの合計サイズを推定してもよい。パケット解析装置３は、推定した合計サイズをサイズ値で割ることで、パケット解析装置３がキャプチャに失敗したと推定されるデータパケットの個数を推定してもよい。
こうして推定されるデータパケットの個数は、換言すれば、前回データパケットのキャプチャからＡＣＫパケットのキャプチャまでの間に生じた、データパケットのキャプチャロスの回数の推定値である。なお、図１の動作例Ｅ１は、データパケットのキャプチャロスの回数が１回の例だが、例えば連続する２個以上のデータパケットのキャプチャにパケット解析装置３が失敗することもあり得る。よって、キャプチャロスの回数の推定値は、２以上の場合もある。
以上述べたような、キャプチャロスの回数の推定値は、第３の数値と第４の数値との差と比べるための上記閾値として好適である。なぜなら、前回データパケットのキャプチャからＡＣＫパケットのキャプチャまでの間に実際にキャプチャロスが１回以上生じた場合、第３の数値と第４の数値の差は、実際のキャプチャロスの回数よりも大きいからである。実際のキャプチャロスの回数はパケット解析装置３にとって未知だが、パケット解析装置３は、実際のキャプチャロスの回数の代わりに、キャプチャロスの回数の推定値を上記閾値として利用することができる。
なお、上記のように最長のペイロード長がサイズ値として使われる場合、以上のようにしてサイズ値による除算に基づいて推定されるキャプチャロスの回数は、推定され得る最小値である。このように、推定され得る最小値を、キャプチャロスの回数の推定値として採用することには、副作用を小さくとどめる利点がある。理由は以下のとおりである。
上記のとおり、パケット解析装置３は、第３の数値と第４の数値との差が上記閾値以下の場合に、「キャプチャされた第２のデータパケットは、ＡＣＫパケットよりも遅れてキャプチャされた第１のデータパケットである」と判断してもよい。つまり、パケット解析装置３は、第３の数値と第４の数値との差が上記閾値以下の場合に、「キャプチャ過程での逆転が生じた」と判断してもよい。
逆に、第３の数値と第４の数値との差が、上記閾値よりも大きい場合、パケット解析装置３は、「キャプチャロスと再送が生じた」と判断してもよい。つまり、この場合、パケット解析装置３は、「第１の装置１が、第２の通信プロトコルの再送手順にしたがって第１のデータパケットと同じ数値を含めて再送したデータパケットを、パケット解析装置３が、第２のデータパケットとしてキャプチャした」と判断してもよい。
ここで、閾値が適切に定められているほど、パケット解析装置３による判断の正確性も高い。しかし、閾値が過度に大きく定められていると、実際にはキャプチャロスと再送が生じたにもかかわらず、パケット解析装置３が「キャプチャ過程での逆転が生じた」と誤判断するおそれがある。また、閾値が過度に小さく定められていると、実際にはキャプチャ過程での逆転が生じたにもかかわらず、パケット解析装置３が「キャプチャロスと再送が生じた」と誤判断するおそれがある。
前者の誤判断と後者の誤判断を比較すると、後者の誤判断の方が、弊害が少ないと考えられる。なぜなら、発明者が得た知見によれば、キャプチャ過程での順序逆転よりは、キャプチャロスと再送が起こる場合の方が多いからである。
よって、全体として判断の精度を高めるためには、パケット解析装置３は、キャプチャ過程での順序逆転が生じたことが明らかな場合だけを順序逆転として検出することが好ましい。換言すれば、「キャプチャ過程での順序逆転が生じたのか、それとも、キャプチャロスと再送が生じたのか」を明確に判断することが難しい場合については、パケット解析装置３は、「キャプチャロスと再送が生じた」と判断することが好ましい。つまり、パケット解析装置３は、後者の誤判断を少々犯してでも、前者の誤判断を避ける方が、結果として、全体的な判断の精度を高めることができる、と期待される。
そして、前者の誤判断は、閾値が過度に大きい場合に生じ得るものである。よって、前者の誤判断を避けるには、閾値を、適切な範囲内で小さめの値に抑えることが有効である。よって、パケット解析装置３は、上記のように、推定され得る最小値をキャプチャロスの回数の推定値として採用し、当該推定値を上記閾値として用いることで、前者の誤判断をより確実に避けることができ、結果として全体的な判断の精度を高めることができる。
以上説明したように、本実施形態のパケット解析装置３によれば、キャプチャロスと再送が生じる場合と、キャプチャ過程での順序逆転が生じる場合とが、比較的高い精度で判別される。つまり、パケット解析装置３によれば、再送に関する誤判断が減る。よって、例えば、再送回数からネットワーク品質を推定してネットワーク品質を監視する用途などにパケット解析装置３が利用される場合、推定の精度が向上する。
近年では、ネットワークを介してサーバがクライアントにサービスを提供する機会も多いので、ネットワーク品質の監視の重要性も増している。よって、パケット解析装置３によるネットワーク品質の推定精度の向上は、サービス提供者やネットワーク提供者にとって非常に有意義である。
以下では、上記第１の通信プロトコルがＩＰ（より具体的にはＩＰバージョン４）であり、上記第２の通信プロトコルがＴＣＰである場合を例にして、本実施形態についてさらに詳しく説明する。なお、以下の説明では、パケット解析装置３は、ネットワーク品質を監視するためにパケット解析を行うネットワーク監視装置であるものとする。
図２は、キャプチャ過程でのパケット間の順序の逆転を例示する図である。図２には、図１の動作例Ｅ２のような逆転が例示されている。
図２にはホスト１１と１２が例示されている。ホスト１１と１２はいずれもコンピュータである。例えば、ホスト１１が図１の第１の装置１に対応し、ホスト１２が図１の第２の装置２に対応する。なお、図２などでは「ホスト」という用語を使っているが、「ホスト」を「ノード」と言い換えてもよい。
ホスト１１と１２の間のネットワーク上には、パケット解析システム１０ａまたは１０ｂが設けられる。パケット解析システム１０ａはネットワーク装置１３ａとネットワーク監視装置１７ａを含み、パケット解析システム１０ｂはネットワーク装置１３ｂとネットワーク監視装置１７ｂを含む。
ネットワーク装置１３ａは、少なくとも３つのポート１４ａ、１５ａ、および１６ａを有し、ネットワーク装置１３ｂは、少なくとも４つのポート１４ｂ、１５ｂ、１６ｂ、および１６ｃを有する。ポート１４ａと１４ｂは図１の通過点４に対応し、ポート１５ａと１５ｂは図１の通過点５に対応する。
ポート１４ａは、ホスト１１と直接的に接続されるか、または、１つ以上の他のネットワーク装置（例えばスイッチやルータなど）を介してホスト１１と間接的に接続される。ポート１５ａは、ホスト１２と直接的に接続されるか、または、１つ以上の他のネットワーク装置（例えばスイッチやルータなど）を介してホスト１２と間接的に接続される。
ポート１６ａは、ネットワーク監視装置１７ａと接続される。ポート１６ａは、ネットワーク監視装置１７ａと直接的にケーブルで接続されることが望ましい。ネットワーク監視装置１７ａは、ポート１６ａからの出力をキャプチャすることで、ホスト１１と１２の間で送受信されるパケットをキャプチャすることができる。
ポート１４ｂは、ホスト１１と直接的に接続されるか、または、１つ以上の他のネットワーク装置（例えばスイッチやルータなど）を介してホスト１１と間接的に接続される。ポート１５ｂは、ホスト１２と直接的に接続されるか、または、１つ以上の他のネットワーク装置（例えばスイッチやルータなど）を介してホスト１２と間接的に接続される。
ポート１６ｂと１６ｃは、ネットワーク監視装置１７ｂと接続される。ポート１６ｂと１６ｃは、それぞれ、ネットワーク監視装置１７ｂと直接的にケーブルで接続されることが望ましい。ネットワーク監視装置１７ｂは、ポート１６ｂから出力されるパケットを受信し、ポート１６ｃから出力されるパケットも受信する。
ネットワーク監視装置１７ｂは、ポート１６ｂから受信したパケットとポート１６ｃから受信したパケットをともに記憶するためのバッファ１８を有する。バッファ１８は、具体的には、ＦＩＦＯ（First-In First-Out）キューである。
ネットワーク装置１３ａは、ポートミラーリング機能を有するスイッチまたはルータであってもよい。この場合、ポート１４ａと１５ａはいずれもネットワークポートであり、ポート１６ａは、ポート１４ａで受信されたパケットとポート１５ａで受信されたパケットの双方をミラーリングするための、集約ミラーポートである。この場合、ネットワーク装置１３ａは、ホスト１１からホスト１２へ向けて送信されるパケットをポート１４ａで受信すると、以下の処理を行う。
・受信したパケットをポート１５ａからホスト１２へ向けて送信する。
・受信したパケットを複製してポート１６ａに出力し、複製したパケットをポート１６ａからネットワーク監視装置１７ａに送信する。
また、ネットワーク装置１３ａがポートミラーリング機能を有するスイッチまたはルータである場合、ネットワーク装置１３ａは、ホスト１２からホスト１１へ向けて送信されるパケットをポート１５ａで受信すると、以下の処理を行う。
・受信したパケットをポート１４ａからホスト１１へ向けて送信する。
・受信したパケットを複製してポート１６ａに出力し、複製したパケットをポート１６ａからネットワーク監視装置１７ａに送信する。
同様に、ネットワーク装置１３ｂも、ポートミラーリング機能を有するスイッチまたはルータであってもよい。この場合、ポート１４ｂと１５ｂはいずれもネットワークポートである。また、この場合、ポート１６ｂは、ポート１４ｂで受信されたパケットをミラーリングするためのミラーポートであり、ポート１６ｃは、ポート１５ｂで受信されたパケットをミラーリングするためのミラーポートである。この場合、ネットワーク装置１３ｂは、ホスト１１からホスト１２へ向けて送信されるパケットをポート１４ｂで受信すると、以下の処理を行う。
・受信したパケットをポート１５ｂからホスト１２へ向けて送信する。
・受信したパケットを複製してポート１６ｂに出力し、複製したパケットをポート１６ｂからネットワーク監視装置１７ａに送信する。
また、ネットワーク装置１３ｂがポートミラーリング機能を有するスイッチまたはルータである場合、ネットワーク装置１３ｂは、ホスト１２からホスト１１へ向けて送信されるパケットをポート１５ｂで受信すると、以下の処理を行う。
・受信したパケットをポート１４ｂからホスト１１へ向けて送信する。
・受信したパケットを複製してポート１６ｃに出力し、複製したパケットをポート１６ｃからネットワーク監視装置１７ａに送信する。
あるいは、ネットワーク装置１３ａはネットワークタップであってもよい。この場合、ポート１６ａは、集約モニタポートである。この場合、ホスト１１からホスト１２へ向けて送信されるパケットの信号がポート１４ａで受信されると、信号は物理層で２つに分岐させられる。分岐した一方の信号は、ネットワーク装置１３ａを通過する（具体的には、ポート１５ａからホスト１２へ向けて出力される）。分岐した他方の信号は、ポート１６ａからネットワーク監視装置１７ａへ出力される。
また、ネットワーク装置１３ａがネットワークタップである場合、ホスト１２からホスト１１へ向けて送信されるパケットの信号がポート１５ａで受信されると、信号は物理層で２つに分岐させられる。分岐した一方の信号は、ネットワーク装置１３ａを通過する（具体的には、ポート１４ａからホスト１１へ向けて出力される）。分岐した他方の信号は、ポート１６ａからネットワーク監視装置１７ａへ出力される。
同様に、ネットワーク装置１３ｂがネットワークタップであってもよい。この場合、ポート１６ｂと１６ｃはいずれもモニタポートである。この場合、ホスト１１からホスト１２へ向けて送信されるパケットの信号がポート１４ｂで受信されると、信号は物理層で２つに分岐させられる。分岐した一方の信号は、ネットワーク装置１３ｂを通過する（具体的には、ポート１５ｂからホスト１２へ向けて出力される）。分岐した他方の信号は、ポート１６ｂからネットワーク監視装置１７ｂへ出力される。
また、ネットワーク装置１３ｂがネットワークタップである場合、ホスト１２からホスト１１へ向けて送信されるパケットの信号がポート１５ｂで受信されると、信号は物理層で２つに分岐させられる。分岐した一方の信号は、ネットワーク装置１３ｂを通過する（具体的には、ポート１４ｂからホスト１１へ向けて出力される）。分岐した他方の信号は、ポート１６ｃからネットワーク監視装置１７ｂへ出力される。
いずれにせよ、ネットワーク監視装置１７ａは、ホスト１１とホスト１２の間で送受信されるパケットを、ポート１６ａを介してキャプチャすることができる。しかし、ポート１４ａからポート１６ａへの経路とポート１５ａからポート１６ａへの経路の間で、パケット間の順序関係を保つための調停が行われない場合、図１の動作例Ｅ２に例示したような、キャプチャ過程での順序逆転が起こり得る。
同様に、ネットワーク監視装置１７ｂは、ホスト１１とホスト１２の間で送受信されるパケットを、ポート１６ｂと１６ｃを介してキャプチャすることができる。しかし、ポート１４ｂからポート１６ｂを通ってバッファ１８に至る経路と、ポート１５ｂからポート１６ｃを通ってバッファ１８に至る経路の間で、パケット間の順序関係を保つための調停が行われない場合、キャプチャ過程での順序逆転が起こり得る。
例えば、ネットワーク装置１３ａが、ポートミラーリング機能を有するスイッチまたはルータである場合、動作例Ｅ３のような順序逆転が起こり得る。まず、ホスト１１がパケットＰ１を送信し、次にホスト１１がパケットＰ２を送信し、その後、ホスト１２がパケットＰ３を送信したとする。よって、ネットワーク装置１３ａは、まずポート１４ａでパケットＰ１を受信し、次にポート１４ａでパケットＰ２を受信し、その後、ポート１５ａでパケットＰ３を受信する。
しかし、何らかの理由により、パケットＰ２よりも遅くにネットワーク装置１３ａに到着したパケットＰ３の方が、パケットＰ２がポート１４ａからポート１６ａに複製されるよりも前に、ポート１５ａからポート１６ａに複製される場合があり得る。その結果、ポート１６ａからは、まずパケットＰ１が出力され、次にパケットＰ３が出力され、その後、パケットＰ２が出力される。したがって、ネットワーク監視装置１７ａは、まずパケットＰ１をキャプチャし、次にパケットＰ３をキャプチャし、その後、パケットＰ２をキャプチャする。つまり、動作例Ｅ３では、パケットＰ２とＰ３の間で、キャプチャ過程において（より具体的にはネットワーク装置１３ａ内において）順序逆転が発生している。
例えば、パケットＰ１とＰ２は、ともに、ホスト１１からホスト１２へ送信されるデータパケットでもよい。パケットＰ３は、ホスト１２が遅延確認応答の仕組みにしたがってパケットＰ２の受信まで待ってから返信するＡＣＫパケットであってもよい。この場合、パケットＰ３によって、パケットＰ１とＰ２の双方の受信がホスト１１に通知される。
以下では説明の便宜上、ＴＣＰセグメントのペイロード長を「ＴＣＰデータ長」という。
ここで、ＩＰパケットの長さは、ＩＰヘッダ長と、ＴＣＰヘッダ長と、ＴＣＰセグメントのペイロード長の和である。そして、ＩＰパケットの長さは、ＩＰヘッダ（具体的にはＩＰバージョン４のヘッダ）中の「全長（total length）」フィールドによりオクテット単位で示される。また、ＩＰヘッダ長は、ＩＰヘッダ中の「ＩＨＬ（Internet Header Length）」フィールドにより３２ビット単位で示される。そして、ＴＣＰヘッダ長は、ＴＣＰヘッダ中の「データオフセット」フィールドにより３２ビット単位で示される。よって、ＴＣＰデータ長は、全長フィールドとＩＨＬフィールドとデータオフセットフィールドの値から計算することができる。
例えば、パケットＰ１のＴＣＰヘッダ内のシーケンス番号が１であり、パケットＰ１のＴＣＰデータ長が１５１４であるとする。この場合、ホスト１１がパケットＰ１の直後に送信するパケットＰ２のＴＣＰヘッダ内のシーケンス番号は、１５１５（＝１＋１５１４）である。また、パケットＰ２のＴＣＰデータ長も、１５１４であるとする。上記のようにパケットＰ３がパケットＰ１とＰ２に対して送信されるＡＣＫパケットである場合、パケットＰ３のＴＣＰヘッダ内のＡＣＫ番号は、３０２９（＝１５１５＋１５１４）である。
パケットＰ１とＰ２のように長いパケットが、連続して同じポート１４ａにおいて受信されると、ポート１４ａからポート１６ａへの複製処理を行う回路の処理負荷が高くなる。その結果、ポート１４ａからポート１６ａへの複製処理は遅れがちとなる。他方、パケットＰ３が上記のようにＡＣＫパケットである場合、パケットＰ３のサイズは小さいので、ポート１５ａからポート１６ａへのパケットＰ３の複製処理は、すぐに完了するであろう。そのため、動作例Ｅ３に示すような順序の逆転が生じ、ネットワーク監視装置１７ａが、パケットＰ１、パケットＰ３、パケットＰ２の順にこれらのパケットをキャプチャする可能性がある。
ネットワーク装置１３ａがネットワークタップである場合も、ネットワーク装置１３ｂが使われる場合も、動作例Ｅ３と同様の順序の逆転が起こる可能性がある。動作例Ｅ３におけるパケットＰ２とＰ３の間の順序逆転は、図１の動作例Ｅ２におけるデータパケットＤ１とＡＣＫパケットＡ１の間の順序逆転と同様である。
ネットワーク装置１３ａと１３ｂは、いずれも、図１のパケット解析装置３と同様の方法により、順序逆転を適切に検出する。つまり、ネットワーク装置１３ａと１３ｂは、いずれも、順序逆転が起こった場合と、キャプチャロスと再送が起こった場合とを適切に判別する。よって、ネットワーク装置１３ａまたは１３ｂによって推定されるネットワーク品質（例えば、再送率やネットワークロス率により示される品質）は、信頼性が高い。
続いて、図３〜６を参照しながら、複数のパケットのさらに具体的な例を使って、キャプチャ過程での順序逆転と誤判断の防止について、説明する。
図３は、パケットの流れを例示する図である。図３のタイミングチャートには、ホスト２１とホスト２２のタイムラインが示されている。ホスト２１と２２は、いずれもコンピュータである。そして、キャプチャ地点（capture location）２３には、ホスト２１と２２の間で送受信されるパケットをキャプチャし、キャプチャしたパケットを使った解析を行うためのパケット解析装置が設けられる。パケット解析装置は、具体的にはコンピュータであってもよい。ホスト２１と２２との間の通信路上には、図３には不図示のネットワーク装置が設けられ、パケット解析装置は、当該ネットワーク装置を介してパケットをキャプチャする。
例えば、ホスト２１は図１の第１の装置１であってもよく、ホスト２２は図１の第２の装置２であってもよい。この場合、キャプチャ地点２３でパケットをキャプチャするパケット解析装置は、パケット解析装置３である。また、この場合、図１の通過点４と５は、図３には不図示の上記ネットワーク装置のポートである。
あるいは、ホスト２１は図２のホスト１１であってもよく、ホスト２２は図２のホスト１２であってもよい。この場合、キャプチャ地点２３でパケットをキャプチャするパケット解析装置は、ネットワーク監視装置１７ａまたは１７ｂである。
図３の例では、ホスト２１が、データパケットＤ１１〜Ｄ１５を順にホスト２２に送信する。なお、ＴＣＰではスライディングウィンドウが使われるので、ホスト２１は、ウィンドウサイズの範囲内で、ホスト２２からのＡＣＫパケットの到着を待たずに、次々とデータパケットを送信することができる。
また、ＴＣＰの遅延確認応答の仕組みにより、ホスト２２は、データパケットＤ１１を受信してもすぐにはＡＣＫパケットを送信しない。ホスト２２は、データパケットＤ１２の受信後に、ＡＣＫパケットＡ１２を送信する。同様に、ホスト２２は、データパケットＤ１３を受信してもすぐにはＡＣＫパケットを送信せず、データパケットＤ１４の受信後に、ＡＣＫパケットＡ１４を送信する。
図３〜６では参照の便宜のため、パケットのＴＣＰヘッダ中のシーケンス番号を「ｓｅｑ＝８０１」のように示しており、パケットのＴＣＰデータ長を「ｌｅｎ＝１００」のように示している。また、図３〜６では、パケットのＴＣＰヘッダ中のＡＣＫ番号を「ａｃｋ＝１００１」のように示している。具体的には以下のとおりである。
・データパケットＤ１１のシーケンス番号は８０１であり、データパケットＤ１１のＴＣＰデータ長は１００オクテットである。
・データパケットＤ１２のシーケンス番号は９０１（＝８０１＋１００）であり、データパケットＤ１２のＴＣＰデータ長は１００オクテットである。
・ＡＣＫパケットＡ１２は、ホスト２２がデータパケットＤ１２までのデータパケットを受信済みであることを示す。よって、ＡＣＫパケットＡ１２のＡＣＫ番号は、１００１（＝９０１＋１００）である。換言すれば、ＡＣＫパケットＡ１２は、ホスト２２が次に受信することを期待するデータパケットのシーケンス番号が１００１であることを示す。
・データパケットＤ１３のシーケンス番号は１００１（＝９０１＋１００）であり、データパケットＤ１３のＴＣＰデータ長は１００オクテットである。
・データパケットＤ１４のシーケンス番号は１１０１（＝１００１＋１００）であり、データパケットＤ１４のＴＣＰデータ長は１００オクテットである。
・ＡＣＫパケットＡ１４は、ホスト２２がデータパケットＤ１４までのデータパケットを受信済みであることを示す。よって、ＡＣＫパケットＡ１４のＡＣＫ番号は、１２０１（＝１１０１＋１００）である。換言すれば、ＡＣＫパケットＡ１４は、ホスト２２が次に受信することを期待するデータパケットのシーケンス番号が１２０１であることを示す。
・データパケットＤ１５のシーケンス番号は１２０１（＝１１０１＋１００）であり、データパケットＤ１５のＴＣＰデータ長は１００オクテットである。
図３では、キャプチャ地点２３でパケットがキャプチャされる順序の詳細を示していないが、具体的には、図３に示した７つのパケットは、図４のような順序でキャプチャされる場合があり得る。図４は、キャプチャの過程でパケット間の順序が逆転する例を示す図である。
例えば、あるネットワークポートからミラーポートへのパケットの複製にかかる時間が、他のネットワークポートからミラーポートへのパケットの複製にかかる時間よりもかなり長い場合や、ホスト２１と２２の間のＲＴＴが短い場合などに、順序逆転が生じ得る。順序逆転が生じやすい条件については、図１に関して前述したとおりである。図４の例では、キャプチャ過程での順序逆転により、具体的には、図３の７つのパケットは、キャプチャ地点２３において以下の順序でキャプチャされたものとする。
・まず、時刻Ｔ１１にデータパケットＤ１１がキャプチャ地点２３でキャプチャされる。
・その後、時刻Ｔ１２にデータパケットＤ１２がキャプチャ地点２３でキャプチャされる。
・その後、時刻Ｔ１３にＡＣＫパケットＡ１２がキャプチャ地点２３でキャプチャされる。
・その後、時刻Ｔ１４にＡＣＫパケットＡ１４がキャプチャ地点２３でキャプチャされる。
・その後、時刻Ｔ１５にデータパケットＤ１３がキャプチャ地点２３でキャプチャされる。
・その後、時刻Ｔ１６にデータパケットＤ１４がキャプチャ地点２３でキャプチャされる。
・その後、時刻Ｔ１７にデータパケットＤ１５がキャプチャ地点２３でキャプチャされる。
図３と４を比較すれば分かるように、図４に逆転範囲２４として示した範囲において、順序逆転が生じている。つまり、図３のように、ＡＣＫパケットＡ１４より前にデータパケットＤ１３とＤ１４が送信されるにもかかわらず、データパケットＤ１３とＤ１４の方がＡＣＫパケットＡ１４より先にキャプチャ地点２３に到達する。
より具体的には、例えば、ポートミラーリング機能を有するスイッチまたはルータが使われる場合、データパケットＤ１３とＤ１４の方が、ＡＣＫパケットＡ１４より先に、スイッチまたはルータのネットワークポートで受信される。あるいは、ネットワークタップが使われる場合、データパケットＤ１３とＤ１４の信号の方が、ＡＣＫパケットＡ１４の信号より先に、ネットワークタップの入力ポートに入力される。それにもかかわらず、図４では、ＡＣＫパケットＡ１４の方がデータパケットＤ１３とＤ１４より先にキャプチャされる。
図４での以上のような順序逆転は、図１の動作例Ｅ２での順序逆転と類似である。つまり、以下の２つの順序逆転は互いに類似している。
・図１の動作例Ｅ２において、時刻Ｔ５にＡＣＫパケットＡ１がキャプチャされ、その後、時刻Ｔ６にデータパケットＤ１がキャプチャされる、という順序逆転。
・図４において、時刻Ｔ１４にＡＣＫパケットＡ１４がキャプチャされ、その後、時刻Ｔ１５とＴ１６にデータパケットＤ１３とＤ１４がキャプチャされる、という順序逆転。
なお、順序逆転のせいでＡＣＫパケットよりも遅れてキャプチャされるデータパケットの個数は、動作例Ｅ２では１個であるが、図４では２個である。しかし、「先に送信された１つ以上のデータパケットの方が、当該１つ以上のデータパケットの受信を通知するＡＣＫパケットより後にキャプチャされる」という点では、図１の動作例Ｅ２と図４の例は共通である。また、動作例Ｅ２における前回データパケットはデータパケットＤ０であり、図４における前回データパケットはデータパケットＤ１２である。
ところで、図１に関して説明したとおり、動作例Ｅ１のようにキャプチャロスと再送が生じる場合と、動作例Ｅ２のように順序逆転が生じる場合を判別するには、コネクション指向の上位層のプロトコルのＰＤＵについてのメタ情報を使うだけでは不十分である。換言すれば、ＴＣＰセグメントについてのメタ情報（例えば、ＴＣＰヘッダ内のシーケンス番号、ＴＣＰヘッダ内のＡＣＫ番号、およびＴＣＰデータ長）を使うだけでは、誤判断が起こり得る。よって、本実施形態では、図１に関して説明したとおり、誤判断の防止のために、コネクションレスな下位層のプロトコルのＰＤＵについてのメタ情報（具体的にはＩＰヘッダ内のＩＤ）が使われる。
以下では、比較例として、キャプチャ地点２３でパケットをキャプチャするパケット解析装置が、ＴＣＰセグメントについてのメタ情報のみを使って解析を行う例について、説明する。図５は、比較例において順序の逆転に起因して起こり得る誤判断について説明する図である。具体的には、図５には、図４のような順序で７つのパケットがキャプチャされた場合に起こり得る誤判断が例示されている。
図５の比較例において、キャプチャ地点２３でパケットをキャプチャするパケット解析装置は、時刻Ｔ１１にデータパケットＤ１１をキャプチャし、時刻Ｔ１２にデータパケットＤ１２をキャプチャし、時刻Ｔ１３にＡＣＫパケットＡ１２をキャプチャする。キャプチャしたＡＣＫパケットＡ１２のＡＣＫ番号に基づいて、パケット解析装置は、「時刻Ｔ１１とＴ１２にキャプチャ済みのデータパケットＤ１１とＤ１２は、ホスト２２により成功裡に受信された」と認識する。つまり、データパケットＤ１１とＤ１２のネットワークロスが生じていないことをパケット解析装置は認識する。以上のような認識は正しい。
その後、パケット解析装置は、時刻Ｔ１４にＡＣＫパケットＡ１４をキャプチャする。ＡＣＫパケットＡ１４のＡＣＫ番号は１２０１である。よって、パケット解析装置は、「ホスト２１と２２の間のコネクション上（より具体的には、ホスト２１からホスト２２へ向かうデータストリーム上）で、１２００という数値で示されるオクテットまでの全データを、ホスト２２が成功裡に受信した」と認識する。この認識自体は正しい。
しかしながら、時刻Ｔ１４より前にパケット解析装置がキャプチャした最後のデータパケットは、データパケットＤ１２である。そして、データパケットＤ１２のシーケンス番号は９０１であり、データパケットＤ１２のＴＣＰデータ長は１００である。つまり、パケット解析装置は、ホスト２１からホスト２２へ向かうデータストリーム上で、１０００（＝９０１＋１００−１）という数値で示されるオクテットまでのデータしか、まだキャプチャしていない。
よって、パケット解析装置は、「１００１と１２００という数値で示される範囲のオクテットに相当する１つ以上のデータパケットが存在したが、当該１つ以上のデータパケットのキャプチャが失敗した」と誤判断する。つまり、パケット解析装置は、「時刻Ｔ１２とＴ１４の間にキャプチャロスが生じた」と誤判断する。
なお、１００１と１２００という数値で示される範囲の長さは２００オクテットである。また、パケット解析装置が今までにキャプチャしたデータパケットＤ１１とＤ１２はいずれも長さが１００オクテットである。よって、パケット解析装置は、例えば、「２（＝２００／１００）個のデータパケットのキャプチャロスが生じた」と推定する。
この推定は間違っている。図５には、こうして間違って推定された２個のデータパケットＬ１１とＬ１２が示されている。
つまり、比較例のパケット解析装置は、「キャプチャロスが生じなければ、時刻Ｔ１２とＴ１４の間にデータパケットＬ１１とＬ１２がキャプチャされたであろう」と誤判断する。パケット解析装置は、必ずしもデータパケットＬ１１とＬ１２の詳細（例えば、それぞれのシーケンス番号とＴＣＰデータ長）を推定する必要はないが、図５には、例として、以下のごときデータパケットＬ１１とＬ１２が例示されている。
・シーケンス番号が１００１であり、ＴＣＰデータ長が１００のデータパケットＬ１１。
・シーケンス番号が１１０１であり、ＴＣＰデータ長が１００のデータパケットＬ１２。
その後、パケット解析装置は、時刻Ｔ１５にデータパケットＤ１３をキャプチャし、時刻Ｔ１６にデータパケットＤ１４をキャプチャする。データパケットＤ１３のシーケンス番号は、データパケットＬ１１と同じく１００１である。また、データパケットＤ１４のシーケンス番号は、データパケットＬ１２と同じく１１０１である。よって、パケット解析装置は、「データパケットＬ１１とＬ１２がそれぞれデータパケットＤ１３とＤ１４として再送された」と誤判断する。
もちろん、パケット解析装置は、単純に、「データパケットＤ１３とＤ１４のシーケンス番号は、いずれも、１００１と１２００という数値で示される範囲内に含まれるから、データパケットＤ１３とＤ１４は再送パケットである」と判断してもよい。しかし、いずれにせよ、パケット解析装置は誤判断を犯す。
以上のような、キャプチャロスについての誤判断や、再送についての誤判断は、解析精度を低下させる要因である。パケット解析のアルゴリズムには様々なものがあり、中には、データパケットの再送を検出すると「ネットワークロスが生じていた」と判断するアルゴリズムもある。例えば、パケット解析のアルゴリズムによっては、比較例のパケット解析装置は、以下のように判断してもよい。
・「１２００という数値で示されるオクテットまでの全データをホスト２２が成功裡に受信した」と示すＡＣＫパケットＡ１４が送信された後に、１２００以下のシーケンス番号を持つデータパケットＤ１３とＤ１４が再送されている。
・このような再送が生じた原因は、ＡＣＫパケットＡ１４が、パケット解析装置にキャプチャされた後、ホスト２１に届く前に、ネットワーク上で消失したからであろう。
例えば以上のように、再送の検出に応じてネットワークロスを検出するタイプのアルゴリズムが利用される場合、図５のような再送についての誤判断は、ネットワークロス数の過大推定（overestimation）を招く。また、ネットワークロス数の過大推定は、コネクション上で送信側のホストから実際に送信されたパケット数の過大推定や、コネクション上で送信側のホストから実際に送信されたトラフィックの量の過大推定を招く。
したがって、図５のような再送についての誤判断は、ネットワークロス率やトラフィック量の推定値の精度劣化を招く。その結果、例えばネットワーク品質の監視のためにパケット解析が行われる場合には、ネットワーク品質の推定値の精度も劣化する。よって、パケット解析の解析精度を高めるためには、図５の比較例で起き得るような誤判断を防止することが望ましい。
ところで、パケット解析のアルゴリズムには様々なものがある。簡易的なアルゴリズムの中には、ホスト２１からホスト２２へ向かう方向のトラフィックと、ホスト２２からホスト２１へ向かう方向のトラフィックを、独立に観察および解析するタイプのアルゴリズムもある。
ここで、図４を参照すると、ホスト２１からホスト２２へ送信される５つのデータパケットＤ１１〜Ｄ１５の間では、キャプチャ順序の逆転は生じていない。また、ホスト２２からホスト２１へ送信される２つのＡＣＫパケットＡ１２とＡ１４の間でも、キャプチャ順序の逆転は生じていない。
よって、２つの方向のトラフィックを独立に観察および解析するタイプの簡易的なアルゴリズムでは、キャプチャ過程でのデータパケットとＡＣＫパケットの間での順序逆転の影響がない。しかしながら、そのような簡易的なアルゴリズムでは、ネットワークロスとキャプチャロスが区別されないし、ネットワークの挙動も大雑把に推測されるだけである。
例えば、データパケットの再送は、元のデータパケットがネットワーク上で消失するのが原因で起こることもある。あるいは、元のデータパケットが成功裡に送信先のホストに受信された後に送信されるＡＣＫパケットが、ネットワーク上で消失するのが原因で、データパケットの再送が起こることもある。
また、再送の具体的なトリガも様々である。例えば、データパケットの送信元のホストが、同一のＡＣＫ番号を有する所定数（例えば３個）のＡＣＫパケットを続けて受信すると、送信元のホストが、当該ＡＣＫ番号をシーケンス番号として含むデータパケットを再送する場合もある。なぜなら、連続する複数のデータパケットのうちの先頭または中途のデータパケットがネットワーク上で消失すると、受信側のホストは、複数のデータパケットのうちの後続のデータパケットを成功裡に受信するたびに、同じＡＣＫ番号を通知するからである。よって、重複ＡＣＫ（duplicate acknowledgement）パケットの受信は、再送のトリガになり得る。
また、「ＲＴＯ（Retransmission Time-Out）」と呼ばれる時間がデータパケットの送信から経過しても、まだＡＣＫパケットが受信されないときに、送信元のホストがデータパケットを再送する場合もある。
したがって、例えば再送に関するネットワークの挙動をより正確に推定するには、データパケットが送られる方向のトラフィックと、ＡＣＫパケットが送られる方向のトラフィックとの間の関連性を考慮に入れることが好ましい。例えば、ネットワークの挙動をより正確に推定するには、ＡＣＫ番号とシーケンス番号の間の関係などを考慮に入れることが好ましい。つまり、パケット解析の目的によっては、２つの方向を独立に解析する簡易的なアルゴリズムでは不十分である。
他方、互いに逆向きの２つの方向を流れるパケット間の関連性を単純素朴に考慮に入れるだけでは、図５に例示したような誤判断を招くおそれがある。図５の誤判断が好ましくないことは、上述したとおりである。
したがって、より正確な解析結果を得るためには（換言すれば、より信頼性の高い解析結果を得るためには）、図１に関して説明したように、キャプチャ過程での順序逆転を検出することが好ましい。なぜなら、キャプチャ過程での順序逆転の検出により、図５のような誤判断が減るからである。
具体的には、図４のような順序で７つのパケットがキャプチャされた場合、本実施形態では、図６のようにしてキャプチャ過程での順序逆転が検出され、誤判断が防止される。なお、図６では参照の便宜のため、パケットのＩＰヘッダ中のＩＤを「ＩＰ−ＩＤ＝９９」のように示している。また、以下では、パケットのＩＰヘッダ中のＩＤを単に「ＩＰ−ＩＤ」と表記することがある。
本実施形態において、キャプチャ地点２３でパケットをキャプチャするパケット解析装置は、パケット解析装置３、ネットワーク監視装置１７ａ、およびネットワーク監視装置１７ｂのいずれであってもよいし、後述のネットワーク監視装置４０であってもよい。図６に関しては、説明の便宜上、パケット解析装置３がキャプチャ地点２３でパケットをキャプチャするものとする。
パケット解析装置３は、時刻Ｔ１１にデータパケットＤ１１をキャプチャし、時刻Ｔ１２にデータパケットＤ１２をキャプチャし、時刻Ｔ１３にＡＣＫパケットＡ１２をキャプチャする。キャプチャしたＡＣＫパケットＡ１２のＡＣＫ番号に基づいて、パケット解析装置３は、「時刻Ｔ１１とＴ１２にキャプチャ済みのデータパケットＤ１１とＤ１２は、ホスト２２により成功裡に受信された」と認識する。つまり、データパケットＤ１１とＤ１２のネットワークロスが生じていないことを、パケット解析装置３は認識する。以上のような認識は正しい。
その後、パケット解析装置３は、時刻Ｔ１４にＡＣＫパケットＡ１４をキャプチャする。ＡＣＫパケットＡ１４のＡＣＫ番号は１２０１である。よって、パケット解析装置３は、「ホスト２１と２２の間のコネクション上（より具体的には、ホスト２１からホスト２２へ向かうデータストリーム上）で、１２００という数値で示されるオクテットまでの全データを、ホスト２２が成功裡に受信した」と認識する。この認識も正しい。
ここで、時刻Ｔ１４より前にパケット解析装置３がキャプチャした最後のデータパケットは、データパケットＤ１２である。そして、データパケットＤ１２のシーケンス番号は９０１であり、データパケットＤ１２のＴＣＰデータ長は１００である。つまり、パケット解析装置３は、ホスト２１からホスト２２へ向かうデータストリーム上で、１０００（＝９０１＋１００−１）という数値で示されるオクテットまでのデータしか、まだキャプチャしていない。
つまり、時刻Ｔ１４でのＡＣＫパケットＡ１４のキャプチャの結果、パケット解析装置３は、「未キャプチャの１つ以上のデータパケットに対するＡＣＫパケットＡ１４がキャプチャされた」と認識する。未キャプチャの１つ以上のデータパケットに対するＡＣＫパケットがキャプチャされた場合、図１から分かるように、キャプチャロスが生じた可能性と、キャプチャ過程での順序逆転が生じた可能性がある。
そこで、パケット解析装置３は、ＡＣＫパケットＡ１４をキャプチャした後の時刻Ｔ１５において、さらにデータパケットＤ１３をキャプチャすると、ＡＣＫパケットＡ１４のＡＣＫ番号とデータパケットＤ１３のシーケンス番号を比較する。
もし、データパケットＤ１３のシーケンス番号が、ＡＣＫパケットＡ１４のＡＣＫ番号以上であれば、パケット解析装置３は、「ＡＣＫパケットＡ１４により受信が通知されたデータパケットの、後続のデータパケットが、キャプチャされた」と判断する。ウィンドウサイズなどの条件によっては、実際にこのように後続のデータパケットがキャプチャされる場合もあり得る。
逆に、データパケットＤ１３のシーケンス番号が、ＡＣＫパケットＡ１４のＡＣＫ番号未満であれば、再送が生じた可能性と、キャプチャ過程での順序逆転が生じた可能性がある。図６の例では、データパケットＤ１３のシーケンス番号は１００１であり、ＡＣＫパケットＡ１２のＡＣＫ番号は１２０１である。つまり、図６の例では、データパケットＤ１３の方が、ホスト２２が次に受信を期待しているデータパケットよりも、コネクション上の順序が早い。
よって、パケット解析装置３は、ＡＣＫパケットＡ１４の後にデータパケットＤ１３をキャプチャすると、再送が生じた可能性と、キャプチャ過程での順序逆転が生じた可能性とを判別するための処理を行う。具体的には、パケット解析装置３は、データパケットＤ１３のＩＰ−ＩＤと、ＡＣＫパケットＡ１４より前にパケット解析装置３がキャプチャしたデータパケットの中では最後にキャプチャされたデータパケットＤ１２のＩＰ−ＩＤとの差を計算する。
図６の例では、データパケットＤ１１、Ｄ１２、Ｄ１３、Ｄ１４、Ｄ１５のＩＰ−ＩＤは、それぞれ、９９、１００、１０１、１０２、１０３である。よって、時刻Ｔ１５にキャプチャされたデータパケットＤ１３のＩＰ−ＩＤと、時刻Ｔ１２にキャプチャされたデータパケットＤ１２のＩＰ−ＩＤの差は、１（＝１０１−１００）である。
パケット解析装置３は、こうして計算した差に基づいて、「時刻Ｔ１５にキャプチャしたデータパケットＤ１３が、ホスト２２での受信がＡＣＫパケットＡ１４によって通知される対象のデータパケットであるのか否か」を判断する。換言すれば、パケット解析装置３は、計算した差に基づいて、「時刻Ｔ１５にキャプチャしたデータパケットＤ１３が、キャプチャ過程での順序逆転のせいでＡＣＫパケットＡ１４よりも遅れてキャプチャされたデータパケットなのか否か」を判断する。
図１に関する説明から分かるように、ＩＰ−ＩＤの差が大きいほど、データパケットＤ１３が再送データパケットである蓋然性が高い。そこで、パケット解析装置３は、具体的には、計算したＩＰ−ＩＤの差を、閾値と比較する。閾値は、具体的には、再送が生じたと仮定した場合に推定されるキャプチャロス数である。この閾値は、例えば以下のようにして決められる。
時刻Ｔ１４よりも前には、パケット解析装置３は、ホスト２１からホスト２２へ向かうデータストリーム上で１０００（＝９０１＋１００−１）という数値で示されるオクテットまでのデータしかキャプチャしていない。しかしＡＣＫパケットＡ１４のＡＣＫ番号は１２０１である。つまり、時刻Ｔ１４では、１００１と１２００という数値で示される範囲の２００オクテットが未キャプチャである。
また、パケット解析装置３は、時刻Ｔ１４までに２個のデータパケット（つまりデータパケットＤ１１とＤ１２）をキャプチャ済みである。これら２個のデータパケットのＴＣＰデータ長の最大値は１００である。
よって、パケット解析装置３は、時刻Ｔ１４において未キャプチャの２００（＝１２０１−（９０１＋１００））オクテットの送信に使われるデータパケットの個数を、少なくとも２（＝ｃｅｉｌ（２００／１００））個である、と推定する。換言すれば、パケット解析装置３は、再送が生じたと仮定した場合に推定されるキャプチャロス数を、２と推定する。なお、ｃｅｉｌ（ｘ）は、引数ｘ以上で引数ｘに最も近い整数とする。
時刻Ｔ１５にキャプチャされたデータパケットＤ１３が、もし真に再送データパケットであるならば、上記のように計算したデータパケットＤ１３とＤ１２のＩＰ−ＩＤの差は、キャプチャロス数の推定値よりも大きい、と想定される。なぜなら、もしデータパケットＤ１３が真に再送データパケットであるならば、少なくとも２個のデータパケットのキャプチャロスが生じている、と想定されるからである。ホスト２１は、それら２個のデータパケット用に２個のＩＰ−ＩＤを消費する。よって、もしデータパケットＤ１３が真に再送データパケットであるならば、上記のように計算したＩＰ−ＩＤの差は、２より大きい、と想定される。
なお、上記段落で「想定される」と述べたのは、実際のキャプチャロス数ではなく、キャプチャロス数の推定値が閾値として使われるためである。キャプチャロス数の推定値が正しければ、想定も正しい。また、図１に関して説明したように、副作用を小さくとどめるために、図６の例では、キャプチャロス数として推定され得る最小値が、閾値として使われる。つまり、副作用を小さくとどめるために、キャプチャロス数の推定値の算出においては、（例えばＴＣＰデータ長の算術平均値等ではなく）ＴＣＰデータ長の最大値が使われる。
図６の例では、上記のとおり、キャプチャロス数の推定値は２であり、この２という値が閾値として使われる。また、図６の例では、上記のとおり、ＩＰ−ＩＤの差は１である。１≦２なので、パケット解析装置３は、「データパケットＤ１３は、キャプチャ過程での順序逆転のせいでＡＣＫパケットＡ１４より遅れてキャプチャされたデータパケットである」と判断する。つまり、パケット解析装置３は、「データパケットＤ１３は再送データパケットではない」と判断する。
パケット解析装置３は、その後の時刻Ｔ１６に、データパケットＤ１４をさらにキャプチャする。データパケットＤ１４のシーケンス番号は１１０１であり、ＡＣＫパケットＡ１４のＡＣＫ番号は１２０１であり、１１０１は１２０１より小さい。よって、時刻Ｔ１６でのデータパケットＤ１４のキャプチャの際にも、パケット解析装置３は、再送が生じた可能性と、キャプチャ過程での順序逆転が生じた可能性とを判別するための処理を行う。
この場合も、パケット解析装置３は、「データパケットＤ１４は、キャプチャ過程での順序逆転のせいでＡＣＫパケットＡ１４より遅れてキャプチャされたデータパケットである」と判断する。例えば、パケット解析装置３は、以下の２つの事項に基づいて、この判断を下してもよい。
・時刻Ｔ１５でのデータパケットＤ１３のキャプチャを契機として、順序逆転が既に検出されている。
・データパケットＤ１４のシーケンス番号は、上記の未キャプチャのオクテット範囲に含まれる。
なお、時刻Ｔ１６にキャプチャされたデータパケットＤ１４のＩＰ−ＩＤと、ＡＣＫパケットＡ１４より前にキャプチャされたデータパケットのうちでは最後にキャプチャされたデータパケットＤ１２のＩＰ−ＩＤの差は、２（＝１０２−１００）である。よって、ＩＰ−ＩＤ間の差が２で、上記の閾値も２であるから、ＩＰ−ＩＤ間の差は閾値以下である。パケット解析装置３は、データパケットＤ１４に関しても、以上のような閾値との比較に基づいて、「データパケットＤ１４は、キャプチャ過程での順序逆転のせいでＡＣＫパケットＡ１４より遅れてキャプチャされたデータパケットである」と判断してもよい。
以上説明した図６の具体例から分かるように、本実施形態によれば、キャプチャ過程での順序逆転が、十分な信頼性をもって検出されるので、再送に関する誤判断が減る。その結果、本実施形態によれば、パケット解析（例えばネットワーク品質の監視のための解析）の精度が向上する。
続いて、図１や図６を参照して説明したような順序逆転の検出を行う装置の詳細について、図７を参照して説明する。図７は、システム構成図である。
図７には、ホスト３１と３２が例示されている。ホスト３１と３２は、いずれもコンピュータである。ホスト３１と３２は、ネットワーク３３を介して接続されている。ネットワーク３３には、ネットワーク装置３４が設けられる。ネットワーク装置３４は、ポートミラーリング機能を有するスイッチまたはルータであってもよいし、ネットワークタップであってもよい。ネットワーク装置３４は少なくとも３つのポート３５〜３７を有する。
ホスト３１は図２のホスト２１と同様であり、ホスト３２は図２のホスト２２と同様である。また、ネットワーク装置３４は図２のネットワーク装置１３ａと同様である。つまり、ポート３５、３６、３７は、それぞれ、図２のポート１４ａ、１５ａ、１６ａと同様である。よって、ホスト３１、ホスト３２、およびネットワーク装置３４についての詳しい説明は省略する。
なお、別の観点から言えば、ホスト３１は図１の第１の装置１に対応し、ホスト３２は第２の装置２に対応し、ポート３５は通過点４に対応し、ポート３６は通過点５に対応する。
ポート３７にはネットワーク監視装置４０が接続される。ネットワーク監視装置４０は、図１のパケット解析装置３に対応し、図２のネットワーク監視装置１７ａにも対応する。
ネットワーク監視装置４０は、通信インタフェイス４１、抽出部４２、管理部４３、検出部４４、出力制御部４５、出力インタフェイス４６、コネクション管理テーブル４７、および解析情報テーブル４８を有する。また、ネットワーク監視装置４０は、出力インタフェイス４６を介して、外部に設けられた出力装置４９と接続される。もちろん、ネットワーク監視装置４０が出力装置４９を内蔵していてもよい。
具体的には、通信インタフェイス４１がネットワーク装置３４のポート３７と接続される。通信インタフェイス４１は、ポート３７からパケットを受信する。
なお、図７の例では、ホスト３１からホスト３２へ送信されるパケットと、ホスト３２からホスト３１へ送信されるパケットは、ネットワーク装置３４の内部で集約され、ポート３７から出力される。このようなネットワーク装置３４内部での集約は、図２のネットワーク装置１３ａ内部での集約と同様である。
一方、図２のネットワーク装置１３ｂとネットワーク監視装置１７ｂの例から分かるように、ネットワーク装置１３ｂ内ではなくネットワーク監視装置１７ｂ内で集約が行われてもよい。つまり、図７のネットワーク監視装置４０の内部で集約が行われるような構成も可能である。具体的には、ネットワーク監視装置４０は、ネットワーク装置の２つのポートからパケットを受信する２つの通信インタフェイス４１と、２つの通信インタフェイス４１が受信したパケットを記憶するための共通のバッファを有してもよい。共通のバッファは、図２のバッファ１８と同様である。
さて、抽出部４２は、通信インタフェイス４１が受信したパケットからヘッダ情報を抽出する。具体的には、抽出部４２は、少なくとも以下の各フィールドの値を抽出する。抽出部４２は、抽出したヘッダ情報を管理部４３に出力する。
・ＩＰヘッダ内の、ＩＨＬ、全長、ＩＤ、送信元ＩＰアドレス、および送信先ＩＰアドレス。
・ＴＣＰヘッダ内の、送信元ポート番号、送信先ポート番号、シーケンス番号、ＡＣＫ番号、ＡＣＫフラグ、ＳＹＮフラグ、ＦＩＮフラグ。
管理部４３は、コネクションに関する情報を管理する。本実施形態では、コネクションに関する情報はコネクション管理テーブル４７に記憶される。つまり、管理部４３は、抽出部４２から出力されるヘッダ情報に基づいて、コネクション管理テーブル４７を更新する。コネクション管理テーブル４７の詳細は、図９とともに後述する。
検出部４４は、キャプチャ過程での順序逆転を検出する。具体的には、検出部４４は、キャプチャロスと再送が発生した場合と、順序逆転が発生した場合とを判別するための処理を実行する。検出部４４は、コネクション管理テーブル４７と、抽出部４２により抽出されたヘッダ情報とを用いて、上記処理を実行する。
さらに、検出部４４は、処理結果に応じて、解析情報テーブル４８を適宜更新する。解析情報テーブル４８の詳細は、図１０とともに後述する。
なお、抽出部４２は、管理部４３だけでなく検出部４４にもヘッダ情報を出力してもよい。あるいは、管理部４３が、抽出部４２から受け取ったヘッダ情報を検出部４４に出力してもよい。管理部４３と検出部４４のより詳しい動作については、図１１〜１４のフローチャートとともに後述する。
出力制御部４５は、解析情報テーブル４８から情報を取得する。そして、出力制御部４５は、パケット解析の結果を出力装置４９に出力するための処理を、取得した情報に基づいて行う。出力装置４９への出力は、例えば、予め決められたスケジュールにしたがって行われてもよいし、図７には示していない入力装置を介してユーザからネットワーク監視装置４０に与えられる命令に応じて行われてもよい。
パケット解析の結果を表すためのフォーマットは実施形態に応じて任意であってよい。例えば、解析情報テーブル４８中の情報そのものがパケット解析の結果の中に含まれていてもよい。また、出力制御部４５が、解析情報テーブル４８から取得した情報に基づいて適宜の計算を行って、計算結果をパケット解析の結果の中に含めてもよい。いずれにせよ、出力制御部４５は、出力インタフェイス４６を制御して、パケット解析の結果を出力装置４９に出力させる。
出力インタフェイス４６は、ネットワーク監視装置４０と出力装置４９との間のインタフェイスである。
例えば、ネットワーク監視装置４０がコンピュータであり、出力装置４９がディスプレイである場合は、出力インタフェイス４６は、コンピュータとディスプレイの間の接続インタフェイス回路と、ディスプレイ用のＶＲＡＭ（Video Random Access Memory）と、ディスプレイドライバにより実現されてもよい。
出力装置４９は、ネットワーク監視装置４０とは別の他のコンピュータ（例えば、ネットワーク３３とは別のネットワークを介してネットワーク監視装置４０に接続されるコンピュータ）であってもよい。この場合、出力インタフェイス４６は、無線ＬＡＮ（Local Area Network）インタフェイス回路または有線ＬＡＮインタフェイス回路により実現されてもよい。
図８は、コンピュータのハードウェア構成図である。図１のパケット解析装置３、図２のネットワーク監視装置１７ａと１７ｂ、および図７のネットワーク監視装置４０は、いずれも、図８に示すようなコンピュータ５０であってもよい。
コンピュータ５０は、ＣＰＵ（Central Processing Unit）５１と、ＲＡＭ（Random Access Memory）５２と、１つ以上の通信インタフェイスを有する。図８には、例として、２つの通信インタフェイス５３ａと５３ｂが例示されている。コンピュータ５０はさらに、入力装置５４と、出力装置５５と、記憶装置５６と、コンピュータ読み取り可能な記憶媒体６０の駆動装置５７を有する。コンピュータ５０のこれらのコンポーネントは、互いにバス５８で接続されている。
ＣＰＵ５１は、シングルコアまたはマルチコアのプロセッサの一例である。コンピュータ５０は、複数のプロセッサを有していてもよい。ＣＰＵ５１はプログラムをＲＡＭ５２にロードし、ＲＡＭ５２をワーキングエリアとしても利用しながら、プログラムを実行する。コンピュータ５０がネットワーク監視装置１７ｂである場合、ＲＡＭ５２は、さらにバッファ１８としても利用される。
通信インタフェイス５３ａと５３ｂの各々は、無線ＬＡＮインタフェイスでもよいが、より確実にパケットをキャプチャする目的のためには、有線ＬＡＮインタフェイスであることが望ましい。コンピュータ５０は、１つ以上の通信インタフェイスを介して、ネットワーク装置１３ａ、１３ｂまたは３７に接続される。
例えば、コンピュータ５０がネットワーク監視装置１７ａである場合、コンピュータ５０は、通信インタフェイス５３ａとケーブルを介してネットワーク装置１３ａのポート１６ａに接続される。
コンピュータ５０がネットワーク監視装置１７ｂである場合、コンピュータ５０は、通信インタフェイス５３ａと５３ｂを介してネットワーク装置１３ｂに接続される。具体的には、通信インタフェイス５３ａがケーブルによりポート１６ｂに接続され、通信インタフェイス５３ｂが別のケーブルによりポート１６ｃに接続される。
コンピュータ５０がネットワーク監視装置４０である場合、コンピュータ５０は、通信インタフェイス５３ａとケーブルを介してネットワーク装置３４のポート３７に接続される。
各通信インタフェイスは、より具体的には、外付けのＮＩＣ（Network Interface Card）でもよいし、オンボード型のネットワークインタフェイスコントローラでもよい。各通信インタフェイスは、物理的なネットワークポートと、物理層の処理を行う「ＰＨＹチップ」と呼ばれる回路と、ＭＡＣ（Media Access Control）副層の処理を行う「ＭＡＣチップ」と呼ばれる回路を含んでいてもよい。
なお、コンピュータ５０は、パケットをキャプチャするためにネットワーク装置１３ａ、１３ｂまたは３４に接続されるだけでなく、さらに他のネットワーク装置（例えばスイッチまたはルータ）に接続されてもよい。コンピュータ５０は、そのような接続のための通信インタフェイス（例えば、無線ＬＡＮインタフェイス、有線ＬＡＮインタフェイス、またはその組み合わせ）を有していてもよい。この場合、コンピュータ５０は、適宜のネットワークから適宜のプログラムをダウンロードすることができる。ダウンロードされたプログラムは、ＣＰＵ５１により実行されてもよい。
入力装置５４は、例えば、キーボード、ポインティングデバイス、またはその組み合わせである。ポインティングデバイスは、例えば、マウスでもよいしタッチパッドでもよいしタッチスクリーンでもよい。
出力装置５５は、ディスプレイ、スピーカ、またはその組み合わせである。ディスプレイはタッチスクリーンであってもよい。なお、図７ではネットワーク監視装置４０の外部に出力装置４９が描かれているが、ネットワーク監視装置４０が出力装置４９を内蔵していてもよい。逆に、図８では入力装置５４と出力装置５５がコンピュータ５０の中に描かれているが、入力装置５４と出力装置５５はコンピュータ５０の外部にあってコンピュータ５０に接続されるのでもよい。
記憶装置５６は、具体的には、１つ以上の不揮発性の記憶装置である。記憶装置５６は、例えば、ＨＤＤ（Hard Disk Drive）でもよいし、ＳＳＤ（Solid-State Drive）でもよいし、両者の組み合わせでもよい。さらにＲＯＭ（Read Only Memory）が記憶装置５６として含まれていてもよい。
記憶媒体６０の例は、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disk）などの光ディスク、光磁気ディスク、磁気ディスク、フラッシュメモリなどの半導体メモリカードなどである。記憶媒体６０の駆動装置５７は、コンピュータ５０の外部にあってコンピュータ５０に接続されるのでもよい。
ＣＰＵ５１が実行するプログラムは、予め記憶装置５６にインストールされていてもよい。あるいは、プログラムは、記憶媒体６０に格納されて提供され、記憶媒体６０から駆動装置５７により読み取られて記憶装置５６にコピーされ、その後、ＲＡＭ５２にロードされてもよい。または、プログラムは、上記のようにダウンロードされてもよい。なお、ＲＡＭ５２、記憶装置５６、および記憶媒体６０は、いずれも、コンピュータ読み取り可能な有形の（tangible）媒体であり、信号搬送波のような一時的な（transitory）媒体ではない。
ところで、図７のネットワーク監視装置４０が図８のコンピュータ５０により実現される場合、通信インタフェイス４１は通信インタフェイス５３ａであってもよい。また、この場合、抽出部４２、管理部４３、検出部４４、および出力制御部４５は、プログラムを実行するＣＰＵ５１により実現されてもよい。コネクション管理テーブル４７と解析情報テーブル４８は、ＲＡＭ５２に記憶されてもよいし、記憶装置５６に記憶されてもよい。なお、出力インタフェイス４６を実現するハードウェアの例については、図７に関して述べたとおりである。
さて、図９は、図７のコネクション管理テーブル４７の例を示す図である。図９には、コネクション管理テーブル４７の例と、コネクション管理テーブル４７中の１つのエントリの内容の変化が例示されている。コネクション管理テーブル４７の各エントリは、以下に説明するような各「サブコネクション」に対応する。
例えば、ホスト３１と３２の間の１つのコネクション上には、ホスト３１からホスト３２へ向かう第１の方向のデータストリームと、ホスト３２からホスト３１へ向かう第２の方向のデータストリームが流れる。管理部４３は、ホスト３１と３２の間の１つのコネクションを、便宜上、第１の方向のサブコネクションと第２の方向サブコネクションに分けて管理する。
第１の方向のサブコネクションは、換言すれば、第１の方向のデータストリーム用のサブコネクションである。ここで、第１の方向に流れるデータパケットに対するＡＣＫパケットは、第２の方向に流れる。よって、以下では説明の便宜上、第１の方向のサブコネクションにとっての第１の方向を「データ方向」といい、第１の方向のサブコネクションにとっての第２の方向を「ＡＣＫ方向」という。
また、第２の方向のサブコネクションは、換言すれば、第２の方向のデータストリーム用のサブコネクションである。ここで、第２の方向に流れるデータパケットに対するＡＣＫパケットは、第１の方向に流れる。よって、第２の方向のサブコネクションにとっては、第２の方向が「データ方向」であり、第１の方向が「ＡＣＫ方向」である。
なお、ホスト３１と３２の間には、複数のコネクションが確立されていてもよい。異なるコネクション同士は、異なるポート番号により識別可能である。
コネクション管理テーブル４７の各エントリは、１つのサブコネクションに対応する。換言すれば、２つのエントリのペアが１つのコネクションに対応する。また、各エントリは以下のフィールドを有する。図９では紙幅の都合上、各フィールドの名称が略称で表されている。
・当該エントリのサブコネクションを識別するための識別情報を表す「コネクションＩＤ」フィールド（図９では「Conn. ID」と示す）。
・当該エントリのサブコネクションにとってのデータ方向の送信側ホストのＩＰアドレスを表す「送信元ＩＰアドレス」フィールド（図９では「Src. IP Addr.」と示す）。
・当該エントリのサブコネクションにとってのデータ方向の送信側ホストのポート番号を表す「送信元ポート番号」フィールド（図９では「Src. Port」と示す）。
・当該エントリのサブコネクションにとってのデータ方向の受信側ホストのＩＰアドレスを表す「送信先ＩＰアドレス」フィールド（図９では「Dst. IP Addr.」と示す）。
・当該エントリのサブコネクションにとってのデータ方向の受信側ホストのポート番号を表す「送信先ポート番号」フィールド（図９では「Dst. Port」と示す）。
・当該エントリのサブコネクションにとってのデータ方向で今までに送信されてキャプチャされたデータパケットの中で最大のシーケンス番号を表す「最大シーケンス番号」フィールド（図９では「Max. Seq.」と示す）。
・当該エントリのサブコネクションにとってのＡＣＫ方向で次に送られるＡＣＫパケットのＡＣＫ番号として期待される最小値を表す「ＡＣＫ期待値」フィールド（図９では「Exp. Ack.」と示す）。
・当該エントリのサブコネクションにとってのＡＣＫ方向で今までに送信されてキャプチャされたＡＣＫパケットの中で最大のＡＣＫ番号を表す「最大ＡＣＫ番号」フィールド（図９では「Max. Ack.」と示す）。
・当該エントリのサブコネクションにとってのデータ方向で今までに送信されてキャプチャされたデータパケットの中で最大のＴＣＰデータ長を表す「最大長さ」フィールド（図９では「Max. Len.」と示す）。
・当該エントリのサブコネクション上を流れるデータストリーム中のオクテットのうち、キャプチャに失敗した可能性がある、と暫定的に判断されたオクテットの範囲を表す「暫定キャプチャロス範囲」フィールド（図９では「Prov. Loss」と示す）。
・当該エントリのサブコネクション上でデータ方向とＡＣＫ方向にそれぞれ送信されるデータパケットとＡＣＫパケットの間で、キャプチャ順序の逆転が生じている範囲を表す「逆転範囲」フィールド（図９では「Inv. Range」と示す）。
・当該エントリのサブコネクションにとってのデータ方向で最も遅くにキャプチャされたデータパケットのＩＰヘッダ中のＩＤを表す「ＩＰ−ＩＤ」フィールド（図９では「IP-ID」と示す）。
例えば、ホスト３１のＩＰアドレスが「１０．２５．１．３」であり、ホスト３２のＩＰアドレスが「１０．２５．１．２００」であるとする。そして、ホスト３１の１５０１番ポートとホスト３２の２０番ポートの間にコネクションが確立されているとする。図９のコネクション管理テーブル４７の１番目のエントリは、以上のようなコネクションの２つのサブコネクションのうち、ホスト３１からホスト３２へ向かう方向のサブコネクションに対応する。また、２番目のエントリは、逆方向（つまりホスト３２からホスト３１へ向かう方向）のサブコネクションに対応する。
１番目のエントリに対応するサブコネクションのコネクションＩＤは、図９によれば「１−１」である。また、２番目のエントリに対応するサブコネクションのコネクションＩＤは、図９によれば「１−２」である。
ところで、ホスト３１とホスト３２の間では、複数のコネクションが確立され得る。つまり、ホスト３１が１５０１番以外のポートを使い、かつ／または、ホスト３２が２０番以外のポートを使うことで、ホスト３１と３２の間に別のコネクションが確立されてもよい。コネクション管理テーブル４７は、ホスト３１と３２の間のコネクションごとに、当該コネクションの２つのサブコネクションに対応する２つのエントリを有する。
また、図７には、ネットワーク装置３４の３つのポートのみが図示されているが、ネットワーク装置３４は、より多くのポートを有していてもよい。ネットワーク装置３４が有する不図示の各ポートには、直接的または間接的に不図示のホストが接続されていてもよい。そして、さらに以下のようなパケットが、ポート３７を介してネットワーク監視装置４０に出力されてもよい。すなわち、ネットワーク監視装置４０は以下のようなパケットをさらにキャプチャしてもよい。
・ネットワーク装置３４の不図示の２つのポートに接続される不図示の２台のホスト間のコネクション上で送受信されるパケット。
・ネットワーク装置３４の不図示の１つのポートに接続される不図示の１台のホストと、ホスト３１との間のコネクション上で送受信されるパケット。
・ネットワーク装置３４の不図示の１つのポートに接続される不図示の１台のホストと、ホスト３２との間のコネクション上で送受信されるパケット。
例えば、ＩＰアドレスが「１０．２５．１．１６」のホストと、ＩＰアドレスが「１０．２５．１．２１０」のホストが、ネットワーク装置３４にさらに接続されていてもよい。そして、前者のホストの３００番ポートと後者のホストの４５番ポートの間にコネクションが確立されていてもよい。図９のコネクション管理テーブル４７の３番目のエントリは、以上のようなコネクションの２つのサブコネクションのうち、前者のホストから後者のホストへ向かう方向のサブコネクションに対応する。また、４番目のエントリは、逆方向のサブコネクションに対応する。
３番目のエントリに対応するサブコネクションのコネクションＩＤは、図９によれば「２−１」である。また、４番目のエントリに対応するサブコネクションのコネクションＩＤは、図９によれば「２−２」である。
なお、図９には、図４および６に示す時刻Ｔ１２〜Ｔ１６それぞれにおけるパケットの受信に応じて更新されたコネクション管理テーブル４７が、コネクション管理テーブル４７ａ〜４７ｅとして例示されている。具体的には、図９には、コネクションＩＤが「１−１」のエントリの変遷が例示されている。コネクション管理テーブル４７ａ〜４７ｅの具体例については、図１１〜１４のフローチャートとともに後述する。
さて、図１０は、図７の解析情報テーブル４８の例を示す図である。解析情報テーブル４８の各エントリも、１つのサブコネクションに対応する。解析情報テーブル４８の各エントリは、以下のフィールドを有する。
・当該エントリのサブコネクションを識別するための識別情報を表す「コネクションＩＤ」フィールド。
・当該エントリのサブコネクションにとってのデータ方向で今までに送信されたと推定されるデータパケットの数を表す「パケット数」フィールド。
・当該エントリのサブコネクションにとってのデータ方向で今までに再送されたと推定されるデータパケットの数を表す「再送数」フィールド。
・当該エントリのサブコネクション上をデータ方向に流れるデータパケットに関して今までに生じたと推定されるキャプチャロスの回数を表す「キャプチャロス数」フィールド。
・当該エントリのサブコネクション上でデータ方向とＡＣＫ方向にそれぞれ送信されるデータパケットとＡＣＫパケットの間で、今までに生じたと推定される、キャプチャ順序の逆転の回数を表す「複製時逆転数」フィールド。
例えば、図１０によれば、「１−１」というコネクションＩＤで識別されるサブコネクションに関する１番目のエントリは、以下のことを示す。
・当該サブコネクション上で今までに１３個のデータパケットがデータ方向に送信された、と推定される。
・当該サブコネクション上で今までにデータパケットの再送が３回生じた、と推定される。
・当該サブコネクション上をデータ方向に流れるデータパケットに関しては、今までにキャプチャロスは１回も生じていない、と推定される。
・当該サブコネクション上で送信されるデータパケットとＡＣＫパケットの間でのキャプチャ順序の逆転が、今までに１回生じた、と推定される。
なお、ネットワーク監視装置４０は、サブコネクションごとのエントリを有する上記のごとき解析情報テーブル４８の代わりに、コネクションごとのエントリを有する解析情報テーブル４８ｂを有してもよい。解析情報テーブル４８ｂにおける１つのエントリは、対になる２つのサブコネクションに対応する解析情報テーブル４８の２つのエントリを集約したものである。解析情報テーブル４８ｂの形式は解析情報テーブル４８と同じである。
例えば、解析情報テーブル４８において「１−１」と「１−２」というコネクションＩＤを持つ２つのエントリには、２つのサブコネクションが対応する。これら２つのサブコネクションを含むコネクションは、解析情報テーブル４８ｂでは、「１」というコネクションＩＤにより識別される。
例えば、解析情報テーブル４８において「１−１」と「１−２」というコネクションＩＤを持つ２つのエントリの複製時逆転数の和は３（＝１＋２）である。この３という数値が、解析情報テーブル４８ｂにおいて「１」というコネクションＩＤを持つエントリの複製時逆転数として記憶される。他のフィールドについても同様に、解析情報テーブル４８において対になる２つのエントリの値が、解析情報テーブル４８の１つのエントリに集約される。
続いて、図７のネットワーク監視装置４０が行う処理について、図１１〜１４のフローチャートを参照して説明する。通信インタフェイス４１がネットワーク装置３４のポート３７に接続され、ネットワーク監視装置４０に電源が入れられると、ネットワーク監視装置４０は図１１〜１４の処理を開始することができる。なお、以下では図１１〜１４の各ステップについて先に説明し、その後、図６および図９に示した具体例と図１１〜１４の処理の関係について説明する。
ステップＳ１０１でネットワーク監視装置４０は、ポート３７から出力されるパケットを通信インタフェイス４１が受信（つまりキャプチャ）するまで待つ。なお、以下では説明の便宜上、ステップＳ１０１で通信インタフェイス４１が受信したパケットを「対象パケット」ともいう。
通信インタフェイス４１がパケットを受信（つまりキャプチャ）すると、抽出部４２は、受信されたパケットからヘッダ情報を抽出し、抽出したヘッダ情報を出力する。ヘッダ情報は、具体的には以下の各フィールドの値を含む。もちろん、抽出部４２はＩＰヘッダとＴＣＰヘッダ中の他のフィールドの値を、ヘッダ情報にさらに含めてもよい。
・ＩＰヘッダ内の、ＩＨＬ、全長、ＩＤ、送信元ＩＰアドレス、および送信先ＩＰアドレス。
・ＴＣＰヘッダ内の、送信元ポート番号、送信先ポート番号、シーケンス番号、ＡＣＫ番号、ＡＣＫフラグ、ＳＹＮフラグ、ＦＩＮフラグ。
こうして抽出される、送信元ＩＰアドレスと、送信元ポート番号と、送信先ＩＰアドレスと、送信先ポート番号との組み合わせにより、「対象パケットはどのコネクション上を流れてきてキャプチャされたのか」ということが識別可能である。
なお、通信インタフェイス４１内のバッファがオーバフローしている場合などには、パケットがポート３７から出力されるにもかかわらず、通信インタフェイス４１がパケットの受信（つまりキャプチャ）に失敗することがあり得る。このように通信インタフェイス４１においてキャプチャロスが生じる場合には、パケットは正常に受信されない。よって、通信インタフェイス４１においてキャプチャロスが生じる場合には、ネットワーク監視装置４０は、次に別のパケットが成功裡に通信インタフェイス４１によりキャプチャされるまで、ステップＳ１０１で待つ。
次に、ステップＳ１０２で管理部４３は、以下の２つの条件のうちのいずれかが成立するか否かを、抽出されたヘッダ情報に基づいて判断する。
・対象パケットの送信に使われているコネクションについての情報が、コネクション管理テーブル４７にはまだ登録されていない。
・対象パケットは、コネクションを解放しようとする（つまりクローズしようとする）ためのパケットである。
具体的には、管理部４３は、対象パケットの送信に使われているコネクションに対応する２つのエントリをコネクション管理テーブル４７において検索する。検索キーとして、対象パケットの送信に使われているコネクションを識別する情報（つまり、対象パケットの送信元ＩＰアドレスと、送信元ポート番号と、送信先ＩＰアドレスと、送信先ポート番号）が使われる。
検索の結果、対象パケットの送信に使われているコネクションに対応する２つのエントリが見つかれば、対象パケットの送信に使われているコネクションについての情報はコネクション管理テーブル４７に登録済みである。逆に、エントリが見つからなければ、対象パケットの送信に使われているコネクションについての情報はコネクション管理テーブル４７にまだ登録されていない。
また、管理部４３は、対象パケットのＦＩＮフラグの値が１ならば、「対象パケットは、コネクションを解放しようとするためのパケットである」と判断する。管理部４３は、かつてキャプチャされたＦＩＮパケットに対するＡＣＫパケットが今回ステップＳ１０１でキャプチャされた場合にも、「対象パケットは、コネクションを解放しようとするためのパケットである」と判断する。
例えば、コネクション管理テーブル４７には、コネクションの確立と解放に関する状態を示すためのフィールドがさらに含まれていてもよい。管理部４３は、そのようなフィールドを参照することにより、「かつてキャプチャされたＦＩＮパケットに対するＡＣＫパケットが今回ステップＳ１０１でキャプチャされたのか否か」を判断してもよい。もちろん、そのようなコネクション管理テーブル４７中のフィールドの代わりに、新たに確立されようとしているコネクションに関する情報と、解放されようとしている確立済みのコネクションに関する情報を記憶するための一時的な記憶領域が使われてもよい。
上記の２つの条件のうちのいずれかが成立する場合、コネクション管理テーブル４７へのエントリの追加、または、コネクション管理テーブル４７からのエントリの削除が生じ得る。よって、上記のいずれかの条件が成立する場合、管理部４３は、ステップＳ１０２の次にステップＳ１０３の判断を行う。
逆に、上記の２つの条件がいずれも成立しない場合とは、コネクション管理テーブル４７に登録済みの既存の２つのエントリに対応するコネクション上を流れるパケットが、今回キャプチャされた場合である。よって、上記の２つの条件がいずれも成立しない場合、検出部４４がステップＳ１０９以降の処理を行う。
さて、ステップＳ１０３で管理部４３は、「対象パケットが、コネクション管理テーブル４７には未登録のコネクション上を流れる通常のパケット（例えば、データパケットや、データパケットに対するＡＣＫパケットなど）であるか否か」を判断する。
例えば、ホスト３１と３２の間にコネクションが確立した後で、ネットワーク監視装置４０がポート３７に接続され、ネットワーク監視装置４０が図１１〜１４の処理を開始することがあり得る。このような場合、ネットワーク監視装置４０は、ＳＹＮパケット等のコネクション確立用のパケットをキャプチャする前に、通常のパケットをキャプチャする可能性がある。
具体的には、管理部４３は、「対象パケットの送信に使われているコネクションについての情報はコネクション管理テーブル４７に未登録」とステップＳ１０２で判断した場合、ステップＳ１０３で対象パケットのＳＹＮフラグを参照する。ＳＹＮフラグの値が１ならば、管理部４３は、「対象パケットは通常のパケットではない」と判断する。また、たとえ対象パケットのＳＹＮフラグの値が０であっても、対象パケットが、かつてキャプチャされたＳＹＮ／ＡＣＫパケットに対するＡＣＫパケットである場合には、管理部４３は、「対象パケットは通常のパケットではない」と判断する。
例えば、上記のように、コネクション管理テーブル４７には、コネクションの確立と解放に関する状態を示すための不図示のフィールドがあってもよい。管理部４３は、そのようなフィールド（または上記のような一時的な記憶領域）を参照することにより、「対象パケットが、かつてキャプチャされたＳＹＮ／ＡＣＫパケットに対するＡＣＫパケットであるのか否か」を判断してもよい。
以上のような処理の結果、管理部４３が対象パケットを「コネクション管理テーブル４７には未登録のコネクション上を流れる通常のパケットである」と判断した場合は、管理部４３は次にステップＳ１０４の処理を行う。
逆に、管理部４３が対象パケットを「コネクション管理テーブル４７には未登録のコネクション上を流れる通常のパケットではない」と判断した場合は、管理部４３は次にステップＳ１０５の処理を行う。なお、管理部４３が「対象パケットは、コネクションを解放しようとするためのパケットである」とステップＳ１０２で判断した場合も、管理部４３は、ステップＳ１０３の次にステップＳ１０５の処理を行う。
ステップＳ１０４で管理部４３は、対象パケットの送信に使われている未登録のコネクションに関する情報を、コネクション管理テーブル４７に登録する。具体的には、管理部４３は、対象パケットの送信に使われている未登録のコネクションの２つのサブコネクションに対応する、２つの新たなコネクションＩＤを発行する。そして、管理部４３は、上記２つのサブコネクションに対応する、２つの新たなエントリをコネクション管理テーブル４７に追加する。管理部４３は、２つの新たなエントリの各々において、上記のように発行した値をコネクションＩＤとして設定する。
また、管理部４３は、２つの新たなエントリのうちの一方の送信元ＩＰアドレス、送信元ポート番号、送信先ＩＰアドレス、および送信先ポート番号のフィールドには、対象パケットから抽出された値を設定する。管理部４３は、他方のエントリでは、送信元ＩＰアドレスと送信元ポート番号として対象パケットの送信先ＩＰアドレスと送信先ポート番号を設定し、送信先ＩＰアドレスと送信先ポート番号として対象パケットの送信元ＩＰアドレスと送信元ポート番号を設定する。
管理部４３は、対象パケットのヘッダ情報に基づいて、コネクション管理テーブル４７の他のフィールドに、適宜のダミー値をさらに設定することが好ましい。
例えば、対象パケットのＴＣＰデータ長が０より大きい場合、管理部４３は、以下のようなダミー値を設定してもよい。以下のダミー値は、後述のステップと整合性のとれる適宜のダミー値の例である。
・対象パケットが流れる方向をデータ方向とするサブコネクションのエントリのＩＰ−ＩＤフィールドのダミー値として、対象パケットのＩＰ−ＩＤから１を引いた値を設定する。
・対象パケットが流れる方向をデータ方向とするサブコネクションのエントリの最大シーケンス番号フィールドのダミー値として、対象パケットのシーケンス番号から適宜の数を引いた値を設定する。
ステップＳ１０４でのコネクション管理テーブル４７への２つのエントリの追加の後、図１１〜１４の処理はステップＳ１０９へと移行する。
さて、ステップＳ１０５で管理部４３は、対象パケットがコネクション確立用のパケットであるか否かを判断する。具体的には、管理部４３は、対象パケットのＳＹＮフラグを参照する。ＳＹＮフラグの値が１ならば、管理部４３は、「対象パケットは、ＳＹＮパケットまたはＳＹＮ／ＡＣＫパケットであるから、コネクション確立用のパケットである」と判断する。また、たとえ対象パケットのＳＹＮフラグの値が０であっても、対象パケットが、かつてキャプチャされたＳＹＮ／ＡＣＫパケットに対するＡＣＫパケットである場合には、管理部４３は、「対象パケットはコネクション確立用のパケットである」と判断する。
例えば、上記のように、コネクション管理テーブル４７には、コネクションの確立と解放に関する状態を示すための不図示のフィールドがあってもよい。管理部４３は、そのようなフィールド（または上記のような一時的な記憶領域）を参照することにより、「対象パケットが、かつてキャプチャされたＳＹＮ／ＡＣＫパケットに対するＡＣＫパケットであるのか否か」を判断してもよい。
以上のような処理の結果、管理部４３が対象パケットを「コネクション確立用のパケットである」と判断した場合には、管理部４３は次にステップＳ１０６の処理を行う。逆に、管理部４３が対象パケットを「コネクション確立用のパケットではない」と判断した場合には、管理部４３は次にステップＳ１０７の処理を行う。
ステップＳ１０６で管理部４３は、新たなコネクションに関する情報をコネクション管理テーブル４７に登録するための処理を行う。
具体的には、対象パケットがＳＹＮパケットの場合、管理部４３は、新たに確立されようとしているコネクションの２つのサブコネクションに対応する、２つの新たなコネクションＩＤを発行し、２つの新たなエントリをコネクション管理テーブル４７に追加する。これら２つのエントリの追加はステップＳ１０４における追加と同様である。
管理部４３は、ＳＹＮパケットに指定されているＩＳＮ（Initial Sequence Number）に応じた適宜のダミー値を、新規エントリ中のフィールドに設定してもよい。例えば、ＳＹＮパケットが送信される方向をデータ方向とするサブコネクションのエントリの最大シーケンス番号のダミー値として、ＩＳＮから１を引いた値が設定されてもよい。
また、対象パケットがＳＹＮ／ＡＣＫパケットの場合、管理部４３は、新たに確立されようとしているコネクションに関してかつてＳＹＮパケットが受信された際に追加された２つのエントリを、適宜更新する。例えば、上記のようにコネクション管理テーブル４７には、コネクションの確立と解放に関する状態を示すための不図示のフィールドがあってもよく、管理部４３は当該フィールドを更新してもよい。また、管理部４３は、例えば、ＳＹＮ／ＡＣＫパケットに指定されているＩＳＮから１を引いた値を、ＳＹＮ／ＡＣＫパケットが送信される方向をデータ方向とするサブコネクションのエントリの最大シーケンス番号のダミー値として、設定してもよい。
あるいは、対象パケットが、かつてキャプチャされたＳＹＮ／ＡＣＫパケットに対するＡＣＫパケットの場合、管理部４３は、新たに確立されようとしているコネクションに関してかつてＳＹＮパケットが受信された際に追加された２つのエントリを、適宜更新する。例えば、管理部４３は、コネクションの確立と解放に関する状態を示すための不図示のフィールドを更新してもよい。
ステップＳ１０６におけるコネクション管理テーブル４７の更新が完了すると、図１１〜１４の処理はステップＳ１０１に戻る。
なお、上記の説明では、コネクションの確立と解放に関する状態を示すための不図示のフィールドがコネクション管理テーブル４７に含まれる場合を例としたが、そのようなフィールドの代わりに、一時的な記憶領域が使われてもよい。例えば、管理部４３は、対象パケットがＳＹＮパケットの場合と、対象パケットがＳＹＮ／ＡＣＫパケットの場合には、ステップＳ１０６では、新規コネクションの２つのサブコネクションに関する情報を一時的な記憶領域に記憶するだけでもよい。そして、対象パケットが、かつてキャプチャされたＳＹＮ／ＡＣＫパケットに対するＡＣＫパケットである場合に、管理部４３は、上記の一時的な記憶領域を参照して、コネクション管理テーブル４７に新規エントリを２つ追加してもよい。
さて、ステップＳ１０７で管理部４３は、「対象パケットは、コネクションを解放する（つまりクローズする）ためのパケットであるか否か」を判断する。具体的には、管理部４３は、対象パケットのＦＩＮフラグを参照する。ＦＩＮフラグの値が１ならば、管理部４３は、「対象パケットは、コネクション解放用のパケットである」と判断する。
また、かつてキャプチャされたＦＩＮパケットに対するＡＣＫパケットが今回ステップＳ１０１でキャプチャされた場合にも、管理部４３は、「対象パケットはコネクション解放用のパケットである」と判断する。例えば、管理部４３は、コネクションの確立と解放に関する状態を示すための、コネクション管理テーブル４７中の不図示のフィールド、または、コネクションの確立と解放に関する情報を記憶するための一時的な記憶領域を参照してもよい。それにより、管理部４３は、「対象パケットが、かつてキャプチャされたＦＩＮパケットに対するＡＣＫパケットであるのか否か」を判断してもよい。
以上のような処理の結果、管理部４３が対象パケットを「コネクション解放用のパケットである」と判断した場合には、管理部４３は次にステップＳ１０８の処理を行う。逆に、管理部４３が対象パケットを「コネクション解放用のパケットではない」と判断した場合には、図１１〜１４の処理はステップＳ１０１へと戻る。
なお、何らかのエラーが生じない限り、ステップＳ１０７で管理部４３が対象パケットを「コネクション解放用のパケットではない」と判断することはない。よって、ステップＳ１０７で管理部４３が対象パケットを「コネクション解放用のパケットではない」と判断した場合、不図示の適宜のエラー処理が、ステップＳ１０７とＳ１０１の間に行われてもよい。
ステップＳ１０８で管理部４３は、解放されようとしているコネクションに関する情報をコネクション管理テーブル４７から削除するための処理を行う。
具体的には、対象パケットがＦＩＮパケットの場合、管理部４３は、ＦＩＮパケットが送信される方向をデータ方向とするサブコネクションの状態を示す情報を更新する。なお、上記のとおり、状態を示す情報は、例えば、コネクション管理テーブル４７中の不図示のフィールドに記憶されてもよいし、一時的な記憶領域に記憶されてもよい。状態を示す情報の更新は、コネクション管理テーブル４７からのエントリの削除を準備する処理であるから、削除のための処理の一種である。また、対象パケットが、かつてキャプチャされたＦＩＮパケットに対するＡＣＫパケットの場合、管理部４３は、当該ＡＣＫパケットが送信される方向をＡＣＫ方向とするサブコネクションのエントリを、コネクション管理テーブル４７から削除する。
ステップＳ１０８の完了後、図１１〜１４の処理はステップＳ１０１に戻る。
さて、ステップＳ１０９は、確立済みのコネクション上で送信されるデータパケットまたはＡＣＫパケットが、ステップＳ１０１で受信（つまりキャプチャ）された場合に実行される。ステップＳ１０２における検索の結果として、または、ステップＳ１０４における登録の結果として、ステップＳ１０９の実行時には、対象パケットの送信に使われるコネクションに関する、コネクション管理テーブル４７の２つのエントリが既に特定されている。そこで、ステップＳ１０９で検出部４４は、コネクションとサブコネクションを選択する。
具体的には、対象パケットの送信元ＩＰアドレス、送信元ポート番号、送信先ＩＰアドレス、および送信先ポート番号は、抽出部４２から直接検出部４４へ出力されてもよいし、抽出部４２から管理部４３を介して検出部４４へ出力されてもよい。いずれにせよ、検出部４４は、対象パケットの送信元ＩＰアドレス、送信元ポート番号、送信先ＩＰアドレス、および送信先ポート番号に基づき、対象パケットの送信に使われるコネクションを認識することができる。よって、検出部４４は認識したコネクションを選択する。
また、選択されたコネクションは２つのサブコネクションを含む。ステップＳ１０９で検出部４４は、２つのサブコネクションのうちの一方を選択する。なお、他方のコネクションは後述のステップＳ１２３で選択される。検出部４４は、どちらのサブコネクションを先にステップＳ１０９で選択してもよい。
以下、ステップＳ１０９で選択されたコネクションを「選択コネクション」ともいう。そして、ステップＳ１０９またはＳ１２３で選択されたサブコネクションを「選択サブコネクション」ともいう。
ステップＳ１０９での選択の後、ステップＳ１１０で検出部４４は、対象パケットが送信される方向が、選択サブコネクションにとってのデータ方向であるのか、それとも、選択サブコネクションにとってのＡＣＫ方向であるのかを判断する。検出部４４は、対象パケットの送信元ＩＰアドレスと送信先ＩＰアドレスを、コネクション管理テーブル４７における選択サブコネクションのエントリの送信元ＩＰアドレスと送信先ＩＰアドレスと比較することで、ステップＳ１１０の判断を行ってもよい。
対象パケットが送信される方向が、選択サブコネクションにとってのデータ方向である場合、検出部４４は次に図１２のステップＳ１１１の判断を行う。逆に、対象パケットが送信される方向が、選択サブコネクションにとってのＡＣＫ方向である場合、検出部４４は次に図１４のステップＳ１２４の判断を行う。
さて、ステップＳ１１１で検出部４４は、対象パケットがデータを含むか否かを判断する。具体的には、検出部４４は、ＩＰヘッダ中の全長フィールドと、ＩＰヘッダ中のＩＨＬフィールドと、ＴＣＰヘッダ中のデータオフセットから、対象パケットのＴＣＰデータ長を算出する。ＴＣＰデータ長が０の場合、対象パケットはデータを含まず、ＴＣＰデータ長が正の場合、対象パケットはデータを含む。
対象パケットがデータを含む場合（つまり、選択サブコネクションのデータ方向に送信されるデータパケットが、ステップＳ１０１で対象パケットとしてキャプチャされた場合）、検出部４４は図１０の解析情報テーブル４８のパケット数フィールドを更新し、次にステップＳ１１２の判断を行う。逆に、対象パケットがデータを含まない場合、検出部４４は次に図１３のステップＳ１２２の判断を行う。
解析情報テーブル４８のパケット数フィールドの更新は、具体的には以下のように行われる。検出部４４は、解析情報テーブル４８において選択サブコネクションのコネクションＩＤを有するエントリを検索する。そして、検出部４４は、見つかったエントリのパケット数フィールドの値を、１だけインクリメントする。
実施形態によっては、解析情報テーブル４８の代わりに解析情報テーブル４８ｂが使われてもよい。この場合、検出部４４は、解析情報テーブル４８ｂにおいて選択コネクションのコネクションＩＤを有するエントリを検索する。そして、検出部４４は、見つかったエントリのパケット数フィールドの値を、１だけインクリメントする。図１０の例では、任意のｊについて、「ｊ−１」と「ｊ−２」というコネクションＩＤで識別される２つのサブコネクションを含むコネクションが、「ｊ」というコネクションＩＤで識別されている。
なお、選択サブコネクションのデータ方向は、選択サブコネクションとは逆方向のサブコネクションにとってのＡＣＫ方向であることに注意されたい。つまり、選択サブコネクションとは逆方向のサブコネクション上を流れるデータストリームに関するＡＣＫパケットは、選択サブコネクションのデータ方向に送信される。
具体的には、対象パケットが、そのようなＡＣＫパケットであり、かつピギーバック（piggy-back）されていないＡＣＫパケットである場合に、ステップＳ１１１で「対象パケットがデータを含まない」と判断される。この場合、次に後述の図１３のステップＳ１２２が実行される。
さて、ステップＳ１１２で検出部４４は、対象パケットのＴＣＰヘッダ中のシーケンス番号と、コネクション管理テーブル４７における選択サブコネクションのエントリの最大ＡＣＫ番号を比較する。シーケンス番号が最大ＡＣＫ番号未満の場合（例えば、図４および図６の時刻Ｔ１５で、データパケットＤ１３が対象パケットとしてキャプチャされた場合など）、次の２つの可能性がある。
・対象パケットが、再送されたデータパケットである可能性。
・対象パケットが、キャプチャ過程での順序逆転のせいで、ＡＣＫパケットよりも遅れてキャプチャされたデータパケットである可能性。
よって、シーケンス番号が最大ＡＣＫ番号未満の場合、検出部４４は、２つの可能性を判別するために、次にステップＳ１１３の判断を行う。逆に、シーケンス番号が最大ＡＣＫ番号以上の場合、検出部４４は、キャプチャ過程でのデータパケットとＡＣＫパケットの間の順序逆転の可能性を考慮する必要がない。よって、シーケンス番号が最大ＡＣＫ番号以上の場合（例えば、図６の時刻Ｔ１７でデータパケットＤ１５が対象パケットとしてキャプチャされた場合など）、検出部４４は次に図１３のステップＳ１１９の判断を行う。
さて、ステップＳ１１３で検出部４４は、コネクション管理テーブル４７における選択サブコネクションのエントリの、逆転範囲フィールドを参照する。そして、検出部４４は、対象パケット（すなわち、選択サブコネクションのデータ方向に送信されるデータパケット）のシーケンス番号が、逆転範囲外か否かを判断する。
逆転範囲フィールドが空であれば、対象パケットのシーケンス番号は逆転範囲外である。あるいは、逆転範囲フィールドに「ＳＮ１以上ＳＮ２未満」という範囲が記憶されている場合があり得る。この場合、対象パケットのシーケンス番号がＳＮ１未満またはＳＮ２以上ならば、対象パケットのシーケンス番号は、逆転範囲外である。逆に、対象パケットのシーケンス番号がＳＮ１以上かつＳＮ２未満ならば、対象パケットのシーケンス番号は、逆転範囲内である。
例えば、図６の時刻Ｔ１４にＡＣＫパケットＡ１４がキャプチャされた場合、逆転範囲２４には２つのデータパケットＤ１３とＤ１４が含まれる。このように、２つ以上のデータパケットがキャプチャされるよりも先に、それら２つ以上のデータパケットの受信を通知するためのＡＣＫパケットがキャプチャされる場合があり得る。
この場合、２つ以上のデータパケットのうちの最初の１つがキャプチャされた際に、再送と順序逆転の判別が行われる。そして、順序逆転と判断された場合には、順序逆転のせいでＡＣＫパケットより遅れてキャプチャされる可能性のある２つ目以降のデータパケットのシーケンス番号の範囲が、逆転範囲フィールドに記録される（詳しくは後述のステップＳ１１７〜Ｓ１１８を参照）。
よって、ＡＣＫパケットより遅れてキャプチャされる２つ以上のデータパケットのうちの、２つ目以降のいずれかのデータパケットがステップＳ１０１でキャプチャされると、ステップＳ１１３では、「対象パケットのシーケンス番号は逆転範囲内」と判断される。なお、逆転範囲の上限のシーケンス番号ＳＮ２は、先にキャプチャされたＡＣＫパケットのＡＣＫ番号により規定される。よって、図９とともに後述する具体例からも明らかなように、例えば図６のデータパケットＤ１５のように逆転範囲２４の後に正常にキャプチャされる後続のデータパケットに関しては、ステップＳ１１３で「逆転範囲外」と判断される。
対象パケットのシーケンス番号が逆転範囲内の場合は、「再送ではなく順序逆転が生じた」という判断が既になされている。よって、この場合、検出部４４は、次に、検出済みの順序逆転に関する処理をステップＳ１１８で行う。
逆に、対象パケットのシーケンス番号が逆転範囲外の場合は、順序逆転はまだ検出されていない。そこで、検出部４４は、順序逆転の可能性について検討するため、次にステップＳ１１４の処理を行う。
具体的には、ステップＳ１１４で検出部４４は、コネクション管理テーブル４７における選択サブコネクションのエントリの、暫定キャプチャロス範囲フィールドを参照する。そして、検出部４４は、対象パケット（すなわち、選択サブコネクションのデータ方向に送信されるデータパケット）のシーケンス番号が、暫定キャプチャロス範囲内か否かを判断する。
暫定キャプチャロス範囲フィールドが空であれば、対象パケットのシーケンス番号は暫定キャプチャロス範囲外である。
あるいは、暫定キャプチャロス範囲フィールドに「ＳＮ１以上ＳＮ２未満」という範囲が記憶されている場合があり得る。この場合、対象パケットのシーケンス番号がＳＮ１未満またはＳＮ２以上ならば、対象パケットのシーケンス番号は、暫定キャプチャロス範囲外である。逆に、対象パケットのシーケンス番号がＳＮ１以上かつＳＮ２未満ならば、対象パケットのシーケンス番号は、暫定キャプチャロス範囲内である。
例えば、図６の時刻Ｔ１４にＡＣＫパケットＡ１４がキャプチャされると、検出部４４は、以下の２つの可能性があることを検出する（詳しくは後述のステップＳ１２５〜Ｓ１２６を参照）。
・キャプチャロスが原因でキャプチャされていない１つ以上のデータパケットが何らかの理由で再送されて、当該１つ以上の再送データパケットが、今回キャプチャされたＡＣＫパケットより後に（つまり将来において）キャプチャされるかもしれない、という可能性。
・キャプチャ過程で、１つ以上のデータパケットと、当該１つ以上のデータパケットの受信を通知するためのＡＣＫパケットとの間での順序逆転が起きており、そのため、今回のＡＣＫパケットがデータパケットより先に受信された、という可能性。
しかし、ＡＣＫパケットがキャプチャされた段階では、キャプチャロスと再送が起きたのか、順序逆転が起きたのかは、まだ不明である。一方、ＡＣＫパケットがキャプチャされた段階で検出部４４により「キャプチャロスが生じたのかもしれない」と認識される範囲は、ＡＣＫパケットがキャプチャされた段階で検出部４４により「順序逆転が起きたのかもしれない」と認識される範囲と同じである。よって、ＡＣＫパケットがキャプチャされた段階では、キャプチャロスまたは順序逆転の範囲が、暫定キャプチャロス範囲フィールドに記録される。
よって、キャプチャロスの後に再送が生じた場合に、再送されたデータパケットがＡＣＫパケットの後にステップＳ１０１でキャプチャされると、ステップＳ１１４では「対象パケットのシーケンス番号は暫定キャプチャロス範囲内」と判断される。また、キャプチャ過程の順序逆転のせいで、１つ以上のデータパケットがＡＣＫパケットより遅れてキャプチャされる場合もあり得る。この場合、当該１つ以上のデータパケットのうちの１つ目がステップＳ１０１でキャプチャされると、ステップＳ１１４では「対象パケットのシーケンス番号は暫定キャプチャロス範囲内」と判断される。
もちろん、キャプチャロスとは無関係にデータパケットが再送される場合もあり得る。例えば、以下のような場合である。
・シーケンス番号が５０１でＴＣＰデータ長が１００のデータパケットが送信され、キャプチャされる。
・その後、当該データパケットに対するＡＣＫとして、ＡＣＫ番号が６０１のＡＣＫパケットが送信され、キャプチャされる。
・しかし、当該ＡＣＫパケットは、キャプチャされた後にネットワーク上で消失してしまう。
・その結果、シーケンス番号が５０１でＴＣＰデータ長が１００のデータパケットが再送され、この再送されたデータパケットがキャプチャされる。
例えば上記の例のように、キャプチャロスとは無関係にデータパケットが再送される場合などは、ステップＳ１１４で「対象パケットのシーケンス番号は暫定キャプチャロス範囲外」と判断される。このように、対象パケットのシーケンス番号が暫定キャプチャロス範囲外の場合、検出部４４は、順序逆転の可能性を排除することができる。
ステップＳ１１４において「対象パケットのシーケンス番号は暫定キャプチャロス範囲内」と判断した場合、検出部４４は、次に、キャプチャロスと再送が起きたのか、それとも順序逆転が起きたのかを判別するために、ステップＳ１１５の判断を行う。逆に、ステップＳ１１４において「対象パケットのシーケンス番号は暫定キャプチャロス範囲外」と判断した場合、検出部４４は、次にステップＳ１１６の処理を行う。
さて、ステップＳ１１５で検出部４４は、コネクション管理テーブル４７における選択サブコネクションのエントリのＩＰ−ＩＤフィールドの値を読み取る。こうして読み取られる値は、図１に関して説明した「前回データパケット」のＩＰ−ＩＤである。なぜなら、ＩＰ−ＩＤフィールドは、後述のステップＳ１２１で更新されるからである。
前回データパケットは、「キャプチャロスと再送が起きたか、キャプチャ過程での順序逆転が起きた」と検出部４４が検出する契機となったＡＣＫパケットよりも前にキャプチャされたデータパケットの中では、最も遅くにキャプチャされたデータパケットである。以下のいくつかの式では、前回データパケットのＩＰ−ＩＤを「Ｐｒｅｖ」と表記することがある。
また、ステップＳ１１５で検出部４４は、「キャプチャロスと再送が起きた」と想定した場合における、ネットワーク監視装置４０がキャプチャに失敗したデータパケットの個数を算出する。以下、この個数を「暫定ロス数」といい、「Ｌｏｓｓ」と表記することがある。
具体的には、検出部４４は、コネクション管理テーブル４７における選択サブコネクションのエントリから、暫定キャプチャロス範囲フィールドと最大長さフィールドの値を読み出す。説明の便宜上、暫定キャプチャロス範囲フィールドに記憶されている範囲を「ＳＮ１以上ＳＮ２未満」とし、かつ、最大長さフィールドに記憶されている長さを「ＭａｘＬｅｎ」とする。この場合、検出部４４は、式（１）のように暫定ロス数を算出する。なお、ｃｅｉｌ（ｘ）は、引数ｘ以上で引数ｘに最も近い整数とする。
Loss = ceil((SN2-SN1)/MaxLen) (1)
式（１）のように最大長さに基づいて算出される暫定ロス数は、キャプチャロスの回数の最小の推定値である。図１に関して説明したとおり、キャプチャロスの回数の推定値として最小の推定値を用いることは、副作用を抑える効果があるので、好ましい。
さらに、ステップＳ１１５で検出部４４は、読み取った前回データパケットのＩＰ−ＩＤと、算出した暫定ロス数と、対象パケットのＩＰ−ＩＤに基づいて、「式（２）が成り立つか否か」を判断する。なお、式（２）では、対象パケットのＩＰ−ＩＤ（すなわち今回キャプチャされたデータパケットのＩＰ−ＩＤ）が「Ｃｕｒ」と表記されている。
Prev+Loss < Cur (2)
式（２）が成り立つ場合、検出部４４は、「キャプチャロスと再送が起きた」と判断する。なぜなら、前回データパケットに対する送信元ホストでのＩＰ−ＩＤの発行後、対象パケットまでのパケットに対して送信元ホストで消費されたＩＰ−ＩＤの個数が、閾値としての暫定ロス数よりも大きいからである。そのため、式（２）が成り立つ場合、検出部４４は次にステップＳ１１６の処理を行う。
逆に、式（２）が成り立たない場合、検出部４４は、「キャプチャ過程でのデータパケットとＡＣＫパケットの間の順序逆転が起きた」と判断する。すなわち、この場合、検出部４４は、順序逆転を検出する。より詳しくは、検出部４４は、「１つ以上のデータパケットと、当該１つ以上のデータパケットの受信を通知するためのＡＣＫパケットとの間での順序逆転が起きて、対象パケットは当該１つ以上のデータパケットのうちの１つ目である」と判断する。この場合、検出部４４は次にステップＳ１１７の処理を行う。
なお、式（２）は式（３）と等価である。つまり、検出部４４は、今回キャプチャされた対象パケットのＩＰ−ＩＤと前回データパケットのＩＰ−ＩＤの差が、閾値としての暫定ロス数より大きければ、「キャプチャロスと再送が生じた」と判断する。逆に、検出部４４は、検出部４４は、今回キャプチャされた対象パケットのＩＰ−ＩＤと前回データパケットのＩＰ−ＩＤの差が、閾値としての暫定ロス数以下ならば、「順序逆転が生じた」と判断する。
Loss < Cur-Prev (3)
なお、式（３）の「Ｃｕｒ」と「Ｐｒｅｖ」と「Ｌｏｓｓ」は、それぞれ、図１に関して説明した「第３の数値」と「第４の数値」と「閾値」の例である。また、図１に関して、「閾値」が「第１の数値」と「第５の数値」と「前回データパケットのサイズ」と「サイズ値」に基づく場合を説明した。式（１）はそのような「閾値」の算出法の一例を示す。つまり、式（１）の「ＳＮ２」は「第１の数値」の例であり、式（１）の「ＳＮ１」は「第５の数値」と「前回データパケットのサイズ」の和に相当し、式（１）の「ＭａｘＬｅｎ」は「サイズ値」の例である。
さて、再送を検出した場合、ステップＳ１１６で検出部４４は、解析情報テーブル４８における選択サブコネクションのエントリの再送数を１だけインクリメントする。あるいは、検出部４４は、解析情報テーブル４８ｂおける選択コネクションのエントリの再送数を１だけインクリメントしてもよい。そして、図１１〜１４の処理はステップＳ１２１へと移行する。
一方、順序逆転を検出した場合、ステップＳ１１７で検出部４４は、コネクション管理テーブル４７における選択サブコネクションのエントリを更新する。具体的には、検出部４４は、暫定キャプチャロス範囲フィールドの値を、逆転範囲フィールドに転写し、暫定キャプチャロス範囲をクリアする。ステップＳ１１７は、キャプチャ過程での順序逆転のせいで、２つ以上のデータパケットがＡＣＫパケットよりも後にキャプチャされる場合の、２つ目以降のデータパケットのキャプチャに備えるために行われる。検出部４４は、ステップＳ１１７の次に、ステップＳ１１８を実行する。
ステップＳ１１８は、順序逆転がステップＳ１１５で検出されてステップＳ１１７が実行された場合か、ステップＳ１１３で「対象パケットのシーケンス番号は逆転範囲内」と判断された場合に、実行される。後者の場合は、換言すれば、検出済みの順序逆転に関する２つ目以降のデータパケットが、ステップＳ１０１でキャプチャされた場合である。つまり、ステップＳ１１８は、対象パケットが、キャプチャ過程での順序逆転のせいでＡＣＫパケットより送れてキャプチャされたいずれかのデータパケットである場合に、実行される。
具体的には、ステップＳ１１８で検出部４４は、解析情報テーブル４８における選択サブコネクションのエントリの複製時逆転数を１だけインクリメントする。あるいは、検出部４４は、解析情報テーブル４８ｂおける選択コネクションのエントリの複製時逆転数を１だけインクリメントしてもよい。
また、ステップＳ１１８で検出部４４は、解析情報テーブル４８における選択サブコネクションのエントリのキャプチャロス数を１だけデクリメントする。あるいは、検出部４４は、解析情報テーブル４８ｂにおける選択コネクションのエントリのキャプチャロス数を１だけデクリメントしてもよい。このようなキャプチャロス数のデクリメントは、以前、ＡＣＫパケットのキャプチャの際に暫定的に行われたキャプチャロス数のインクリメント（詳しくはステップＳ１２６とともに後述する）の影響を、打ち消すために行われる。
さらに、ステップＳ１１８で検出部４４は、コネクション管理テーブル４７における選択サブコネクションのエントリの逆転範囲フィールドを更新する。具体的には、検出部４４は、対象パケットのシーケンス番号と対象パケットのＴＣＰデータ長の和を算出する。そして、算出した和が逆転範囲の上限以上ならば、検出部４４は、逆転範囲フィールドをクリアする。逆に、算出した和が逆転範囲の上限より小さければ、検出部４４は、逆転範囲の下限を、算出した和に更新する。このように逆転範囲を更新することで、検出部４４は、順序逆転に起因してＡＣＫパケットより後にキャプチャされると推定される１つ以上のデータパケットのうち未キャプチャのデータパケットに相当するオクテットの範囲を、適切に認識することができる。
以上のようなステップＳ１１８における解析情報テーブル４８とコネクション管理テーブル４７の更新の後、図１３のステップＳ１１９が実行される。
図１２〜１３から分かるように、ステップＳ１１９は、ステップＳ１１２で「対象パケットのシーケンス番号が選択サブコネクションのエントリの最大ＡＣＫ番号以上である」と判断された場合に実行される。また、ステップＳ１１９は、ステップＳ１１２で「対象パケットのシーケンス番号が選択サブコネクションのエントリの最大ＡＣＫ番号未満である」と判断された後に、「対象パケットは再送データパケットではない」と判断された場合にも実行される。
具体的には、ステップＳ１１９で検出部４４は、対象パケットのシーケンス番号と、コネクション管理テーブル４７における選択サブコネクションのエントリの最大シーケンス番号を比較する。
対象パケットのシーケンス番号が最大シーケンス番号より大きい場合、「対象パケットは再送データパケットではない」と推定される。よって、この場合、検出部４４は次にステップＳ１２０を実行する。
逆に、対象パケットのシーケンス番号が最大シーケンス番号以下の場合、「対象パケットは再送データパケットである」と推定される。よって、この場合、検出部４４は次に前述のステップＳ１１６を実行する。
ステップＳ１２０で検出部４４は、コネクション管理テーブル４７における選択サブコネクションのエントリの最大シーケンス番号とＡＣＫ期待値を更新する。具体的には、検出部４４は、対象パケットのシーケンス番号を、最大シーケンス番号フィールドに記憶する。また、検出部４４は、対象パケットのシーケンス番号と対象パケットのＴＣＰデータ長の和を、ＡＣＫ期待値フィールドに記憶する。
そして、ステップＳ１２０またはＳ１１６の実行後に、検出部４４は、ステップＳ１２１の処理を行う。
具体的には、検出部４４は、コネクション管理テーブル４７における選択サブコネクションのＩＰ−ＩＤフィールドの値を、対象パケットのＩＰ−ＩＤに更新する。
また、ステップＳ１２１で検出部４４は、コネクション管理テーブル４７における選択サブコネクションの最大長さフィールドを、必要に応じて更新する。つまり、検出部４４は、最大長さフィールドの値を対象パケットのＴＣＰデータ長と比較し、対象パケットのＴＣＰデータ長の方が最大長さフィールドの現在の値より大きければ、最大長さフィールドに対象パケットのＴＣＰデータ長を設定する。
次に、ステップＳ１２２で検出部４４は、選択サブコネクションと逆方向のサブコネクションが解析済みか否かを判断する。つまり、ステップＳ１０９で選択されたコネクションの２つのサブコネクションの双方について、ステップＳ１１０以降の処理が済んでいるか否かを検出部４４は判断する。
２つのサブコネクションについてステップＳ１１０以降の処理が実行済みの場合、対象パケットに関する処理は完了している。よって、この場合、図１１〜１４の処理はステップＳ１０１へと戻り、ネットワーク監視装置４０は次のパケットを待つ。
逆に、２つのサブコネクションのうちの一方についてしか、まだステップＳ１１０以降の処理が実行されていない場合、検出部４４は、次にステップＳ１２３を実行する。つまり、検出部４４は、現在の選択サブコネクションとは逆方向のサブコネクションを選択する。そして、検出部４４は、新たに選択したサブコネクションに関して、ステップＳ１１０以降の処理を実行する。
さて、ステップＳ１２４は、ステップＳ１１０において、「対象パケットが送信される方向が、選択サブコネクションにとってのＡＣＫ方向である」と判断された場合に実行される。
ところで、ここまでの説明においては、説明の簡略化のため、単に「ＡＣＫパケット」という用語を用いてきたが、あるデータパケットに対するＡＣＫは、逆方向に送信される別のデータパケットにピギーバックされる場合もあり得る。つまり、ＴＣＰデータペイロードを持つＡＣＫパケットも存在し得る。もちろん、逆方向に送信されるデータが存在しない場合などには、ＴＣＰデータペイロードを持たないＡＣＫパケットが送信される場合もあり得る。
また、ＴＣＰコネクションの確立後に送信されるどのパケットでも、ＡＣＫフラグは１に設定される。つまり、ＴＣＰコネクションの確立後に送信されるどのパケットでも、ＡＣＫ番号フィールドは有効である。よって、例えば以下のような場合には、同じＡＣＫ番号が何度も繰り返し通知される可能性がある。
・ホスト３１がホスト３２に宛てて、コネクション上で、あるデータパケットを送信する。
・そのデータパケットに対して、ホスト３２がホスト３１にＡＣＫパケットを返信する。このＡＣＫパケットは、ＴＣＰデータペイロードを持っている場合もあり得るし、ＴＣＰデータペイロードを持っていない場合もあり得る。
・その後しばらくの間は、ホスト３１では、ホスト３２へ送信する対象のデータがない。そのため、その期間中、ホスト３１はホスト３２にデータパケットを送信しない。
・しかし、その期間中、ホスト３２には、ホスト３１へ送信する対象のデータがある。そのため、その期間中にホスト３２はホスト３１にいくつかのデータパケットを送信する。これらのデータパケットのＡＣＫ番号は、上記のＡＣＫパケットのＡＣＫ番号と同じである。
以上の説明から分かるように、選択サブコネクションにとってのＡＣＫ方向に送信されるパケットは、ＴＣＰデータペイロードを持つ可能性もあるし、ＴＣＰデータペイロードを持たない可能性もある。いずれにせよ、選択サブコネクションにとってのＡＣＫ方向に送信されるどのパケットにおいても、ＡＣＫ番号フィールドは有効である。
しかし、ＡＣＫ番号はパケットごとに異なるとは限らない。例えば上記の例のように（あるいは、データパケットのネットワークロスに起因して）、同じＡＣＫ番号を持つ複数のパケットが送信される可能性もある。
したがって、対象パケットが送信される方向が選択サブコネクションのＡＣＫ方向である場合、ステップＳ１２４において検出部４４は、まず、「過去に通知されたＡＣＫ番号と同じＡＣＫ番号がまた対象パケットによって通知されているのか否か」を判断する。つまり、検出部４４は、コネクション管理テーブル４７における選択サブコネクションのエントリの最大ＡＣＫ番号フィールドの値と、対象パケットのＡＣＫ番号フィールドの値を比較する。
最大ＡＣＫ番号が対象パケットのＡＣＫ番号未満ならば、対象パケットにより通知されるＡＣＫ番号は、過去にキャプチャされたどのパケットによっても通知されてはいない。よって、この場合、検出部４４は次にステップＳ１２５を実行する。
逆に、最大ＡＣＫ番号が対象パケットのＡＣＫ番号以上ならば、対象パケットにより通知されるＡＣＫ番号は、過去にキャプチャされたいずれかのＡＣＫパケットによって既に通知された番号である。よって、この場合、検出部４４は、ＡＣＫパケットとしての対象パケットを無視する。具体的には、この場合、検出部４４は、ステップＳ１２５〜Ｓ１２７を実行せずに、次に前述のステップＳ１２２の判断を行う。
さて、ステップＳ１２５で検出部４４は、「対象パケットが、未検出のデータパケット（つまり、未キャプチャのデータパケット）に対するＡＣＫパケットであるか否か」を判断する。具体的には、検出部４４は、コネクション管理テーブル４７の選択サブコネクションのエントリのＡＣＫ期待値フィールドを参照する。そして、検出部４４は、ＡＣＫ期待値と対象パケットのＡＣＫ番号を比較する。
ＡＣＫ期待値よりＡＣＫ番号が大きい場合、検出部４４は、「対象パケットは、未検出のデータパケットに対するＡＣＫパケットである」と判断する。この場合、データパケットのキャプチャロスが生じた可能性と、キャプチャ過程での順序逆転によりＡＣＫパケットがデータパケットに先んじてキャプチャされた可能性がある。よって、ＡＣＫ期待値よりＡＣＫ番号が大きい場合、検出部４４は、次にデータパケットがキャプチャされたときにこれら２つの可能性を判別することができるようにするための準備を行う。つまり、この場合、検出部４４はステップＳ１２５の次にステップＳ１２６を実行する。
逆に、ＡＣＫ番号がＡＣＫ期待値以下の場合、検出部４４は、「対象パケットは、検出済みのデータパケットに対するＡＣＫパケットである」と判断する。この場合、検出部４４は、ステップＳ１２５の次にステップＳ１２７を実行する。
さて、ステップＳ１２６で検出部４４は、コネクション管理テーブル４７の選択サブコネクションのエントリの暫定キャプチャロス範囲フィールドを更新する。具体的には、検出部４４は、ステップＳ１２６で参照したＡＣＫ期待値を暫定キャプチャロス範囲の下限に設定し、対象パケットのＡＣＫ番号を暫定キャプチャロス範囲の上限に設定する。
例えば、以上のようにして設定される下限と上限の値がＳＮ１とＳＮ２だとする。選択サブコネクション上でデータ方向に送信されるデータストリームにおいて、ＳＮ１という数値で示されるオクテットから、（ＳＮ２−１）という数値で示されるオクテットまでが、キャプチャ過程で失われたか、または、キャプチャが遅れている可能性がある。
検出部４４は、ステップＳ１２６においてさらに、解析情報テーブル４８の選択サブコネクションのエントリにおいて、キャプチャロス数を暫定的にインクリメントする。具体的には、検出部４４は、キャプチャロスの可能性があるデータパケットの個数を、式（４）により推定する。
Loss = ceil((SN2-SN1)/MaxLen) (4)
なお、ステップＳ１２６では上記のように「ＳＮ１以上ＳＮ２未満」と暫定キャプチャロス範囲が記録されたものとする。また、コネクション管理テーブル４７の選択サブコネクションのエントリの最大長さフィールドの値を「ＭａｘＬｅｎ」とする。式（４）の「Ｌｏｓｓ」は、キャプチャロスの可能性があると推定されるデータパケットの個数であり、すなわち、暫定ロス数である。式（４）は、ステップＳ１１５での暫定ロス数の算出に関して参照した式（１）と同じである。
検出部４４は、解析情報テーブル４８の選択サブコネクションのエントリにおいて、キャプチャロス数フィールドの値を、式（４）により推定した暫定ロス数の分だけ、インクリメントする。なお、解析情報テーブル４８の代わりに解析情報テーブル４８ｂが使われる実施形態では、検出部４４は、解析情報テーブル４８ｂの選択コネクションのエントリにおいて、キャプチャロス数フィールドの値を暫定ロス数の分だけインクリメントする。
以上のような暫定キャプチャロス範囲とキャプチャロス数の更新の後、検出部４４は、ステップＳ１２７を実行する。
なお、ステップＳ１２６で上記のように暫定的にインクリメントされたキャプチャロス数は、後に「キャプチャロスと再送が生じた」と判断された場合には、そのままにしておかれる。つまり、ステップＳ１１６ではキャプチャロス数は更新されず、それにより、キャプチャロス数が確定する。
逆に、後に「順序逆転が生じた」と判断された場合は、前述のステップＳ１１８においてキャプチャロス数がデクリメントされる。それにより、ステップＳ１２６での暫定的なインクリメントの影響が打ち消される。
もちろん、実施形態によっては、検出部４４は、ステップＳ１２６での暫定的なインクリメントとステップＳ１１８のデクリメントの代わりに、例えばＲＡＭ５２上の適宜の一時的な記憶領域を利用してもよい。つまり、検出部４４は、式（４）により推定した暫定ロス数を、ステップＳ１２６で一時的な記憶領域に記憶してもよい。そして、現在の選択サブコネクションのデータ方向に送信されるデータパケットが次にキャプチャされたときに、もし、ステップＳ１１５が実行されて「式（２）が成り立つ」と判断されたならば、検出部４４は、キャプチャロス数をインクリメントしてもよい。つまり、検出部４４は、キャプチャロスと再送を検出した後になってはじめて、キャプチャロス数を、一時的な記憶領域に記憶した暫定ロス数の分だけ、インクリメントしてもよい。
さて、ステップＳ１２７で検出部４４は、ステップＳ１０１でキャプチャされた対象パケットのＡＣＫ番号を、コネクション管理テーブル４７における選択サブコネクションのエントリの最大ＡＣＫ番号として記録する。そして、検出部４４は、次に前述のステップＳ１２２を実行する。
以上説明した図１１〜１４の処理によれば、例えば図５に例示したような再送に関する誤判断を防ぐことができ、例えば図６に例示したような適切な判断が行われる。その結果、パケット解析の精度が高まる。
なお、図１１〜１４の処理では、１つの方向に送信されるパケット間ではキャプチャ過程での順序逆転が生じない（よってＩＰ−ＩＤやＡＣＫ番号が単調増加する）、という性質が利用されている。詳しくは以下のとおりである。
ホスト３１と３２の間の１つのコネクション上で、ホスト３１からホスト３２に向けて送信されるデータパケットと、当該コネクション上でホスト３２からホスト３１に向けて送信されるＡＣＫパケットの間の順序は、キャプチャ過程で逆転する可能性がある。同様に、当該コネクション上でホスト３２からホスト３１に向けて送信されるデータパケットと、当該コネクション上でホスト３１からホスト３２に向けて送信されるＡＣＫパケットの間の順序が、キャプチャ過程で逆転する可能性もある。このような順序逆転は、ある方向に流れるパケットと、その逆の方向に流れるパケットを、１つの出口（例えば、ポート１６ａもしくはポート３７のような集約ポート、または、バッファ１８など）に集約する過程において、２つの方向の間で起こり得る。
しかし、１つの方向を流れる複数のパケット間での順序は、キャプチャ過程を経ても保たれる。つまり、ホスト３１と３２の間の１つのコネクション上で、ホスト３１からホスト３２に向けて送信される複数のパケット間の順序は、キャプチャ後も保たれる。同様に、当該コネクション上でホスト３２からホスト３１に向けて送信される複数のパケット間の順序も、キャプチャ後も保たれる。
なお、複数のパケットがネットワーク上の別々の経路をルーティングされることに起因して、それら複数のパケット間での順序の逆転が起きる場合もあり得る。しかし、以下では説明の簡単化のため、その種の逆転の影響がない（あるいは、その種の逆転の影響は適宜打ち消される）ものとする。複数の経路を通る複数のパケット間での順序の逆転の検出のために、例えば、既存のパケット解析アルゴリズムが利用されてもよい。
換言すれば、当該コネクション上でホスト３１が送信する複数のデータパケット間の順序は、キャプチャ後も保たれる。よって、当該コネクション上でホスト３１から送信されてネットワーク監視装置４０にキャプチャされた複数のデータパケット間では、ＩＰ−ＩＤが狭義単調増加する。また、当該コネクション上でホスト３２が送信する複数のＡＣＫパケット間の順序も保たれる。また、ＴＣＰでは、累積確認応答方式（cumulative acknowledgment scheme）のＡＣＫ番号が使われる。よって、当該コネクション上でホスト３２から送信されてネットワーク監視装置４０にキャプチャされた複数のＡＣＫパケット間では、ＡＣＫ番号が広義単調増加する。
同様に、当該コネクション上でホスト３２が送信する複数のデータパケット間の順序は保たれるし、当該コネクション上でホスト３１が送信する複数のＡＣＫパケット間の順序も保たれる。よって、当該コネクション上でホスト３２から送信されてネットワーク監視装置４０にキャプチャされた複数のデータパケット間では、ＩＰ−ＩＤが狭義単調増加する。また、当該コネクション上でホスト３１から送信されてネットワーク監視装置４０にキャプチャされた複数のＡＣＫパケット間では、ＡＣＫ番号が広義単調増加する。
図１１〜１４の処理では、例えばステップＳ１１５、Ｓ１２１、Ｓ１２４、Ｓ１２７などにおいて、以上のようなＩＰ−ＩＤとＡＣＫ番号の単調性が利用されている。
また、図１１〜１４の処理は、ＩＰフラグメンテーションが起きない場合についての処理である。ＴＣＰを用いた通信では、コネクション確立の際に適宜のＭＳＳ（Maximum Segment Size）が通知される場合が多いので、「ＩＰフラグメンテーションが起きない」という想定は、現実的な想定である。
ＩＰフラグメンテーションが起きない場合、１つのＴＣＰセグメントは１つのＩＰパケットにより搬送されるから、ＴＣＰセグメントの搬送に使われるどのＩＰパケットも、ＴＣＰヘッダを含む。また、ＩＰフラグメンテーションが起きない場合、２つ以上のＩＰパケットのＩＰ−ＩＤは互いに異なる。図１１〜１４の処理（例えば、ステップＳ１０１でのヘッダ情報の抽出、ＩＰ−ＩＤに関するステップＳ１１５とＳ１２１の処理、など）では、ＩＰフラグメンテーションが起きない場合におけるこれらの性質が、利用される。
続いて、図６と９に示した具体例を用いて、図１１〜１４を参照して以上説明した処理についてさらに説明する。なお、図６は、図３のようにホスト２１と２２の間のパケット送受信に関する例であり、図９には図７のホスト３１と３２の間のコネクションに関する情報が例示されている。ここで、上記のとおり、ホスト２１は具体的にはホスト３１であってもよく、ホスト２２は具体的にはホスト３２であってもよいので、以下では、ホスト２１がホスト３１であり、ホスト２２がホスト３２であるものとする。
図９のコネクション管理テーブル４７において、コネクションＩＤが「１−１」と「１−２」の２つのエントリは、図６の時刻Ｔ１１より前に行われるコネクション確立のための３ウェイハンドシェイクの際にステップＳ１０６で登録されてもよい。あるいは、コネクションの確立後にネットワーク監視装置４０がパケットキャプチャを開始した場合は、これら２つのエントリは、ネットワーク監視装置４０が最初にパケットをキャプチャした際にステップＳ１０４で登録されてもよい。
図６の時刻Ｔ１１にデータパケットＤ１１がステップＳ１０１でキャプチャされると、次にステップＳ１０２とＳ１０９が実行される。説明の便宜上、ステップＳ１０９では、コネクションＩＤが「１−１」のサブコネクションが選択されたものとする。
すると、データパケットＤ１１の送信方向は、選択サブコネクションにとってのデータ方向であるから、ステップＳ１１１が実行される。また、データパケットＤ１１はデータペイロードを含むので、次にステップＳ１１２が実行される。
ところで、図６では省略されているが、説明の便宜上、時刻Ｔ１１の前には、正常にＡＣＫパケット（具体的にはＡＣＫ番号が８０１のＡＣＫパケット）がキャプチャされていたものとする。よって、以前正常にキャプチャされたＡＣＫパケットのＡＣＫ番号が、コネクション管理テーブル４７に最大ＡＣＫ番号として記憶されている。そのため、データパケットＤ１１の８０１というシーケンス番号は、最大ＡＣＫ番号以上であると判断される。その結果、ステップＳ１１２の次にはステップＳ１１９が実行される。
また、データパケットＤ１１は、再送されたものではないとする。すると、データパケットＤ１１のシーケンス番号は、コネクション管理テーブル４７に記憶されている最大シーケンス番号より大きい。そのため、次にステップＳ１２０が実行される。
そして、ステップＳ１２０では、データパケットＤ１１のシーケンス番号である８０１という値が、最大シーケンス番号として記憶される。ステップＳ１２０ではさらに、データパケットＤ１１のシーケンス番号とＴＣＰデータ長の和である９０１（＝８０１＋１００）という値が、ＡＣＫ期待値として記憶される。
そして、ステップＳ１２１では、データパケットＤ１１のＩＰ−ＩＤである９９という値が、「１−１」というコネクションＩＤのエントリにＩＰ−ＩＤとして記憶される。また、データパケットＤ１１のＴＣＰデータ長が最大長さより長ければ、データパケットＤ１１のＴＣＰデータ長である１００という値が最大長さとして記憶され、データパケットＤ１１のＴＣＰデータ長が最大長さ以下ならば、最大長さは更新されない。いずれにせよ、図６と９の例では、最大長さは１００であるものとする。
その後、ステップＳ１２２では「逆方向のサブコネクションは未解析」と判断され、ステップＳ１２３では、コネクションＩＤが「１−２」のサブコネクションが選択される。すると、データパケットＤ１１の送信方向は、選択サブコネクションにとってのＡＣＫ方向であるから、ステップＳ１２４が実行される。
図６には明記されていないが、データパケットＤ１１においてもＡＣＫフラグの値は１であり、ＡＣＫ番号は有効である。よって、データパケットＤ１１のＡＣＫ番号に応じて、ステップＳ１２４以降の処理が適宜実行される。そして、ステップＳ１２４でデータパケットＤ１１のＡＣＫ番号が最大ＡＣＫ番号以下だった場合はステップＳ１２４の後に、そうでない場合はステップＳ１２７の後に、再度ステップＳ１２２が実行される。今度は、「逆方向のサブコネクションも解析済み」と判断されるので、ネットワーク監視装置４０は再度ステップＳ１０１でパケットの受信を待つ。
すると、時刻Ｔ１２にデータパケットＤ１２がキャプチャされ、続いて、ステップＳ１０２とＳ１０９が実行される。説明の便宜上、ステップＳ１０９では、コネクションＩＤが「１−１」のサブコネクションが選択されたものとする。
すると、データパケットＤ１２の送信方向は、選択サブコネクションにとってのデータ方向であるから、ステップＳ１１１が実行される。また、データパケットＤ１２はデータペイロードを含むので、次にステップＳ１１２が実行される。
ここで、データパケットＤ１１に関して上述したとおり、コネクションＩＤが「１−１」のエントリに記憶されている最大ＡＣＫ番号が８０１だとする。データパケットＤ１２のシーケンス番号である９０１という値は、８０１という最大ＡＣＫ番号以上である。よって、ステップＳ１１２の次にはステップＳ１１９が実行される。
また、データパケットＤ１１に関して上述したとおり、コネクションＩＤが「１−１」のエントリに記憶されている最大シーケンス番号は、８０１である。よって、データパケットＤ１２のシーケンス番号である９０１という値の方が、最大シーケンス番号より大きい。そのため、次にステップＳ１２０が実行される。
そして、ステップＳ１２０では、データパケットＤ１２のシーケンス番号である９０１という値が、最大シーケンス番号として記憶される。ステップＳ１２０ではさらに、データパケットＤ１２のシーケンス番号とＴＣＰデータ長の和である１００１（＝９０１＋１００）という値が、ＡＣＫ期待値として記憶される。
そして、ステップＳ１２１では、データパケットＤ１２のＩＰ−ＩＤである１００という値が、「１−１」というコネクションＩＤのエントリにＩＰ−ＩＤとして記憶される。また、データパケットＤ１２のＴＣＰデータ長は、記憶されている１００という最大長さ以下であるから、最大長さは更新されない。
図９のコネクション管理テーブル４７ａに示した、コネクションＩＤが「１−１」のエントリは、時刻Ｔ１２でのデータパケットＤ１２のキャプチャを契機として以上のようにしてステップＳ１２１までの処理が行われた後の状態を示す。
なお、この後、ステップＳ１２２では「逆方向のサブコネクションは未解析」と判断され、ステップＳ１２３では、コネクションＩＤが「１−２」のサブコネクションが選択される。そして、データパケットＤ１２のＡＣＫ番号に応じて、ステップＳ１２４以降の処理が適宜実行され、その後、ネットワーク監視装置４０は再度ステップＳ１０１でパケットの受信を待つ。
すると、時刻Ｔ１３にＡＣＫパケットＡ１２がキャプチャされ、続いて、ステップＳ１０２とＳ１０９が実行される。説明の便宜上、ステップＳ１０９では、コネクションＩＤが「１−１」のサブコネクションが選択されたものとする。
すると、ＡＣＫパケットＡ１２の送信方向は、選択サブコネクションにとってのＡＣＫ方向であるから、ステップＳ１２４が実行される。コネクション管理テーブル４７ａに示すように、記憶されている最大ＡＣＫ番号は８０１であり、図６に示すように、ＡＣＫパケットＡ１２のＡＣＫ番号は１００１である。８０１＜１００１なので、次に、ステップＳ１２５が実行される。
コネクション管理テーブル４７ａに示すように、記憶されているＡＣＫ期待値は１００１である。よって、ＡＣＫパケットＡ１２のＡＣＫ番号は、ＡＣＫ期待値以下である。よって、検出部４４は、ＡＣＫパケットＡ１２を「キャプチャ済みのデータパケットに対するＡＣＫパケットである」と判断する。図３、４、および６から分かるように、ＡＣＫパケットＡ１２はデータパケットＤ１１とＤ１２に対するＡＣＫパケットであるから、この判断は正しい。
上記のように判断されると、次にステップＳ１２７が実行される。つまり、コネクションＩＤが「１−１」のエントリの最大ＡＣＫ番号フィールドに、ＡＣＫパケットＡ１２のＡＣＫ番号である１００１という値が設定される。
図９のコネクション管理テーブル４７ｂに示した、コネクションＩＤが「１−１」のエントリは、時刻Ｔ１３でのＡＣＫパケットＡ１２のキャプチャを契機として以上のようにしてステップＳ１２７までの処理が行われた後の状態を示す。
なお、この後、ステップＳ１２２では「逆方向のサブコネクションは未解析」と判断され、ステップＳ１２３では、コネクションＩＤが「１−２」のサブコネクションが選択される。もし、ＡＣＫパケットＡ１２がピギーバックＡＣＫパケットであれば、ステップＳ１１２以降の処理が適宜行われ、その後、ステップＳ１２２からステップＳ１０１へと処理が戻る。逆に、ＡＣＫパケットＡ１２がＴＣＰデータペイロードを持たなければ、ステップＳ１１１の次にステップＳ１２２が実行され、ステップＳ１０１へと処理が戻る。
ステップＳ１０１でネットワーク監視装置４０がパケットの受信を待っていると、図６の時刻Ｔ１４にＡＣＫパケットＡ１４がキャプチャされる。そして、ステップＳ１０２とＳ１０９が実行される。説明の便宜上、ステップＳ１０９では、コネクションＩＤが「１−１」のサブコネクションが選択されたものとする。
すると、ＡＣＫパケットＡ１４の送信方向は、選択サブコネクションにとってのＡＣＫ方向であるから、ステップＳ１２４が実行される。コネクション管理テーブル４７ｂに示すように、記憶されている最大ＡＣＫ番号は１００１であり、図６に示すように、ＡＣＫパケットＡ１４のＡＣＫ番号は１２０１である。１００１＜１２０１なので、次に、ステップＳ１２５が実行される。
コネクション管理テーブル４７ｂに示すように、記憶されているＡＣＫ期待値は１００１である。よって、ＡＣＫパケットＡ１４のＡＣＫ番号は、ＡＣＫ期待値より大きい。したがって、検出部４４は、ＡＣＫパケットＡ１４を「未キャプチャのデータパケットに対するＡＣＫパケットである」と判断する。図３と６から分かるように、ＡＣＫパケットＡ１４は、データパケットＤ１３とＤ１４に対するＡＣＫパケットであるから、この判断は正しい。
また、未キャプチャのデータパケットに対するＡＣＫパケットがキャプチャされた場合には、データパケットのキャプチャロスが生じた可能性と、キャプチャ過程での順序逆転が生じた可能性がある。この２つの可能性の判別は、コネクションＩＤが「１−１」のサブコネクションのデータ方向に流れるデータパケットが次にキャプチャされたときに行われる。ＡＣＫパケットＡ１４がキャプチャされた段階では、ステップＳ１２５での上記判断に続いて、ステップＳ１２６で暫定キャプチャロス範囲とキャプチャロス数が更新される。
具体的には、現在のＡＣＫ期待値が１００１であり、ＡＣＫパケットＡ１４のＡＣＫ番号が１２０１である。よって、暫定キャプチャロス範囲フィールドには、「１００１以上１２０１未満」という範囲が設定される。
また、コネクション管理テーブル４７ｂに示すように、最大長さは１００である。よって、式（４）により推定される暫定ロス数は、２（＝ｃｅｉｌ（（１２０１−１００１）／１００））である。したがって、解析情報テーブル４８においてコネクションＩＤが「１−１」のエントリのキャプチャロス数は、暫定的に、２だけインクリメントされる。
そして、ステップＳ１２７では、コネクションＩＤが「１−１」のエントリの最大ＡＣＫ番号フィールドに、ＡＣＫパケットＡ１４のＡＣＫ番号である１２０１という値が設定される。
図９のコネクション管理テーブル４７ｃに示した、コネクションＩＤが「１−１」のエントリは、時刻Ｔ１４でのＡＣＫパケットＡ１４のキャプチャを契機として以上のようにしてステップＳ１２７までの処理が行われた後の状態を示す。
なお、この後、ステップＳ１２２では「逆方向のサブコネクションは未解析」と判断され、ステップＳ１２３では、コネクションＩＤが「１−２」のサブコネクションが選択される。もし、ＡＣＫパケットＡ１４がピギーバックＡＣＫパケットであれば、ステップＳ１１２以降の処理が適宜行われ、その後、ステップＳ１２２からステップＳ１０１へと処理が戻る。逆に、ＡＣＫパケットＡ１４がＴＣＰデータペイロードを持たなければ、ステップＳ１１１の次にステップＳ１２２が実行され、ステップＳ１０１へと処理が戻る。
そして、ネットワーク監視装置４０がステップＳ１０１でパケットの受信を待っていると、図６の時刻Ｔ１５にデータパケットＤ１３がキャプチャされる。続いて、ステップＳ１０２とＳ１０９が実行される。説明の便宜上、ステップＳ１０９では、コネクションＩＤが「１−１」のサブコネクションが選択されたものとする。
すると、データパケットＤ１３の送信方向は、選択サブコネクションにとってのデータ方向であるから、ステップＳ１１１が実行される。また、データパケットＤ１３はデータペイロードを含むので、次にステップＳ１１２が実行される。
ここで、コネクション管理テーブル４７ｃに示すように、コネクションＩＤが「１−１」のエントリに記憶されている最大ＡＣＫ番号は１２０１である。また、データパケットＤ１３のシーケンス番号は、図６に示すように１００１である。１００１＜１２０１であるから、次に、ステップＳ１１３が実行される。
ここで、コネクション管理テーブル４７ｃに示すように、コネクションＩＤが「１−１」のエントリにおける逆転範囲フィールドは空である。よって、ステップＳ１１３では、「１００１というシーケンス番号は、逆転範囲外」と判断される。
そのため、次にステップＳ１１４が実行される。コネクション管理テーブル４７ｃに示すように、コネクションＩＤが「１−１」のエントリにおける暫定キャプチャロス範囲フィールドには、「１００１以上１２０１未満」という範囲が記憶されている。よって、ステップＳ１１４では、「１００１というシーケンス番号は、暫定キャプチャロス範囲内」と判断される。
よって、次にステップＳ１１５が実行される。ここで、コネクションＩＤが「１−１」のサブコネクション上でデータ方向に送信されて、ＡＣＫパケットＡ１４よりも前にキャプチャされたデータパケットのうち、最後にキャプチャされたデータパケットは、データパケットＤ１２である。データパケットＤ１２のＩＰ−ＩＤは図６のとおり１００であり、この１００というＩＰ−ＩＤは、コネクション管理テーブル４７ｃに示すように、コネクションＩＤが「１−１」のエントリに記憶されている。
また、コネクション管理テーブル４７ｃによれば、最大長さは１００であり、暫定キャプチャロス範囲は「１００１以上１２０１未満」という範囲である。よって、ステップＳ１１５では式（１）により、２（＝ｃｅｉｌ（（１２０１−１００１）／１００））という暫定ロス数が算出される。
そして、図６に示すように、データパケットＤ１３のＩＰ−ＩＤは１０１である。よって、前回データパケットのＩＰ−ＩＤと暫定ロス数の和は１０２（＝１００＋２）であり、この１０２という値は、今回キャプチャされたデータパケットＤ１３のＩＰ−ＩＤである１０１という値以上である。よって、ステップＳ１１５では、式（２）が成り立たない（換言すれば、式（３）が成り立たない）。つまり、ステップＳ１１５では、「キャプチャ過程でのデータパケットとＡＣＫパケットの間の順序逆転が起きた」と判断される。
その結果、ステップＳ１１７が実行される。具体的には、コネクションＩＤが「１−１」のエントリにおける現在の暫定キャプチャロス範囲フィールドの値が、逆転範囲フィールドに転写される。つまり、「１００１以上１２０１未満」という範囲が、逆転範囲フィールドに記憶される。そして、暫定キャプチャロス範囲フィールドはクリアされる。
その後、ステップＳ１１８では、解析情報テーブル４８においてコネクションＩＤが「１−１」のエントリが更新される。具体的には、複製時逆転数が１だけインクリメントされる。また、ＡＣＫパケットＡ１４がキャプチャされたときに上述のようにステップＳ１２６で暫定的に２だけインクリメントされたキャプチャロス数が、ここで１だけデクリメントされる。
なお、キャプチャロス数が２ではなく１だけデクリメントされる理由は、順序逆転のせいでＡＣＫパケットよりも遅れてキャプチャされる各データパケットについて１回ずつステップＳ１１８が実行されるからである。ステップＳ１２６でのインクリメントとステップＳ１１８でのデクリメントの組み合わせは、検出部４４により検出されるキャプチャロスの回数を、解析情報テーブル４８のキャプチャロス数フィールドに反映するための方法の一例である。検出部４４により検出されるキャプチャロスの回数とは、換言すれば、今回キャプチャされたデータパケットのＩＰ−ＩＤと、図１に関して説明した「前回データパケット」のＩＰ−ＩＤとの差が閾値より大きかった回数である。
さらに、ステップＳ１１８では、コネクション管理テーブル４７においてコネクションＩＤが「１−１」のエントリの逆転範囲も更新される。具体的には、ステップＳ１１７で上記のとおり暫定キャプチャロス範囲フィールドから転写された「１００１以上１２０１未満」という範囲の下限が、１００１から１１０１（＝１００１＋１００）へと更新される。
なぜなら、「１００１以上１２０１未満」という範囲のうちの、「１００１以上１１０１未満」という範囲のオクテットは、今回キャプチャされたデータパケットＤ１３に含まれるからである。よって、順序逆転に起因して今後キャプチャされると予測される１つ以上のデータパケットは、具体的には、残りの「１１０１以上１２０１未満」という範囲のオクテットをデータペイロードに含むような１つ以上のデータパケットである。
したがって、コネクション管理テーブル４７においてコネクションＩＤが「１−１」のエントリの逆転範囲の下限は、上記のように、データパケットＤ１３のシーケンス番号とＴＣＰデータ長の和である１１０１という値に更新される。その結果、逆転範囲フィールドには「１１０１以上１２０１未満」という範囲が記録されることになる。
さて、以上説明したようなステップＳ１１８の実行後、ステップＳ１１９が実行される。ここで、データパケットＤ１３のシーケンス番号は図６のとおり１００１である。また、コネクション管理テーブル４７ｃのとおり、最大シーケンス番号は９０１である。１００１＞９０１であるから、次にステップＳ１２０が実行される。
そして、ステップＳ１２０では、データパケットＤ１３のシーケンス番号である１００１という値が、最大シーケンス番号として記憶される。ステップＳ１２０ではさらに、データパケットＤ１３のシーケンス番号とＴＣＰデータ長の和である１１０１（＝１００１＋１００）という値が、ＡＣＫ期待値として記憶される。
そして、ステップＳ１２１では、データパケットＤ１３のＩＰ−ＩＤである１０１という値が、「１−１」というコネクションＩＤのエントリにＩＰ−ＩＤとして記憶される。また、データパケットＤ１３のＴＣＰデータ長は、記憶されている１００という最大長さ以下であるから、最大長さは更新されない。
図９のコネクション管理テーブル４７ｄに示した、コネクションＩＤが「１−１」のエントリは、時刻Ｔ１５でのデータパケットＤ１３のキャプチャを契機として以上のようにしてステップＳ１２１までの処理が行われた後の状態を示す。
なお、この後、ステップＳ１２２では「逆方向のサブコネクションは未解析」と判断され、ステップＳ１２３では、コネクションＩＤが「１−２」のサブコネクションが選択される。そして、データパケットＤ１３のＡＣＫ番号に応じて、ステップＳ１２４以降の処理が適宜実行され、その後、ネットワーク監視装置４０は再度ステップＳ１０１でパケットの受信を待つ。
すると、時刻Ｔ１６にデータパケットＤ１４がキャプチャされ、続いて、ステップＳ１０２とＳ１０９が実行される。説明の便宜上、ステップＳ１０９では、コネクションＩＤが「１−１」のサブコネクションが選択されたものとする。
すると、データパケットＤ１４の送信方向は、選択サブコネクションにとってのデータ方向であるから、ステップＳ１１１が実行される。また、データパケットＤ１４はデータペイロードを含むので、次にステップＳ１１２が実行される。
ここで、コネクション管理テーブル４７ｄに示すように、コネクションＩＤが「１−１」のエントリに記憶されている最大ＡＣＫ番号は１２０１である。また、データパケットＤ１４のシーケンス番号は、図６に示すように１１０１である。１１０１＜１２０１であるから、次に、ステップＳ１１３が実行される。
ここで、コネクション管理テーブル４７ｄに示すように、コネクションＩＤが「１−１」のエントリにおける逆転範囲フィールドには、「１１０１以上１２０１未満」という範囲が記憶されている。よって、ステップＳ１１３では、「１１０１というシーケンス番号は、逆転範囲内」と判断される。つまり、「１１０１というシーケンス番号を有するデータパケットＤ１４は、検出済みの逆転範囲に含まれる」と判断される。
その結果、次にステップＳ１１８が実行される。具体的には、解析情報テーブル４８においてコネクションＩＤが「１−１」のエントリにおいて、複製時逆転数が１だけインクリメントされ、キャプチャロス数が１だけデクリメントされる。その結果、ＡＣＫパケットＡ１４がキャプチャされたときのステップＳ１２６での暫定的なインクリメントの影響は、なくなる。
さらに、ステップＳ１１８では、コネクション管理テーブル４７においてコネクションＩＤが「１−１」のエントリの逆転範囲も更新される。具体的には、逆転範囲フィールドがクリアされる。
なぜなら、逆転範囲フィールドに現在記憶されている「１１０１以上１２０１未満」という範囲のオクテットは、すべて、今回キャプチャされたデータパケットＤ１４に含まれるからである。このことは、データパケットＤ１４のシーケンス番号とＴＣＰデータ長から明らかである。
そして、以上説明したようなステップＳ１１８の実行後、ステップＳ１１９が実行される。ここで、データパケットＤ１４のシーケンス番号は図６のとおり１１０１である。また、コネクション管理テーブル４７ｄのとおり、最大シーケンス番号は１００１である。１１０１＞１００１であるから、次にステップＳ１２０が実行される。
そして、ステップＳ１２０では、データパケットＤ１４のシーケンス番号である１１０１という値が、最大シーケンス番号として記憶される。ステップＳ１２０ではさらに、データパケットＤ１４のシーケンス番号とＴＣＰデータ長の和である１２０１（＝１１０１＋１００）という値が、ＡＣＫ期待値として記憶される。
そして、ステップＳ１２１では、データパケットＤ１４のＩＰ−ＩＤである１０２という値が、「１−１」というコネクションＩＤのエントリにＩＰ−ＩＤとして記憶される。また、データパケットＤ１４のＴＣＰデータ長は、記憶されている１００という最大長さ以下であるから、最大長さは更新されない。
図９のコネクション管理テーブル４７ｅに示した、コネクションＩＤが「１−１」のエントリは、時刻Ｔ１６でのデータパケットＤ１４のキャプチャを契機として以上のようにしてステップＳ１２１までの処理が行われた後の状態を示す。
なお、この後、ステップＳ１２２では「逆方向のサブコネクションは未解析」と判断され、ステップＳ１２３では、コネクションＩＤが「１−２」のサブコネクションが選択される。そして、データパケットＤ１４のＡＣＫ番号に応じて、ステップＳ１２４以降の処理が適宜実行され、その後、ネットワーク監視装置４０は再度ステップＳ１０１でパケットの受信を待つ。
すると、時刻Ｔ１７にデータパケットＤ１５がキャプチャされ、続いて、ステップＳ１０２とＳ１０９が実行される。説明の便宜上、ステップＳ１０９では、コネクションＩＤが「１−１」のサブコネクションが選択されたものとする。
すると、データパケットＤ１５の送信方向は、選択サブコネクションにとってのデータ方向であるから、ステップＳ１１１が実行される。また、データパケットＤ１５はデータペイロードを含むので、次にステップＳ１１２が実行される。
ここで、コネクション管理テーブル４７ｅに示すように、コネクションＩＤが「１−１」のエントリに記憶されている最大ＡＣＫ番号は１２０１である。また、図６に示すようにデータパケットＤ１５のシーケンス番号は１２０１である。よって、シーケンス番号が最大ＡＣＫ番号以上なので、ステップＳ１１２の次にはステップＳ１１９が実行される。
また、コネクション管理テーブル４７ｅに示すように、コネクションＩＤが「１−１」のエントリに記憶されている最大シーケンス番号は、１１０１である。よって、データパケットＤ１５のシーケンス番号である１２０１という値の方が、最大シーケンス番号より大きい。そのため、次にステップＳ１２０が実行される。
そして、ステップＳ１２０では、データパケットＤ１５のシーケンス番号である１２０１という値が、最大シーケンス番号として記憶される。ステップＳ１２０ではさらに、データパケットＤ１５のシーケンス番号とＴＣＰデータ長の和である１３０１（＝１２０１＋１００）という値が、ＡＣＫ期待値として記憶される。
そして、ステップＳ１２１では、データパケットＤ１５のＩＰ−ＩＤである１０３という値が、「１−１」というコネクションＩＤのエントリにＩＰ−ＩＤとして記憶される。また、データパケットＤ１５のＴＣＰデータ長は、記憶されている１００という最大長さ以下であるから、最大長さは更新されない。
その後、ステップＳ１２２では「逆方向のサブコネクションは未解析」と判断され、ステップＳ１２３では、コネクションＩＤが「１−２」のサブコネクションが選択される。そして、データパケットＤ１５のＡＣＫ番号に応じて、ステップＳ１２４以降の処理が適宜実行され、その後、ネットワーク監視装置４０は再度ステップＳ１０１でパケットの受信を待つ。
以上説明したように、図１１〜１４の処理によれば、各パケットのキャプチャのたびに図９のコネクション管理テーブル４７が適切に更新されるので、図６のような適切な判断が下される。そのため、図１０の解析情報テーブル４８の各種フィールドを使ってカウントされる種々のカウント値の信頼性も高く、その結果、パケット解析の精度も高い。
また、図１１〜１４の処理によれば、１つのコネクション上で互いに逆方向に流れる２つのデータストリームについての２つのエントリを用いた、データストリームごとの管理が可能である。換言すれば、１つのコネクションに含まれる２つのサブコネクションについての２つのエントリを用いた、サブコネクションごとの管理が可能である。つまり、図１１〜１４の処理によれば、２つのうちどちらのデータストリームに関して順序逆転が生じたとしても、検出部４４は適切な判断を下すことができる。
ところで、図１１〜１４のフローチャートには、キャプチャロスと再送が生じた場合と、順序逆転が生じた場合の判別に関わる種々のステップが例示されているが、ネットワーク監視装置４０は、さらに他の処理を行ってもよい。例えば、ネットワーク監視装置４０が不図示の解析部を有してもよく、解析部が解析情報テーブル４８に基づいてネットワークロス数やネットワークロス率などを推定してもよい。検出部４４は、具体的には解析部の中のモジュールであってもよい。
あるいは、解析部ではなく、検出部４４が、ネットワークロス数やネットワークロス率などの推定をさらに行ってもよい。そのために、解析情報テーブル４８には、ネットワークロス数のフィールドが追加されてもよい。
例えば、ステップＳ１２４で「最大ＡＣＫ番号が対象パケットのＡＣＫ番号以上である」と判断した場合、検出部４４は、ステップＳ１２２を実行する前に、「同じＡＣＫ番号のＡＣＫパケットが重複して２回以上送信されたのか否か」をチェックしてもよい。具体的には、最大ＡＣＫ番号が対象パケットのＡＣＫ番号と等しければ、検出部４４は、「重複ＡＣＫパケットが送信された」と検出し、検出した重複ＡＣＫパケットのＡＣＫ番号を記録してもよい。
例えば、コネクション管理テーブル４７の各エントリには、重複ＡＣＫパケットのＡＣＫ番号を記録するためのフィールド（以下「重複ＡＣＫ番号フィールド」という）がさらに追加されてもよい。重複ＡＣＫ番号フィールドは、ステップＳ１２４とＳ１２５の間でクリアされてもよい。
また、ステップＳ１１２で「対象パケットのシーケンス番号が最大ＡＣＫ番号以上である」と判断した場合、検出部４４は、ステップＳ１１９を実行する前に、選択サブコネクションのエントリの重複ＡＣＫ番号フィールドを参照してもよい。そして、重複ＡＣＫ番号フィールドに重複ＡＣＫ番号が記憶されている場合、検出部４４は、記憶されている重複ＡＣＫ番号と対象パケットのシーケンス番号を比べてもよい。
対象パケットのシーケンス番号と重複ＡＣＫ番号が等しい場合、検出部４４は、「ネットワークロスに起因する再送が生じた」と判断してもよい。より具体的には、検出部４４は、「今回の対象パケットと同じシーケンス番号を持つデータパケットが、かつてネットワーク上で消失し、そのせいで重複ＡＣＫパケットが送信され、重複ＡＣＫパケットに応じてデータパケットが再送された」と判断してもよい。
また、ステップＳ１１２で「対象パケットのシーケンス番号が最大ＡＣＫ番号以上である」と判断した場合、検出部４４は、さらに、重複ＡＣＫ番号フィールドの値によらず、再送に関する以下のような判断を行ってもよい。具体的には、検出部４４は、対象パケットのシーケンス番号が最大ＡＣＫ番号と等しいか否かを判断してもよい。両者が等しい場合、検出部４４はさらに、ネットワークロスと、その結果としてのタイムアウトによる再送が起きたのか否かを判断してもよい。
具体的には、検出部４４は、以下の条件がともに成り立つか否かを推定してもよい。
・対象パケットと同じシーケンス番号を持つデータパケットが、かつて送信されたことがある。
・対象パケットと同じシーケンス番号を持つデータパケットが最初に送信された時刻から、対象パケットが送信された時刻までの間隔が、ＲＴＯ（Retransmission Time-Out）以上である。
検出部４４は、コネクション管理テーブル４７中の最大シーケンス番号フィールドを参照することで、前者の条件が成立するか否かを判断してもよい。検出部４４は、前者の条件が成立すると判断した場合に、さらに、後者の条件が成立するか否かを判断してもよい。
例えば、検出部４４は、以下の２つの時間を計測し、計測結果に基づいて、ホスト３１と３２の間のＲＴＴを推定してもよい。
・ホスト３１からホスト３２へ送信されるデータパケットのキャプチャ時刻から、当該データパケットに対するＡＣＫパケットのキャプチャ時刻までの時間。
・ホスト３２からホスト３１へ送信されるデータパケットのキャプチャ時刻から、当該データパケットに対するＡＣＫパケットのキャプチャ時刻までの時間。
また、ネットワーク監視装置４０は、実際には、ホスト３１や３２にパケットを送信するわけではない。しかし、検出部４４は、擬似的に、ホスト３１とネットワーク監視装置４０の間のＲＴＴや、ネットワーク監視装置４０とホスト３２の間のＲＴＴなどを推定してもよい。例えば、上記２つの時間のうち、前者の時間が、ネットワーク監視装置４０とホスト３２の間の擬似的なＲＴＴとして推定されてもよい。同様に、後者の時間が、ネットワーク監視装置４０とホスト３１の間の擬似的なＲＴＴとして推定されてもよい。
検出部４４は、上記のようなＲＴＴの推定のために、各パケットのキャプチャ時刻をＲＡＭ５２などに一時的に記憶してもよい。検出部４４は、推定した擬似的なＲＴＴと、キャプチャ時刻とに基づいて、対象パケットと同じシーケンス番号を持つデータパケットが最初に送信された時刻を推定してもよい。同様に、検出部４４は、対象パケットが送信された時刻を推定してもよい。
また、ホスト３１とホスト３２の間のＲＴＴの４倍の値に適宜の値（例えばＲＴＴの標準偏差）を足した和が、ＲＴＯとして使われることが多い。よって、検出部４４は、推定したＲＴＴからＲＴＯを推定してもよい。
以上のような種々の推定値を使うことで、検出部４４は、「対象パケットと同じシーケンス番号を持つデータパケットが最初に送信された時刻から、対象パケットが送信された時刻までの間隔が、ＲＴＯ以上であるか否か」を推定してもよい。当該間隔がＲＴＯ以上であると推定した場合、検出部４４は、「ネットワークロスと、タイムアウトによる再送が生じた」と判断してもよい。
例えば以上例示したように、ステップＳ１１２で「対象パケットのシーケンス番号が最大ＡＣＫ番号以上である」と判断した場合、検出部４４は、「ネットワークロスに起因する再送が生じたか否か」を判断してもよい。そして、「ネットワークロスに起因する再送が生じた」と判断した場合、検出部４４は、解析情報テーブル４８の選択サブコネクションのエントリにおいて、再送数を１だけインクリメントするとともに、ネットワークロス数を１だけインクリメントしてもよい。
例えば以上説明したようにして、再送数やネットワークロス数の推定が行われてもよい。
ところで、本発明は上記実施形態に限られるものではない。上記の説明においてもいくつかの変形について説明したが、上記実施形態は、さらに例えば下記の観点から様々に変形することもできる。上記および下記の変形は、相互に矛盾しない限り、任意に組み合わせることが可能である。
例えば、図１１〜１４の処理は、パケット解析のための他の適宜のアルゴリズムと組み合わされてもよく、組み合わせに応じて適宜変更されてもよい。例えば、再送率やネットワークロス率の推定を行うステップが、図１１〜１４のフローチャートに追加されてもよい。また、出力制御部４５による出力インタフェイス４６を介した出力装置４９への出力は、図１１〜１４の処理とは独立したタイミングで行われてもよいし、例えば所定数のパケットのキャプチャのたびに１回行われてもよい。
図９のコネクション管理テーブル４７には最大長さフィールドがあり、最大長さフィールドはステップＳ１２１で必要に応じて更新される。よって、例えばコネクションＩＤが「１−１」のエントリにおける最大長さフィールドには、コネクションＩＤが「１−１」のサブコネクションのデータ方向に今まで送信された全データパケットのＴＣＰデータ長のうちの、最大値が記録される。
しかし、最大値以外の統計値が使われてもよい。例えば、コネクションＩＤが「１−１」のサブコネクションのデータ方向に今まで送信された全データパケットのＴＣＰデータ長のヒストグラムを、管理部４３または検出部４４が作成してもよい。そして、「ペイロードが長い方から上位Ｘ１％以内の長さ」や「ペイロードが長い方から上位Ｘ２位以内の長さ」などの統計値が使われてもよい（Ｘ１とＸ２は予め決められた値であるものとする）。
あるいは、ステップＳ１２１での最大長さフィールドの動的な更新は省略されてもよい。その代わり、コネクション確立の際のネゴシエーションにより通知されるＭＳＳの値が、ＳＹＮパケットまたはＳＹＮ／ＡＣＫパケットがキャプチャされた際に、ステップＳ１０１で抽出部４２によりＴＣＰヘッダから抽出されてもよい。こうして抽出されたＭＳＳの値を、管理部４３がステップＳ１０６で最大長さフィールドに設定してもよい。そして、ステップＳ１１５やＳ１２６での暫定ロス数の算出においては、こうして静的に設定された最大長さ（すなわちＭＳＳ）が利用されてもよい。
ところで、ＴＣＰのＡＣＫ番号は、累積確認応答方式による番号である。しかし、ＴＣＰの実装によっては、累積確認応答方式による通常のＡＣＫ番号に加えて、オプショナルにＳＡＣＫ（selective acknowledgment）が利用されることがある。ＳＡＣＫが利用される場合、図１１〜１４の処理とコネクション管理テーブル４７が適宜変形されてもよい。
例えば、コネクション管理テーブル４７には、今までにＳＡＣＫオプションを使って通知された範囲のうち、最大ＡＣＫ番号より大きい範囲を記憶しておくためのフィールド（以下「ＳＡＣＫ範囲フィールドという」）が追加されてもよい。コネクション管理テーブル４７中のＳＡＣＫ範囲フィールドは、空の場合もあり得るし、１つ以上のオクテット範囲が列挙されている場合もあり得る。例えば、ステップＳ１２７とＳ１２２の間で、以下の情報に基づいて検出部４４がＳＡＣＫ範囲フィールドを適宜更新してもよい。
・コネクション管理テーブル４７中の最大ＡＣＫ番号フィールドの現在の値。
・コネクション管理テーブル４７中のＳＡＣＫ範囲フィールドの現在の内容（つまり、空リスト、または、１つ以上のオクテット範囲のリスト）。
・対象パケット中のＴＣＰヘッダ内でＳＡＣＫオプションにより通知されている内容（つまり、空リスト、または、１つ以上のオクテット範囲のリスト）。
ＳＡＣＫオプションが使われる場合、図１１〜１４の処理においては、ステップＳ１１２とＳ１２４とＳ１２５が変形されてもよい。
具体的には、互いに排他な以下の２つの条件の一方がステップＳ１１２において成立する場合に、次にＳ１１３が実行されてもよい。逆に、どちらの条件もステップＳ１１２において成立しない場合に、次にＳ１１９が実行されてもよい。
・コネクション管理テーブル４７中のＳＡＣＫ範囲フィールドが空であり、かつ、対象パケットのシーケンス番号の方が最大ＡＣＫ番号より小さい。
・コネクション管理テーブル４７中のＳＡＣＫ範囲フィールドに１つ以上のオクテット範囲が列挙されており、かつ、そのうちの最後のオクテット位置を示す数値よりも、対象パケットのシーケンス番号の方が小さい。
また、以下の２つの条件のうち少なくとも１つがステップＳ１２４において成立する場合に、次にステップＳ１２５が実行されてもよい。逆に、どちらの条件もステップＳ１２４において成立しない場合には、次に、ステップＳ１２２が実行されてもよい。
・対象パケットのＡＣＫ番号が最大ＡＣＫ番号より大きい。
・コネクション管理テーブル４７中のＳＡＣＫ範囲フィールドには記録されていない１つ以上の範囲が、対象パケットにおいて、ＳＡＣＫオプションを使ってオプションフィールド内に指定されている。
そして、以下の２つの条件のうち少なくとも１つがステップＳ１２５において成立する場合に、検出部４４は「未キャプチャのデータパケットに対するＡＣＫおよび／またはＳＡＣＫが通知された」と判断してもよい。その結果、次にステップＳ１２６が実行されてもよい。逆に、どちらの条件もステップＳ１２５において成立しない場合には、検出部４４は、「今回通知されたＡＣＫおよび／またはＳＡＣＫは、キャプチャ済みのいずれかのデータパケットに対応する」と判断してもよい。その結果、次にステップＳ１２７が実行されてもよい。
・コネクション管理テーブル４７中のＡＣＫ期待値より、対象パケットのＡＣＫ番号の方が大きい。
・コネクション管理テーブル４７中のＡＣＫ期待値より大きな番号の範囲が、対象パケットにおいて、ＳＡＣＫオプションを使ってオプションフィールド内に指定されている。
なお、以上のようにＳＡＣＫオプションが使われる場合において、もし、現在の最大ＡＣＫ番号が対象パケットのＡＣＫ番号以上であれば、ステップＳ１２７では最大ＡＣＫ番号の更新は省略される。
ところで、上記のステップＳ１１２、Ｓ１１３、Ｓ１１４、Ｓ１１９、Ｓ１２４、およびＳ１２５では、ＴＣＰヘッダ中の番号を用いた比較が行われる。図１１〜１４についての説明では、説明の簡単化のために、例えば「シーケンス番号が最大ＡＣＫ番号未満である」などの単純な表現を用いたが、実際には番号のラップアラウンド（wrap-around）が生じ得る。
よって、ＴＣＰヘッダ中の番号を用いた比較においては、ラップアラウンドを考慮した比較が行われる。同様に、ＩＰ−ＩＤもラップアラウンドする可能性がある。よって、ステップＳ１１５におけるＩＰ−ＩＤを用いた比較においても、ラップアラウンドが考慮に入れられる。
ラップアラウンドを考慮に入れるために、例えば、ＴＣＰヘッダ中のオプションフィールドに含まれるタイムスタンプが使われてもよい。また、ラップアラウンドを考慮に入れた比較のために、各パケットがキャプチャされた時刻が使われてもよい。
なお、パケットのキャプチャ時刻は、他にも、ステップＳ１１５の判断をより正確にするために利用されてもよい。ここで、キャプチャ過程での順序逆転が生じるのは、データパケットのキャプチャ時刻とＡＣＫパケットのキャプチャ時刻が近い場合である。よって、例えば、データパケットのキャプチャ時刻とＡＣＫパケットのキャプチャ時刻との差が所定の閾値より短く、かつ、式（２）が成り立たない場合にのみ、検出部４４は、「順序逆転が生じた」と判断してもよい。
ところで、図９ではコネクション管理テーブル４７および４７ａ〜４７ｅをテーブル形式で例示し、図１０では解析情報テーブル４８および４８ｂをテーブル形式で例示した。しかし、テーブル以外の他のデータ形式が利用されてもよい。
なお、上記の説明では、第１の通信プロトコルがＩＰバージョン４であり、第２の通信プロトコルがＴＣＰである場合について特に詳しく説明した。しかし、図１に関する説明から明らかなように、識別用の数値を各パケットに割り当てるような、コネクションレスな他の通信プロトコルが、ＩＰバージョン４の代わりに第１の通信プロトコルとして使われてもよい。同様に、第１の通信プロトコルよりも上位の層で定義されており再送手順を有するような、コネクション指向の他のプロトコルが、ＴＣＰの代わりに第２の通信プロトコルとして使われてもよい。
最後に、上記の種々の実施形態に関して、さらに下記の付記を開示する。
（付記１）
コンピュータに、
識別用の数値を各パケットに割り当てる第１の通信プロトコルと、前記第１の通信プロトコルより上位の層で定義されるコネクション指向の第２の通信プロトコルにしたがって第１の装置と第２の装置の間で送受信される個々のパケットを、キャプチャし、
前記第１の装置から送信された第１のデータパケットに対して前記第２の装置から送信された確認応答パケットがキャプチャされた時点では、前記第１のデータパケットがキャプチャされておらず、かつ、前記第２の通信プロトコルによるコネクション上で前記第２の装置が前記第１の装置から次に受信すると期待するデータパケットの識別用に前記確認応答パケットが含む第１の数値よりも、前記第１の装置から送信されて前記確認応答パケットの後にキャプチャされた第２のデータパケットが前記コネクション上での識別用に含む第２の数値の方が前の順序を示す場合、前記第１の通信プロトコルにより前記第２のデータパケットに割り当てられた第３の数値と、前記第１の装置から送信されて前記確認応答パケットより前にキャプチャされたデータパケットの中では最も遅くキャプチャされた前回データパケットに前記第１の通信プロトコルにより割り当てられた第４の数値との差に基づき、キャプチャされた前記第２のデータパケットが前記確認応答パケットより遅れてキャプチャされた前記第１のデータパケットなのか否かを判断する
ことを含む処理を実行させるパケット解析プログラム。
（付記２）
前記差が、前記第１の数値と、前記コネクション上での識別用に前記前回データパケットが含む第５の数値とに応じて決まる閾値以下の場合に、キャプチャされた前記第２のデータパケットは前記確認応答パケットより遅れてキャプチャされた前記第１のデータパケットである、と判断される
ことを特徴とする付記１に記載のパケット解析プログラム。
（付記３）
前記差が前記閾値よりも大きい場合、前記第１の装置が前記第２の通信プロトコルによる再送手順にしたがって前記第１のデータパケットと同じ数値を含めて再送したデータパケットを、前記コンピュータが前記第２のデータパケットとしてキャプチャしたのだ、と判断する
ことを前記処理がさらに含むことを特徴とする付記２に記載のパケット解析プログラム。
（付記４）
前記閾値は、前記第１の数値、前記第５の数値、前記前回データパケットのサイズ、および、前記コネクション上で前記第１の装置から前記第２の装置へ送信される複数のデータパケットのサイズに関するサイズ値に基づく
ことを特徴とする付記２または３に記載のパケット解析プログラム。
（付記５）
前記サイズ値は、前記コネクション上で前記第１の装置から前記第２の装置へ送信される前記複数のデータパケットの中での相対比較において、所定の基準以上に長いペイロード長である
ことを特徴とする付記４に記載のパケット解析プログラム。
（付記６）
前記サイズ値は、前記コネクション上で前記第１の装置から前記第２の装置へ送信される前記複数のデータパケットの中で最長のペイロード長である
ことを特徴とする付記５に記載のパケット解析プログラム。
（付記７）
前記確認応答パケットは、１つ以上の前記第１のデータパケットを前記第２の装置が受信したことを示し、
前記閾値は、前記１つ以上の前記第１のデータパケットのうち、前記コンピュータがキャプチャに失敗したデータパケットの個数の推定値である
ことを特徴とする付記２から６のいずれか１項に記載のパケット解析プログラム。
（付記８）
前記コネクション上で前記第１の装置から前記第２の装置へ向けて送信されたデータパケットと前記コネクション上で前記第２の装置から前記第１の装置に送信された確認応答パケットとの間でキャプチャの過程で生じる順序の逆転の回数である第１の逆転回数を数えるか、または、前記コネクション上で前記第２の装置から前記第１の装置へ向けて送信されたデータパケットと前記コネクション上で前記第１の装置から前記第２の装置に送信された確認応答パケットとの間でキャプチャの過程で生じる順序の逆転の回数である第２の逆転回数と前記第１の逆転回数との和を数えるための、逆転カウント値を、前記差が前記閾値以下の場合にインクリメントする
ことを前記処理がさらに含むことを特徴とする付記２から７のいずれか１項に記載のパケット解析プログラム。
（付記９）
前記コネクション上で前記第１の装置から前記第２の装置へ向かう方向に送信されたのに前記コンピュータがキャプチャに失敗したデータパケットの数を数えるか、または前記コネクション上で送信されたのに前記コンピュータがキャプチャに失敗したデータパケットの数を方向によらず数えるための、ロスカウント値に、前記第３の数値と前記第４の数値との前記差が前記閾値よりも大きかった回数を反映させる
ことを前記処理がさらに含むことを特徴とする付記２から８のいずれか１項に記載のパケット解析プログラム。
（付記１０）
前記コネクション上で前記第１の装置から前記第２の装置へ向かう方向に生じた再送の回数を数えるか、または前記コネクション上で生じた再送の回数を方向によらず数えるための、再送カウント値を、前記第３の数値と前記第４の数値との前記差が前記閾値よりも大きい場合にインクリメントする
ことを前記処理がさらに含むことを特徴とする付記２から９のいずれか１項に記載のパケット解析プログラム。
（付記１１）
前記第１の通信プロトコルがInternet Protocolであり、前記第２の通信プロトコルがTransmission Control Protocolであることを特徴とする付記１から１０のいずれか１項に記載のパケット解析プログラム。
（付記１２）
コンピュータが、
識別用の数値を各パケットに割り当てる第１の通信プロトコルと、前記第１の通信プロトコルより上位の層で定義されるコネクション指向の第２の通信プロトコルにしたがって第１の装置と第２の装置の間で送受信される個々のパケットを、キャプチャし、
前記第１の装置から送信された第１のデータパケットに対して前記第２の装置から送信された確認応答パケットがキャプチャされた時点では、前記第１のデータパケットがキャプチャされておらず、かつ、前記第２の通信プロトコルによるコネクション上で前記第２の装置が前記第１の装置から次に受信すると期待するデータパケットの識別用に前記確認応答パケットが含む第１の数値よりも、前記第１の装置から送信されて前記確認応答パケットの後にキャプチャされた第２のデータパケットが前記コネクション上での識別用に含む第２の数値の方が前の順序を示す場合、前記第１の通信プロトコルにより前記第２のデータパケットに割り当てられた第３の数値と、前記第１の装置から送信されて前記確認応答パケットより前にキャプチャされたデータパケットの中では最も遅くキャプチャされた前回データパケットに前記第１の通信プロトコルにより割り当てられた第４の数値との差に基づき、キャプチャされた前記第２のデータパケットが前記確認応答パケットより遅れてキャプチャされた前記第１のデータパケットなのか否かを判断する
ことを特徴とするパケット解析方法。
（付記１３）
第１の装置と第２の装置の間で送受信される個々のパケットを、キャプチャして解析するパケット解析装置であって、
識別用の数値を各パケットに割り当てる第１の通信プロトコルと、前記第１の通信プロトコルより上位の層で定義されるコネクション指向の第２の通信プロトコルにしたがって前記第１の装置から送信された第１のデータパケットに対して、前記第２の装置から送信された確認応答パケットを、前記パケット解析装置がキャプチャした時点では、前記第１のデータパケットがキャプチャされておらず、かつ、前記第２の通信プロトコルによるコネクション上で前記第２の装置が前記第１の装置から次に受信すると期待するデータパケットの識別用に前記確認応答パケットが含む第１の数値よりも、前記第１の装置から送信されて前記確認応答パケットの後にキャプチャされた第２のデータパケットが前記コネクション上での識別用に含む第２の数値の方が前の順序を示す場合、前記第１の通信プロトコルにより前記第２のデータパケットに割り当てられた第３の数値と、前記第１の装置から送信されて前記確認応答パケットより前にキャプチャされたデータパケットの中では最も遅くキャプチャされた前回データパケットに前記第１の通信プロトコルにより割り当てられた第４の数値との差に基づき、キャプチャされた前記第２のデータパケットが前記確認応答パケットより遅れてキャプチャされた前記第１のデータパケットなのか否かを判断する判断手段
を備えることを特徴とするパケット解析装置。
（付記１４）
第１の装置と第２の装置の間で送受信される個々のパケットを、前記第１の装置と前記第２の装置との間の通信路の途中で取り出すネットワーク装置と、
前記ネットワーク装置に接続されており、前記ネットワーク装置を介して前記個々のパケットをキャプチャし、前記個々のパケットを解析するパケット解析装置であって、
識別用の数値を各パケットに割り当てる第１の通信プロトコルと、前記第１の通信プロトコルより上位の層で定義されるコネクション指向の第２の通信プロトコルにしたがって前記第１の装置から送信された第１のデータパケットに対して、前記第２の装置から送信された確認応答パケットを、前記パケット解析装置がキャプチャした時点では、前記第１のデータパケットがキャプチャされておらず、かつ、前記第２の通信プロトコルによるコネクション上で前記第２の装置が前記第１の装置から次に受信すると期待するデータパケットの識別用に前記確認応答パケットが含む第１の数値よりも、前記第１の装置から送信されて前記確認応答パケットの後にキャプチャされた第２のデータパケットが前記コネクション上での識別用に含む第２の数値の方が前の順序を示す場合、前記第１の通信プロトコルにより前記第２のデータパケットに割り当てられた第３の数値と、前記第１の装置から送信されて前記確認応答パケットより前にキャプチャされたデータパケットの中では最も遅くキャプチャされた前回データパケットに前記第１の通信プロトコルにより割り当てられた第４の数値との差に基づき、キャプチャされた前記第２のデータパケットが前記確認応答パケットより遅れてキャプチャされた前記第１のデータパケットなのか否かを判断する判断手段を備えるパケット解析装置と、
を備えることを特徴とするパケット解析システム。
（付記１５）
前記ネットワーク装置が、前記パケット解析装置に接続されるモニタポートを有するネットワークタップであるか、または、前記パケット解析装置に接続されるミラーポートを有するスイッチもしくはルータである
ことを特徴とする付記１４に記載のパケット解析システム。
（付記１６）
前記パケット解析装置が、
前記第１の装置から前記第２の装置へ向けて送信される個々のパケットを前記ネットワーク装置から受信する第１の通信インタフェイスと、
前記第２の装置から前記第１の装置へ向けて送信される個々のパケットを前記ネットワーク装置から受信する第２の通信インタフェイスと、
前記第１の通信インタフェイスで受信した前記個々のパケットと前記第２の通信インタフェイスで受信した前記個々のパケットを記憶する記憶手段
を備えることを特徴とする付記１４または１５に記載のパケット解析システム。
（付記１７）
前記パケット解析装置が、
前記第１の装置から前記第２の装置へ向けて送信される個々のパケットと、前記第２の装置から前記第１の装置へ向けて送信される個々のパケットの双方を、前記ネットワーク装置から受信する通信インタフェイス
を備えることを特徴とする付記１４または１５に記載のパケット解析システム。
１ 第１の装置
２ 第２の装置
３ パケット解析装置
４、５ 通過点
Ｅ１〜Ｅ３ 動作例
Ｄ０、Ｄ１、Ｄ１１〜Ｄ１５、Ｌ１１、Ｌ１２ データパケット
Ａ１、Ａ１２、Ａ１４ ＡＣＫパケット
Ｒ１ 再送パケット
Ｔ１〜Ｔ６、Ｔ１１〜Ｔ１７ 時刻
１０ａ、１０ｂ パケット解析システム
１１、１２、２１、２２、３１、３２ ホスト
１３ａ、１３ｂ、３４ ネットワーク装置
１４ａ、１４ｂ、１５ａ、１５ｂ、１６ａ、１６ｂ、１６ｃ、３５〜３７ ポート
１７ａ、１７ｂ、４０ ネットワーク監視装置
１８ バッファ
Ｐ１〜Ｐ３ パケット
２３ キャプチャ地点
２４ 逆転範囲
３３ ネットワーク
４１、５３ａ、５３ｂ 通信インタフェイス
４２ 抽出部
４３ 管理部
４４ 検出部
４５ 出力制御部
４６ 出力インタフェイス
４７、４７ａ〜４７ｅ コネクション管理テーブル
４８、４８ｂ 解析情報テーブル
４９、５５ 出力装置
５０ コンピュータ
５１ ＣＰＵ
５２ ＲＡＭ
５４ 入力装置
５６ 記憶装置
５７ 駆動装置
５８ バス
６０ 記憶媒体

Claims (9)

  1. コンピュータに、
    識別用の数値を各パケットに割り当てる第１の通信プロトコルと、前記第１の通信プロトコルより上位の層で定義されるコネクション指向の第２の通信プロトコルにしたがって第１の装置と第２の装置の間で送受信される個々のパケットを、キャプチャし、
    前記第１の装置から送信された第１のデータパケットに対して前記第２の装置から送信された確認応答パケットがキャプチャされた時点では、前記第１のデータパケットがキャプチャされておらず、かつ、前記第２の通信プロトコルによるコネクション上で前記第２の装置が前記第１の装置から次に受信すると期待するデータパケットの識別用に前記確認応答パケットが含む第１の数値よりも、前記第１の装置から送信されて前記確認応答パケットの後にキャプチャされた第２のデータパケットが前記コネクション上での識別用に含む第２の数値の方が前の順序を示す場合、前記第１の通信プロトコルにより前記第２のデータパケットに割り当てられた第３の数値と、前記第１の装置から送信されて前記確認応答パケットより前にキャプチャされたデータパケットの中では最も遅くキャプチャされた前回データパケットに前記第１の通信プロトコルにより割り当てられた第４の数値との差に基づき、キャプチャされた前記第２のデータパケットが前記確認応答パケットより遅れてキャプチャされた前記第１のデータパケットなのか否かを判断する
    ことを含む処理を実行させるパケット解析プログラム。
  2. 前記差が、前記第１の数値と、前記コネクション上での識別用に前記前回データパケットが含む第５の数値とに応じて決まる閾値以下の場合に、キャプチャされた前記第２のデータパケットは前記確認応答パケットより遅れてキャプチャされた前記第１のデータパケットである、と判断される
    ことを特徴とする請求項１に記載のパケット解析プログラム。
  3. 前記差が前記閾値よりも大きい場合、前記第１の装置が前記第２の通信プロトコルによる再送手順にしたがって前記第１のデータパケットと同じ数値を含めて再送したデータパケットを、前記コンピュータが前記第２のデータパケットとしてキャプチャしたのだ、と判断する
    ことを前記処理がさらに含むことを特徴とする請求項２に記載のパケット解析プログラム。
  4. 前記閾値は、前記第１の数値、前記第５の数値、前記前回データパケットのサイズ、および、前記コネクション上で前記第１の装置から前記第２の装置へ送信される複数のデータパケットのサイズに関するサイズ値に基づく
    ことを特徴とする請求項２または３に記載のパケット解析プログラム。
  5. 前記サイズ値は、前記コネクション上で前記第１の装置から前記第２の装置へ送信される前記複数のデータパケットの中で最長のペイロード長である
    ことを特徴とする請求項４に記載のパケット解析プログラム。
  6. 前記コネクション上で前記第１の装置から前記第２の装置へ向けて送信されたデータパケットと前記コネクション上で前記第２の装置から前記第１の装置に送信された確認応答パケットとの間でキャプチャの過程で生じる順序の逆転の回数である第１の逆転回数を数えるか、または、前記コネクション上で前記第２の装置から前記第１の装置へ向けて送信されたデータパケットと前記コネクション上で前記第１の装置から前記第２の装置に送信された確認応答パケットとの間でキャプチャの過程で生じる順序の逆転の回数である第２の逆転回数と前記第１の逆転回数との和を数えるための、逆転カウント値を、前記差が前記閾値以下の場合にインクリメントする
    ことを前記処理がさらに含むことを特徴とする請求項２から５のいずれか１項に記載のパケット解析プログラム。
  7. コンピュータが、
    識別用の数値を各パケットに割り当てる第１の通信プロトコルと、前記第１の通信プロトコルより上位の層で定義されるコネクション指向の第２の通信プロトコルにしたがって第１の装置と第２の装置の間で送受信される個々のパケットを、キャプチャし、
    前記第１の装置から送信された第１のデータパケットに対して前記第２の装置から送信された確認応答パケットがキャプチャされた時点では、前記第１のデータパケットがキャプチャされておらず、かつ、前記第２の通信プロトコルによるコネクション上で前記第２の装置が前記第１の装置から次に受信すると期待するデータパケットの識別用に前記確認応答パケットが含む第１の数値よりも、前記第１の装置から送信されて前記確認応答パケットの後にキャプチャされた第２のデータパケットが前記コネクション上での識別用に含む第２の数値の方が前の順序を示す場合、前記第１の通信プロトコルにより前記第２のデータパケットに割り当てられた第３の数値と、前記第１の装置から送信されて前記確認応答パケットより前にキャプチャされたデータパケットの中では最も遅くキャプチャされた前回データパケットに前記第１の通信プロトコルにより割り当てられた第４の数値との差に基づき、キャプチャされた前記第２のデータパケットが前記確認応答パケットより遅れてキャプチャされた前記第１のデータパケットなのか否かを判断する
    ことを特徴とするパケット解析方法。
  8. 第１の装置と第２の装置の間で送受信される個々のパケットを、キャプチャして解析するパケット解析装置であって、
    識別用の数値を各パケットに割り当てる第１の通信プロトコルと、前記第１の通信プロトコルより上位の層で定義されるコネクション指向の第２の通信プロトコルにしたがって前記第１の装置から送信された第１のデータパケットに対して、前記第２の装置から送信された確認応答パケットを、前記パケット解析装置がキャプチャした時点では、前記第１のデータパケットがキャプチャされておらず、かつ、前記第２の通信プロトコルによるコネクション上で前記第２の装置が前記第１の装置から次に受信すると期待するデータパケットの識別用に前記確認応答パケットが含む第１の数値よりも、前記第１の装置から送信されて前記確認応答パケットの後にキャプチャされた第２のデータパケットが前記コネクション上での識別用に含む第２の数値の方が前の順序を示す場合、前記第１の通信プロトコルにより前記第２のデータパケットに割り当てられた第３の数値と、前記第１の装置から送信されて前記確認応答パケットより前にキャプチャされたデータパケットの中では最も遅くキャプチャされた前回データパケットに前記第１の通信プロトコルにより割り当てられた第４の数値との差に基づき、キャプチャされた前記第２のデータパケットが前記確認応答パケットより遅れてキャプチャされた前記第１のデータパケットなのか否かを判断する判断手段
    を備えることを特徴とするパケット解析装置。
  9. 第１の装置と第２の装置の間で送受信される個々のパケットを、前記第１の装置と前記第２の装置との間の通信路の途中で取り出すネットワーク装置と、
    前記ネットワーク装置に接続されており、前記ネットワーク装置を介して前記個々のパケットをキャプチャし、前記個々のパケットを解析するパケット解析装置であって、
    識別用の数値を各パケットに割り当てる第１の通信プロトコルと、前記第１の通信プロトコルより上位の層で定義されるコネクション指向の第２の通信プロトコルにしたがって前記第１の装置から送信された第１のデータパケットに対して、前記第２の装置から送信された確認応答パケットを、前記パケット解析装置がキャプチャした時点では、前記第１のデータパケットがキャプチャされておらず、かつ、前記第２の通信プロトコルによるコネクション上で前記第２の装置が前記第１の装置から次に受信すると期待するデータパケットの識別用に前記確認応答パケットが含む第１の数値よりも、前記第１の装置から送信されて前記確認応答パケットの後にキャプチャされた第２のデータパケットが前記コネクション上での識別用に含む第２の数値の方が前の順序を示す場合、前記第１の通信プロトコルにより前記第２のデータパケットに割り当てられた第３の数値と、前記第１の装置から送信されて前記確認応答パケットより前にキャプチャされたデータパケットの中では最も遅くキャプチャされた前回データパケットに前記第１の通信プロトコルにより割り当てられた第４の数値との差に基づき、キャプチャされた前記第２のデータパケットが前記確認応答パケットより遅れてキャプチャされた前記第１のデータパケットなのか否かを判断する判断手段を備えるパケット解析装置と、
    を備えることを特徴とするパケット解析システム。
JP2013057038A 2013-03-19 2013-03-19 パケット解析プログラム、パケット解析方法、パケット解析装置、およびパケット解析システム Expired - Fee Related JP6015509B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2013057038A JP6015509B2 (ja) 2013-03-19 2013-03-19 パケット解析プログラム、パケット解析方法、パケット解析装置、およびパケット解析システム
US14/147,060 US9282017B2 (en) 2013-03-19 2014-01-03 Apparatus and method for analyzing a packet

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2013057038A JP6015509B2 (ja) 2013-03-19 2013-03-19 パケット解析プログラム、パケット解析方法、パケット解析装置、およびパケット解析システム

Publications (2)

Publication Number Publication Date
JP2014183483A JP2014183483A (ja) 2014-09-29
JP6015509B2 true JP6015509B2 (ja) 2016-10-26

Family

ID=51569070

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2013057038A Expired - Fee Related JP6015509B2 (ja) 2013-03-19 2013-03-19 パケット解析プログラム、パケット解析方法、パケット解析装置、およびパケット解析システム

Country Status (2)

Country Link
US (1) US9282017B2 (ja)
JP (1) JP6015509B2 (ja)

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9240939B2 (en) * 2013-10-22 2016-01-19 Cisco Technology, Inc. Detecting packet loss and retransmission in a network environment
US9300565B2 (en) * 2014-04-17 2016-03-29 Accedian Networks Inc. System and method for out-of-line real-time in-service performance measurement
US9635147B2 (en) * 2014-07-09 2017-04-25 The Regents Of The University Of Michigan Protocol for an electronic device to receive a data packet from an external device
CN105763474B (zh) * 2014-12-19 2019-10-25 华为技术有限公司 数据传输方法和装置
US9264370B1 (en) 2015-02-10 2016-02-16 Centripetal Networks, Inc. Correlating packets in communications networks
US9866576B2 (en) 2015-04-17 2018-01-09 Centripetal Networks, Inc. Rule-based network-threat detection
US10536357B2 (en) 2015-06-05 2020-01-14 Cisco Technology, Inc. Late data detection in data center
US10142353B2 (en) 2015-06-05 2018-11-27 Cisco Technology, Inc. System for monitoring and managing datacenters
WO2017003475A1 (en) * 2015-07-01 2017-01-05 Hewlett Packard Enterprise Development Lp Latency measurer
US10396939B2 (en) 2017-05-22 2019-08-27 Zycada Networks, Inc. Dynamic management of packet loss
CN110213024B (zh) * 2018-04-26 2021-12-31 腾讯科技（深圳）有限公司 数据包重传方法、装置及设备
CN109150651A (zh) * 2018-07-02 2019-01-04 北京市天元网络技术股份有限公司 传输资源的监控方法
US10707993B2 (en) * 2018-08-23 2020-07-07 Sr Technologies, Inc. Blind detection and synchronization of data packets
JP2020053855A (ja) * 2018-09-27 2020-04-02 株式会社日立情報通信エンジニアリング 送信装置、通信システム、送信プログラムおよび通信方法
JP7192367B2 (ja) * 2018-10-01 2022-12-20 日本電気株式会社 通信障害解析装置、通信障害解析システム、通信障害解析方法および通信障害解析プログラム
US10749765B2 (en) * 2019-01-08 2020-08-18 International Business Machines Corporation Method and system for monitoring communication in a network
US10790872B1 (en) 2019-03-25 2020-09-29 General Dynamics Mission Systems, Inc. Cooperative broadcast multi-hop network that employs broadcast flood routing and multi-hop transmission using a direct-sequence spread-spectrum (DSSS) waveform with cooperative beamforming and adaptive space-spectrum whitening
CN111464374B (zh) * 2020-02-21 2021-09-21 中国电子技术标准化研究院 网络延迟控制方法、设备及装置
US11303548B2 (en) 2020-07-31 2022-04-12 Bank Of America Corporation Network directionality mapping system
US20230188443A1 (en) * 2021-12-10 2023-06-15 Arista Networks, Inc. Packet drop analysis for networks

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5056438B2 (ja) * 2008-01-29 2012-10-24 富士通株式会社 パケット解析方法
JP4809416B2 (ja) * 2008-10-28 2011-11-09 富士通株式会社 パケットキャプチャ装置

Also Published As

Publication number Publication date
US9282017B2 (en) 2016-03-08
US20140286174A1 (en) 2014-09-25
JP2014183483A (ja) 2014-09-29

Similar Documents

Publication Publication Date Title
JP6015509B2 (ja) パケット解析プログラム、パケット解析方法、パケット解析装置、およびパケット解析システム
US8605590B2 (en) Systems and methods of improving performance of transport protocols
US10630749B2 (en) Timely delivery of real-time media problem when TCP must be used
US7593331B2 (en) Enhancing transmission reliability of monitored data
US20060221825A1 (en) Congestion control network relay device and method
CN110661723A (zh) 一种数据传输方法、计算设备、网络设备及数据传输系统
US9871878B2 (en) Network traffic accelerator
US20220029900A1 (en) Detecting sources of computer network failures
JP5867188B2 (ja) 情報処理装置、輻輳制御方法および輻輳制御プログラム
EP2760182B1 (en) Data communication apparatus, data transmission method, and computer system
CN112737940A (zh) 一种数据传输的方法和装置
JP5957318B2 (ja) ネットワークシステム、情報中継装置、及びパケット配信方法
JP6455135B2 (ja) パケット抽出装置、パケット抽出プログラムおよびパケット抽出方法
JP7003467B2 (ja) パケット分類プログラム、パケット分類方法およびパケット分類装置
JP5887324B2 (ja) 中継装置および中継方法
JP5723307B2 (ja) パケット監視システム
JP2015195511A (ja) パケット解析プログラム、パケット解析装置およびパケット解析方法
EP3100413B1 (en) Reliable network probing session
JP2004140596A (ja) Ｔｃｐ上のデータ転送における品質を推定する方法およびシステム
JP5537692B1 (ja) 品質劣化原因推定装置、品質劣化原因推定方法、品質劣化原因推定プログラム
KR20130101598A (ko) 중복응답 패킷 식별을 위한 패킷 처리장치 및 그 방법
JP2003318984A (ja) Ｐｄｕ観測方法、コネクションレス型データ通信装置、およびｐｄｕ観測装置
JP2012044278A (ja) エッジノードおよび帯域制御方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20151106

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20160826

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20160830

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20160912

R150 Certificate of patent or registration of utility model

Ref document number: 6015509

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees