JPH1127308A - インターネット対応リンクモニタ方法 - Google Patents

Abstract

(57)【要約】 【課題】 TCP/IPプロトコルに従った通信におけるスル
ープット低下の原因を検査するのに有用なインターネッ
ト対応リンクモニタ方法を提供する。 【解決手段】 通信システム間のPDU を PDU取得部３１
で取得し、これを PDU解析部３２で解析してエミュレー
ションログ３４を作成し、エミュレーションログ３４を
元に一対の通信システムのイベントシーケンスをイベン
トシーケンス推定部４３で推定してイベントシーケンス
ログ４５を作成し、独自に作成した TCP状態遷移仕様４
６と、 TCPプロトコルの内部変数４７と、 TCPプロトコ
ルの複数の内部手順のどれが行われているかを示すステ
ータス及び各内部手順で使用される内部変数を含む内部
手順に対応する内部変数４８とを用いて、状態遷移に基
づくTCPプロトコルの振舞い及び内部手順のエミュレー
ションを TCPエミュレーション部４４で行うことによ
り、通信の詳細を解析する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はインターネットに対
応可能なリンクモニタ方法に関し、詳しくは、回線上に
流れるデータから、状態遷移に基づいた TCPプロトコル
の振舞いに加えて、フロー制御のための TCPプロトコル
の内部手順をエミュレートすることにより、通信の詳細
を解析するインターネット対応リンクモニタ方法であ
り、TCP/IPプロトコルに従った通信におけるスループッ
ト低下の原因の検査に有用である。

【０００２】

【従来の技術】近年、ワールド・ワイドなインターネッ
ト(INTERNET)の普及に伴い、様々なコンピュータ通信に
おいてTCP/IPプロトコルが広く利用されてきている。し
かし、TCP/IPプロトコルの通信機能を使うユーザの多く
は、TCP/IPプロトコルの通信処理の詳細に関して十分な
知識を有していない。

【０００３】ここで、 TCP（Transmission Control Pro
tocol ：トランスミッション・コントロール・プロトコ
ル）及びIP（Internet Protocol ：インターネット・プ
ロトコル）はインターネットで使用されている主要なプ
ロトコルであり、 TCPはトランスポート層のコネクショ
ン型伝送制御プロトコル、IPはネットワーク層のコネク
ションレス型パケット転送制御プロトコルである。

【０００４】TCP/IPプロトコルに従った通信では、ネッ
トワークの輻輳や伝送誤りによるパケット紛失が発生す
る場合や、双方の通信システムのソケットバッファサイ
ズなどのパラメータ値が異なる場合に、スループット低
下などの問題が発生する。このような場合には、通信の
詳細を解析してスループット低下の原因を検査する必要
がある。

【０００５】従来は、市販のプロトコルモニタを用いて
PDU(プロトコル・データ・ユニット:Protocol Data Uni
t)のフォーマット解析及び解析結果の表示を行わせ、エ
キスパートが PDUフォーマットの解析結果を見て通信シ
ーケンスを解析し、スループット低下の原因を調査して
いる。なお、エキスパートとはTCP/IPプロトコルの通信
処理の詳細に精通した者である。

【０００６】このようにエキスパートが必要なのは、市
販のプロトコルモニタは PDUのフォーマット解析や表示
機能を持つのみであり、通信シーケンスを解析する機能
や、それに基づくスループット低下の原因を調査する機
能を持たないからである。

【０００７】従って、TCP/IPプロトコルの通信機能を使
うユーザの多くにとって、スループット低下の原因を調
査することは困難であった。

【０００８】

【発明が解決しようとする課題】以上のことから、本発
明の課題は、TCP/IPプロトコルに従った通信におけるス
ループット低下の原因を検査するのに有用なインターネ
ット対応リンクモニタ方法を提供することである。

【０００９】

【課題を解決するための手段】請求項１に係る発明のイ
ンターネット対応リンクモニタ方法は、TCP/IPプロトコ
ルに従う通信を行う通信システムのイベントシーケンス
と、 TCPのプロトコル仕様に基づいて作成した TCP状態
遷移仕様と、 TCPプロトコルの状態及び内部変数と、 T
CPプロトコルの輻輳制御に関する複数の内部手順のうち
どれが行われているかを示すステータス及び各内部手順
で使用される内部変数を含む内部手順に対応する内部変
数とを用いて、状態遷移に基づく TCPプロトコルの振舞
い及び内部手順のエミュレーション処理を行うことによ
り、通信の詳細を解析することを特徴とする。

【００１０】請求項２に係る発明のインターネット対応
リンクモニタ方法は、前記 TCP状態遷移仕様として、送
信イベント処理においては、各状態において送信可能な
PDUと、送信PDU のパラメータの条件を規定し、送信イ
ベント処理後の状態及び内部変数の少なくとも一方を定
義したこと、受信イベント処理においては、受信イベン
トのパラメータ、現在の状態及び内部変数のうち少なく
とも一つ毎に、受信イベント処理後の状態及び内部変数
の少なくとも一方を定義したこと、受信イベント処理に
おいて、受信イベントに対する応答として期待される送
信イベントが存在する場合は、その送信PDU のパラメー
タの条件を規定し、送信イベント処理後の状態及び内部
変数の少なくとも一方を定義したことを特徴とする。

【００１１】請求項３に係る発明のインターネット対応
リンクモニタ方法は、前記エミュレーション処理におい
て、送信イベントを処理する場合は、そのイベントの送
信が可能か否かを TCP状態遷移仕様を探索することによ
り判断し、可能ならば送信イベント処理後の状態または
内部変数を推定すること、受信イベントを処理する場合
は、受信イベントに対する応答となる送信イベントを抽
出し、 TCP状態遷移仕様を探索することにより遷移可能
か否かを判断し、遷移可能であり送信イベントが処理さ
れたならば、送信イベント処理後の状態または内部変数
を TCP状態遷移仕様に従って推定し、遷移可能であり送
信イベントが処理されなかったならば受信イベント処理
後の状態または内部変数を TCP状態遷移仕様に従って推
定することを特徴とする。

【００１２】請求項４に係る発明のインターネット対応
リンクモニタ方法は、前記エミュレーション処理におい
て、イベントシーケンスからイベントを逐次抽出し、抽
出したイベントが送信イベントであるか受信イベントで
あるかを識別すること、抽出したイベントが送信イベン
トである場合は、 TCP状態遷移仕様に従って実行可能な
遷移を探索し、実行可能な遷移の探索に成功すれば状態
及び内部変数を更新し、失敗すればプロトコルエラーで
あると判定すること、抽出したイベントが受信イベント
である場合は、イベントシーケンスから未処理で且つ当
該受信イベント以降最初の送信イベントを抽出し、この
送信イベントが前記受信イベントに対する応答であると
仮定して該当する遷移を TCP状態遷移仕様に従って探索
し、この探索に失敗すれば受信イベントが紛失したもの
と判定し、この探索に成功し且つ前記応答であると仮定
した送信イベントが処理された場合はイベントシーケン
スに同送信イベントが処理済みであることを記録した
後、状態及び内部変数を更新して該当する遷移を実行
し、この探索に成功したが前記応答であると仮定した送
信イベントが処理されていない場合は状態及び内部変数
を更新して該当する遷移を実行することを特徴とする。

【００１３】請求項５に係る発明のインターネット対応
リンクモニタ方法は、前記エミュレーション処理におい
て、現在行われている輻輳制御に関する内部手順を示す
ステータスとして、スロー・スタート、コンジェスチョ
ン・アボイダンス、高速再転送と高速リカバリ、どの内
部手順も行われていない又は行われている内部手順が不
明であることを示すノーマルの４つを推定すること、送
信イベント及び受信イベントのうちいずれか一方の処理
を契機に、輻輳制御に関する内部手順の発生、輻輳制御
に関する内部手順の終了、輻輳制御に関する内部手順が
使用する内部変数の値を判断すること、輻輳制御に関す
る内部手順のうちスロー・スタートについては、タイム
アウト再送を契機に、スロー・スタート発生したことを
判断し、以降のDT送信毎及び ACK受信毎に、内部変数の
値を推定すること、輻輳制御に関する内部手順のうち高
速再転送と高速リカバリについては、３つの重複ACK の
受信を契機に、それぞれが発生したことを判断すること
を特徴とする。

【００１４】請求項６に係る発明のインターネット対応
リンクモニタ方法は、一対の通信システム間のPDU を回
線上に流れるデータから取得し、取得したPDU を解析し
てエミュレーションログを作成し、エミュレーションロ
グを元にそのPDU を送受信した双方の通信システムのイ
ベントシーケンスを推定することを特徴とする。

【００１５】

【発明の実施の形態】以下、図１〜図１４を参照して本
発明に係るインターネット対応リンクモニタ方法の実施
の形態を説明する。

【００１６】まず、図１〜図５により、TCP/IPプロトコ
ルの概要を説明する。

