JPH08331146A - Ｌａｎアナライザ - Google Patents
ＬａｎアナライザInfo
- Publication number
- JPH08331146A JPH08331146A JP7136847A JP13684795A JPH08331146A JP H08331146 A JPH08331146 A JP H08331146A JP 7136847 A JP7136847 A JP 7136847A JP 13684795 A JP13684795 A JP 13684795A JP H08331146 A JPH08331146 A JP H08331146A
- Authority
- JP
- Japan
- Prior art keywords
- protocol
- packet
- lan
- state
- lan analyzer
- 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.)
- Pending
Links
Landscapes
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
- Maintenance And Management Of Digital Transmission (AREA)
Abstract
(57)【要約】
【目的】採取したパケットデータ群に基づいて人手によ
らず自動的に解析を行うとともに、採取したパケットデ
ータ群をリアルタイムに解析することができるＬＡＮア
ナライザを提供する。 【構成】パケットヘッダ１１の合計１２オクテットの送
信先アドレスおよび送信元アドレスを圧縮して２オクテ
ットのアドレスに変換し、これにより状態記録テーブル
１４をポイントする。同時に、パケットヘッダ内の遷移
パラメータ（ＡＣＫ，ＳＹＮ，ＦＩＮ）に基づいて状態
変遷テーブル１５を参照し、当該端末間のパケットの授
受手順に関する状態遷移を追跡する。得られた状態を状
態記録テーブル１４のポイントされた記録エリアに格納
する。この記録エリアの内容に応じてエラー表示を行
う。
らず自動的に解析を行うとともに、採取したパケットデ
ータ群をリアルタイムに解析することができるＬＡＮア
ナライザを提供する。 【構成】パケットヘッダ１１の合計１２オクテットの送
信先アドレスおよび送信元アドレスを圧縮して２オクテ
ットのアドレスに変換し、これにより状態記録テーブル
１４をポイントする。同時に、パケットヘッダ内の遷移
パラメータ（ＡＣＫ，ＳＹＮ，ＦＩＮ）に基づいて状態
変遷テーブル１５を参照し、当該端末間のパケットの授
受手順に関する状態遷移を追跡する。得られた状態を状
態記録テーブル１４のポイントされた記録エリアに格納
する。この記録エリアの内容に応じてエラー表示を行
う。
Description
【０００１】
【産業上の利用分野】本発明は、ＬＡＮ（ローカルエリ
アネットワーク）システムのためのＬＡＮアナライザに
係り、特にＬＡＮの管理、保守において、ＬＡＮ上を伝
送されるパケットを採取しパケットのやり取りの正当性
を検出するＬＡＮアナライザに関する。
アネットワーク）システムのためのＬＡＮアナライザに
係り、特にＬＡＮの管理、保守において、ＬＡＮ上を伝
送されるパケットを採取しパケットのやり取りの正当性
を検出するＬＡＮアナライザに関する。
【０００２】
【従来の技術】ＬＡＮシステムの管理、保守（特に障害
箇所の切り分け）を実施するに際して、端末間のパケッ
トのやりとりを調査することは、ＯＳＩ（Open System
Interconnection）レベル４層以下の状態を把握するた
めの有効な一手段である。
箇所の切り分け）を実施するに際して、端末間のパケッ
トのやりとりを調査することは、ＯＳＩ（Open System
Interconnection）レベル４層以下の状態を把握するた
めの有効な一手段である。
【０００３】このようなＬＡＮシステムの管理・保守を
支援するための従来のＬＡＮアナライザにおいては、Ｌ
ＡＮ上を伝送されるすべての端末間のパケットを時系列
にデータバッファ（メモリ）に蓄積している。ＬＡＮシ
ステムの検証時には、一旦パケットの収集を中断して、
当該データバッファに蓄積された多量のパケットデータ
群を人手で調査している。
支援するための従来のＬＡＮアナライザにおいては、Ｌ
ＡＮ上を伝送されるすべての端末間のパケットを時系列
にデータバッファ（メモリ）に蓄積している。ＬＡＮシ
ステムの検証時には、一旦パケットの収集を中断して、
当該データバッファに蓄積された多量のパケットデータ
群を人手で調査している。
【０００４】
【発明が解決しようとする課題】このような方式では以
下の問題があった。
下の問題があった。
【０００５】（１）対象とする端末間で伝送されるパケ
ットを取り出し、その手順を解析することを手作業で実
施しなければならず、解析に多大な工数がかかる。
ットを取り出し、その手順を解析することを手作業で実
施しなければならず、解析に多大な工数がかかる。
【０００６】（２）問題が発生したときのパケットデー
タを採取するために、ＬＡＮシステムを常に監視し問題
が発生した時点でＬＡＮアナライザを操作する操作者が
必要となる。これは、インターミッテント（間欠的）に
発生する問題を解決する場合の大きなネックとなる。
尚、現状のＬＡＮアナライザには、特定のイベントが発
生した場合にパケット採取を自動的に停止する機能を持
つものもあるが、一般的にＯＳＩの上位層の問題では停
止させるべきイベントを指定できない場合が多い。
タを採取するために、ＬＡＮシステムを常に監視し問題
が発生した時点でＬＡＮアナライザを操作する操作者が
必要となる。これは、インターミッテント（間欠的）に
発生する問題を解決する場合の大きなネックとなる。
尚、現状のＬＡＮアナライザには、特定のイベントが発
生した場合にパケット採取を自動的に停止する機能を持
つものもあるが、一般的にＯＳＩの上位層の問題では停
止させるべきイベントを指定できない場合が多い。
【０００７】（３）ＬＡＮアナライザのデータバッタの
容量には限りがありその記憶領域がラップアラウンドし
て用いられるために、仮に問題が発生していても、その
状態がデータバッファに残っていることは必ずしも期待
できない。
容量には限りがありその記憶領域がラップアラウンドし
て用いられるために、仮に問題が発生していても、その
状態がデータバッファに残っていることは必ずしも期待
できない。
【０００８】本発明の目的は、採取したパケットデータ
群に基づいて人手によらず自動的に解析を行うことがで
きるＬＡＮアナライザを提供することにある。
群に基づいて人手によらず自動的に解析を行うことがで
きるＬＡＮアナライザを提供することにある。
【０００９】本発明の他の目的は、採取したパケットデ
ータ群をリアルタイムに解析することができるＬＡＮア
ナライザを提供することにある。
ータ群をリアルタイムに解析することができるＬＡＮア
ナライザを提供することにある。
【００１０】
【課題を解決するための手段】前記問題を解決するため
に、本発明によるＬＡＮアナライザは、ＬＡＮ上の通信
プロトコル（ＴＣＰ／ＩＰやＳＰＸ／ＩＰＸ等）のパケ
ットを採取してパケット授受手順の正当性を検証するＬ
ＡＮアナライザであって、ＬＡＮに接続された第１の端
末と第２の端末との間で授受されるパケットを、該パケ
ットヘッダに含まれる送信元アドレスおよび送信先アド
レスに基づいて認識し、当該パケットヘッダに含まれる
プロトコル状態遷移の契機となる遷移パラメータに基づ
いて、両端末間のプロトコル状態遷移を認識し、該認識
されたプロトコル状態遷移を当該通信プロトコルで決め
られている正常なプロトコル状態遷移と比較することに
よって、両端末間のパケット授受手順の正当性を検証
し、該検証結果を表示画面上に表示するＬＡＮアナライ
ザを提供する。
に、本発明によるＬＡＮアナライザは、ＬＡＮ上の通信
プロトコル（ＴＣＰ／ＩＰやＳＰＸ／ＩＰＸ等）のパケ
ットを採取してパケット授受手順の正当性を検証するＬ
ＡＮアナライザであって、ＬＡＮに接続された第１の端
末と第２の端末との間で授受されるパケットを、該パケ
ットヘッダに含まれる送信元アドレスおよび送信先アド
レスに基づいて認識し、当該パケットヘッダに含まれる
プロトコル状態遷移の契機となる遷移パラメータに基づ
いて、両端末間のプロトコル状態遷移を認識し、該認識
されたプロトコル状態遷移を当該通信プロトコルで決め
られている正常なプロトコル状態遷移と比較することに
よって、両端末間のパケット授受手順の正当性を検証
し、該検証結果を表示画面上に表示するＬＡＮアナライ
ザを提供する。
【００１１】このＬＡＮアナライザにおいて、前記パケ
ット授受手順の正当性の検証をパケット採取と並行して
リアルタイムに実行することが望ましい。
ット授受手順の正当性の検証をパケット採取と並行して
リアルタイムに実行することが望ましい。
【００１２】また、好ましくは、前記通信プロトコルで
決められているパケットの授受手順を示した状態遷移図
に対してエラー（予め決めておいた応答時間を超過した
エラーも含む）を示す状態を加味して作成したテーブル
であって、現在のプロトコル状態に対してどの遷移パラ
メータを受けたとき次にどのプロトコル状態に移行する
かを示す状態変遷テーブルを有し、前記パケットヘッダ
に含まれる遷移パラメータに基づいて該状態変遷テーブ
ルを参照することによりプロトコル状態遷移をリアルタ
イムに認識する。
決められているパケットの授受手順を示した状態遷移図
に対してエラー（予め決めておいた応答時間を超過した
エラーも含む）を示す状態を加味して作成したテーブル
であって、現在のプロトコル状態に対してどの遷移パラ
メータを受けたとき次にどのプロトコル状態に移行する
かを示す状態変遷テーブルを有し、前記パケットヘッダ
に含まれる遷移パラメータに基づいて該状態変遷テーブ
ルを参照することによりプロトコル状態遷移をリアルタ
イムに認識する。
【００１３】さらに、各端末ペア間のプロトコル状態を
保持するために端末の全ての１対１の組み合わせに対す
るプロトコル状態を格納する状態記録テーブルを有し、
前記第１および第２の端末間のパケットについて前記変
遷テーブルの参照により得られた状態を当該状態記録テ
ーブルの対応するエリアに格納し、該エリアに格納され
た内容に応じて前記検証結果の表示を行う。
保持するために端末の全ての１対１の組み合わせに対す
るプロトコル状態を格納する状態記録テーブルを有し、
前記第１および第２の端末間のパケットについて前記変
遷テーブルの参照により得られた状態を当該状態記録テ
ーブルの対応するエリアに格納し、該エリアに格納され
た内容に応じて前記検証結果の表示を行う。
【００１４】このＬＡＮアナライザにおいて、送信元ア
ドレスおよび送信先アドレスの組をより小さいアドレス
値に圧縮する圧縮手段を設け、該圧縮されたアドレス値
により前記状態記録テーブルを検索することが好まし
い。
ドレスおよび送信先アドレスの組をより小さいアドレス
値に圧縮する圧縮手段を設け、該圧縮されたアドレス値
により前記状態記録テーブルを検索することが好まし
い。
【００１５】前記送信元アドレスおよび送信先アドレス
は、例えば、パケットヘッダの先頭にあるユニークなＭ
ＡＣアドレスである。
は、例えば、パケットヘッダの先頭にあるユニークなＭ
ＡＣアドレスである。
【００１６】前記圧縮手段は、例えばＣＲＣ演算を実行
するものである。好ましくは、このＣＲＣ演算はハード
ウエアで実行する。
するものである。好ましくは、このＣＲＣ演算はハード
ウエアで実行する。
【００１７】前記圧縮手段は、圧縮の前に前記送信元ア
ドレスおよび送信先アドレスに交換則が成り立つ演算を
施し、該演算の結果に対して圧縮処理をを施すことが望
ましい。
ドレスおよび送信先アドレスに交換則が成り立つ演算を
施し、該演算の結果に対して圧縮処理をを施すことが望
ましい。
【００１８】前記状態変遷テーブルを異なる通信プロト
コル毎に用意し、前記パケットヘッダに含まれるプロト
コルタイプに応じて複数の状態変遷テーブルを選択して
用いることも可能である。
コル毎に用意し、前記パケットヘッダに含まれるプロト
コルタイプに応じて複数の状態変遷テーブルを選択して
用いることも可能である。
【００１９】
【作用】本発明のＬＡＮアナライザでは、個々の検証の
対象となる端末間で授受されるパケットを、該パケット
ヘッダに含まれる送信元アドレスおよび送信先アドレス
に基づいて認識し、当該パケットヘッダに含まれるプロ
トコル状態遷移の契機となる遷移パラメータに基づい
て、両端末間のプロトコル状態遷移を認識し、該認識さ
れたプロトコル状態遷移を当該通信プロトコルで決めら
れている正常なプロトコル状態遷移と比較することによ
って、両端末間のパケット授受手順の正当性を検証する
ようにしたので、従来人手で行っていた検証作業を自動
的に行うことが可能になる。
対象となる端末間で授受されるパケットを、該パケット
ヘッダに含まれる送信元アドレスおよび送信先アドレス
に基づいて認識し、当該パケットヘッダに含まれるプロ
トコル状態遷移の契機となる遷移パラメータに基づい
て、両端末間のプロトコル状態遷移を認識し、該認識さ
れたプロトコル状態遷移を当該通信プロトコルで決めら
れている正常なプロトコル状態遷移と比較することによ
って、両端末間のパケット授受手順の正当性を検証する
ようにしたので、従来人手で行っていた検証作業を自動
的に行うことが可能になる。
【００２０】また、このパケット授受手順の正当性の検
証をパケット採取と並行してリアルタイムに実行するこ
とにより、エラーの発生を見逃すことがなくなる。ま
た、採取したパケットデータをすべて蓄積しておくデー
タバッファは必ずしも必要ではなくなる。
証をパケット採取と並行してリアルタイムに実行するこ
とにより、エラーの発生を見逃すことがなくなる。ま
た、採取したパケットデータをすべて蓄積しておくデー
タバッファは必ずしも必要ではなくなる。
【００２１】このリアルタイムの検証のためには、各端
末ペア間に伝送されるパケット（すなわち端末ペア）を
リアルタイムに認識することが必要となる。また、検証
処理も迅速に実行する必要がある。
末ペア間に伝送されるパケット（すなわち端末ペア）を
リアルタイムに認識することが必要となる。また、検証
処理も迅速に実行する必要がある。
【００２２】端末ペアをリアルタイムに認識するために
は、圧縮手段により、送信元アドレスおよび送信先アド
レスの組をより小さいアドレス値に圧縮して、この圧縮
されたアドレス値により状態記録テーブルを検索する。
これにより、実質的に、端末ペアを高速に認識したこと
と等価な結果が得られる。また、このアドレス圧縮によ
り、状態記録テーブルのサイズを小さくすることができ
る。この圧縮手段は例えばＣＲＣ演算であり、これをハ
ードウエアで実行すればよりリアルタイム処理により好
都合な高速な認識処理が行える。
は、圧縮手段により、送信元アドレスおよび送信先アド
レスの組をより小さいアドレス値に圧縮して、この圧縮
されたアドレス値により状態記録テーブルを検索する。
これにより、実質的に、端末ペアを高速に認識したこと
と等価な結果が得られる。また、このアドレス圧縮によ
り、状態記録テーブルのサイズを小さくすることができ
る。この圧縮手段は例えばＣＲＣ演算であり、これをハ
ードウエアで実行すればよりリアルタイム処理により好
都合な高速な認識処理が行える。
【００２３】前記圧縮の前に送信元アドレスおよび送信
先アドレスに交換則が成り立つ演算を施すことによって
もアドレス長を半減することができると同時に、１対の
端末間の双方向のパケットを状態記録テーブルの同一の
記録エリアで監視することが可能になる。
先アドレスに交換則が成り立つ演算を施すことによって
もアドレス長を半減することができると同時に、１対の
端末間の双方向のパケットを状態記録テーブルの同一の
記録エリアで監視することが可能になる。
【００２４】さらに、現在のプロトコル状態に対してど
の遷移パラメータを受けたとき次にどのプロトコル状態
に移行するかを示す状態変遷テーブルを予め作成してお
き、パケットヘッダに含まれる遷移パラメータに基づい
て該状態変遷テーブルを参照する。これによって、検証
処理も高速に行うことが可能になる。
の遷移パラメータを受けたとき次にどのプロトコル状態
に移行するかを示す状態変遷テーブルを予め作成してお
き、パケットヘッダに含まれる遷移パラメータに基づい
て該状態変遷テーブルを参照する。これによって、検証
処理も高速に行うことが可能になる。
【００２５】
【実施例】以下、本発明の一実施例を説明する。
【００２６】先ず、図４に本発明によるＬＡＮアナライ
ザの基本ハードウエア構成を示す。ＬＡＮの伝送ケーブ
ル４０に接続されるＬＡＮアナライザ４１は、このＬＡ
Ｎアナライザ４１全体をプログラム制御するＣＰＵ４３
と、ＬＡＮの伝送ケーブル４０とのインタフェースを司
るＬＡＮボード４２と、処理結果の表示等を行う表示装
置４４と、各種の指示あるいはデータ等の入力を行う入
力装置４５、ＣＰＵ４３の実行するプログラムおよび種
々のデータを格納するメモリ４６と、ＣＲＣ演算回路４
７とを有する。
ザの基本ハードウエア構成を示す。ＬＡＮの伝送ケーブ
ル４０に接続されるＬＡＮアナライザ４１は、このＬＡ
Ｎアナライザ４１全体をプログラム制御するＣＰＵ４３
と、ＬＡＮの伝送ケーブル４０とのインタフェースを司
るＬＡＮボード４２と、処理結果の表示等を行う表示装
置４４と、各種の指示あるいはデータ等の入力を行う入
力装置４５、ＣＰＵ４３の実行するプログラムおよび種
々のデータを格納するメモリ４６と、ＣＲＣ演算回路４
７とを有する。
【００２７】図５は、図４に示したＣＰＵ４３により実
行されるソフトウエアの構成を示す。本実施例における
ソフトウエア処理は、ＭＡＣ(Media Access Control)ア
ドレス演算処理５１、パケットヘッダ認識処理５３、再
送チェック処理５４、ウインドウ（Window)チェック処
理５５、ａｃｋチェック処理５６、応答時間チェック処
理５７、およびエラー表示処理５８からなる。ＣＲＣ演
算処理をハードウエアではなくソフトエアで行う場合に
は、ＣＲＣ演算処理５２を含んでもよい。なお、ウイン
ドウとは、ＴＣＰ／ＩＰ(Transmission Control Protoc
ol/ Internet Protocol)プロトコルにおいて、受信側で
確認応答されているデータを越えて受け入れることがで
きるデータの容量を示すものであり、受信側が確認応答
を送るときに送信側へ送る。
行されるソフトウエアの構成を示す。本実施例における
ソフトウエア処理は、ＭＡＣ(Media Access Control)ア
ドレス演算処理５１、パケットヘッダ認識処理５３、再
送チェック処理５４、ウインドウ（Window)チェック処
理５５、ａｃｋチェック処理５６、応答時間チェック処
理５７、およびエラー表示処理５８からなる。ＣＲＣ演
算処理をハードウエアではなくソフトエアで行う場合に
は、ＣＲＣ演算処理５２を含んでもよい。なお、ウイン
ドウとは、ＴＣＰ／ＩＰ(Transmission Control Protoc
ol/ Internet Protocol)プロトコルにおいて、受信側で
確認応答されているデータを越えて受け入れることがで
きるデータの容量を示すものであり、受信側が確認応答
を送るときに送信側へ送る。
【００２８】図６に、本実施例におけるパケットの構成
を示す。本パケットは、送信先アドレス６１、送信元ア
ドレス６２、プロトコルタイプ６３、ＩＰヘッダ６４、
ＴＣＰヘッダ６５、データ６６からなる。ＴＣＰヘッダ
６５は、ソースポート６５０、デスティネーションポー
ト６５１、シーケンス値６５２、ＡＣＫ値６５３、ＯＦ
Ｆ６５４、フラグ値６５５，ｗｉｎｄｏｗ値６５６、チ
ェックサム６５７、緊急ポインタ６５８、オプション６
５９からなる。さらに、フラグ値６５５は、予約部(res
erved)６５５０の他、”urg”ビット６５５１,”ack”
ビット６５５２,”psh”ビット６５５３,”rst”ビット
６５５４,”syn”ビット６５５５,”fin”ビット６５５
６からなる。これは、ＴＣＰ／ＩＰプロトコルのパケッ
トの構成は周知であり、ここでは詳述はしない。この通
信プロトコル以外の他のプロトコルのパケットであって
も本実施例で必要とする情報を得ることができる。
を示す。本パケットは、送信先アドレス６１、送信元ア
ドレス６２、プロトコルタイプ６３、ＩＰヘッダ６４、
ＴＣＰヘッダ６５、データ６６からなる。ＴＣＰヘッダ
６５は、ソースポート６５０、デスティネーションポー
ト６５１、シーケンス値６５２、ＡＣＫ値６５３、ＯＦ
Ｆ６５４、フラグ値６５５，ｗｉｎｄｏｗ値６５６、チ
ェックサム６５７、緊急ポインタ６５８、オプション６
５９からなる。さらに、フラグ値６５５は、予約部(res
erved)６５５０の他、”urg”ビット６５５１,”ack”
ビット６５５２,”psh”ビット６５５３,”rst”ビット
６５５４,”syn”ビット６５５５,”fin”ビット６５５
６からなる。これは、ＴＣＰ／ＩＰプロトコルのパケッ
トの構成は周知であり、ここでは詳述はしない。この通
信プロトコル以外の他のプロトコルのパケットであって
も本実施例で必要とする情報を得ることができる。
【００２９】本実施例におけるＬＡＮ上のパケットは、
例えば１０Mbpsの転送時、パケット間の間隔は、最小７
３.６μｓとなる。この間に、端末のペアの識別、該当
するプロトコルの認識、状態遷移、異常時の処理を実施
する必要がある。
例えば１０Mbpsの転送時、パケット間の間隔は、最小７
３.６μｓとなる。この間に、端末のペアの識別、該当
するプロトコルの認識、状態遷移、異常時の処理を実施
する必要がある。
【００３０】図２は、最小パケット間隔内で実行すべき
処理を時系列で表したものである。すなわち、あるパケ
ット採取割り込みと次のパケット採取割り込みとの間
に、ＭＡＣアドレス認識（すなわち端末ペアの認識）、
テーブル（後述する状態記録テーブル）サーチ、パケッ
トヘッダ認識、および異常の検出の各処理を所定の時間
内に行う必要がある。図に示したステップ数はアセンブ
ラの命令ステップ数を示し、各処理の所要処理時間に相
当する。この所要処理時間で各処理を行うための具体的
な処理の内容を以下に説明する。
処理を時系列で表したものである。すなわち、あるパケ
ット採取割り込みと次のパケット採取割り込みとの間
に、ＭＡＣアドレス認識（すなわち端末ペアの認識）、
テーブル（後述する状態記録テーブル）サーチ、パケッ
トヘッダ認識、および異常の検出の各処理を所定の時間
内に行う必要がある。図に示したステップ数はアセンブ
ラの命令ステップ数を示し、各処理の所要処理時間に相
当する。この所要処理時間で各処理を行うための具体的
な処理の内容を以下に説明する。
【００３１】図１は、ＬＡＮ上のパケットに関する情報
がメモリー上に保存される過程を説明するためのもので
ある。
がメモリー上に保存される過程を説明するためのもので
ある。
【００３２】端末ペアの識別は、パケットヘッダ１１の
１２オクテットのＭＡＣアドレス１２を好ましくはＣＲ
Ｃハードウエアを利用して２オクテットの空間に写像す
る。この場合、ハードウエアを利用することにより約
９.６μｓで実行できる。このＣＲＣ演算は、通常のエ
ラーチェックのために用いるものではなく、単にデータ
圧縮（ここでは、６オクテットのデータを２オクテット
のデータに変換）のために用いるものであり、この目的
を達成できれば、他の演算であってもよい。すなわち、
端末の全ての１対１の組み合わせの状態を格納する状態
記録テーブル１４を実装可能な大きさにし、かつ、高速
のテーブルサーチを可能にする利点がある。この２オク
テットのデータは、直接、状態記録テーブル１４のポイ
ンタとなる。この状態記録テーブル１４のポイントされ
る各エリアには、エラー検出時のエラーフラグが状態と
して格納される。但し、後述するフラグのセットを行わ
ない状態、例えば、「CLOSEWAIT」、「再送チェック」
等の場合は何も格納する必要はない。なお、端末間の双
方向のパケットを同一テーブルで監視する必要があるた
め１２オクテットのＭＡＣアドレスの送信、受信アドレ
スが逆になった場合もＣＲＣ演算結果は同一にする必要
がある。このため、送信、受信のアドレスを逆にしたＭ
ＡＣアドレスと交換則が成り立つ演算（例えば、足し
算、論理和、排他的論理和等）を施しバッファ１３に格
納し、このバッファ１３の値に対してＣＲＣ演算を施し
て２オクテットの値を得る。ＣＲＣ演算をソフトで行う
場合には、一回計算した値を図８に示すような変換テー
ブル８１として登録しておくことによって次回のＣＲＣ
演算の実行を省略することができ、処理時間をさらに削
減できる。なお、１２オクテットを２オクテットの空間
に写像する際に、重なりが発生する場合がある。（但
し、一般には１２オクテットのアドレスは製造メーカ単
位に距離を持たせてあるため、重なりが発生する頻度は
少ない。）重なりが発生した場合は、２オクテットのポ
インタにプラス１を施しその記録エリアを利用する。そ
こも既に使用されている場合はさらにポインタにプラス
１を施し空きエリアを使う。このポインタの値は変換テ
ーブル８１に登録する。これにより演算結果が同一とな
った場合、使用するメモリアドレスが一意に定まる。
１２オクテットのＭＡＣアドレス１２を好ましくはＣＲ
Ｃハードウエアを利用して２オクテットの空間に写像す
る。この場合、ハードウエアを利用することにより約
９.６μｓで実行できる。このＣＲＣ演算は、通常のエ
ラーチェックのために用いるものではなく、単にデータ
圧縮（ここでは、６オクテットのデータを２オクテット
のデータに変換）のために用いるものであり、この目的
を達成できれば、他の演算であってもよい。すなわち、
端末の全ての１対１の組み合わせの状態を格納する状態
記録テーブル１４を実装可能な大きさにし、かつ、高速
のテーブルサーチを可能にする利点がある。この２オク
テットのデータは、直接、状態記録テーブル１４のポイ
ンタとなる。この状態記録テーブル１４のポイントされ
る各エリアには、エラー検出時のエラーフラグが状態と
して格納される。但し、後述するフラグのセットを行わ
ない状態、例えば、「CLOSEWAIT」、「再送チェック」
等の場合は何も格納する必要はない。なお、端末間の双
方向のパケットを同一テーブルで監視する必要があるた
め１２オクテットのＭＡＣアドレスの送信、受信アドレ
スが逆になった場合もＣＲＣ演算結果は同一にする必要
がある。このため、送信、受信のアドレスを逆にしたＭ
ＡＣアドレスと交換則が成り立つ演算（例えば、足し
算、論理和、排他的論理和等）を施しバッファ１３に格
納し、このバッファ１３の値に対してＣＲＣ演算を施し
て２オクテットの値を得る。ＣＲＣ演算をソフトで行う
場合には、一回計算した値を図８に示すような変換テー
ブル８１として登録しておくことによって次回のＣＲＣ
演算の実行を省略することができ、処理時間をさらに削
減できる。なお、１２オクテットを２オクテットの空間
に写像する際に、重なりが発生する場合がある。（但
し、一般には１２オクテットのアドレスは製造メーカ単
位に距離を持たせてあるため、重なりが発生する頻度は
少ない。）重なりが発生した場合は、２オクテットのポ
インタにプラス１を施しその記録エリアを利用する。そ
こも既に使用されている場合はさらにポインタにプラス
１を施し空きエリアを使う。このポインタの値は変換テ
ーブル８１に登録する。これにより演算結果が同一とな
った場合、使用するメモリアドレスが一意に定まる。
【００３３】該当するプロトコルの認識はパケットのヘ
ッダの一部（図６のプロトコルタイプ６３）をみること
によって決定できる。高速に行うためにプロトコル対応
テーブルを予め設定しておくことによって数μｓで実行
させる。
ッダの一部（図６のプロトコルタイプ６３）をみること
によって決定できる。高速に行うためにプロトコル対応
テーブルを予め設定しておくことによって数μｓで実行
させる。
【００３４】本実施例では、異常の検出処理にプロトコ
ルステータス（状態）変遷テーブル１５を用いる。この
テーブル１５は、図３に示すように、特定のプロトコル
の状態遷移図に対して各種異常チェックのステータスを
追加し、この状態遷移図に基づいて、構成することがで
きる。図３に示した状態遷移図は、ＴＣＰ／ＩＰプロト
コルに対応するものである（Mark A. Miller, P.E., ”
TROUBLE SHOOTING TCP/IP”, June 1992参照）。
ルステータス（状態）変遷テーブル１５を用いる。この
テーブル１５は、図３に示すように、特定のプロトコル
の状態遷移図に対して各種異常チェックのステータスを
追加し、この状態遷移図に基づいて、構成することがで
きる。図３に示した状態遷移図は、ＴＣＰ／ＩＰプロト
コルに対応するものである（Mark A. Miller, P.E., ”
TROUBLE SHOOTING TCP/IP”, June 1992参照）。
【００３５】プロトコルステータス変遷テーブル１５
は、状態を縦軸、遷移パラメータを横軸に配し、その交
点に遷移するステータス番号（および必要なら処理内
容）を記録したものであり、パケットのヘッダ部から遷
移パラメータ（図６のフラグ値）を取り出しこの変遷テ
ーブル１５を参照することによって、遷移状態を数十μ
ｓで検出できる。変遷テーブル１５は各プロトコル単位
に用意しておく。パケットヘッダ内のプロトコルタイプ
６３に基づいて、該当するプロトコルを検出し対応する
変遷テーブル１５を選択することができる。遷移パラメ
ータは、現在の状態に対して次の状態に移行する契機と
なるパラメータであり、図３の例ではＳＹＮ，ＡＣＫ，
ＦＩＮ等がある。ＳＹＮは、ＴＣＰプロトコルにより送
られる最初のセグメントであり、コネクション確立の準
備のためにコネクションの両端側で同期するのに用いら
れるものである。ＡＣＫは、確認応答の意味であり、情
報を正しく受け取ったことを示すために受信側が送る応
答である。ＦＩＮは、コネクションを切断するという意
味のパラメータである。
は、状態を縦軸、遷移パラメータを横軸に配し、その交
点に遷移するステータス番号（および必要なら処理内
容）を記録したものであり、パケットのヘッダ部から遷
移パラメータ（図６のフラグ値）を取り出しこの変遷テ
ーブル１５を参照することによって、遷移状態を数十μ
ｓで検出できる。変遷テーブル１５は各プロトコル単位
に用意しておく。パケットヘッダ内のプロトコルタイプ
６３に基づいて、該当するプロトコルを検出し対応する
変遷テーブル１５を選択することができる。遷移パラメ
ータは、現在の状態に対して次の状態に移行する契機と
なるパラメータであり、図３の例ではＳＹＮ，ＡＣＫ，
ＦＩＮ等がある。ＳＹＮは、ＴＣＰプロトコルにより送
られる最初のセグメントであり、コネクション確立の準
備のためにコネクションの両端側で同期するのに用いら
れるものである。ＡＣＫは、確認応答の意味であり、情
報を正しく受け取ったことを示すために受信側が送る応
答である。ＦＩＮは、コネクションを切断するという意
味のパラメータである。
【００３６】図３の変遷テーブル１５で、例えば、ESTA
B状態（コネクション確立状態）において、正常な遷移
の場合には”FIN”か”ACK”のパケットしかありえな
い。”FIN”を認識した場合は項目２のCLOSE WAITに移
り、”ACK”を認識した場合は項目５の追加ステータス
の１つである再送チェック状態に移る。これら以外のも
の（例えばＳＹＮ）を認識した場合は、正常なパケット
授受手順ではないと判断できるので、項目１３の遷移エ
ラー状態に移る。
B状態（コネクション確立状態）において、正常な遷移
の場合には”FIN”か”ACK”のパケットしかありえな
い。”FIN”を認識した場合は項目２のCLOSE WAITに移
り、”ACK”を認識した場合は項目５の追加ステータス
の１つである再送チェック状態に移る。これら以外のも
の（例えばＳＹＮ）を認識した場合は、正常なパケット
授受手順ではないと判断できるので、項目１３の遷移エ
ラー状態に移る。
【００３７】このように、異常は変遷テーブル１５に一
つの状態として異常状態を登録しておくことによって検
出することができる。したがって、変遷テーブル１５か
ら異常状態に入ったことが認識され、両ＭＡＣアドレス
に対応するメモリ上アドレス１４１のステータスデータ
１４２の該当するビットにフラグがセットされる。異常
状態に入った場合は、対応するＭＡＣアドレスとともに
画面に表示する。必要であればブザーを鳴らす。
つの状態として異常状態を登録しておくことによって検
出することができる。したがって、変遷テーブル１５か
ら異常状態に入ったことが認識され、両ＭＡＣアドレス
に対応するメモリ上アドレス１４１のステータスデータ
１４２の該当するビットにフラグがセットされる。異常
状態に入った場合は、対応するＭＡＣアドレスとともに
画面に表示する。必要であればブザーを鳴らす。
【００３８】通常、ＬＡＮアナライザでは、パケットの
ヘッダ部を使って不良の切り分けを行っており、特定の
場合を除いては、パケットの内部データ（図６のデータ
６６）をチェックする事はない。従って上記処理に加
え、パケット数、衝突数、エラー数のカウント値を保存
することとによって、パケットを内部メモリに保存して
おく必要が無くなり、従来のＬＡＮアナライザには必須
であったパケットバッファを無くすことができる。
ヘッダ部を使って不良の切り分けを行っており、特定の
場合を除いては、パケットの内部データ（図６のデータ
６６）をチェックする事はない。従って上記処理に加
え、パケット数、衝突数、エラー数のカウント値を保存
することとによって、パケットを内部メモリに保存して
おく必要が無くなり、従来のＬＡＮアナライザには必須
であったパケットバッファを無くすことができる。
【００３９】前記遷移パラメータ等（プロトコルタイ
プ、SYN,ACK,FIN）をパケットから取り出す手順を説明
する。図６に示したパケット構成において、該当プロト
コルはパケットヘッダ（ETHERヘッダ）のプロトコルタ
イプ６３によって識別できる（このプロトコルタイプの
値が0800の場合にはTCP／IPを示す。）次に、TCPヘッダ
６５中の１２ビットのフラグ値によりその中のどのビッ
トが１になっているかによって遷移パラメータ（SYN,AC
K,FIN）を識別できる。
プ、SYN,ACK,FIN）をパケットから取り出す手順を説明
する。図６に示したパケット構成において、該当プロト
コルはパケットヘッダ（ETHERヘッダ）のプロトコルタ
イプ６３によって識別できる（このプロトコルタイプの
値が0800の場合にはTCP／IPを示す。）次に、TCPヘッダ
６５中の１２ビットのフラグ値によりその中のどのビッ
トが１になっているかによって遷移パラメータ（SYN,AC
K,FIN）を識別できる。
【００４０】具体的な例としてウィンドウサイズエラー
が発生した場合の過程を説明する。ＥＳＴＡＢ状態にお
いて、１つのパケットを受信すると送信先アドレスと送
信元アドレスの演算を行い、得られた結果に対しCRC演
算を実施しメモリ上のアドレス、すなわち状態記録テー
ブル１４の記録エリアを求める。次に、TCPヘッダ中の
フラグ値が”000000010000”となっており、遷移パラメ
ータACKであることを示しているとする。この場合、変
遷テーブル１５の追加ステータスの項５「再送チェッ
ク」に移行する。さらに、「再送チェック」を経て「ウ
ィンドウチェック」に移行する。このウインドウチェッ
クでは、ウインドウ値のチェックを行う。ここで、ウイ
ンドウサイズエラーが検出されたとする。そこで項８に
移行する。次いで項９、１１に順次、移行する。この例
では、ウインドウエラーが発生した旨表示し、次のパケ
ット受信に備える。
が発生した場合の過程を説明する。ＥＳＴＡＢ状態にお
いて、１つのパケットを受信すると送信先アドレスと送
信元アドレスの演算を行い、得られた結果に対しCRC演
算を実施しメモリ上のアドレス、すなわち状態記録テー
ブル１４の記録エリアを求める。次に、TCPヘッダ中の
フラグ値が”000000010000”となっており、遷移パラメ
ータACKであることを示しているとする。この場合、変
遷テーブル１５の追加ステータスの項５「再送チェッ
ク」に移行する。さらに、「再送チェック」を経て「ウ
ィンドウチェック」に移行する。このウインドウチェッ
クでは、ウインドウ値のチェックを行う。ここで、ウイ
ンドウサイズエラーが検出されたとする。そこで項８に
移行する。次いで項９、１１に順次、移行する。この例
では、ウインドウエラーが発生した旨表示し、次のパケ
ット受信に備える。
【００４１】図７に、異常検出処理の一例として、ウイ
ンドウチェック処理の具体例を示す。まず、ＴＣＰヘッ
ダ中のウィンドウ値（図６の６５６）を取得してこの値
Ｗが０か否かを調べる。０であれば、項８のウィンドウ
エラーへ移行し第２ビットにフラグをセットする。０で
なければ、この処理を終了する。
ンドウチェック処理の具体例を示す。まず、ＴＣＰヘッ
ダ中のウィンドウ値（図６の６５６）を取得してこの値
Ｗが０か否かを調べる。０であれば、項８のウィンドウ
エラーへ移行し第２ビットにフラグをセットする。０で
なければ、この処理を終了する。
【００４２】図９にエラー表示例を示す。２個の数字列
は、１組のＭＡＣアドレスを示し、両ＭＡＣアドレスの
端末間でのパケットの伝送において、ウインドウサイズ
エラーが発生したことを示している。
は、１組のＭＡＣアドレスを示し、両ＭＡＣアドレスの
端末間でのパケットの伝送において、ウインドウサイズ
エラーが発生したことを示している。
【００４３】
【発明の効果】本発明のＬＡＮアナライザによれば、採
取したパケットデータ群に基づいて人手によらず自動的
に解析を行うとともに、採取したパケットデータ群をリ
アルタイムに解析することができる。
取したパケットデータ群に基づいて人手によらず自動的
に解析を行うとともに、採取したパケットデータ群をリ
アルタイムに解析することができる。
【図１】本発明の実施例において、回線上のパケットに
関する情報がメモリー（状態記録テーブル）上に保存さ
れる過程を説明するための説明図である。
関する情報がメモリー（状態記録テーブル）上に保存さ
れる過程を説明するための説明図である。
【図２】実施例において、最小パケット間隔内で実行す
べき処理を時系列で表した図である。
べき処理を時系列で表した図である。
【図３】実施例において、プロトコル状態の変遷をテー
ブル化した変遷テーブルの説明図である。
ブル化した変遷テーブルの説明図である。
【図４】実施例のハードウェア構成図である。
【図５】実施例のソフトウェア構成図である。
【図６】実施例のパケット構成図である。
【図７】実施例における異常検出処理の一例のフローチ
ャートである。
ャートである。
【図８】実施例におけるアドレス変換テーブルの一例の
説明図である。
説明図である。
【図９】実施例におけるエラー表示例の説明図である。
１１…パケットヘッダ、１５…プロトコルステータス変
遷テーブル、４１…ＬＡＮアナライザ、４２…ＬＡＮボ
ード、４３…ＣＰＵ、４４…表示装置、４５…入力装
置、４６…メモリ、４７…ＣＲＣ演算回路。
遷テーブル、４１…ＬＡＮアナライザ、４２…ＬＡＮボ
ード、４３…ＣＰＵ、４４…表示装置、４５…入力装
置、４６…メモリ、４７…ＣＲＣ演算回路。
───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.6 識別記号 庁内整理番号 ＦＩ 技術表示箇所 Ｈ０４Ｌ 29/14
Claims (10)
- 【請求項１】ＬＡＮ上の通信プロトコル（ＴＣＰ／ＩＰ
やＳＰＸ／ＩＰＸ等）のパケットを採取してパケット授
受手順の正当性を検証するＬＡＮアナライザであって、 ＬＡＮに接続された第１の端末と第２の端末との間で授
受されるパケットを、該パケットヘッダに含まれる送信
元アドレスおよび送信先アドレスに基づいて認識し、当
該パケットヘッダに含まれるプロトコル状態遷移の契機
となる遷移パラメータに基づいて、両端末間のプロトコ
ル状態遷移を認識し、該認識されたプロトコル状態遷移
を当該通信プロトコルで決められている正常なプロトコ
ル状態遷移と比較することによって、両端末間のパケッ
ト授受手順の正当性を検証し、該検証結果を表示画面上
に表示するＬＡＮアナライザ。 - 【請求項２】請求項１に記載のＬＡＮアナライザにおい
て、前記パケット授受手順の正当性の検証をパケット採
取と並行してリアルタイムに実行することを特徴とする
ＬＡＮアナライザ。 - 【請求項３】請求項２に記載のＬＡＮアナライザにおい
て、前記通信プロトコルで決められているパケットの授
受手順を示した状態遷移図に対してエラー（予め決めて
おいた応答時間を超過したエラーも含む）を示す状態を
加味して作成したテーブルであって、現在のプロトコル
状態に対してどの遷移パラメータを受けたとき次にどの
プロトコル状態に移行するかを示す状態変遷テーブルを
有し、前記パケットヘッダに含まれる遷移パラメータに
基づいて該状態変遷テーブルを参照することによりプロ
トコル状態遷移をリアルタイムに認識することを特徴と
するＬＡＮアナライザ。 - 【請求項４】請求項３記載のＬＡＮアナライザにおい
て、各端末ペア間のプロトコル状態を保持するために端
末の全ての１対１の組み合わせに対するプロトコル状態
を格納する状態記録テーブルを有し、前記第１および第
２の端末間のパケットについて前記変遷テーブルの参照
により得られた状態を当該状態記録テーブルの対応する
エリアに格納し、該エリアに格納された内容に応じて前
記検証結果の表示を行うことを特徴とするＬＡＮアナラ
イザ。 - 【請求項５】請求項４に記載のＬＡＮアナライザにおい
て、送信元アドレスおよび送信先アドレスの組をより小
さいアドレス値に圧縮する圧縮手段を有し、該圧縮され
たアドレス値により前記状態記録テーブルを検索するこ
とを特徴とするＬＡＮアナライザ。 - 【請求項６】請求項５記載のＬＡＮアナライザにおい
て、前記送信元アドレスおよび送信先アドレスは、パケ
ットヘッダの先頭にあるユニークなＭＡＣアドレスであ
るＬＡＮアナライザ。 - 【請求項７】請求項５または６記載のＬＡＮアナライザ
において、前記圧縮手段は、ＣＲＣ演算を実行する手段
であることを特徴とするＬＡＮアナライザ。 - 【請求項８】請求項７記載のＬＡＮアナライザにおい
て、前記圧縮手段は、前記ＣＲＣ演算をハードウエアで
実行することを特徴とするＬＡＮアナライザ。 - 【請求項９】請求項５、６、７または８記載のＬＡＮア
ナライザにおいて、前記圧縮手段は、圧縮の前に前記送
信元アドレスおよび送信先アドレスに交換則が成り立つ
演算を施し、該演算の結果に対して圧縮処理をを施すこ
とを特徴とするＬＡＮアナライザ。 - 【請求項１０】請求項３記載のＬＡＮアナライザにおい
て、前記状態変遷テーブルを異なる通信プロトコル毎に
用意し、前記パケットヘッダに含まれるプロトコルタイ
プに応じて複数の状態変遷テーブルを選択して用いるこ
とを特徴とするＬＡＮアナライザ。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP7136847A JPH08331146A (ja) | 1995-06-02 | 1995-06-02 | Ｌａｎアナライザ |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP7136847A JPH08331146A (ja) | 1995-06-02 | 1995-06-02 | Ｌａｎアナライザ |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JPH08331146A true JPH08331146A (ja) | 1996-12-13 |
Family
ID=15184899
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP7136847A Pending JPH08331146A (ja) | 1995-06-02 | 1995-06-02 | Ｌａｎアナライザ |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JPH08331146A (ja) |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH1127308A (ja) * | 1997-07-01 | 1999-01-29 | Kokusai Denshin Denwa Co Ltd <Kdd> | インターネット対応リンクモニタ方法 |
| JP2000124952A (ja) * | 1998-10-15 | 2000-04-28 | Ntt Data Corp | 電子データの追跡方法及びシステム、記録媒体 |
| JP2003534721A (ja) * | 2000-05-24 | 2003-11-18 | イーシーテル・リミテツド | インターネット通信を監視する方法 |
| JP2006180002A (ja) * | 2004-12-21 | 2006-07-06 | Nec Corp | ネットワーク性能計測方法およびその装置 |
| JP2019159634A (ja) * | 2018-03-12 | 2019-09-19 | オムロン株式会社 | ＦＡ（Ｆａｃｔｏｒｙ Ａｕｔｏｍａｔｉｏｎ）システム、コントローラ、および制御方法 |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH04117843A (ja) * | 1990-09-07 | 1992-04-17 | Nippon Telegr & Teleph Corp <Ntt> | プロトコル故障検出装置 |
| JPH05500291A (ja) * | 1989-05-19 | 1993-01-21 | コンコード コミュニケーションズ インコーポレイテッド | 受動回路網モニタ |
-
1995
- 1995-06-02 JP JP7136847A patent/JPH08331146A/ja active Pending
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH05500291A (ja) * | 1989-05-19 | 1993-01-21 | コンコード コミュニケーションズ インコーポレイテッド | 受動回路網モニタ |
| JPH04117843A (ja) * | 1990-09-07 | 1992-04-17 | Nippon Telegr & Teleph Corp <Ntt> | プロトコル故障検出装置 |
Cited By (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH1127308A (ja) * | 1997-07-01 | 1999-01-29 | Kokusai Denshin Denwa Co Ltd <Kdd> | インターネット対応リンクモニタ方法 |
| JP2000124952A (ja) * | 1998-10-15 | 2000-04-28 | Ntt Data Corp | 電子データの追跡方法及びシステム、記録媒体 |
| JP2003534721A (ja) * | 2000-05-24 | 2003-11-18 | イーシーテル・リミテツド | インターネット通信を監視する方法 |
| JP4708662B2 (ja) * | 2000-05-24 | 2011-06-22 | ベリント・システムズ・リミテツド | インターネット通信を監視する方法 |
| JP2006180002A (ja) * | 2004-12-21 | 2006-07-06 | Nec Corp | ネットワーク性能計測方法およびその装置 |
| JP2019159634A (ja) * | 2018-03-12 | 2019-09-19 | オムロン株式会社 | ＦＡ（Ｆａｃｔｏｒｙ Ａｕｔｏｍａｔｉｏｎ）システム、コントローラ、および制御方法 |
| WO2019176337A1 (ja) * | 2018-03-12 | 2019-09-19 | オムロン株式会社 | ＦＡ（Ｆａｃｔｏｒｙ Ａｕｔｏｍａｔｉｏｎ）システム、コントローラ、および制御方法 |
| CN111065976A (zh) * | 2018-03-12 | 2020-04-24 | 欧姆龙株式会社 | 工厂自动化系统、控制器和控制方法 |
| US11215974B2 (en) | 2018-03-12 | 2022-01-04 | Omron Corporation | Factory automation (FA) system, controller, and control method |
| CN111065976B (zh) * | 2018-03-12 | 2024-02-20 | 欧姆龙株式会社 | 工厂自动化系统、控制器和控制方法 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8085673B2 (en) | Method and apparatus for generating bi-directional network traffic and collecting statistics on same | |
| JP3329842B2 (ja) | ネットワークモニタ装置及びシステム | |
| US5097469A (en) | Passive monitor for broadcast communication network | |
| US7010592B2 (en) | Method for collecting statistical traffic data | |
| JP2002515152A (ja) | 自動化されたネットワークワイドのサーベイランスおよびセキュリティ違反介入のための方法および装置 | |
| US9203728B2 (en) | Metadata capture for testing TCP connections | |
| US10333803B2 (en) | Relay apparatus and relay method | |
| JPH08331146A (ja) | Ｌａｎアナライザ | |
| CN106161143A (zh) | 一种基于arm服务器的网络性能测试方法及装置 | |
| CN109005081A (zh) | 一种丢包自动检测系统及方法 | |
| CN110838949A (zh) | 一种网络流量日志记录方法及装置 | |
| WO2022270767A1 (ko) | 지능형 네트워크 관리 시스템의 정보묶음 생성관리 장치 및 그 방법 | |
| CN114172796B (zh) | 通信网络的故障定位方法及相关装置 | |
| KR20020035210A (ko) | 이동통신망용 무선데이타 성능분석 시스템 | |
| CN103458431A (zh) | 多点采集及跨层的回放系统 | |
| US20050286432A1 (en) | Packet discard point probing method and device | |
| EP0425655B1 (en) | Passive network monitor and corresponding method of monitoring | |
| US20140359106A1 (en) | Network analysis device, management system, network analysis method and program | |
| CN104468190A (zh) | 一种wifi数据抓包方法、装置及智能终端 | |
| CN113923272A (zh) | 数据解析方法、装置和服务器设备 | |
| CN113542044A (zh) | 网络质量监测方法、装置及计算设备 | |
| CN114710424B (zh) | 基于软件定义网络的主机侧数据包处理延时测量方法 | |
| CN105141476A (zh) | 一种tcp报文出错信息的获取方法和装置 | |
| CN117201292B (zh) | 能准确定位微服务间请求调用异常的方法 | |
| CN115720201A (zh) | 透传设备数据传输稳定性的测试方法、终端设备以及介质 |