【文献】
熊野 由一,暗号化トラヒックに対するアプリケーション識別のオンライン化に向けた検討,電子情報通信学会技術研究報告,日本,一般社団法人電子情報通信学会,2013年 9月
【文献】
岡田 洋平,暗号化によるフロー特性変化にもとづく暗号化トラヒックに対応したアプリケーション識別法,電子情報通信学会技術研究報告,日本,社団法人電子情報通信学会,2010年 9月
(58)【調査した分野】(Int.Cl.,DB名)
上記所定タイミング特徴量値予測手段は、上記特徴量値保持手段が保持している特徴量値の最新の値が、所定のパケット数より多いパケットが到来して得た特徴量値になっている場合に、その特徴量値を、上記アプリケーション種類推定手段が用いるようにすることを特徴とする請求項1〜3のいずれかに記載のトラヒック監視装置。
【背景技術】
【0002】
ネットワークが加入者によってどのように利用されているか、各フローでどのような通信が行われているかを把握することは、ネットワークオペレータが設備投資の判断、フローの制御、異常監視を行う上で有用である。
【0003】
しかしながら、今日の通信では、暗号化されたトラヒック(ここで、トラヒックとは通信回線を通じて送受信される情報を呼んでおり、以下、暗号化されたトラヒックを暗号トラヒックと呼ぶこととする)が増え、暗号文の中でどのような通信を行っているかの把握が困難になりつつある。また、プライバシ保護の観点から、ペイロードの内容を観測せずに、パケット長や到着間隔等の統計情報で、内容を推定したいという要求が存在する。
【0004】
このような背景下で、特許文献1に記載の暗号化通信特徴抽出装置が提案されている。
【0005】
この暗号化通信特徴抽出装置では、事前に、既知の暗号化方法で暗号化した暗号文を、この装置の外部通信部より発信し、この試験通信暗号データを暗号文データ収集部で収集して特徴を求めておく。次に、暗号判定機能部では、トラヒックの種別が不明な通信情報に対して、特徴情報を求め、求めた種別の不明な通信情報の特徴情報と、先に求めた既知の暗号文の特徴情報とを比較する。この比較結果が一致した場合、この種別不明なトラヒックを、どの種類の暗号化方法で暗号化された文章のトラフィックであると推定する。
【0006】
この特許文献1の記載方法を用いれば、暗号化通信の種別として、使用される通信アプリケーション、暗号通信ソフト、及び暗号化プロトコルの組合せを示すことができる。使用可能な暗号化プロトコルとしては、WEBサービスの場合であればHTTPS(Hypertext Transfer Protocol over Secure Socket Layer)を挙げることができ、VPN(Virtual Private Network)の場合であれば、DES(Data Encryption Standard)、3DES、AES(Advanced Encryption Standard)等を挙げることができる。
【0007】
また、適用できる特徴情報としては、(1)通信セッションの発生間隔、(2)通信セッション中のパケット発生間隔、(3)通信セッション中のパケットサイズ、(4)通信セッション中の総パケット数、(5)通信セッション中のパケット送受信方向の関係、(6)通信セッション中のパケット送受信数方向比、(7)通信セッション中のプロトコル占有率、(8)通信セッション開始時の各パケットサイズ、(9)通信セッション開始時の総パケット数、(10)通信セッション開始時の総データサイズ、(11)長期間の送信元/宛先IP分布、(12)長期間の宛先ポート分布、(13)長期間のDNS(Domain Name System)サーバへの問合せの有無、(14)通信アプリケーション側から何も通信していない時に送信されるデータの有無が挙げられる。
【発明を実施するための形態】
【0017】
(A)主たる実施形態
以下、本発明によるトラヒック監視装置及びプログラム、並びに、通信装置の一実施形態を、図面を参照しながら説明する。実施形態に係るトラヒック監視装置は、主として、暗号トラヒックを監視するものである。
【0018】
(A−1)実施形態の構成
図1は、実施形態に係るトラヒック監視装置1と、ネットワークとの関係を示す説明図である。実施形態に係るトラヒック監視装置1は、データパケット(以下、IPパケットとする)を転送する通信装置に関連して設けられる。例えば、ネットワークNA〜NZ間の境界に位置するゲートウェイ装置に、実施形態のトラヒック監視装置1が搭載される通信装置である。
【0019】
図2は、実施形態のトラヒック監視装置1の機能的な構成を示すブロック図である。ここで、実施形態のトラヒック監視装置1は、ハードウェア的に各種回路を接続して構築されたものであっても良く、また、CPU、ROM、RAMなどを用いてトラヒック監視プログラムを実行することで該当するトラヒック監視機能を実現するように構築されたものであっても良く(この場合であっても、後述する通信入力部10や通信出力部13の一部はハードウェアで構成することを要する)、いずれの構築方法が適用された場合であっても、機能的には、
図2で表すことができる。
【0020】
図2において、実施形態のトラヒック監視装置1は、通信入力部10、推定対象フロー抽出部11、通信制御部12、通信出力部13、特徴量保持部14、特徴量収束予測部15、アプリケーション推定部16及びフロー制御変更指令部17を有する。
【0021】
通信入力部10は、ネットワークに接続されていて、トラヒックが入力され、入力されたトラヒックを推定対象フロー抽出部11に渡すものである。
【0022】
推定対象フロー抽出部11は、暗号化フローと非暗号化フローを選別し、各暗号化フローに関する特徴量(パラメタ)を計測し、暗号化フローに関するフローの特定情報と特徴量を特徴量保持部14に与え、特徴量が計測された暗号化フローの情報を通信制御部12に与えるものである。
【0023】
ここで、暗号化フローとは、そのフローのデータパケットにおけるヘッダ及びペイロード(あるいはその一部)が暗号化されているフローを呼び、非暗号化フローとは、そのフローのデータパケットが暗号化されていないフローを呼ぶこととする。さらに、ここで暗号化とは、必ずしも良く知られた暗号を用いた符号化処理でなくても良く、一般的な通信で利用されるヘッダとペイロードを含んだパケットの難読化処理、あるいは独自符号化のような処理を加えることによって本来の通信内容がわからないように加工された処理のことも含むものとする。
【0024】
トラフィック監視装置1は、非暗号化フローのトラヒックをも監視するものであるが、非暗号化フローのトラヒックの監視機能は、従来装置と同様であるので、以下では、暗号化フローのトラフィックについての機能を説明する。
【0025】
推定対象フロー抽出部11は、新たな暗号化フローを認識した場合には、フローの識別情報(ID;数字列に限定されない)の採番を行い、フローの両端ノードのIPアドレスとフローIDをフローの特定情報とし、所定情報を特徴量保持部14及び通信制御部12に与える。
【0026】
なお、推定対象フロー抽出部11が、非暗号化フローの特徴量を計測して特徴量保持部14に与え、後述する暗号化フローに対する処理を、非暗号化フローに対して行うようにしても良いことは勿論である。
【0027】
特徴量保持部14は、暗号化フローのそれぞれに対して、フローの特定情報に対応付けて特徴量を管理するものである。
図3は、特徴量保持部14が保持しているデータの構成を示す説明図である。特徴量保持部14は、例えば、フローIDに対応付けて、フローの一方のノードのIPアドレス、他方のノードのIPアドレス、フロー開始時刻、フロー開始からのパケット数、複数種類のパラメタのフロー開始からの値を管理する(パラメタ値に関してはその代表値をも管理するようにしても良い)。特徴量保持部14は、例えば、
図3に示すように、表形式で各暗号化フローの特定情報と特徴量を管理し、フローの終了後にはエントリーを削除する(フローの終了判定の一例としては、フローの開始時間から十分に時間が経過していてデータパケットが到来しないことを挙げられる)。
【0028】
図4は、この実施形態のトラヒック監視装置1が適用しているパラメタの説明図である。
図4は、計49種類のパラメタを示しているが、パラメタの組はこれに限定されるものではない。
【0029】
パラメタは、大きくは、パケットサイズと、パケット到着間隔と、フロー情報とに関するものである。
【0030】
パケットサイズについては、一方の転送方向(以下、順方向と呼ぶ)のデータパケットについてのパケットサイズのパラメタと、他方の転送方向(以下、逆方向と呼ぶ)のデータパケットについてのパケットサイズのパラメタと、両転送方向(以下、両方向と呼ぶ)のデータパケットについてのパケットサイズのパラメタとがある。パケットサイズのパラメタは、最小値、25%値、50%値、平均値、75%値、最大値及び分散値がある。ここで、25%値、50%値、75%値はそれぞれ、全てのパケットサイズの値を小さい順に並べた場合において、小さい方から25%、50%、75%に位置するパケットサイズの値である。従って、50%値は、中央値(メディアン)と同じものである。
【0031】
パケット到着間隔についても、順方向、逆方向、両方向のデータパケットについてのパラメタがある。パケット到着間隔のパラメタは、最小値、25%値、50%値、平均値、75%値、最大値及び分散値がある。
【0032】
フロー情報についてのパラメタは、順方向及び逆方向については、合計パケット数、合計バイト数及び転送時間であり、両方向については転送時間である。ここで、転送時間とは、該当する方向(両方向を含む)のフローの開始時刻から最新のパケットが当該トラヒック監視装置1に到着した時刻までの時間である。
【0033】
特徴量収束予測部15は、各種類のパラメタについて、特徴量保持部14が管理しているフロー開始時点からのパラメタ値を基に、パラメタの変化傾向を捉えて、収束状態になっていると思われる所定パケット数(例えば、180パケット目)のパケットが到来したと仮定したときのパラメタ値を予測し、フローの特定情報と共に、アプリケーション推定部16に与えるものである。なお、当該トラヒック監視装置1に既に所定パケット数のパケットが到来した以降においては、特徴量収束予測部15は、実測したパラメタ値をアプリケーション推定部16に与える。
【0034】
図5は、特徴量保持部14が上述した
図3の情報を保持している場合において、特徴量収束予測部15からアプリケーション推定部16に引き渡される情報の説明図である。各パラメタについて、予測されたパラメタ値若しくは実測されたパラメタ値が特徴量収束予測部15からアプリケーション推定部16に引き渡される。
図5の例の場合、フローIDが「1」のフローは到来パケット数が20であり、フローIDが「2」のフローは到来パケット数が30であるので、両フロー共に、予測されたパラメタ値が特徴量収束予測部15からアプリケーション推定部16に引き渡される。なお、文字列「parameter」と数字列「1」、「2」、…でなるパラメタを区別する名称の最後に「#」を付与することにより、引き渡されたパラメタ値が予測値であることをアプリケーション推定部16が認識し得るようになされている。
【0035】
図6は、特徴量収束予測部15における所定パケット数でのパラメタ値の予測方法の説明図である。パラメタ値は、そのパラメタ値を算出するパケット数がある程度のパケット数より多くなると同じような値をとる収束状態になる。収束状態に至るまでは、算出に供するパケット数が多くなるについてパラメタ値は変化する。
図6(A)は、パケット数が10パケット増える毎にパラメタ値をプロットした図であり、パケット数が多くなるについてパラメタ値の増加率が大きくなる変化傾向を有している。
図6(B)に示すように、複数の予測用関数(
図6は7つの例を示している)を用意しておき、今回のパラメタ値の変化にフィットする予測用関数を選択すると共に、
図6(C)に示すように、その関数の係数などをアレンジし、その後、予測用関数に収束状態を捉えるためのパケット数Bを入力して、所定パケット数(収束状態)におけるパラメタ値Aを予測する。
【0036】
なお、
図6(B)は収束状態に至るまでの変化傾向を示しており、図示は省略しているが、収束状態では、
図6(B)における右端の値と同様な値を維持する。
【0037】
タイプ1〜タイプ3の予測用関数は、算出パケット数が多くなるに従って、算出されるパラメタ値が大きくなる場合に適用して好適な関数であり、それぞれ、増加率が、一定、漸増、漸減の関数である。タイプ4〜タイプ6の予測用関数は、算出パケット数が多くなるに従って、算出されるパラメタ値が小さくなる場合に適用して好適な関数であり、それぞれ、減少率が、一定、漸減、漸増の関数である。タイプ7の予測用関数は、先頭の数パケットではそのパラメタ値が不安定であるが、その後、安定した値をとるパラメタに適用して好適な関数であり、先頭の数パケットを除外させる関数である。
図4の例とは合致しないが、例えば、TCP(Transmission Control Protocol)の3ウェイハンドシェイクに係る当初の数パケットは、特定の統計量(特徴量)を乱すものとなっている。
【0038】
特徴量収束予測部15は、適用する予測用関数を選別することを行うものであるが、パラメタの種類によっては、適用する予測用関数を予め定めておくようにしても良い。パラメタ値の収束値を予測するパケット数(
図6(C)のB参照)も、パラメタの種類を問わず、同じパケット数を適用しても良く、また、パラメタの種類に応じて変えるようにしても良い。
【0039】
図6は、予測用関数として7タイプを用意しておく場合を示したが、予測用関数の対応数はこれより多くても少なくても良い。また、増加率や減少率の変化傾向が途中で切り替わるような予測用関数を用意しておいても良い。例えば、前半が
図6(B)のタイプ1でそれより先がタイプ3のような変化傾向を有する予測用関数を用意しておくようにしても良い。
【0040】
アプリケーション推定部16は、フローの特定情報と共に、所定パケット数に係る予測された若しくは実測されたパラメタ値の組が与えられたとき、各アプリケーションについて予め登録されている所定パケット数におけるパラメタ値の組(以下、教師データと呼ぶこともある)と照合し、照合結果が最も良好なアプリケーションの種類を、そのフローで適用されているアプリケーションの種類と推定し、フローの特定情報と推定したアプリケーションの種類の識別情報(ID)の対をフロー制御変更指令部17に通知するものである。通知するフローの特定情報は、例えば、フローIDである。
【0041】
アプリケーション推定部16として、例えば、SVM(Support Vector Machine)等の汎用的な教師有り学習・識別器を適用することができる。教師データは、アプリケーションが既知な状態で、特徴量収束予測部15に予測動作させて得られた所定パケット数におけるパラメタ値の組であり、アプリケーションの種類情報に対応付けられて、アプリケーション推定部16に入力されて登録されたものである。
【0042】
図4では、パラメタの種類数が49種類の例を示したが、アプリケーション推定部16がアプリケーションの推定に用いるパラメタは49種類全てであっても良く、49種類の一部(例えば20種類程度)のパラメタをアプリケーションの推定に用いるようにしても良い。アプリケーションの種類によって、推定(教師データとの照合)に用いるパラメタの数や種類を切り替えるようにしても良い。このような場合であれば、照合するパラメタの種類を特定できるように、教師データを構成しておくことを要する。
【0043】
ここで、アプリケーションとは、転送しようとするデータからIPパケットを組み立てる処理、及び、その逆処理を行う通信アプリケーションであり、暗号化処理だけでなく、その他の処理(例えば、誤り訂正処理など)を行うものである。適用している暗号化の種類や、他の処理の種類や、取り扱うデータの種類(音声、画像、データ)等によって、アプリケーションは様々である。
【0044】
フロー制御変更指令部17は、アプリケーションの識別情報(ID)毎にフローに対する制御内容を記憶しており、アプリケーション推定部16から、フローIDと推定したアプリケーションのIDとが与えられたとき、通信制御部12に、そのフローIDのフローに対して適用するアプリケーションの種類を特定するアプリケーションIDを通知するものである。フロー制御変更指令部17は、デフォルトの制御内容から変更する内容だけを記述している。
【0045】
例えば、ストリーミング系のアプリケーションと、音声通信のアプリケーションとでは、パケットロスによる影響度が異なる。ネットワーク仮想化に対応しているアプリケーションは、転送するネットワークも仮想化対応ものであることが好ましい。P2Pのアプリケーションは通信速度が低くても構わない。このようにアプリケーションの種類により要求事項が異なっており、推定されたアプリケーションの種類に好適な通信制御を通信制御部12が実行し得るように、フロー制御変更指令部17が制御内容を見直すこととした。
【0046】
図7は、アプリケーションの種類と、その種類に対する通信制御の内容の例(制御ルール)を示す説明図である。通信制御の内容は、優先度付け、帯域制御、パケット破棄、転送先の設定等である。
【0047】
例えば、推定されたアプリケーションの種類が、アプリケーションIDが「1」のアプリケーション種類であれば(条件部)、フローの優先度を「A」に高めると共に、転送先のネットワークを「NetworkA」にする(アクション部)制御ルールを適用する。また、例えば、推定されたアプリケーションの種類が、アプリケーションIDが「3」のアプリケーション種類であれば、フローの優先度を「Z」に低めると共に、そのフローのパケットを10,000パケット毎に1パケットずつ強制廃棄する(廃棄率は0.01%)制御ルールを適用する。さらに、例えば、推定されたアプリケーションの種類が、アプリケーションIDが「4」のアプリケーション種類であれば、上限帯域(可用帯域)を200kbpsとするシェーピングを行うと共に、転送先のネットワークを「NetworkC」にする制御ルールを適用する。さらにまた、例えば、推定されたアプリケーションの種類が、アプリケーションIDが「5」のアプリケーション種類であれば、優先度の変更等をなにもせずに、デフォルトの制御をそのまま適用する制御ルールを適用する。なお、デフォルトの制御を適用する場合であれば、フロー制御変更指令部17が、通信制御部12に制御指令を与えないようにすれば良い。
【0048】
通信制御部12は、推定対象フロー抽出部11からフロー(のパケット)を受け取り、そのフローが、フロー制御変更指令部17が制御内容の変更を指令したフローチャートであるか確認し、制御内容を変更するフローである場合には、そのフローについて推定されたアプリケーションの種類の通信制御を行うものである。
【0049】
図8は、通信制御部12が内部管理する制御内容を変更するフローに関する情報を示す説明図である。
【0050】
通信制御部12は、フローのIDに対応付けて、そのフローについて推定されたアプリケーションのIDと、当該エントリーを削除するまでの残り時間とを管理している。通信制御部12は、入力されたフローが、管理しているIDを有するとき、それに対応付けられたアプリケーションIDを取出し、取出したアプリケーションIDをフロー制御変更指令部17に与えて、推定アプリケーションに対する制御内容を取り込んで、入力されたフローに対して、取り込んだ制御内容の通信制御を行う。通信制御には直接関係しないが、通信制御部12は、残り時間が0になると、当該エントリーを削除する。
【0051】
なお、通信制御部12が、アプリケーション種類毎の制御内容をも管理しておき、フローIDが入力された際に、フロー制御変更指令部17に問い合わせを行うことなく、該当する通信制御を行うようにしても良い。
【0052】
通信出力部13は、1つ以上の外部ネットワークに接続され、通信入力部10に入力されたフローを、転送するネットワークを選択して出力するものである。通信出力部13は、フローの送信先IPアドレスで定まるネットワークを選択することを基本としながら、制御内容で転送先となるネットワークが規定されている場合には、規定されているネットワークにフローを出力する。
【0053】
(A−2)実施形態の動作
次に、以上のような構成を有する実施形態のトラヒック監視装置1の動作を説明する。
【0054】
当該トラヒック監視装置1は、ネットワークに接続されるとトラヒック監視装置として動作を開始し、パケットを受信し始める。
【0055】
受信されたパケットは、通信入力部10に入力され、当該トラヒック監視装置1を搭載した通信装置が中継する適切なパケットであれば、推定対象フロー抽出部11に与えられる。
【0056】
推定対象フロー抽出部11においては、暗号化フローと非暗号化フローとが選別され、暗号化フローに関するパラメタが計測され(算出動作を伴うこともある)、各種のパラメタ値が、フローの特定情報と共に特徴量保持部14に与えられる。例えば、入力されたフローのヘッダ情報を用いてペイロードが判別できないフローは、推定対象フロー抽出部11によって、暗号化フローと判定される。また例えば、単純な分類手法(例えば、統計学的クラス分類器とみなされているC4.5決定木等を利用する)によって、フロー情報を元に暗号化の有無を判別し、暗号化フローを認識する。
【0057】
フロー開始時点からの暗号化フローについてのパラメタ値は、フロー毎に、特徴量保持部14において保持される。なお、パケットが所定時間の送られてこないエントリー(フローのパラメタ値群)や開始時間から十分な時間がたったエントリー(フローのパラメタ値群)については、特徴量保持部14から削除される。なお、フローの開始時点から所定パケット数(例えば、180パケット程度)のパケットが到来したフローについては、特徴量保持部14を、実測値のみ保持するように切り替える。
【0058】
所定パケット数でのパラメタ値を予測するために、統計量保持部14がフロー開始からさほど経過していない段階のパラメタ値を保持しているときには、特徴量収束予測部15によって、所定パケット数でのパラメタ値が予測される。
【0059】
図9は、ある一つのパラメタに対する、特徴量収束予測部15の処理を示すフローチャートである。特徴量収束予測部15は、そのフローに係る新たなパケットが到来する毎に
図9に示す処理を実行するようにしても良く、また、複数パケット(例えば、10パケットや20パケット)の到来毎に、
図9に示す処理を実行するようにしても良い。
【0060】
特徴量収束予測部15は、新たなパラメタ値の予測処理(予測しない場合を含む)が必要となると、
図9に示す処理を開始し、予測が不要なパラメタか否かを判別する(ステップ100)。
【0061】
予測が不要なパラメタであれば、特徴量収束予測部15は、
図9に示す一連の処理を直ちに終了する。
【0062】
予測が必要なパラメタであれば、特徴量収束予測部15は、先頭yパケットを除外するパラメタか否かを判別する(ステップ101)。すなわち、
図6(B)のタイプ7のパラメタか否かを判別する。先頭yパケットを除外するパラメタであれば、特徴量収束予測部15は、今回の到来パケットが先頭yパケットを超えているか否かを判別する(ステップ102)。今回の到来パケットが先頭yパケットを超えていなければ、特徴量収束予測部15は、今回の到来パケットを除外した後(ステップ103)、
図9に示す一連の処理を終了し、一方、今回の到来パケットが先頭yパケットを超えていれば、特徴量収束予測部15は、アプリケーション推定部16が参照するパラメタ値を、先頭yパケットを超えた以降のパケットの情報を基に算出したパラメタ値に更新し(ステップ104)、
図9に示す一連の処理を終了する。
【0063】
先頭yパケットを除外するパラメタでなければ、特徴量収束予測部15は、今回のパケットを含めたフローの到来パケット数が、実測値を適用する境界パケット数(先頭zパケット)を超えているか否かを判別する(ステップ105)。今回の到来パケットが先頭zパケットを超えていなければ、特徴量収束予測部15は、アプリケーション推定部16が参照するパラメタ値を、
図6を用いて上述した予測処理で得たパラメタ値に更新した後(ステップ106)、
図9に示す一連の処理を終了し、一方、今回の到来パケットが先頭zパケットを超えていれば、特徴量収束予測部15は、アプリケーション推定部16が参照するパラメタ値を、実測したパラメタ値に更新し(ステップ107)、
図9に示す一連の処理を終了する。
【0064】
図9の処理における先頭yパケットの「y」は、例えば、180より小さい値であって、例えば、10程度の値を適用できる。また、
図9の処理における先頭zパケットの「z」は、例えば、180程度の値を適用できる。先頭zパケットは、パラメタの種類によって異なるようにしても良い。同様に、先頭yパケットも、同じタイプ7のパラメタではあるがパラメタの種類によって異なるようにしても良い。
【0065】
ステップ106で、パラメタ値を予測する方法は、上述した通りである(
図6参照)。
【0066】
以上のようにして、今回の受信パケットに係るフローについて、複数種類のパラメタ値(予測値若しくは実測値)が得られると、アプリケーション推定部17によって、学習されたパラメタ値群と照合され、フローに対応するアプリケーションの種類が推定される。そして、推定されたアプリケーションの種類に適する制御内容が、フロー制御変更指令部17によって認識され、通信制御部12によって、今回の受信パケットに係るフローに対して、認識された通信制御が実行される。
【0067】
なお、パラメタ値の更新やアプリケーション種類の推定が、所定数のパケットの到来毎に行われる場合であれば、更新や推定が実行されないタイミングで到来したパケットは、直前に推定されたアプリケーションの種類に応じて、通信制御部12による通信制御が施される。
【0068】
通信制御部12により通信制御されたトラヒック(パケット;但し、廃棄されたパケットを除く)は、通信出力部13によって、適切な外部ネットワークに向けて送出される。
【0069】
(A−3)実施形態の効果
上記実施形態によれば、暗号トラフィックを取扱うアプリケーションの種類を推定することにより、アプリケーションの種類に適した通信制御を適切に実施することができる。すなわち、優先度付けや帯域制御を行うことができ、オペレーティングにかかるコストや、設備投資にかかるコストを削減することができる。
【0070】
この際、パケットの到来数が少ないフローの開始からさほど期間が経過していない段階でも、各種類のパラメタの収束値を予測してアプリケーションの種類を推定するようにしたので、フロー開始から早い段階でフローの制御を行うことができる。このような迅速な制御により(例えば、優先度の低いフローを早期に判別して優先度の高いフローを早期に優先させることにより)、ユーザの体感品質を早期に向上させることができる。
【0071】
アプリケーションの種類を早期に推定するようにしても、推定に供するパラメタの種類が多い上、予測用関数のタイプとしても種々のものを用意して選別できるようにしたので、アプリケーションの種類の推定精度を十分高いものとすることができる。
【0072】
(B)他の実施形態
上記実施形態の説明においても、種々変形実施形態に言及したが、さらに、以下に例示するような変形実施形態を挙げることができる。
【0073】
上記実施形態では、アプリケーションの種類を推定した後、推定したアプリケーションの種類に応じた通信制御を実行するものを示したが、アプリケーションの種類の推定結果を得る装置として、トラヒック監視装置を構築するようにしても良い。例えば、どのようなトラヒックが流れているかをモニタリングする装置であれば、通信制御を行う機能を持っていなくても良い。また、トラヒック情報を収集する装置が複数あり、それらから、一つのトラヒック監視装置に収集情報を転送してトラヒックの監視を行うようにしても良い。
【0074】
上記実施形態では、トラヒック監視装置がパケットを転送する通信装置に搭載される場合を示したが、トラヒック監視装置が通信装置と異なる装置として構築され、通信装置からトラヒック情報が与えられてトラヒックを監視するものであっても良い。この場合、監視のリアルタイム性は損なわれるが、例えば、どのようなトラヒックが流れているかをモニタリングする場合であれば、リアルタイム性が多少損なわれても問題となることはない。
【0075】
以上から明らかなように、アプリケーションの推定結果の利用の仕方は、実施形態の方法に限定されるものではない。
【0076】
上記実施形態では、アプリケーションの種類の推定対象のフローについて、十分な数のパケットが到来していない段階では、タイプ別の予測用関数を用いて、到来数より多い所定パケット数でのパラメタの予測値を求め、それを適用して、アプリケーションの種類を推定するものを示したが、タイプ情報そのものを利用して、アプリケーションの種類を推定するようにしても良い。例えば、タイプ1〜タイプ7をそれぞれ数値化し、今までに到来したパケット数から求めたN個のパラメタのタイプの組み合わせをベクトル表記し、そのベクトルを、予め登録されている教師データとしてのベクトルと照合することにより、アプリケーションの種類を推定するようにしても良い。
【0077】
上記実施形態では、パラメタの多くが統計量であるものを示したが、アプリケーションの推定に利用するパラメタは統計量に限定されるものではなく、統計量以外でも、アプリケーション毎の特徴を表すものであればパラメタとして用いることができる。また、パラメタは時間と共に変化しないものであっても良い。例えば、送信元又は宛先のIPアドレスが属するドメイン名などをアプリケーションの推定に利用することもできる。到来数より多い所定パケット数での予測値を求めるパラメタ以外のパラメタも、アプリケーションの種類の推定に用いるようにしても良い。
【0078】
上記実施形態では、各フローについて、パケットが到来する毎にパラメタ値を得て保持するものを示したが、パラメタ値を得る間隔はこれより長くても良い。例えば、2パケット毎にパラメタ値を得て保持するようにしても良い。また例えば、ある閾値のパケット数までは、パケットが到来する毎にパラメタ値を得て保持し、閾値のパケット数を超えた以降は、2パケット毎にパラメタ値を得て保持するようにしても良い。
【0079】
本発明は、フローのパケットの中身を解析することなく、そのフローのアプリケーションの種類を推定することを特徴とするものである。そのため、非暗号化フローの中身を解析しないでアプリケーションの種類を推定する場合にも、本発明を適用することができる。