【００１７】［ネットワークの構成例］図１にネットワ
ークの構成例を示す。このネットワークは、WAN (Wide
Area Network：ワイド・エリア・ネットワーク）１と、
この WAN１にルータ２、３で接続された２つのLAN (Loc
al Area Network ：ローカル・エリア・ネットワーク）
４、５から構成されている。これらの LAN４、５には、
TCP/IPプロトコルに従った通信を相互に行う通信システ
ム(A)(B)(C) が、図示のように、接続されているものと
する。従って、この例では、 LAN４上に、通信システム
(A)(B)間のプロトコル・データ・ユニット( 以下、PDU
）と通信システム(A)(C)間のPDU がともに流れる。 WA
N１には例えばISDN (Integrated Services Digital Net
work ：サービス総合ディジタル網）が使用され、 LAN
４、５には例えばイーサネット(Ethernet)が使用され
る。

【００１８】このようなネットワークの LAN４にインタ
ーネット対応リンクモニタ（以下、リンクモニタと略称
する）２０が接続され、そこに流れるPDU を観測する。

【００１９】［ PDUのフォーマット］リンクモニタ２０
が観測するPDU の例を図２に模式的に示す。データリン
ク層のPDU はフレームと呼ばれる。

【００２０】通常は LAN４がイーサネットであるので、
フレーム１０はイーサネット・ヘッダ１１及びイーサネ
ット・トレーラ１２をIPデータグラム１３の前後に付加
したものであり、IPデータグラム１３はIPヘッダ１４を
TCPセグメント１５の前に付加したものである。 TCPセ
グメント１５は TCPヘッダ１６をユーザ・データ１７の
前に付加したものである。ここでいうユーザ・データ１
７には、アプリケーション・ヘッダを含めている。ユー
ザ・データ１７の長さを、UD長と呼ぶ。

【００２１】［IPヘッダ］図３にIPヘッダ１４のフォー
マットを模式的に示す。IPヘッダ１４には、発信元アド
レス、宛先アドレス等のフィールドがある。IPヘッダ１
４の長さは、オプションの指定が無いかぎり、２０バイ
トである。

【００２２】［ TCPヘッダとフラグ］図４に TCPヘッダ
１６のフォーマットを模式的に示す。 TCPヘッダ１６に
は、発信元ポート番号、宛先ポート番号、シーケンス番
号、確認応答番号、ヘッダ長、制御ビット、ウインドウ
・サイズ、 TCPチェックサム、緊急ポインタ等のフィー
ルドがある。 TCPヘッダ１６の長さも、オプションの指
定が無いかぎり、２０バイトである。

【００２３】TCPヘッダ１６の制御ビット・フィールド
１８には、URG, ACK, PSH, RST, SYN, FINという６個の
フラグ・ビットがある。各フラグ・ビットの意味を下記
に示す。 URG ：緊急ポインタが有効である。 ACK ：確認応答番号が有効である。 PSH ：受け手はこのデータを可能な限り早急にアプリケ
ーションに渡さなければならない。 RST ：コネクションをリセットする。 SYN ：コネクションを初期化するためにシーケンス番号
を同期させる。 FIN ：送り手はデータの送信を終了した。

【００２４】これらのフラグ・ビットは１つだけをオン
にしたり、あるいは、複数を同時にオンにすることがで
きる。フラグ・ビットがオンの TCPセグメントを下記の
ように呼ぶ。 SYN セグメント ： SYNビットのみがオン（ ACKビッ
トはオフ）、単に SYNとも呼ぶ。 SYN+ACK セグメント： SYNビットと ACKビットのみがオ
ン、単にSYN+ACK とも呼ぶ。 ACK セグメント ：ユーザ・データは無く ACKビット
のみがオン、単にACK とも呼ぶ。 DTセグメント ： URGビットと RSTビットのオンと
オフに関係なく、ユーザ・データが有り ACKビットのみ
がオン、単にDTとも呼ぶ。 FIN セグメント ： FINビットがオン（ ACKビットが
オンのことが多い）、単に FINとも呼ぶ。 RST セグメント ： RSTビットがオン（ ACKビットが
オンのことが多い）、単に RSTとも呼ぶ。

【００２５】ACKセグメントのうち、確認応答番号が互
いに等しく、TCP ユーザ・データ長が０で、ウインドウ
の更新が無いものは、重複 ACK(duplicate ACK：デュー
プリケイトACK)と呼び、相手側の通信システムに対し、
受信すべきデータを受信していないこと示す。また、 A
CKセグメントのうち、確認応答番号が互いに等しく、TC
P ユーザ・データ長が０で、ウインドウの値が更新され
たものは、window update(ウインドウ・アップデイト：
ウインドウ更新）を示すACK と呼び、相手側の通信シス
テムに対し、新しいデータが受信可能になったことを示
す。

【００２６】［イベント］TCPプロトコルに対するイベ
ントには、送信イベント（送信した TCPセグメント）や
受信イベント（受信した TCPセグメント）等があり、下
記に代表例とその意味を示す。 SYNsent ：送信した SYNセグメント。 SYN+ACKsent ：送信した SYN+ACKセグメント。 ACKsent ：送信した ACKセグメント。 DT/ACKsent ：送信した DTセグメント又は ACKセグメ
ント。 FINsent ：送信した FINセグメント。 SYNrecv ：受信した SYNセグメント。 SYN+ACKrecv ：受信した SYN+ACKセグメント。 ACKrecv ：受信した ACKセグメント。 DT/ACKrecv ：受信した DTセグメント又は ACKセグメ
ント。 FINrecv ：受信した FINセグメント。

【００２７】［ TCPプロトコルにおける状態（ステー
ト：state ）］TCPプロトコルでは、発着のポート番号
とIPヘッダ上のIPアドレスとにより識別されるコネクシ
ョンを確立する。このコネクション確立は SYN、SYN+AC
K 及びACK という３つの TCPセグメントで行われる。デ
ータ転送においては、３２ビットのシーケンス番号と A
CK番号（確認応答番号）とを用いる。また、相手側通信
システムから通知される１６ビットのウインドウ・サイ
ズを用いて、フロー制御を行う。データ転送が終わる
と、 FIN及びACK という２つの TCPセグメントの交換を
双方の通信システムで行うことにより、コネクションを
解放する。

【００２８】TCP/IPプロトコルにおける状態は、図５に
示すように、CLOSED、 SYN＿SENT、SYN＿RCVD、ESTABLI
SHED 、 FIN＿WAIT＿1 、 FIN＿WAIT＿2 、CLOSING 、
CLOSE＿WAIT、LAST＿ACK 、TIME＿WAITという値を取り
得る。各値の意味を下記に示す。 CLOSED ：コネクション無しの状態。 SYN＿SENT ： SYNセグメントを送信してコネクショ
ン確立処理中の状態。 SYN＿RCVD ： SYNセグメントを受信してコネクショ
ン確立処理中の状態。 ESTABLISHED ：双方向にデータ転送可能な状態。 FIN＿WAIT＿1 ：データ送信終了要求の状態。 FIN＿WAIT＿2 ：データ送信終了完了の状態。 CLOSING ：データ送受信同時終了の状態。 TIME ＿WAIT ：コネクション解放完了時のコネクショ
ン情報保持状態。 CLOSE＿WAIT ：コネクション解放の待機状態。 LAST ＿ACK ：最終ACK の受信待ち状態。

【００２９】［ TCPプロトコルの内部変数（パラメー
タ）］TCP/IPプロトコルには送信シーケンスに関する内
部変数と、受信シーケンスに関する内部変数と、輻輳回
避ためのフロー制御の内部手順に対応する内部変数があ
る。

【００３０】［送信シーケンスに関する内部変数］送信
シーケンスに関する内部変数を、下記に示す。但し、 s
nd＿max と finrecv＿flagは実装上あるいはモニタとし
て処理する上で必要な内部変数である。 snd＿nxt : 次に送信するシーケンス番号。 snd＿una : 送信済みであるが確認応答されていない最
小のシーケンス番号。 snd＿wnd : 送信側のウインドウサイズ。 iss : 初期送信シーケンス番号。 mss : 最大セグメントサイズ。 snd＿max : 過去に送信した最大の送信シーケンス番
号。 finrecv＿flag： FIN受信を既に行ったことを示すフラ
グ。

【００３１】［受信シーケンスに関する内部変数］受信
シーケンスに関する内部変数を、下記に示す。但し、 r
cv＿una と finrecv＿flagは実装上あるいはモニタとし
て処理する上で必要な内部変数である。 rcv＿nxt : 次に受信するシーケンス番号。 rcv＿wnd : 受信側のウインドウサイズ。 irs : 初期受信シーケンス番号。 rcv＿una : 受信済みであるが確認応答してない最小の
受信シーケンス番号。 finrecv＿flag： FIN受信を既に行ったことを示すフラ
グ。

【００３２】［輻輳回避のためのフロー制御の内部手
順］TCPプロトコルは、ネットワーク層プロトコルであ
るIPプロトコル上において高信頼なデータ転送を提供す
るものであり、ネットワークの輻輳回避のために TCPプ
ロトコル独自のフロー制御を行う。そのため、スロー・
スタート（slow startと表記される）、コンジェスチョ
ン・アボイダンス（congestion avoidanceと表記され
る）、高速再転送（fast retransmit （ファースト・リ
トランスミット）と表記される）、高速リカバリ（fast
recovery （ファースト・リカバリ）と表記される）と
いう４つの内部手順を実装している。

【００３３】これら４つの内部手順の基本方針は、以下
(1)(2)の通りである。 (1)送受信の通信システム間において物理回線速度の低
いネットワークが介在する場合、ネットワークが輻輳し
TCPセグメントの紛失が起きることが考えられる。この
ため、送信側は、コンジェスチョン・ウインドウ（cong
estion window :cwndと略記される）と、スロー・スタ
ート・スレッシュホルド（slow start threshold : sst
hresh と略記される）という２つのパラメータを用い
て、送信速度を送信側内部で調節することにより輻輳を
回避する。 (2)特に、大きいウインドウを持つ通信システムにおい
てスループットを向上させるため、送信側では、複数の
重複ACK(duplicate ACK)を受け取ることにより TCPセグ
メントが紛失したものと判断し、紛失した TCPセグメン
トを再送する。

【００３４】また、上記内部手順は、以下(i) 〜(iv)の
手続きに従う。 (i) 送信側は、現在のウインドウ（コンジェスチョン・
ウインドウcwndと、受信側より通知されたウインドウad
vertised window とのうち小さい方の値) より大きいデ
ータを送ることはできない。 (ii)輻輳は、タイムアウトまたは複数の重複ACK の受信
で検出される。タイムアウトにより輻輳が検出された場
合、送信側は、スロー・スタート・スレッシュホルドss
threshを現在のウインドウの半分に、コンジェスチョン
・ウインドウcwndを１セグメント( 最大セグメントサイ
ズ分) にそれぞれ設定して、 TCPセグメントの再送を行
う。 (iii) ３つの重複ACK を受け取った場合、送信済みの T
CPセグメントが紛失したものと判断し、ssthreshを現在
のウインドウの半分に設定し、 TCPセグメントを再送す
る。その後、新しいデータに対応するACK を受信した時
点で、cwndをssthreshに設定する。 (iv)新しいデータに対応するACK を受信した場合、以下
のようにcwndを増加させる。cwndがssthresh以下の場
合、スロース・タートslow startの手順を実行し、ACK
受信毎に１セグメントずつcwndを増加させる。この場
合、cwndは、往復遅延時間に対し指数的に増加する。ま
た、cwndがssthreshよりも大きい場合、コンジェスチョ
ン・アボイダンスcongestion avoidanceの手順を実行
し、cwndを線形に増加させる。

【００３５】［輻輳回避のための内部手順に対応する内
部変数］従って、 TCPプロトコルには、上記内部手順に
対応する内部変数として、status（ステータス) 、cwn
d、ssthresh、dupacks と表記されるものがある。各内
部変数の意味を下記に示す。 status ：現在行われている内部手順を表す内部
変数であり、SS，CA，FR，NORMAL（ノーマル）のいずれ
かの値をとる。 SS ：内部手順slow start（スロース・ター
ト）を示す値。 CA ：内部手順congestion avoidance（コン
ジェスチョン・アボイダンス）を示す値。 FR ：内部手順fast retransmit （高速再転
送）と内部手順fast recovery （高速リカバリ）のいず
れかの値をとる。 NORMAL ：どの内部手順も行われていないか、行
われている内部手順が不明であることを示す値。 cwnd ：congestion window （コンジェスチョ
ンウインドウ）の値。 ssthresh ：slow startにおけるスレッショルド(th
reshold) の値。 dupacks ：連続して受信した重複ACK （dupulicat
e ACK）の値。

【００３６】［リンクモニタの概要］次に、リンクモニ
タ２０の概要を説明する。TCP/IPプロトコルに従った通
信の詳細を解析するには、市販のプロトコルモニタと同
様な PDUの監視機能に加えて、通信システムの動作を T
CPに従ってエミュレートする機能が必要である。

【００３７】発明者らは既に、OSI(Open Systems Inter
connection: 開放形システム間接続）プロトコルの動作
を解析してプロトコル誤りを検出する OSI対応リンクモ
ニタを開発し、特願平６−２２３１３８号（発明の名
称：インテリジェント通信プロトコルモニタ装置）とし
て出願している。特開平８−８８６７２号公報参照。

【００３８】そこで、基本的には、上記 OSI対応リンク
モニタの実現技法をTCP/IPプロトコルに適用して TCPプ
ロトコルの振舞いを解析することにより、通信システム
の動作を TCPに従ってエミュレートすることができる。

【００３９】しかし、 TCPプロトコルでは、 OSIプロト
コルにおいてローカル依存となっている内部手順、即
ち、前述したslow start（スロー・スタート）やconges
tion avoidance（コンジェスチョン・アボイダンス）
等、ネットワークの輻輳を回避するためにネットワーク
に送出するデータ量を送信側で制御する内部手順がプロ
トコル仕様に組み込まれている。

【００４０】従って、インターネット対応リンクモニタ
では、 OSI対応リンクモニタに比べて、より複雑なプロ
トコルエミュレーション機能を実装する必要がある。

【００４１】［要求条件］本実施の形態に係るリンクモ
ニタ２０は、下記の要求条件(1) 〜(6) を満たすものと
している。 (1) TCP/IPプロトコルは LANなどの高速なネットワーク
上で使用されるため、ネットワーク上を流れるPDU の取
得はオンラインで行い、通信の詳細な解析はオフライン
で行う。 (2) TCP/IPプロトコルに従う通信を、「ネットワーク上
を流れる全てのPDU のフォーマット解析」及び「特定の
通信システム間での通信状況の解析」という２つの観点
において検査する。これは、TCP/IPプロトコルの中では
TCPプロトコルが最も複雑な手順を有するため、 TCPプ
ロトコルを対象としてこれらの解析を行う必要があるか
らである。 (3) 上記(2) の前者（ネットワーク上を流れる全てのPD
U のフォーマット解析）では、ネットワーク上を流れる
１つのPDU を、２つの通信システムへの入力（受信）及
び出力（送信）のイベントとして扱う。 (4) 上記(2) の後者（特定の通信システム間での通信状
況の解析）では、 TCPセグメントのシーケンスから、通
信システムにおける TCPプロトコルの振舞いをエミュレ
ートする。このエミュレーションは、個々の通信システ
ム毎に独立に行う。 (5) エミュレーション対象の TCPプロトコルは、基本的
には、slow startやcongestion avoidanceなどの内部手
順を実装しているものとする。ただし、これらの内部手
順の仕様は近年追加されたものであり、市販のソフトウ
ェアがこれらの内部手順を実装しているとは限らない。
従って、本実施の形態のリンクモニタ２０では、内部手
順をエミュレートする機能とともに、内部手順を実装し
ていない可能性をも推定する機能を備える。以下の説明
では、内部手順を実装している TCPプロトコルをモダン
TCP (Modern-TCP)と呼び、実装していない TCPプロトコ
ルをオリジナルTCP (Original-TCP)と呼ぶ。 (6) ISDNなど WANを経由して接続される通信を監視する
場合も考えられる。このような場合、通信システムが P
DUを実際に処理する時刻と、リンクモニタ２０がPDUを
検出する時刻との間に時間差があるので、この時間差を
考慮してエミュレーションを行う。

【００４２】［リンクモニタの具体的な設計］本実施の
形態に係るリンクモニタ２０は、図１に示したネットワ
ークにおいて、丸印６で囲んだように LAN４上の全ての
TCP/IPプロトコルに従った通信に関して PDUのフォーマ
ット解析を行う PDU監視機能と、丸印７、８で囲んだよ
うに任意の特定一対の通信システム間を対象として TCP
プロトコルの振る舞いを推定する TCPエミュレーション
機能を持つ。

【００４３】PDU監視機能は市販の汎用プロトコルアナ
ライザが持つ機能とほぼ同様である。この PDU監視機能
は LAN４上を流れる PDUを取り込み、ARP, IP, UDP, TC
P 等の各種プロトコルに従って PDUフォーマットやその
パラメータの解析を行う。

【００４４】TCPエミュレーション機能は、以下の手順
(1)(2)により実現する。 (1) リンクモニタ２０が PDUを取得した時刻と、そのPD
U を通信システムが実際に処理する時刻との時間差を考
慮し、個々の通信システムにおけるイベントの処理順序
（イベントシーケンス）を推定する。即ち、この時間差
は、図１における通信システム(A)(B)のように双方の通
信システムがリンクモニタ２０と同一の LAN４上にある
場合にはおおよそ無視できるが、通信システム(A)(C)の
ように WAN１を経由した別々の LAN４、５上にある場合
には無視できない。そのため、個々の通信システムにお
けるイベントシーケンスを推定する。 (2) 次に、推定したイベントシーケンスを元に、個々の
通信システムの TCPプロトコルの振舞いをエミュレート
する。

【００４５】リンクモニタ２０はUNIXワークステーショ
ン上のソフトウェアとして実装することにより、実現し
ている。具体的には図６に示すように、リンクモニタ２
０は、大きく分けてオンライン部３０と、オフライン部
４０から構成される。オンライン部３０は LAN４上を流
れるフレームを取り込むフレーム取得部３１と、TCP/IP
プロトコルに従い PDUフォーマットやそのパラメータの
解析を行う PDU解析部３２から構成される。 PDU解析部
３２では、解析結果をモニタログ３３に蓄積するととも
に、オフライン部４０の TCP振舞いエミュレーション部
４２で使用する情報をエミュレーションログ３４に記録
する。

【００４６】オフライン部４０は PDUモニタ結果検査部
４１と、 TCP振舞いエミュレーション部４２から構成さ
れる。 PDUモニタ結果検査部４１はモニタログ３３に蓄
積された情報の表示機能を提供する。 TCP振舞いエミュ
レーション部４２はイベントシーケンス推定部４３と、
TCPエミュレーション部４４から構成される。詳細は後
述するが、イベントシーケンス推定部４３は個々の通信
システムのイベントシーケンスを推定により作成し、 T
CPエミュレーション部４４はイベントシーケンスに基づ
いて TCPプロトコルの振舞いをエミュレートする。イベ
ントシーケンスは、図９、図１０に例示するように、送
信イベントや受信イベント等の TCPプロトコルに対する
イベントと、そのイベントを処理した時刻からなる。

【００４７】TCPエミュレーション部４４は、 TCP状態
遷移仕様４６を保持している。 TCP状態遷移仕様４６
は、 TCPのプロトコル仕様を元に、本発明において独自
に定義したものであり、基本的な定義を下記（１）
（２）に示す。 （１）送信イベント処理においては、各状態において送
信可能なPDU と、送信PDU のパラメータの条件を規定
し、送信イベント処理後の状態及び内部変数の少なくと
も一方を定義する。 （２）受信イベント処理においては、受信イベントのパ
ラメータや現在の状態及び内部変数毎に、受信イベント
処理後の状態及び内部変数の少なくとも一方を定義す
る。また、応答として期待される送信イベントが存在す
る場合は、その送信PDU のパラメータの条件を規定し、
送信イベント処理後の状態及び内部変数の少なくとも一
方を定義する。

【００４８】TCPエミュレーション部４４は TCP状態遷
移仕様４６を用い、基本的には、送受信のイベントに応
じて以下の処理(1)(2)を行う。 (1) 受信イベントを処理する場合は、その受信イベント
の応答として送出されたと考えられる送信イベントを、
当該受信イベントの直後のイベントシーケンスから探し
出す。 TCPエミュレーション部４４は、これら受信イベ
ントと送信イベントの組から、 TCPプロトコルの条件に
従った状態遷移を実行する。換言すれば、受信イベント
に対する応答となるべき送信イベントを抽出し、 TCP状
態遷移仕様を探索することにより遷移が本当に可能か否
かを判断し、可能であり送信イベントが処理されたなら
ば、送信イベント処理後の状態／内部変数を推定し、可
能であり送信イベントが処理されなかったならば受信イ
ベント処理後の状態／内部変数を推定する。 (2) 送信イベントを処理する場合は、現在の状態毎にイ
ベントを処理する。つまり、現在の状態において、当該
送信イベントを送出する遷移を TCP状態遷移表より探し
出し、その遷移を実行する。送信イベントの送出が可能
でない場合は、プロトコルエラーが発生したものとして
処理する。換言すれば、送信イベントの送信が本当に可
能か否かを TCP状態遷移仕様を探索することにより判断
し、可能ならば送信イベント処理後の状態／内部変数を
推定する。

【００４９】次に、 TCPエミュレーション機能の詳細を
説明する。

【００５０】［エミュレーションログの生成］まず、オ
ンライン部３０内の PDU解析部３２は、取得した全ての
TCPセグメントに対して PDUフォーマットの解析を行
い、この解析結果から下記(i) 〜(v) に示す各種の情報
をエミュレーションログ３４として記録する。これらの
情報は、オンライン部４０の TCP振舞いエミュレーショ
ン部４２で用いられる。図８にエミュレーションログの
例を示す。 (i) TCPセグメントの先頭と末尾を検出した時刻。 (ii)発側IPアドレスと着側IPアドレス（図３に示したIP
ヘッダ１４中の発信元アドレスと宛先アドレス）。 (iii) チェックサムを除く TCPヘッダのパラメータ（図
４に示した TCPヘッダ１６中の発信元ポート番号、宛先
ポート番号、シーケンス番号、肯定応答番号、ウインド
ウ・サイズ等）。 (iv) TCP ユーザデータ長。 (v) TCPチェックサムの正否を示すフラグ。

【００５１】ただし、上記(i) の TCPセグメントの先頭
と末尾を検出した時刻のうち、各フレームの末尾を検出
した時刻のみを計測する。 TCPセグメントの先頭時刻に
関しては、後述のように、フレーム末尾時刻からフレー
ム長に比例するフレーム転送時間を引いて計算する。

【００５２】［イベントシーケンスの推定］TCP振舞い
エミュレーション部４２のうち、イベントシーケンス推
定部４３で、対象とする１対１の通信システムを示すIP
アドレスの組毎に、イベントシーケンスの推定を行う。
実際の TCPエミュレーションは、 TCPエミュレーション
部４４で行う。

【００５３】イベントシーケンス推定部４３はエミュレ
ーションログ３４を元にイベントシーケンスの推定を行
うことにより、個々の通信システムに対し、観測した T
CPセグメントを実際のイベント処理時刻順に並べ替え
て、イベントシーケンスログ４５を作成する。即ち、送
信イベント及び受信イベントの取り扱いにおいて、リン
クモニタ２０と個々の通信システムとの物理的な位置関
係や、 PDU長等を元に、リンクモニタ２０が PDUを取得
した時刻から、通信システムが実際にイベントを送受信
した時刻を推定する。

【００５４】イベントシーケンス推定の具体的な操作
を、２つの通信システム(A)(B)を対象とした場合につい
て、下記(1) 〜(3) に示す。 (1) イベントシーケンス推定部４３は、通信システム
(A) と(B) がそれぞれ送受信した TCPセグメントに対応
する情報をエミュレーションログ３４より逐次抽出す
る。 (2) 通信システム(A) から通信システム(B) への TCPセ
グメントを抽出した場合は、通信システム(A) に対して
は送信イベント、通信システム(B) に対しては受信イベ
ントが発生したものと判断する。逆に、通信システム
(B) から通信システム(A) への TCPセグメントを抽出し
た場合は、通信システム(B) に対して送信イベント、通
信システム(A) に対して受信イベントが発生したものと
判断する。 (3) 各通信システム(A) (B) のイベント処理時刻を推定
する。イベント処理時刻は、送信イベントの場合にはフ
レーム先頭時刻からリンクモニタ２０と通信システムの
間のフレーム転送遅延を引いたものとなり、受信イベン
トの場合にはフレーム先頭時刻にリンクモニタ２０と通
信システムの間のフレーム転送遅延を加えたものとな
る。フレーム転送遅延は、伝送遅延に、フレーム長に比
例するフレーム転送時間を加えたものとなる。

【００５５】図７〜図１０に、 WAN１を経由する LAN
４、５に接続された２つの通信システム(A)(C)における
イベントシーケンスの推定例を示す。図８は PDU解析部
３２が記録したエミュレーションログ３４の内容を示
し、図９はイベントシーケンス部４３が作成したイベン
トシーケンスログ４５のうち通信システム(A) に関する
内容を示し、図９はイベントシーケンス部４３が作成し
たイベントシーケンスログ４５のうち通信システム(C)
に関する内容を示す。

【００５６】この例において、通信システム(A) のイベ
ントシーケンスは、同通信システム(A) がリンクモニタ
２０と同じ LAN４上にあり伝送遅延が小さいため、リン
クモニタ２０で監視した順序（図８参照）と同様とな
る。

【００５７】しかし、通信システム(C) のイベントシー
ケンスについては、通信システム(C) がリンクモニタ２
０とは異なる LAN５上にあり伝送遅延が大きいため、デ
ータ受信イべントDATA1recv とデータ送信イべントDATA
2sent が、リンクモニタ２０で監視した順序に対し逆転
している。従って、イベントシーケンスの推定と並べ替
えが必要である。

【００５８】例えば、通信システム(C) におけるデータ
受信イベントDATA1recv のイベント処理時刻は、以下の
ように計算する。ただし、 WAN１は伝送遅延１００ms、
伝送速度６４KbpsのISDNであるとする。また、 LAN４、
５は伝送速度10Mbpsのイーサネットであるとする。

【００５９】まず、 TCPセグメントDATA1 が LAN４から
WAN(ISDN)１を経由してルータ３に到達するには、約18
8ms(=(1460+40)*8/64000) 要する。次に、 TCPセグメン
トDATA1 がルータ４から通信システム(C) に到達するに
は、約1ms=((1460+40)*8/1000000) 要する。フレーム長
は、UD長(TCPユーザデータ長）に、IPヘッダ及び TCPヘ
ッダを加えたサイズで計算する。なお、1460は TCPセグ
メントDATA1 のUD長（バイト）、40はIPヘッダとTCP ヘ
ッダを加算したデータ長（バイト）である。

【００６０】従って、通信システム(C) におけるデータ
受信イベントDATA1recv のイベント処理時刻は、00:01.
456(リンクモニタ２０の監視時刻）＋ 0.100（伝送遅
延）＋0.188( WAN1でのフレーム転送時間）＋ 0.001( L
AN3でのフレーム転送時間）＝0:01.745と推定する。

【００６１】［ TCPエミュレーションの詳細］次に、 T
CPエミュレーションの詳細を説明する。

【００６２】［オリジナルTCP の振舞い］TCPプロトコ
ルは、前述したように、IPプロトコル上において高信頼
なデータ転送を提供するものである。オリジナルTCP で
は、発着のポート番号とIPヘッダ上のIPアドレスとによ
り識別されるコネクションの確立を、３つの TCPセグメ
ント SYN、SYN+ACK 及びACK で行う。コネクションの確
立後、シーケンス番号と ACK番号（確認応答番号）とを
用いてデータ転送を行う。このデータ転送においては、
相手側通信システムから通知されるウインドウ・サイズ
を用いて、フロー制御を行う。データ転送が終わると、
FIN及びACK という２つの TCPセグメントの交換を双方
の通信システムで行うことにより、コネクションを解放
する。

【００６３】［モダンTCP の内部手順］モダンTCP は、
オリジナルTCP の機能に加え、輻輳制御のために、前述
したslow start, congestion avoidance, fast retrans
mit, fast recoveryという４つの内部手順を実装してお
り、TCP プロトコル独自のフロー制御を行う。

【００６４】［ TCPエミュレーションの方針］TCPエミ
ュレーション部４４は、 TCPコネクション毎に、オリジ
ナルTCP とモダンTCP の双方の振舞いをエミュレートす
る。この場合、イベント発生時刻順に送信イベント及び
受信イベントを処理し、イベント処理を契機に TCPの状
態や内部変数の推定を随時おこなう。

【００６５】オリジナルTCP の振舞いに対応するため、
TCPエミュレーション部４４は、RFC (Request for Com
ment：インターネットの公式書類）で定義された状態
（ステート:state）と内部変数を保持する。また、 RFC
では定義されていないが、実装上必要となる内部変数
や、リンクモニタとして必要な内部変数も保持する。

【００６６】RFCで定義された状態は、前述したよう
に、以下に示す値を取りうる。 CLOSED 、 SYN＿SENT、 SYN＿RCVD、 ESTABLISHED、 FIN＿WAIT＿1 、 FIN＿WAIT＿2 、 CLOSING、 CLOSE＿WAIT、 LAST＿ACK 、 TIME＿WAIT

【００６７】RFCで定義されたオリジナルTCP に対応す
る内部変数としては、前述したように、以下に示す送信
シーケンスに関するものと受信シーケンスに関するもの
とがある。 snd＿nxt : 次に送信するシーケンス番号。 snd＿una : 送信済みであるが確認応答されていない最
小のシーケンス番号。 snd＿wnd : 送信側のウインドウサイズ。 iss : 初期送信シーケンス番号。 mss : 最大セグメントサイズ。 rcv＿nxt : 次に受信するシーケンス番号。 rcv＿wnd : 受信側のウインドウサイズ。 irs : 初期受信シーケンス番号。

【００６８】また、実装上あるいはモニタとして処理す
る上で必要な内部変数として、前述したように、以下に
示すものがある。 snd＿max : 過去に送信した最大の送信シーケンス番
号。 rcv＿una : 受信済みであるが確認応答してない最小の
受信シーケンス番号。 finrecv＿flag : FIN受信を既に行ったことを示すフラ
グ。

【００６９】モダンTCP の振舞いに対応するため、 TCP
エミュレーション部４４は、 TCPが有する輻輳制御に関
する内部手順の推定を送受信イベント処理を契機に行
う。例えば、内部手順slow start発生の検出は、コネク
ション確立時（ SYNまたはSYN+ACK 送信イベント処理
時）、及び、タイムアウトによるデータ再送発生時（DT
送信イベント処理時) に行う。

【００７０】更に詳細にいえば、 TCPが有する輻輳制御
に関して、送信イベントまたは受信イベントの処理を契
機に、その制御の発生及び終了や、それらが使用する内
部変数の値を判断する。スロー・スタート（slow star
t）は、タイムアウト再送( シーケンス番号が次に送る
べきデータのシーケンス番号よりも小さいDT送信）を契
機に、それが発生したことを判断し、以降のDT送信や A
CK受信毎に、内部変数の値を推定する。高速再転送と高
速リカバリ（fast retransmit and fast recovery ）
は、３つの重複ACK( ACK番号とウインドウ・サイズが等
しく、ユーザ・データのないACK)の受信を契機に、それ
ぞれが発生したことを判断する。また、現在行われてい
る輻輳制御の内部手順を示すステータス（slow start、
congestion avoidance、fast retransmit and fast rec
overy 、NORMAL（どの内部手順も行われていないか、行
われている内部手順が不明な場合）の４つが存在する）
を推定する。

【００７１】モダンTCP の内部手順に対応するための内
部変数として、 TCPエミュレーション部４４は、どの内
部手順が行われているかを示すステータス(status)と、
各内部手順で使用される内部変数を保持する。

【００７２】内部手順に対応する上記内部変数として
は、前述したように、以下に示すものがある。 ステータス(status)：SS(slow start), CA(congestion avoidance), FR(fast re transmit and fast recovery) , NORMALいずれかの値。 cwnd : congestion window の値。 ssthresh : slow start thresholdの値。 dupacks : 連続して受信した重複ACK(dupulicate) の値。

【００７３】TCPエミュレーション部４４は、オリジナ
ルTCP の振舞い及びモダンTCP の内部手順とを規定した
TCP状態遷移仕様４６と、状態及び内部変数４７（ RFC
で定義されたオリジナルTCP に対応する内部変数、及
び、実装上あるいはモニタとして処理する上で必要な内
部変数）と、内部変数４８（モダンTCP の内部手順に対
応するために、どの内部手順が行われているかを示すス
テータスと、各内部手順で使用される内部変数）を有し
ており、イベントシーケンスログ４５に蓄積されたイベ
ント毎に、この TCP状態遷移仕様４６に従って各通信シ
ステムにおける TCPプロトコルエンティティの振舞いを
エミュレートする。

【００７４】図５にコネクション確立フェーズ及びデー
タ転送フェーズ等における TCPプロトコルの状態遷移を
示す。 TCPエミュレーション部４４では、イベント毎
に、状態や内部変数の遷移をエミュレートする。例え
ば、現在の状態がCLOSEDであり、送信イベントSYNsent
を処理する場合には、遷移#1を処理することにより、状
態を SYN＿SENTに遷移する。

【００７５】次に、 TCPエミュレーションのアルゴリズ
ムを説明する。

【００７６】［ TCPエミュレーションのメイン処理］TC
Pエミュレーション部４４は、図１１に示すフローに従
ってメイン処理を行う。即ち、 (1) 初めに、ステップＳ１にて、イベントシーケンスロ
グより逐次イベントを抽出する。 (2) 次に、ステップＳ２にて、抽出したイベントが送信
イベントか受信イベントかを識別する。 (3) ステップＳ１で抽出したイベントが送信イベントの
場合は、ステップＳ３にて、エミュレーションのための
TCP状態遷移仕様に基づいて、実行可能な遷移を探索す
る。 (4) 実行可能な遷移の探索がステップＳ３で成功(TRUE)
すれば、ステップＳ４にて、状態や内部変数の更新を含
め、その遷移を実行する。 (5) 実行可能な遷移の探索がステップＳ３で失敗(FALS
E) すれば、ステップＳ５にて、プロトコルエラーと仮
定する。 (6) ステップＳ１で抽出したイベントが受信イベントの
場合は、ステップＳ６にて、イベントシーケンスログよ
り未処理で且つ当該受信イベント以降最初の送信イベン
トを抽出する。 (7) ステップＳ６で抽出した送信イベントを受信イベン
トに対する応答と仮定して、ステップＳ７にて、該当す
る遷移を探索する。ここで、遷移の探索が失敗した場合
はFALSE とする。遷移の探索が成功した場合のうち、送
信イベントが処理された場合はTRUE＿ONとし、送信イベ
ントが処理されていない場合はTRUE＿OFFとする。 (8) ステップＳ７における遷移の探索が失敗(FALSE）す
れば、ステップＳ８にて、受信イベントが紛失したもの
と仮定する。 (9) ステップＳ７における遷移の探索が成功し、且つ、
送信イベントが処理された場合（TRUE＿ON）は、ステッ
プＳ９にて、送信イベントが処理済みであることをイベ
ントシーケンスログの送信イベントに記録した後、ステ
ップＳ４にて、状態や内部変数の更新を含めてその遷移
を実行する。 (10)ステップＳ７における遷移の探索が成功し、且つ、
送信イベントが処理されていない場合（TRUE＿OFF ）
は、ステップＳ４にて、状態や内部変数の更新を含めて
その遷移を実行する。

【００７７】［エミュレーション例：その１］次に、図
１２に示す幾つかの遷移*1、*4、*6、*9を例に採り、送
信イベント毎、あるいは、受信イベント及び送信イベン
トの組毎に行う遷移探索処理の詳細を以下に示す。

【００７８】まず、図１１のステップＳ３の送信イベン
ト処理と、ステップＳ７の受信イベント処理の２つの遷
移探索処理について、それぞれＣ言語（コンピュータ・
プログラム言語の一つ）で書いた関数形式を以下に示
す。

【００７９】［送信イベントの状態遷移探索処理の関数
形式］送信イベントに基づく遷移探索処理の関数を、下
記数１に示す。この関数は process＿sent＿event(sent
＿evt)、戻り値(return)はTRUE（遷移探索成功）と FAL
SE（遷移探索失敗）である。

【００８０】

【数１】 process＿sent＿event(sent＿evt)｛ switch(state) ｛ case CLOSED: switch (sent＿evt)｛ case SYNsent: ---- 遷移*1 iss=SSEG.SEQ; snd＿una=iss; snd＿nxt=iss+1; rcv＿wnd=SSEG.WND; snd＿max= snd＿nxt; cwnd=mss; ssthresh=655335; state=SYN＿SENT; status=SS; return(TRUE); （注）SSEG.SEQは送信イベントのシーケンス番号を示し、 SSEG.WNDは送信イベントのウインドウを表す。 ・ ・ ｝ ・ ・ case ESTABLISHED: switch (sent＿evt)｛ case DATAsent: ---- 遷移*6 if(MSSより大きいデータ送信、ウインドウを超えたデ ータ送信など) ｛ [プロトコルエラー処理(return(FALSE)となる)]; ｝else ｛ /*正しいデータ*/ if (SSEG.SEQ== snd＿nxt)｛ if (status!=NORMAL && snd＿nxt+SSEG.LEN > snd＿una +cwnd) [slow start違反と判断し、内部手順の推定を 中断（status=NORMAL とする) ]; snd＿nxt+=SSEG.LEN; （注）SSEG.LENは送信イベントの TCPユーザデータ長を表す。 if (SSEG.SEQ== snd＿max) snd＿max= snd＿nxt; ｝else ｛ /* データ再送(SSEG.SEQ!=snd＿nxt の場合*/ ssthresh=max(2*mss, min(cwnd, snd ＿wnd)/2); cwnd=mss; status=SS; ｝ return(TRUE); ｝ ・ ・ ｝

【００８１】［受信イベントの状態遷移探索処理の関数
形式］受信イベントに基づく遷移探索処理の関数を、下
記数２に示す。この関数は process＿recv＿event(recv
＿evt, sent＿evt)、戻り値(return)はTRUE＿ON（送信
イベントが処理された場合の遷移探索成功) 、TRUE＿OF
F （送信イベントが処理されていない場合の遷移探索成
功) 、 FALSE（遷移探索失敗）である。

【００８２】

【数２】 process＿recv＿event(tbl,recv＿evt,sent＿evt)｛ switch(state) ｛ ・ ・ case SYN＿SENT: if( 受信イベントが、期待しない ACK番号を持つ場合 や RSTビットがONまたは SYNビットが OFFの場合) ｝ ・ ・ /* 省略*/ ｝else｛ /*正しいSYN+ACK */ if (送信イベントがACK)&&（送信イベントのパラメータが SYN に対する確認である条件を満たす)) ｝ ---- 遷移*4 irs=RSEG.SEQ; snd＿una=RSEG.ACK; rcv＿nxt=irs+1; rcv＿wnd=SSEG.WND; rcv＿una=SSEG.ACK; snd＿wnd=RSEG.WND; state=ESTABLISHED; return(TRUE＿ON); /*受信／送信イベントを正常に処理した*/ （注）SSEG.ACKは、送信イベントの ACK番号を示す。 ｝else｛ return(FALSE);/*受信が紛失したと判断*/ ｝ ｝ ・ ・ case ESTABLISHED: if (RSEG.ACK== snd＿una)｛ if (受信イベントが、ウインドウ更新など、 duplicate ACK でない条件) dupacks=0; （注）RSEG.ACKは、受信イベントの ACK番号を示す。 else｛ /* duplicate ACK の場合 */ if (++dupacks>=3) ｛ if (status!=FR) ｛ if (送信イベントとしてfast retransmit による データの再送が正しく行われている) ｛ /* fast retransmitをエミュレートする*/ ssthresh=max(2*mss, min(snd ＿wnd,cwnd)/2); cwnd=ssthresh+3*mss; status=FR; return( TRUE＿ON); ｝else｛return(FALSE);｝ ｝else cwnd+=mss; /* fast retransmit中はcwndを1mss増加*/ ｝ ｝ ｝else if (RSEG.ACK> snd＿una && RSEG.ACK< snd＿max) ｝/*新しい ACK番号*/ ---- 遷移*9 switch(status)｛ case SS: cwnd+=mss; if (cwnd>65535) ｛ status=NORNAL; cwnd=65535; ｝ else if (cwnd>ssthresh) status=CA; break; case CA: cnwd+=mss*mss/cwnd+mss/8; if (cwnd>65535) ｛ status=NORNAL; cwnd=65535; ｝ break; case FR: cwnd=ssthresh; status=CA; break; ｝ ｝ snd＿wnd=RSEG.ACK-snd＿una; snd＿una=RSEG.ACK; ・ ・ return(TRUE＿OFF); /* 受信イベントのみ正常に処理 ( 送信イベントは処理されなかった) */ ｝

【００８３】上記 TCPエミュレーションの実装に基づく
エミュレーション例を、図１２及び図１３を参照して説
明する。図１３（ａ）は２つの通信システム(A)(B)の通
信シーケンスを示し、同図（ｂ）は通信システム(A) に
関するイベントシーケンスログ４５の内容を示す。この
場合のエミュレーションは下記(1) 〜(5) により行われ
る。 (1)TCPエミュレーション部４４は、イベントシーケンス
ログ４５から送信イベントSYNsent を抽出し、遷移*1を
選択する。このとき、遷移探索結果はTRUEとなり、次の
状態(state) は SYN＿SENTとなる。前の状態はCLOSEDで
あった。内部変数については、 iss=SSEG.SEQ snd＿una=iss snd＿nxt=iss+1 rcv＿wnd=SSEG.WND snd＿max= snd＿nxt cwnd=mss ssthresh=655335; state= SYN＿SENT status=SS と推定する。但し、SSEG.SEQは送信イベントのシーケン
ス番号を示し、SSEG.WNDは送信イベントのウインドウを
表す。 (2) 次に、受信イベントSYN+ACKrecv を抽出し、同受信
イベント以降で最初の送信イベントであるACKsent を抽
出する。このとき、遷移*4が探索され、遷移探索結果は
TRUE＿ONとなり、この送信イベントACKsent を処理済み
とし、次の状態はESTABLISH となる。内部変数について
は、 irs=RSEG.SEQ snd＿una=RSEG.ACK rcv＿nxt=irs+1 rcv＿wnd=SSEG.WND rcv＿una=SSEG.ACK snd＿wnd=RSEG.WND state=ESTABLISHED; return(TRUE ＿ON); と推定する。但し、SSEG.ACKは、送信イベントの ACK番
号を示す。 (3) 次に、送信イベントDATAsentを抽出し、遷移*6を探
索する。このとき、内部手順がslow startに従っている
か否かの確認を行い、内部変数を更新する。遷移探索結
果はTRUEとなる。内部変数については、 ssthresh=max(2*mss, min(cwnd, snd＿wnd)/2) cwnd=mss status=SS; と推定する。 (4) 次に、受信イベントACKrecv を抽出し、同受信イベ
ント以降で最初の送信イベントであるDATAsentを抽出す
る。このとき、遷移*9を探索し、内部手順に対応する内
部変数status（ステータス）の値がSSなので、内部変数
CWNDを1460から2920に更新する。遷移探索結果はTRUE＿
OFF であるため、送信イベントDATAsentは未処理のまま
とする。 (5) 上記(3) と同様に残る２つの送信イベントDATAsent
を順にエミュレーションし、内部変数の更新を行う。

【００８４】［エミュレーション例：その２］次に、図
５に示した遷移#1〜#21 を例に採り、送信イベント毎、
あるいは、受信イベント及び送信イベントの組毎に行う
遷移探索処理の詳細を以下に示す。この例の場合も、状
態はCLOSED,SYN＿SENT,SYN＿RCVD,ESTABLISHED,FIN＿WA
IT＿1, FIN＿WAIT＿2,CLOSING, CLOSE＿WAIT, LAST＿AC
K,TIME＿WAITの値を取り得る。また、内部変数としては
snd＿nxt, snd＿una, snd＿wnd, mss, rcv＿nxt, rcv
＿wnd, rcv＿una, status(NORMAL,SS,CA,FR のいずれか
の値をとる), cwnd, ssthresh, dupacks,finrecv＿flag
を保持する。

【００８５】送信イベントの状態遷移探索処理(process
＿sent＿event)を、下記[1] 〜[8]に示す。

【００８６】[1] 状態CLOSEDにおける SYN送信イベント
の場合：この場合、状態をCLOSEDから SYN＿SENTに遷移
し、また、内部手順slow startを開始したと推定してス
テータスをNORMALからSSに遷移する。更に、送信セグメ
ント (SYN)のパラメータを元に、他の内部変数を推定す
る。遷移探索結果としてTRUEを返す。図５中の遷移#1参
照。

【００８７】[2] 状態ESTABLISHED におけるDTまたはAC
K 送信イベントの場合：DT送信時は下記(1) の ACK送信
処理と下記(2) のDT送信処理を実行し、 ACK送信時は
(1)の ACK送信処理のみを実行する。図５中の遷移#2-
1、#2-2参照。 (1)ACK送信処理： (i) 送信セグメントの ACK番号が rcv＿una に等しく、
且つ、送信セグメントのTCPユーザデータ長が０である
場合は、送信セグメントのウインドウが rcv＿wnd より
も大きければwindow update を示すACK であると判断し
て rcv＿wnd の値を更新し、送信セグメントのウインド
ウが rcv＿wnd に等しければ重複ACK(duplicate ACK)で
あると判断する。 (ii)送信セグメントの ACK番号が rcv＿una と等しくな
い場合は、新しい受信データを確認したものと判断して
rcv＿wnd 、及び、 rcv＿una を更新する。ここで、 f
inrecv＿flagがON（オン）であり、全てのデータを確認
している場合( 送信セグメントの ACK番号が rcv＿nxt
に等しい場合) は、状態をESTABLISHED から CLOSE＿WA
ITに遷移する。 (2) DT送信処理： (i) 送信セグメントのシーケンス番号が snd＿nxt に等
しい場合は、以下(a)(b)の操作を行う。 (a) 輻輳制御のエミュレーション中であり、送信セグメ
ントのシーケンス番号の右端(snd＿nxt ＋ TCPユーザデ
ータ長）が現在のウインドウの右端(snd＿una ＋cwnd）
よりも大きい場合は、輻輳制御の手順に従っていないも
のと判断し、輻輳制御のエミュレーションを終了する。
つまり、オリジナル-TCPである。 (b)snd＿nxt を TCPユーザデータ長分、増加させる。 (ii)送信セグメントのシーケンス番号が snd＿nxt に等
しくない場合は、データの再送が発生したものと判断
し、以下(a)(b)の操作を行う。 (a) 輻輳制御のエミュレーション中ならば、内部変数ss
threshをmax(2*mss, min(snd＿wnd, cwnd)) に更新し、
内部変数cwndを mssに更新し、ステータスをSSに設定す
る。 (b)snd＿nxt を TCPユーザデータ長分、増加させる。 (3) 終了処理：遷移探索結果としてTRUEを返す。

【００８８】[3] 状態ESTABLISHED における FIN送信イ
ベントの場合:前記[2](状態ESTABLISHED におけるDTま
たはACK 送信) における(1)(2)と同様の処理を行い、更
に、状態を FIN＿WAIT＿1 に遷移し、輻輳制御のエミュ
レーションを終了する。送信セグメント(FIN) のパラメ
ータを元に、他の内部変数を設定する。遷移探索結果と
してTRUEを返す。図５中の遷移#3参照。

【００８９】[4] 状態 FIN＿WAIT＿1 における ACK送信
イベントの場合：前記[2](状態ESTABLISHED におけるDT
またはACK 送信）における(1) と同様の処理を行い、更
に、 finrecv＿flagがONであり、 FINを確認する ACK送
信の場合、状態を CLOSINGに遷移する。FIN を確認しな
い ACK送信の場合は、状態は FIN＿WAIT＿1 のままとす
る。遷移探索結果としてTRUEを返す。図５中の遷移#4-
1,#4-2 参照。

【００９０】[5] 状態 FIN＿WAIT＿2 における ACK送信
イベントの場合：前記[2](状態ESTABLISHED におけるDT
またはACK 送信）における(1) と同様の処理を行い、更
に、 finrecv＿flagがONであり、 FINを確認する ACK送
信の場合、状態をTIME＿WAITに遷移する。 FINを確認し
ない ACK送信の場合は、状態は FIN＿WAIT＿2 のままと
する。遷移探索結果としてTRUEを返す。図５中の遷移#5
-1,#5-2 参照。

【００９１】[6] 状態 CLOSE＿WAITにおけるDTまたはAC
K 送信イベントの場合：前記[2](状態ESTABLISHED にお
けるDTまたはACK 送信) と同様の処理を行う。図５中の
遷移#6参照。

【００９２】[7] 状態 CLOSE＿WAITにおける FIN送信イ
ベントの場合：前記[3](状態ESTABLISHED における FIN
送信) と同様の処理を行う。図５中の遷移#7参照。

【００９３】[8] 状態TIME＿WAITにおける SYN送信イベ
ントの場合：状態が既にCLOSEDに遷移していたものと判
断し、上記[8](状態CLOSEDにおける SYN送信）と同様の
処理を行う。図５中の遷移#8参照。

【００９４】次に、受信イベントの状態遷移探索処理(p
rocess＿recv＿event)を、下記[9]〜[21]に示す。

【００９５】[9] 状態CLOSEDにおける SYN受信イベント
の場合： (1) 抽出した送信セグメントがSYN+ACK の場合には、状
態を SYN＿RCVDに遷移し、ステータスをSSに遷移し(slo
w start を開始したと推定) 、受信セグメント(SYN) 及
び送信セグメント(SYN,ACK) のパラメータを元に、他の
内部変数を推定する。この場合、遷移探索結果としてTR
UE＿ONを返す。図５中の遷移#9-1参照。 (2) 送信セグメントがRST+ACK の場合は、状態はCLOSED
のままとし、コネクション要求が拒否されたものと判断
し、遷移探索結果としてTRUE＿ONを返す。図５中の遷移
#9-2参照。 (3) 送信セグメントが上記以外の場合は、状態はCLOSED
のままとし、遷移探索結果としてTRUE＿OFF を返す。図
５中の遷移#9-2参照。

【００９６】[10]状態 SYN＿SENTにおける SYN受信イベ
ントの場合： (1) 抽出した送信セグメントがSYN+ACK の場合、状態を
SYN＿RCVDに遷移する。この場合、双方からのコネクシ
ョン確立要求の衝突(simultaneous open) が発生したも
の判断される。この場合、遷移探索結果としてTRUE＿ON
を返す。図５中の遷移#10-1 参照。なお、simultaneous
open は双方向から同時にコネクション要求が発生した
場合であり、図１４に示すシーケンスにより、コネクシ
ョンが確立される。 (2) 送信セグメントが上記以外の場合は、状態は SYN＿
SENTのままとし、遷移探索結果としてTRUE＿OFF を返
す。図５中の遷移#10-2 参照。

【００９７】[11]状態 SYN＿SENTにおける SYN+ACK受信
イベントの場合： (1)抽出した送信セグメントが ACKの場合、状態をESTAB
LISHED に遷移する。この場合、遷移探索結果としてTRU
E＿ONを返す。図５中の遷移#11-1 参照。 (2) 送信セグメントが RSTの場合、状態をCLOSEDに遷移
する。この場合、コネクション要求が拒否されたものと
判断し、遷移探索結果としてTRUE＿ONを返す。図５中の
遷移#11-2 参照。 (3) 送信セグメントが上記以外の場合は、状態は SYN＿
SENTのままとし、遷移探索結果としてTRUE＿OFF を返
す。

【００９８】[12]状態 SYN＿RCVDにおける ACK受信イベ
ントの場合：状態をESTABLISHED に遷移し、遷移探索結
果としてTRUE＿OFF を返す。図５中の遷移#12 参照。

【００９９】[13]状態ESTABLISHED におけるDTまたはAC
K 受信イベントの場合：DT受信時は下記(1) の ACK受信
処理と下記(2) のDT受信処理を実行し、 ACK受信時は
(1) の ACK受信処理のみを実行する。図５中の遷移#13
参照。 (1)ACK受信処理： (i) 受信セグメントの ACK番号が snd＿una に等しく、
且つ、受信セグメントのTCPユーザデータ長が０である
場合は、受信セグメントのウインドウが snd＿wnd に等
しければ、 duplicate ACKの受信であると判断し、以下
の操作を行う。 (a) dupacks を１加算する。 (b) dupacks が既定値（３とする）以上であり、fast r
etransmit の手順を実行中でない（ステータスがFRでな
い）ならば、抽出した送信セグメントがデータの再送を
示すDTの場合、fast retransmit が行われたものと判断
し、ssthreshをmax(2*mss,min(snd＿wnd,cwnd))に更新
し、、cwndをssthresh+3*mssに更新し、ステータスをFR
に設定する。この場合、遷移探索結果としてTRUE＿ONを
返す。 (c) ただし、上記において抽出した送信セグメントがデ
ータの再送を示すDTでない場合には、輻輳制御のエミュ
レーションに従っていないもの、つまりオリジナルTCP
と判断し、輻輳制御のエミュレーションを終了する。こ
の場合、遷移探索結果としてTRUE＿OFF を返す。 (d) fast retransmit の手順を実行中ならば、cwndを m
ssだけ増加する。この場合、遷移探索結果としてTRUE＿
OFF を返す。 (ii)受信セグメントの ACK番号が snd＿una に等しい
が、受信セグメントの TCPユーザデータ長が０でない場
合は、後述する(2) のDT受信処理を実行する。 (iii) 受信セグメントの ACK番号が snd＿una に等しく
ない場合は、新しい送信セグメントが ACKされたものと
判断する。この場合、 (a) slow startのエミュレーション中（ステータスがS
S）ならば、cwndを mssだけ増加させる。ただし、cwnd
が最大ウインドウサイズ(65535) を超えた場合は、輻輳
制御のエミュレーションを終了する。また、cwndがssth
reshを超えた場合は、congestion avoidanceのエミュレ
ーション（ステータスがCA）を行う。 (b) congestion avoidanceのエミュレーション中なら
ば、cwndを(mss*mss)/cwnd+mss/8だけ増加させる。ただ
し、cwndが最大ウインドウサイズ(65535) を超えた場
合、輻輳制御のエミュレーションを終了する。 (c) fast retransmit のエミュレーション中ならば、co
ngestion avoidanceのエミュレーションを行う。 (2) DT受信処理：受信データの TCPユーザデータ長分、
rcv＿nxt を増加させる。状態はESTABLISHED のままで
あり、ステータスも変化しない。 (3) 終了処理：遷移探索結果としてTRUE＿OFF を返す。

【０１００】[14]状態ESTABLISHED における FIN受信イ
ベントの場合：前記[13]（状態ESTABLISHED におけるDT
またはACK 受信）と同様の処理を行い、更に、 finrecv
＿flagをON（オン）に設定する。遷移探索結果としてTR
UE＿OFFを返す。図５中の遷移#14 参照。

【０１０１】[15]状態 FIN＿WAIT＿1 におけるDTまたは
ACK 受信イベントの場合：FINを確認する ACK受信の場
合、状態を FIN＿WAIT＿2 に遷移する。図５中の遷移#1
5-1 参照。DT受信の場合は、 ACK受信の処理に加えて、
上記[14]（状態ESTABLISHED におけるDTまたはACK 受
信）の(2) と同様のDT受信処理を行う。 FINを確認しな
い ACK受信の場合は、状態は FIN＿WAIT＿1 のままとな
る。遷移探索結果としてTRUE＿OFF を返す。図５中の遷
移#15-2 参照。

【０１０２】[16]状態 FIN＿WAIT＿1 における FIN受信
イベントの場合：上記[13]（状態ESTABLISHED における
DTまたはACK 受信）の(1)(2)と同様の処理を行い、更
に、 finrecv＿flagをONに設定する。図５中の遷移#16
参照。

【０１０３】[17]状態 FIN＿WAIT＿2 におけるDTまたは
ACK 受信イベントの場合：上記[13]（状態ESTABLISHED
におけるDTまたはACK 送信）と同様の処理を行う。図５
中の遷移#17 参照。

【０１０４】[18]状態 FIN＿WAIT＿2 における FIN受信
イベントの場合：上記[13]（状態ESTABLISHED における
DTまたはACK 受信）の(1)(2)と同様の処理を行い、更
に、 finrecv＿flagをONに設定する。図５中の遷移#18
参照。

【０１０５】[19]状態 CLOSINGにおける ACK受信イベン
トの場合：FINを確認するACK 受信の場合、状態をTIME
＿WAITに遷移する。図５中の遷移#19-1 参照。 FINを確
認しない ACK受信の場合は、状態はCLOSING のままとな
る。遷移探索結果としてTRUE＿OFF を返す。図５中の遷
移#19-2 参照。

【０１０６】[20]状態LAST＿ACK における ACK受信イベ
ントの場合：FINを確認する ACK受信の場合、状態をCLO
SEDに遷移する。図５中の遷移#20-1参照。 FINを確認し
ない ACK受信の場合は、状態はLAST＿ACK のままとな
る。遷移探索結果としてTRUE＿OFF を返す。図５中の遷
移#20-2 参照。

【０１０７】[21]状態TIME＿WAITにおける SYN受信イベ
ントの場合：状態が既にCLOSEDに遷移していたものと判
断し、上記[9](状態CLOSEDにおける SYN受信）と同様の
処理を行う。図５中の遷移#21 参照。

【０１０８】ところで、イベントシーケンスの順序を誤
って推定したり、誤ったエミュレーションを行う場合が
考えられる。例えば、イベントの送受信時刻の上述した
推定においては、ルータにおけるバッファリングの遅延
を考慮していないが、この遅延が大きい場合は、リンク
モニタ２０で推定したイベントシーケンスの順序が実際
に処理した順序と異なる可能性がある。そのような場合
に対処するためには、ルールベースプログラミング等の
ヒューリスティックなアルゴリズムを適用して、イベン
トシーケンスを並び替える。

【０１０９】上述した説明では、通信の詳細な解析をオ
フライン部４０で行っているが、UNIXワークステーショ
ン等の計算速度が十分高速であれば、 PDUの取得及びそ
のフォーマット解析と同時に、オンライン処理で行って
も良い。

【０１１０】リンクモニタ２０及び同リンクモニタ２０
が行うインターネット対応リンクモニタ方法は、コンピ
ュータプログラムを CPU（中央処理装置）が読み取って
実現している。つまり、TCP/IPに従った通信の詳細な解
析に必要な上述した機能をコンピュータプログラム化
し、 CPUが読み取り可能なデータの形式で記録媒体に記
録し、このコンピュータプログラムを CPUに読み取らせ
るようにしている。

【０１１１】

【発明の効果】本発明によれば、下記（１）〜（３）の
効果がある。 （１）本発明に係るインターネット対応リンクモニタ方
法は、TCP/IPに従った通信の詳細解析を行うことができ
るに。特に、フロー制御のための TCPの内部手順の解析
に有効である。例えば、slow startやデータの再送がど
の程度発生したかを推定することにより、スループット
低下の原因を調査するのに有用である。

【０１１２】（２）詳しくは、本発明に係るインターネ
ット対応リンクモニタ方法は、市販のプロトコルモニタ
が持つ PDU解析機能と、特定の一対の通信システムを対
象として TCPプロトコルエンティティの振舞いをエミュ
レートすることにより、行われている通信を詳細に解析
する機能を持ち、状態遷移に基づいた振舞いに加えて、
slow startなどフロー制御のための内部手順をエミュレ
ートすることができるので、slow startの発生回数、タ
イムアウトやfast retransmit によるデータの再送回数
などの推定を含め、TCP/IPの通信を詳細に解析すること
が可能となる。

【０１１３】（３）本発明に係るインターネット対応リ
ンクモニタ方法は、 OSI対応のインテリジェントモニタ
と比較すると、下記(i) 〜(iii) の利点がある。 (i) 単一のレイヤのエミュレーションを対象とするの
で、設計が容易である。 (ii) TCPのエミュレーション機能をオフラインで実行す
る場合は、更に設計が容易である。 (iii) TCPのエミュレーションはOSI のプロトコルに比
べて、フロー制御に関わる内部手順をサポートするとい
う点で複雑となるが、状態遷移に基づく状態（ステー
ト：state ）の他に、ステータス（status）という内部
手順の実行の状態に相当する内部変数を保持することに
より、設計が容易である。

【図面の簡単な説明】

【図１】ネットワークの構成例とリンクモニタの接続例
を示す図。

【図２】PDUの例としてイーサネットにおけるフレーム
構成を示す図。

【図３】IPヘッダのフォーマットを示す図。

【図４】TCPヘッダのフォーマットを示す図。

【図５】TCPの状態遷移を示す図。

【図６】リンクモニタの構成例を示す図。

【図７】イベントシーケンスの例を示す図。

【図８】エミュレーションログの内容の例を示す図。

【図９】通信シムテム(A) に関するイベントシーケンス
ログの内容の例を示す図。

【図１０】通信シムテム(C) に関するイベントシーケン
スログの内容の例を示す図。

【図１１】TCPシミュレーション部の処理フローを示す
図。

【図１２】TCPの一部抜粋した状態遷移を示す図。

【図１３】TCPシミュレーションの例を示す図。

【図１４】双方向同時コネクション要求が発生した場合
のシーケンスを示す図。

【符号の説明】 (A) 、(B) 、 (C) 通信システム １ WAN ２、３ ルータ ４、５ LAN ６ フォーマット解析 ７、８ エミュレーション １０ フレーム １１ イーサネットヘッダ １２ イーサネットトレーラ １３ IPデータグラム １４ IPヘッダ １５ TCPセグメント １６ TCPヘッダ １７ TCPユーザ・データ １８ 制御ビット・フィールド ２０ リンクモニタ ３０ オンライン部 ３１ フレーム取得部 ３２ PDU解析部 ３３ モニタログ ３４ エミュレーションログ ４０ オフライン部 ４１ PDUモニタ結果検査部 ４２ TCP振舞いエミュレーション部 ４３ イベントシーケンス推定部 ４４ TCPエミュレーション部 ４５ イベントシーケンスログ ４６ TCP状態遷移仕様 ４７、４８ 内部変数

───────────────────────────────────────────────────── フロントページの続き (72)発明者 鈴木 健二 東京都新宿区西新宿二丁目３番２号 国際 電信電話株式会社内

Claims (6)

【特許請求の範囲】
1. 【請求項１】 TCP/IPプロトコルに従う通信を行う通信
   システムのイベントシーケンスと、 TCPのプロトコル仕
   様に基づいて作成した TCP状態遷移仕様と、TCPプロト
   コルの状態及び内部変数と、 TCPプロトコルの輻輳制御
   に関する複数の内部手順のうちどれが行われているかを
   示すステータス及び各内部手順で使用される内部変数を
   含む内部手順に対応する内部変数とを用いて、状態遷移
   に基づく TCPプロトコルの振舞い及び内部手順のエミュ
   レーション処理を行うことにより、通信の詳細を解析す
   ることを特徴とするインターネット対応リンクモニタ方
   法。
2. 【請求項２】 前記 TCP状態遷移仕様として、送信イベ
   ント処理においては、各状態において送信可能なPDU
   と、送信PDU のパラメータの条件を規定し、送信イベン
   ト処理後の状態及び内部変数の少なくとも一方を定義し
   たこと、受信イベント処理においては、受信イベントの
   パラメータ、現在の状態及び内部変数のうち少なくとも
   一つ毎に、受信イベント処理後の状態及び内部変数の少
   なくとも一方を定義したこと、受信イベント処理におい
   て、受信イベントに対する応答として期待される送信イ
   ベントが存在する場合は、その送信PDU のパラメータの
   条件を規定し、送信イベント処理後の状態及び内部変数
   の少なくとも一方を定義したことを特徴とする請求項１
   に記載のインターネット対応リンクモニタ方法。
3. 【請求項３】 前記エミュレーション処理において、送
   信イベントを処理する場合は、そのイベントの送信が可
   能か否かを TCP状態遷移仕様を探索することにより判断
   し、可能ならば送信イベント処理後の状態または内部変
   数を推定すること、受信イベントを処理する場合は、受
   信イベントに対する応答となる送信イベントを抽出し、
   TCP状態遷移仕様を探索することにより遷移可能か否か
   を判断し、遷移可能であり送信イベントが処理されたな
   らば、送信イベント処理後の状態または内部変数を TCP
   状態遷移仕様に従って推定し、遷移可能であり送信イベ
   ントが処理されなかったならば受信イベント処理後の状
   態または内部変数を TCP状態遷移仕様に従って推定する
   ことを特徴とする請求項１又は２に記載のインターネッ
   ト対応リンクモニタ方法。
4. 【請求項４】 前記エミュレーション処理において、イ
   ベントシーケンスからイベントを逐次抽出し、抽出した
   イベントが送信イベントであるか受信イベントであるか
   を識別すること、抽出したイベントが送信イベントであ
   る場合は、 TCP状態遷移仕様に従って実行可能な遷移を
   探索し、実行可能な遷移の探索に成功すれば状態及び内
   部変数を更新し、失敗すればプロトコルエラーであると
   判定すること、抽出したイベントが受信イベントである
   場合は、イベントシーケンスから未処理で且つ当該受信
   イベント以降最初の送信イベントを抽出し、この送信イ
   ベントが前記受信イベントに対する応答であると仮定し
   て該当する遷移を TCP状態遷移仕様に従って探索し、こ
   の探索に失敗すれば受信イベントが紛失したものと判定
   し、この探索に成功し且つ前記応答であると仮定した送
   信イベントが処理された場合はイベントシーケンスに同
   送信イベントが処理済みであることを記録した後、状態
   及び内部変数を更新して該当する遷移を実行し、この探
   索に成功したが前記応答であると仮定した送信イベント
   が処理されていない場合は状態及び内部変数を更新して
   該当する遷移を実行することを特徴とする請求項１又は
   ２に記載のインターネット対応リンクモニタ方法。
5. 【請求項５】 前記エミュレーション処理において、現
   在行われている輻輳制御に関する内部手順を示すステー
   タスとして、スロー・スタート、コンジェスチョン・ア
   ボイダンス、高速再転送と高速リカバリ、どの内部手順
   も行われていない又は行われている内部手順が不明であ
   ることを示すノーマルの４つを推定すること、送信イベ
   ント及び受信イベントのうちいずれか一方の処理を契機
   に、輻輳制御に関する内部手順の発生、輻輳制御に関す
   る内部手順の終了、輻輳制御に関する内部手順が使用す
   る内部変数の値を判断すること、輻輳制御に関する内部
   手順のうちスロー・スタートについては、タイムアウト
   再送を契機に、スロー・スタート発生したことを判断
   し、以降のDT送信毎及び ACK受信毎に、内部変数の値を
   推定すること、輻輳制御に関する内部手順のうち高速再
   転送と高速リカバリについては、３つの重複ACK の受信
   を契機に、それぞれが発生したことを判断すること特徴
   とする請求項１から４いずれかに記載のインターネット
   対応リンクモニタ方法。
6. 【請求項６】 一対の通信システム間のPDU を回線上に
   流れるデータから取得し、取得したPDU を解析してエミ
   ュレーションログを作成し、エミュレーションログを元
   にそのPDU を送受信した双方の通信システムのイベント
   シーケンスを推定することを特徴とする請求項１から５
   いずれかに記載のインターネット対応リンクモニタ方
   法。