JP2015226074A - トラヒック再現システム - Google Patents
トラヒック再現システム Download PDFInfo
- Publication number
- JP2015226074A JP2015226074A JP2014107770A JP2014107770A JP2015226074A JP 2015226074 A JP2015226074 A JP 2015226074A JP 2014107770 A JP2014107770 A JP 2014107770A JP 2014107770 A JP2014107770 A JP 2014107770A JP 2015226074 A JP2015226074 A JP 2015226074A
- Authority
- JP
- Japan
- Prior art keywords
- log
- traffic
- packet
- structured
- structuring
- 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
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
【課題】商用環境で発生した実トラヒックを検証環境で忠実に再現することができるトラヒック再現システムを提供する。【解決手段】トラヒック再現システムは、トラヒックログをログ構造化ルールに従い構造化することにより、標準化されたフォーマットの構造化ログを生成するログサーバ30と、構造化ログを用いてトラヒックを再生するトラヒック再生装置40とを備える。具体的には、ログサーバ30は、トラヒックログに含まれる全ての時間情報とパケット詳細情報を抽出して構造化ログを生成し、トラヒック再生装置40は、パケット詳細情報に基づいてパケットデータを生成し、生成したパケットデータを時間情報に基づいて送信する。【選択図】図2
Description
本発明は、トラヒックを再現するトラヒック再現システムに関する。
通信事業者にとって、高品質なIPネットワークを提供することは重要である。そこで、IPネットワークの検証のため、商用環境で発生したトラヒックを再現して検証環境に負荷することが知られている(特許文献1〜3参照)。
このような負荷試験では、次の2つの手法が用いられる。1つは、パケットキャプチャのバイナリファイルを用いるパケットキャプチャ手法である。もう1つは、Avalancheやqueryperf等、トラヒックのシナリオを作成して擬似的なトラヒックを生成するシナリオ作成手法である。シナリオとは、負荷試験機に読み込ませるファイルである。シナリオには、特定プロトコルにおいて最低限必要なペイロード情報を記述する。1行に1パケット分の情報を記述するのが通常である。
しかし、パケットキャプチャ手法では、実際のトラヒックを再現することは可能であるが、キャプチャの実施がアプリケーションの性能を大きく劣化させることが多い。そのため、この手法は、トラヒック解析のために一時的に取得することはまれにあるものの、通常の運用で用いられることはほとんど無い。
一方、シナリオ作成手法では、通常運用で取得しているログから発生したトラヒックの一部の情報を用いて再帰的にトラヒックを再現する。すなわち、限られた情報を繰り返し用いてトラヒックを再現するため、実際のトラヒックを忠実に再現することは不可能である。
本発明は、上述した従来の技術に鑑み、商用環境で発生した実トラヒックを検証環境で忠実に再現することができるトラヒック再現システムを提供することを目的とする。
上記目的を達成するため、第1の態様に係る発明は、トラヒックを再現するトラヒック再現システムであって、トラヒックログをログ構造化ルールに従い構造化することにより、標準化されたフォーマットの構造化ログを生成するログサーバと、前記構造化ログを用いてトラヒックを再生するトラヒック再生装置とを備えることを要旨とする。
第2の態様に係る発明は、第1の態様に係る発明において、前記ログサーバが、前記トラヒックログに含まれる全ての時間情報とパケット詳細情報を抽出して前記構造化ログを生成し、前記トラヒック再生装置が、前記パケット詳細情報に基づいてパケットデータを生成し、生成したパケットデータを前記時間情報に基づいて送信することを要旨とする。
本発明によれば、商用環境で発生した実トラヒックを検証環境で忠実に再現することができるトラヒック再現システムを提供することが可能である。
以下、本発明の実施の形態について図面を参照して詳細に説明する。なお、以下の実施の形態は、この発明の技術的思想を具体化するためのトラヒック再現システムを例示するものであり、装置の構成やデータの構成等は以下の実施の形態に限定されるものではない。
(構成例)
図1は、本発明の実施の形態におけるトラヒック再現システムの構成図である。このトラヒック再現システムは、装置ログを用いることにより、装置に発生したトラヒックを忠実に再現するシステムである。具体的には、図1に示すように、通信網(IPネットワーク)10にサーバ20A,20B,20C,…が接続され、サーバ20A,20B,20C,…にログサーバ30が接続され、ログサーバ30にトラヒック再生装置40が接続されている。
図1は、本発明の実施の形態におけるトラヒック再現システムの構成図である。このトラヒック再現システムは、装置ログを用いることにより、装置に発生したトラヒックを忠実に再現するシステムである。具体的には、図1に示すように、通信網(IPネットワーク)10にサーバ20A,20B,20C,…が接続され、サーバ20A,20B,20C,…にログサーバ30が接続され、ログサーバ30にトラヒック再生装置40が接続されている。
サーバ20A,20B,20C,…は、通信網10を介してクライアントと通信し、そのトラヒックログ(生ログ)を生成する。以下の説明では、サーバ20A,20B,20C,…を一括して「サーバ20」という場合がある。
ログサーバ30は、ログ構造化機構を実装するログ収集サーバ等である。具体的には、生ログをログ構造化ルールに従い構造化することにより、標準化されたフォーマットの構造化ログを生成する。標準化されたフォーマットとは、例えば、JSON(JavaScript (登録商標)Object Notation)フォーマットである。JSONは、様々なソフトウェアやプログラミング言語間におけるデータの受け渡しに使えるよう設計されている。
トラヒック再生装置40は、構造化ログを読み込み、その構造化ログを用いてトラヒックを再生し、検証対象の装置にトラヒックを負荷する負荷試験機等である。通常、生ログはサーバ20固有の形式であるため、トラヒック再生装置40に読み込ませることができない。本発明の実施の形態では、仕様化されたログ構造化機構を用いるようにしているため、JSONフォーマット等の構造化ログをトラヒック再生装置40に読み込ませることが可能である。
図2は、本発明の実施の形態におけるトラヒック再現システムの機能ブロック図である。以下、図2を用いて、ログサーバ30及びトラヒック再生装置40の構成を詳細に説明する。
ログサーバ30は、ログ構造化ルール記憶部31と、ログ構造化部32とを備える。ログ構造化ルール記憶部31は、ログ構造化ルールをあらかじめ記憶する記憶装置である。ログ構造化ルールは、生ログを構造化する際のルールを定めたファイルである。ログ構造化部32は、サーバ20から収集した生ログをログ構造化ルールに基づいて構造化し、このように構造化した構造化ログをトラヒック再生装置40に送信する。
トラヒック再生装置40は、構造化ログを解析するログ解析部41と、ログ解析部41の解析結果に基づいてトラヒックを再生するトラヒック再生部42とを備える。この図に示すように、ログ解析部41には、構造化ログ読み込み部43と、プロトコルデータ記憶部44と、プロトコル解析部45とが含まれる。構造化ログ読み込み部43は、ログサーバ30からの構造化ログを読み込み、プロトコル解析部45に渡す。プロトコルデータ記憶部44は、プロトコルデータをあらかじめ記憶する記憶装置である。プロトコル解析部45は、プロトコルデータ記憶部44に記憶されているプロトコルデータに基づいてプロトコルを解析する。一方、トラヒック再生部42には、時系列情報生成部46と、プロトコルデータ読み込み部47と、パケットデータ生成部48とが含まれる。時系列情報生成部46は、構造化ログに基づいて時系列情報を生成する。例えば、1パケット分のデータ(時間情報)を読み込み、その時間情報を送信時間として保存する。プロトコルデータ読み込み部47は、プロトコル解析部45の解析結果に基づいてプロトコルデータを読み込む。パケットデータ生成部48は、構造化ログやプロトコルデータを用いてパケットデータを生成し、保存した送信時間に送信するパケットデータを全て送信する。全てのパケットデータを送信するまで同様の動作を繰り返す。これにより、検証装置50にトラヒックが負荷される。
(動作例)
図3は、本発明の実施の形態におけるトラヒック再現システムのシーケンス図である。まず、通信網10からサーバ20にトラヒックが発生すると、サーバ20において生ログが生成される(S1→S2)。次いで、サーバ20からログサーバ30に生ログが転送されると、ログサーバ30においてログ構造化ルールが読み込まれ、ログ構造化が行われる(S3→S4→S5)。次いで、ログサーバ30からトラヒック再生装置40に構造化ログが転送されると、トラヒック再生装置40において構造化ログが読み込まれ、時系列情報が生成され、プロトコルデータが読み込まれ、パケットデータが生成される(S6→S7→S8→S9→S10)。最後に、トラヒック再生装置40から検証網51にパケットデータが送信され、トラヒックが再生される(S11)。
図3は、本発明の実施の形態におけるトラヒック再現システムのシーケンス図である。まず、通信網10からサーバ20にトラヒックが発生すると、サーバ20において生ログが生成される(S1→S2)。次いで、サーバ20からログサーバ30に生ログが転送されると、ログサーバ30においてログ構造化ルールが読み込まれ、ログ構造化が行われる(S3→S4→S5)。次いで、ログサーバ30からトラヒック再生装置40に構造化ログが転送されると、トラヒック再生装置40において構造化ログが読み込まれ、時系列情報が生成され、プロトコルデータが読み込まれ、パケットデータが生成される(S6→S7→S8→S9→S10)。最後に、トラヒック再生装置40から検証網51にパケットデータが送信され、トラヒックが再生される(S11)。
図4は、本発明の実施の形態におけるトラヒック再現システムのフローチャートである。まず、ログサーバ30において生ログが読み込まれ、ログ構造化ルールが読み込まれ、ログ構造化が行われる(S21→S22→S23)。次いで、トラヒック再生装置40において構造化ログが読み込まれ、1パケット分のデータ(時間情報)が読み込まれ、その時間情報が送信時間として保存される(S24→S25→S26)。次いで、プロトコルデータが読み込まれ、パケットデータが生成され、保存された送信時間に示されるタイミングでパケットが送信される(S27→S28→S29)。ここで、未送信パケットがない場合(S30:NO)は終了し、未送信パケットがある場合(S30:YES)は次のパケットが同時間内に送信するパケットかどうか判定される(S31)。そして、次のパケットが同時間内に送信するパケットでない場合(S31:NO)はステップS25に戻り、次のパケットが同時間内に送信するパケットである場合(S31:YES)はステップS27に戻る。
(ログ構造化の具体例)
図5は、本発明の実施の形態におけるログ構造化の具体例を示す図であり、図5(a)は生ログ1、図5(b)はログ構造化ルール2、図5(c)は構造化ログ3を示している。図5(a)に示すように、生ログ1では、各サーバ20のログフォーマットに従い、スペースやコンマ等により数値が並べられている。ここでは、1行に1パケット分のデータが記述されている場合を例示している。また、図5(b)に示すように、ログ構造化ルール2では、正規表現を用いて生ログ1から構造化ログ3を生成する際のルールを表現している。更に、図5(c)に示すように、構造化ログ3では、ログ構造化ルール2に従い、ログ中の各値の意味をJSONフォーマットで表現している。ここでは、time,client_ip,client_port,TYPE等の属性名を例示しているが、これらの属性名は一例であることは言うまでもない。これにより、トラヒック再生装置40側でソフトウェアによって各サーバ20のトラヒックログを解釈することが可能となる。
図5は、本発明の実施の形態におけるログ構造化の具体例を示す図であり、図5(a)は生ログ1、図5(b)はログ構造化ルール2、図5(c)は構造化ログ3を示している。図5(a)に示すように、生ログ1では、各サーバ20のログフォーマットに従い、スペースやコンマ等により数値が並べられている。ここでは、1行に1パケット分のデータが記述されている場合を例示している。また、図5(b)に示すように、ログ構造化ルール2では、正規表現を用いて生ログ1から構造化ログ3を生成する際のルールを表現している。更に、図5(c)に示すように、構造化ログ3では、ログ構造化ルール2に従い、ログ中の各値の意味をJSONフォーマットで表現している。ここでは、time,client_ip,client_port,TYPE等の属性名を例示しているが、これらの属性名は一例であることは言うまでもない。これにより、トラヒック再生装置40側でソフトウェアによって各サーバ20のトラヒックログを解釈することが可能となる。
(トラヒック再生の具体例)
図6は、本発明の実施の形態におけるトラヒック再生の具体例を示す図である。この図に示すように、トラヒック再生装置40は、構造化ログ3とDNSデータを読み込み、これらに基づいて時系列情報4とパケットデータ1,2,3,…を生成する。
図6は、本発明の実施の形態におけるトラヒック再生の具体例を示す図である。この図に示すように、トラヒック再生装置40は、構造化ログ3とDNSデータを読み込み、これらに基づいて時系列情報4とパケットデータ1,2,3,…を生成する。
以下、パケットデータ1の生成方法について説明する。図6に示すように、パケットデータ1は、IP,UDP,DNSのプロトコル別に構成されている。「IP」プロトコルの「Version」フィールドには、構造化ログ3のclient_ipに基づいて「4(IPv4)」が格納される。「IP」プロトコルの「送信元IP」フィールドには、構造化ログ3のclient_ipに基づいて「66.128.50.67」が格納される。「UDP」プロトコルの「送信元ポート」フィールドには、構造化ログ3のclient_portに基づいて「62828」が格納される。「DNS」プロトコルの「QNAME」フィールドには、構造化ログ3のdomainに基づいて「www.ex.info」が格納される。「DNS」プロトコルの「QTYPE」フィールドには、構造化ログ3のTYPEに基づいて「A」が格納される。なお、その他のフィールドには、自動で読み込まれたプロトコルデータ(図3のS9参照)や、本システムのツール使用時にユーザが指定したデータが格納される。
図7は、忠実なトラヒック再生を説明するための図である。トラヒックを忠実に再現するためには、(1)発生した時系列に従ってトラヒックを生成すること、(2)機械的に同じパケットを送信するのではなく、発生した多様なパケットを再現すること、の2つの条件が必要である。本発明の実施の形態によれば、図7に示すように、「08:51:39」や「08:51:40」等の時系列情報f1に従ってトラヒックを生成することができ、また、パケットデータ1〜6等の多様なパケットf2を再現することができる。そのため、商用環境で発生した実トラヒックを検証環境で忠実に再現することが可能である。
(負荷試験の具体例)
図8は、本発明の実施の形態における負荷試験の具体例を説明するための図である。この図に示すように、商用環境には、クライアント61と、サーバ20A,20Bと、ログ基盤62とが含まれる。また、検証環境には、ログ基盤63と、負荷試験機64と、サーバ20A,20Bとが含まれる。ログ基盤62及び63はログサーバ30に相当し、負荷試験機64はトラヒック再生装置40に相当する。
図8は、本発明の実施の形態における負荷試験の具体例を説明するための図である。この図に示すように、商用環境には、クライアント61と、サーバ20A,20Bと、ログ基盤62とが含まれる。また、検証環境には、ログ基盤63と、負荷試験機64と、サーバ20A,20Bとが含まれる。ログ基盤62及び63はログサーバ30に相当し、負荷試験機64はトラヒック再生装置40に相当する。
具体的には、ログ基盤62は、クライアント61とサーバ20A,20B間の商用ログを汎用的な形式に構造化してログ基盤63に転送する。ログ基盤63は、ログ基盤62からの構造化ログを負荷試験機64に読み込ませる。負荷試験機64は、構造化ログに基づいてサーバ20A,20Bにトラヒックを負荷する。これにより、トラブル発生時等において、商用環境で発生した実トラヒックを検証環境で忠実に再現することが可能である。
(従来技術と本実施の形態との比較)
図9は、従来技術と本実施の形態とを比較した図である。ここでは、従来技術としてシナリオ作成手法を例示している。図9(a)に示すように、サーバ20Aがクライアント61A,61Bから収集した生ログには、時間情報とパケット詳細情報が含まれる。パケット詳細情報とは、送信元IPアドレスやポート番号等である。従来技術によれば、シナリオ101に記述する際に時間情報とパケット詳細情報が削ぎ落とされる。すなわち、シナリオ101は、パケットのペイロード部に関する情報を一部記述するものであり、それらを基に負荷試験機102が同じトラヒックを送信し続ける。このように、従来は、記述したパケットを性能の限り送信し続ける動作しか行わないため、時間情報とパケット詳細情報は再現することができない。そこで、本実施の形態では、時間情報とパケット詳細情報が含まれる構造化ログを用いて、時系列に従ってトラヒックを詳細に再現するようになっている。
図9は、従来技術と本実施の形態とを比較した図である。ここでは、従来技術としてシナリオ作成手法を例示している。図9(a)に示すように、サーバ20Aがクライアント61A,61Bから収集した生ログには、時間情報とパケット詳細情報が含まれる。パケット詳細情報とは、送信元IPアドレスやポート番号等である。従来技術によれば、シナリオ101に記述する際に時間情報とパケット詳細情報が削ぎ落とされる。すなわち、シナリオ101は、パケットのペイロード部に関する情報を一部記述するものであり、それらを基に負荷試験機102が同じトラヒックを送信し続ける。このように、従来は、記述したパケットを性能の限り送信し続ける動作しか行わないため、時間情報とパケット詳細情報は再現することができない。そこで、本実施の形態では、時間情報とパケット詳細情報が含まれる構造化ログを用いて、時系列に従ってトラヒックを詳細に再現するようになっている。
従来技術と本実施の形態との比較結果をまとめると、図9(b)のようになる。すなわち、従来技術によれば、(1)時系列情報がないため、発生トラヒックに関係なく送信し続ける他ない、(2)送信元IPアドレスやポート番号等、全ての詳細なデータの記述は難しい、(3)特定プロトコルの生成にしか対応できない等の問題がある。それに対して、本実施の形態によれば、(1)トラヒックログから全てのクエリの時系列情報を抽出し、トラヒックデータを生成するため、忠実な時系列で再現が可能である。また、(2)トラヒックログを用いるため、送信元IPアドレスやポート番号等、全ての詳細なデータの記述が可能である。更に、(3)標準化された構造化手法を用いるため、様々なプロトコルに対応可能である。
以上のように、本発明の実施の形態におけるトラヒック再現システムは、トラヒックを再現するシステムであって、トラヒックログをログ構造化ルールに従い構造化することにより、標準化されたフォーマットの構造化ログを生成するログサーバ30と、構造化ログを用いてトラヒックを再生するトラヒック再生装置40とを備える。これにより、商用環境で発生した実トラヒックを検証環境で忠実に再現することができるため、商用同様のトラヒックを用いた検証が可能になり、検証の品質を大きく向上させることが可能になる。また、JSONフォーマット等の標準化仕様フォーマットを利用しているため、様々なプロトコルの再現が可能であり、拡張性に優れているという効果もある。
具体的には、ログサーバ30は、トラヒックログに含まれる全ての時間情報とパケット詳細情報を抽出して構造化ログを生成し、トラヒック再生装置40は、パケット詳細情報に基づいてパケットデータを生成し、生成したパケットデータを時間情報に基づいて送信する。これにより、時系列情報、送信元IPアドレス、ポート番号等、商用環境で発生した全ての実トラヒックを低コストで保存し、全てのパケットを忠実に再現することができる。
なお、サーバ20A,20B,20C,…によって生ログのフォーマットが異なる場合は、それぞれの生ログに対応する複数のログ構造化ルールをログ構造化ルール記憶部31に記憶しておく。これにより、それぞれの生ログに対応する複数のログ構造化ルールを用いて同一フォーマットの構造化ログを生成することが可能である。
また、本発明は、トラヒック再現システムとして実現することができるだけでなく、このトラヒック再現システムに用いられるログサーバ30又はトラヒック再生装置40として実現することもできる。もちろん、ログサーバ30又はトラヒック再生装置40が備える特徴的な処理部をステップとするトラヒック再現方法として実現したり、それらのステップをコンピュータに実行させるトラヒック再現プログラムとして実現したりすることも可能である。このようなプログラムは、CD−ROM等の記録媒体やインターネット等の伝送媒体を介して配信することができるのはいうまでもない。
1…トラヒックログ(生ログ)
2…ログ構造化ルール
3…構造化ログ
30…ログサーバ
31…ログ構造化ルール記憶部
32…ログ構造化部
40…トラヒック再生装置
41…ログ解析部
42…トラヒック再生部
43…構造化ログ読み込み部
44…プロトコルデータ記憶部
45…プロトコル解析部
46…時系列情報生成部
47…プロトコルデータ読み込み部
48…パケットデータ生成部
2…ログ構造化ルール
3…構造化ログ
30…ログサーバ
31…ログ構造化ルール記憶部
32…ログ構造化部
40…トラヒック再生装置
41…ログ解析部
42…トラヒック再生部
43…構造化ログ読み込み部
44…プロトコルデータ記憶部
45…プロトコル解析部
46…時系列情報生成部
47…プロトコルデータ読み込み部
48…パケットデータ生成部
Claims (2)
- トラヒックを再現するトラヒック再現システムであって、
トラヒックログをログ構造化ルールに従い構造化することにより、標準化されたフォーマットの構造化ログを生成するログサーバと、
前記構造化ログを用いてトラヒックを再生するトラヒック再生装置と
を備えることを特徴とするトラヒック再現システム。 - 前記ログサーバは、前記トラヒックログに含まれる全ての時間情報とパケット詳細情報を抽出して前記構造化ログを生成し、
前記トラヒック再生装置は、前記パケット詳細情報に基づいてパケットデータを生成し、生成したパケットデータを前記時間情報に基づいて送信する
ことを特徴とする請求項1に記載のトラヒック再現システム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2014107770A JP2015226074A (ja) | 2014-05-26 | 2014-05-26 | トラヒック再現システム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2014107770A JP2015226074A (ja) | 2014-05-26 | 2014-05-26 | トラヒック再現システム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2015226074A true JP2015226074A (ja) | 2015-12-14 |
Family
ID=54842592
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2014107770A Pending JP2015226074A (ja) | 2014-05-26 | 2014-05-26 | トラヒック再現システム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2015226074A (ja) |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2003283564A (ja) * | 2002-03-27 | 2003-10-03 | Ntt Comware Corp | Ipトラヒック発生装置ならびにその方法、およびトラヒック発生プログラムおよび記録媒体 |
JP2007208740A (ja) * | 2006-02-02 | 2007-08-16 | Fujitsu Ltd | パケット記録再生装置 |
JP2013171541A (ja) * | 2012-02-22 | 2013-09-02 | Nippon Telegr & Teleph Corp <Ntt> | 可視化装置、可視化方法及び可視化プログラム |
-
2014
- 2014-05-26 JP JP2014107770A patent/JP2015226074A/ja active Pending
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2003283564A (ja) * | 2002-03-27 | 2003-10-03 | Ntt Comware Corp | Ipトラヒック発生装置ならびにその方法、およびトラヒック発生プログラムおよび記録媒体 |
JP2007208740A (ja) * | 2006-02-02 | 2007-08-16 | Fujitsu Ltd | パケット記録再生装置 |
JP2013171541A (ja) * | 2012-02-22 | 2013-09-02 | Nippon Telegr & Teleph Corp <Ntt> | 可視化装置、可視化方法及び可視化プログラム |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN103139326B (zh) | Ip溯源方法、设备和系统 | |
US20180152468A1 (en) | Processing network data using a graph data structure | |
US9473369B2 (en) | Application topology based on network traffic | |
CN104219330A (zh) | 一种基于web代理进行录屏审计的方法及系统 | |
Kim et al. | ONTAS: Flexible and scalable online network traffic anonymization system | |
CN107534690A (zh) | 采集域名系统流量 | |
US10678676B2 (en) | Playback of captured network transactions in a simulation environment | |
WO2017161965A1 (zh) | 一种动态域名系统dns重定向方法、装置及系统 | |
CN110324437A (zh) | 一种原始地址传输方法、系统、存储介质和处理器 | |
US10298653B1 (en) | Methods for monitoring streaming video content quality of experience (QOE) and devices thereof | |
CN111049947B (zh) | 报文转发方法及装置、电子设备、存储介质 | |
CN111698110B (zh) | 一种网络设备性能分析方法、系统、设备及计算机介质 | |
Gont et al. | Observations on the dropping of packets with IPv6 extension headers in the real world | |
Khan et al. | Network forensics investigation: Behaviour analysis of distinct operating systems to detect and identify the host in IPv6 network | |
JP6762911B2 (ja) | パケット識別装置およびパケット識別方法 | |
CN106878308B (zh) | 一种icmp报文匹配系统及方法 | |
US20150180942A1 (en) | Message-oriented middleware | |
Butler | NGINX Cookbook | |
JP2015226074A (ja) | トラヒック再現システム | |
JP2007165990A (ja) | Ipアドレス変換方法及び情報処理装置 | |
Oudah et al. | Using burstiness for network applications classification | |
JP6605149B2 (ja) | 共有端末の検出方法及びその装置 | |
CN116939035A (zh) | 数据处理方法、装置、电子设备以及存储介质 | |
Jaswal | Hands-On Network Forensics: Investigate network attacks and find evidence using common network forensic tools | |
JP3896361B2 (ja) | 通信経路設定装置、通信経路設定方法および通信経路設定プログラム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20150929 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20160209 |