(57)【要約】【課題】簡便な処理で受信パケットの処理を効率化する。【解決手段】パケット通信装置は、複数の受信キュー、複数のプロセッサ、送信処理部を備える、複数の受信キューは、ネットワーク中の装置からの受信パケットを格納する。複数のプロセッサは、複数の受信キューの少なくとも１つが受信処理の対象に設定されたプロセッサを含む。送信処理部は、ネットワーク中の装置に宛てた送信パケットを送信する。複数のプロセッサのいずれかは、送信データ量が所定値を超えた通信先宛ての送信パケットに対する確認応答の受信処理を行うプロセッサを、複数のプロセッサから選択する。さらに、複数のプロセッサのいずれかが選択したプロセッサによって受信処理が行われる受信キューを、確認応答の格納先に設定する処理を行う。【選択図】図１
2016149698.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク中の装置からの受信パケットを格納する複数の受信キューと、
前記複数の受信キューの少なくとも１つが受信処理の対象に設定されたプロセッサを含む複数のプロセッサと、
前記ネットワーク中の装置に宛てた送信パケットを送信する送信処理部
を備え、
送信データ量が所定値を超えた通信先宛ての送信パケットに対する確認応答の受信処理を行うプロセッサを、前記複数のプロセッサから選択すると共に、選択したプロセッサによって受信処理が行われる受信キューを、前記確認応答の格納先に設定する処理を、前記複数のプロセッサのいずれかが行う
ことを特徴とするパケット通信装置。
【請求項２】
前記確認応答の受信処理を行うプロセッサを選択するプロセッサは、前記送信処理部に対する１回の送信要求で送信が要求されたデータ量が前記所定値を超えると、前記通信先に宛てた送信データ量が前記所定値を超えたと判定する
ことを特徴とする請求項１に記載のパケット通信装置。
【請求項３】
前記確認応答の受信処理を行うプロセッサを選択するプロセッサは、
前記通信先宛の前回の送信要求が行われた時刻から前記通信先宛の新たな送信要求が行われた時刻までの期間の長さが閾値未満の場合、前記新たな送信要求を行う前の送信データ量に前記新たな送信要求の対象となったデータ量を加えた値を、前記新たな送信要求後での送信データ量とし、
前記期間の長さが前記閾値を超えると、前記新たな送信要求の対象となったデータ量を、前記新たな送信要求後での送信データ量とする
ことを特徴とする請求項１に記載のパケット通信装置。
【請求項４】
前記確認応答の受信処理を行うプロセッサを選択するプロセッサは、
前記通信先宛の前回の送信要求が行われた時刻から、前記通信先宛の新たな送信要求が行われた時刻までの期間を求め、
前記通信先への送信要求の対象となったデータのうちで前記確認応答を受信していないデータ量の前記期間での減少量と、前記新たな送信処理で送信が要求されたデータ量の関数として、前記送信データ量を求め、
前記送信データ量が前記所定値を超えると、前記確認応答の受信処理を行うプロセッサを選択する
ことを特徴とする請求項１に記載のパケット通信装置。
【請求項５】
ネットワーク中の装置からの受信パケットを格納する複数の受信キューと、前記複数の受信キューの少なくとも１つが受信処理の対象に設定されたプロセッサを含む複数のプロセッサを備えるパケット通信装置に、
送信データ量が所定値を超えた通信先宛ての送信パケットに対する確認応答の受信処理を行うプロセッサを、前記複数のプロセッサから選択し、
選択したプロセッサによって受信処理が行われる受信キューを、前記確認応答の格納先に設定する
処理を行わせることを特徴とするパケット受信処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パケット通信に関する。
【背景技術】
【０００２】
近年のコンピュータでは、マルチコアＣＰＵ（Central Processing Unit）が搭載されることが多い。また、ネットワーク接続に用いるＮＩＣ(Network Interface Card)においても、インタフェース速度の高速化に伴って、複数のキューが備えられることがある。複数のキューが備えられたＮＩＣでは、キューに格納されたパケットを処理するＣＰＵをキューごとに決定し、複数のＣＰＵが複数のキューに格納されたパケットを並行して処理する。
【０００３】
複数の受信キューを備える通信装置において、通信装置が受信したパケットを無秩序に各キューに振り分けると、受信キューでのパケットの滞留量や、プロセッサの負荷などにより、パケットの順序逆転が起こる恐れがある。ＴＣＰ（Transport Control Protocol）を用いた通信では、パケットの順序逆転が起こると、パケットロスが発生したと誤認されて、無駄な再送処理や、Fast Recoveryなどの送信スループットを一時的に低下させる処理が行われる恐れがある。また、パケットの順序逆転により、音声や動画などのリアルタイム通信を行うアプリケーションでの品質の劣化が発生する恐れもある。
【０００４】
このため、パケットが属するセッションを意識して受信パケットを複数のキューに振り分ける方法についても考案されている。例えば、ＲＳＳ（Receive Side Scaling）では、パケットヘッダ中のパケットが属するセッションあるいはフローに関する特定のフィールドの情報から計算したハッシュ値に応じて振り分け先のキューを決定する。関連する技術として、パケットの送信元識別子と宛先識別子から生成したフローキーを処理することによって得られた計算値に対応するプロセッサを、そのパケットの処理を行うプロセッサに決定する方法も提案されている（例えば、特許文献１）。また、Ｉｎｔｅｌ  Ｆｌｏｗ  Ｄｉｒｅｃｔｏｒでは、パケットヘッダを用いて計算したハッシュ値を用いて、あるフローの送信処理を行ったＣＰＵと、そのフローに対する応答の受信処理を行うＣＰＵが同じになるように、ＣＰＵを割り当てる（非特許文献１）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特表２００２−５３８７２４号公報
【非特許文献】
【０００６】
【非特許文献１】Wenji Wu, Phil DeMar, Matt Crawford、“Why Does Flow Director Cause Packet Reordering?”、[online]、[平成26年12月17日検索]、インターネット＜URL:http://arxiv.org/ftp/arxiv/papers/1106/1106.0443.pdf＞
【発明の概要】
【発明が解決しようとする課題】
【０００７】
フローごとに決まる値のハッシュ値に応じて、各フローを処理するプロセッサを決める場合、振り分けルールを削減することはできるが、プロセッサの使用状況とは無関係に受信フローの処理が割り当ててしまうと、プロセッサの使用状況にアンバランスが生じ処理効率を下げてしまう恐れがある。そこで、処理効率を改善するためには、フローごとに処理を行うプロセッサを決定することが好ましい。しかし、通信量の増大に従い、通信装置で処理するフローの数も大きくなってきているため、フローごとに振り分けルールを決めていると、通信装置側で記憶する振り分けルールの数が膨大になる。振り分けルールの数が大きくなると、振り分けルールを記憶するためのメモリ容量が大きくなり、ハードウェアで許容されるテーブルサイズに収まらなくなる。十分なルール数を登録することができたとしても、エントリの登録などの管理が煩雑になる。
【０００８】
本発明は、簡便な処理で受信パケットの処理を効率化することを目的とする。
【課題を解決するための手段】
【０００９】
ある１つの態様にかかるパケット通信装置は、複数の受信キュー、複数のプロセッサ、送信処理部を備える、複数の受信キューは、ネットワーク中の装置からの受信パケットを格納する。複数のプロセッサは、前記複数の受信キューの少なくとも１つが受信処理の対象に設定されたプロセッサを含む。送信処理部は、前記ネットワーク中の装置に宛てた送信パケットを送信する。前記複数のプロセッサのいずれかは、送信データ量が所定値を超えた通信先宛ての送信パケットに対する確認応答の受信処理を行うプロセッサを、前記複数のプロセッサから選択する。さらに、前記複数のプロセッサのいずれかは、選択したプロセッサによって受信処理が行われる受信キューを、前記確認応答の格納先に設定する処理を行う。
【発明の効果】
【００１０】
受信パケットの処理が簡便に効率化される。
【図面の簡単な説明】
【００１１】
【図１】実施形態にかかる通信方法の例を説明するフローチャートである。
【図２】通信装置の構成の例を示す図である。
【図３】通信装置のハードウェア構成の例を説明する図である。
【図４】送信フローテーブルの例を示す図である。
【図５】送信フローテーブルの例を示す図である。
【図６】パケットを送信する際の通信装置の処理の例を説明するフローチャートである。
【図７】キューテーブルの例を示す図である。
【図８】振り分けテーブルの例を示す図である。
【図９】パケットを受信する際の通信装置の処理の例を説明するフローチャートである。
【図１０】ハッシュ値テーブルの例を示す図である。
【図１１】フローの送信処理を行ったプロセッサを特定する情報の例を説明する図である。
【図１２】振り分けテーブルの例を示す図である。
【図１３】第３の実施形態にかかる送信フローテーブルの例を示す図である。
【図１４】第３の実施形態にかかる送信フローテーブルの例を示す図である。
【図１５】第３の実施形態にかかる送信フローテーブルの例を示す図である。
【図１６】第３の実施形態にかかる通信装置の処理の例を説明するフローチャートである。
【図１７】第４の実施形態にかかる通信装置の処理の例を説明するフローチャートである。
【図１８】仮想マシンを運用している通信装置の構成の例を示す図である。
【図１９】送信フローテーブルの例を示す図である。
【図２０】ＶＭアドレステーブルの例を示す図である。
【図２１】プロセッサテーブルの例を示す図である。
【発明を実施するための形態】
【００１２】
図１は、実施形態にかかる通信方法の例を説明するフローチャートで、受信パケットを、振り分けテーブルに記録されている振り分けルールに従って受信キューに振り分ける通信装置において、パケットの送信の際に行われる処理を示している。なお、通信装置には、複数の受信キューと複数のプロセッサが備えられている。
【００１３】
ステップＳ１において、通信装置は、処理対象のフローのうち、ＴＣＰのように確認応答が行われるプロトコルでの送信を行っているフローがあるかを判定する。ここで、ＴＣＰのように、確認応答を行うプロトコルを用いた通信では、データの送信元の通信装置は、データの宛先の通信装置から確認応答パケットを受信する。換言すると、通信装置は、ステップＳ１の処理により、送信中のフローの宛先の装置からパケットを受信する可能性が高いかを判定している。確認応答を行わないプロトコルのパケットの場合、通信装置は、振り分けテーブルを用いた処理を行わない（ステップＳ１でＮｏ）。
【００１４】
確認応答が行われるプロトコルについてのパケットの処理を行っている場合、通信装置は、そのパケットが属するフローが、送信データ量が所定量を超えたフローであるかを判定する（ステップＳ１でＹｅｓ、ステップＳ２）。ここで、サーバがクライアントとして動作する装置に対してデータを送信する場合など、通信中の装置のうちの一方が大量にデータを送信し、他方の装置はデータを送信せずに受信を行うことが多くみられる。ステップＳ２では、大量のデータが送信されるフローの逆向きのフローでは、データを伴わない確認応答パケットが大量に送信される可能性が高いことに基づいて、データを大量に送信するフローであるかを判定している。送信データ量が所定量を超えたフローではない場合、通信装置は振り分けテーブルの登録処理を行わない（ステップＳ２でＮｏ）。
【００１５】
送信データ量が所定量を超えたフローである場合、通信装置は、送信対象のフローの識別情報を特定する（ステップＳ２でＹｅｓ、ステップＳ３）。通信装置は、特定されたフロー中のパケットに対する確認応答パケットを処理するプロセッサを決定する（ステップＳ４）。さらに、通信装置は、確認応答パケットを識別する情報と、それを処理するプロセッサの情報を受信パケットの振り分けテーブルに登録する（ステップＳ５）。
【００１６】
図１に示す処理を行うことにより、通信装置は、確認応答パケットを大量に受信する可能性の高いフローを選択した上で、選択した各フローを処理するプロセッサを決定することができる。従って、通信装置での処理負荷が所定以上のフローに対しては、振り分けルールを用いて、受信処理が効率化されるように、受信パケットの処理を行うプロセッサを決定できる。
【００１７】
ここで、通信装置での処理負荷が所定以上のフローに対しては、振り分けルールが決定されるが、処理負荷が相対的に小さいことが予測されるフローに対しては振り分けルールが決定されない。このため、通信装置が記憶する振り分けルールの数が少なくなり、振り分けルールの記憶に使用するメモリが削減できる上、振り分けルールの登録や管理にかかる処理負荷も軽減される。
【００１８】
ところで、図１の処理を行う通信装置は、比較的大きなデータを送信しているフローの逆向きのフローを、振り分けルールを決定する対象としている。前述のとおり、比較的大きなデータを送信しているフローの逆向きのフローでは、データが送信される可能性は比較的小さいことが予想される。つまり、通信装置は、データを含まない確認応答パケットが送信される確率の高いフローに対して、振り分けルールを決定している。データを含まない確認応答パケットの場合、パケットの順序が逆転しても、受信に成功したことが通知されるシーケンス番号の順序が逆転するにすぎないため、再送処理などの原因とはならない。従って、振り分けルールを用いた処理を開始することによって、処理を行うプロセッサが変更される場合においても、無駄な再送処理や送信スループットを一時的に低下させる処理の要因にはならない。
【００１９】
＜装置構成＞
図２は、通信装置１０の構成の例を示す図である。通信装置１０は、アプリケーション処理部１１、Ｈｏｓｔカーネル１５、インタフェース部１６、記憶部５０を備える。Ｈｏｓｔカーネル１５は、ソケット処理部１２、プロトコル処理部１３、プロトコル処理部１４、送受信部２０を有する。送受信部２０は、出力処理部２１、検出部２２、振り分け決定部２３、受信処理部２４（２４ａ〜２４ｄ）を有する。インタフェース部１６は、送信処理部３０、振り分け制御部４１、受信キュー４２（４２ａ〜４２ｄ）を有する。送信処理部３０は、送信スケジューラ３１と送信キュー３２（３２ａ〜３２ｄ）を含む。記憶部５０は、送信フローテーブル５１、振り分けテーブル５２、キューテーブル５３、ハッシュ値テーブル５４を記憶する。
【００２０】
アプリケーション処理部１１は、通信先とデータの送受信を行うアプリケーションの実行をする。ソケット処理部１２は、通信を行うためのソケットに関する処理を行う。プロトコル処理部１３は、通信装置１０から送信されるデータに、通信で使用されるプロトコルによる処理を行い、出力処理部２１に出力する。一方、プロトコル処理部１４は、受信処理部２４ａ〜２４ｄから取得したパケット中のデータをソケット処理部１２に出力する。ここで、プロトコル処理部１３は、データが送信されるフローの情報を用いて送信パケットを生成したうえで、送信パケットを出力処理部２１に出力してもよい。また、通信装置１０は、ＴＳＯ（TCP Segmentation Offload）やＧＳＯ（generic segmentation offload）などにより送信処理負荷を軽減する機能を有する装置であっても良い。この場合、プロトコル処理部１３は、複数のパケット分のデータと、送信フローの情報を含めた情報を、出力処理部２１に出力する。
【００２１】
出力処理部２１は、プロトコル処理部１３からの入力パケットを、送信キュー３２ａ〜３２ｄのいずれかに出力する。検出部２２は、プロトコル処理部１３から出力処理部２１に出力されたパケットのヘッダやフローの情報を用いて、送信データ量が所定の値を超えたフローかどうかを判定する。このとき、検出部２２は、適宜、送信フローテーブル５１を使用しても良い。送信フローテーブル５１には、通信装置１０から送信されたフローを特定する情報や送信されたデータ量などの情報が含まれている。検出部２２は、送信データ量が所定の値を超えたフローを検出すると、検出したフローの情報を振り分け決定部２３に通知する。振り分け決定部２３は、キューテーブル５３を用いて、振り分けテーブル５２を更新する。ここで、キューテーブル５３は、受信キュー４２ａ〜４２ｄがいずれのプロセッサ（図４のプロセッサ１０１）によって処理されるかを示している。振り分けテーブル５２は、通信装置１０が受信するパケットを受信キュー４２ａ〜４２ｄのいずれに振り分けるかを示す情報を記録する。
【００２２】
通信装置１０がパケットを受信すると、受信パケットは振り分け制御部４１に入力される。振り分け制御部４１は、振り分けテーブル５２を用いて、受信パケットを、受信キュー４２ａ〜４２ｄに振り分ける。振り分けテーブル５２に振り分け先が記録されていないパケットについては、振り分け制御部４１は、ハッシュ値テーブル５４を用いて、受信キュー４２ａ〜４２ｄのいずれかに格納する。受信キュー４２ａ〜４２ｄに格納されたパケットは、受信処理部２４ａ〜２４ｄで処理される。
【００２３】
なお、図２では、受信処理部２４、送信キュー３２、受信キュー４２を、それぞれ４つずつ図示しているが、通信装置１０は、受信処理部２４、送信キュー３２、受信キュー４２のいずれも、任意の数だけ備えることができる。
【００２４】
図３は、通信装置１０のハードウェア構成の例を説明する図である。通信装置１０は、プロセッサ１０１（１０１ａ、１０１ｂ）、メモリ１０２、バスコントローラ１０３、ストレージ装置１０４、Ｉ／Ｏ（Input/Output）バス、ネットワーク接続装置１０８、タイマ１０９を備える。さらに、通信装置１０は、ストレージＩ／Ｏ１０５（１０５ａ、１０５ｂ）、ディスプレイＩ／Ｏ１０６、Ｉ／Ｏ１０７を備える。プロセッサ１０１は、Central Processing Unit（ＣＰＵ）を含む任意のプロセッサとすることができる。なお、図３では、図を簡略化するためにプロセッサ１０１を２つ図示しているが、通信装置１０に含まれているプロセッサ１０１の数は任意の複数となりうる。また、通信装置１０に含まれるプロセッサ１０１が１つであっても、プロセッサ１０１に含まれているプロセッサコアの数が複数であって、プロセッサコアの各々が１つ以上の受信キュー４２を処理する場合、実施形態にかかる方法を適用できる。
【００２５】
プロセッサ１０１は、アプリケーション処理部１１、Ｈｏｓｔカーネル１５として動作する。プロセッサ１０１は、適宜、ストレージ装置１０４に格納されたプログラムを読み込み、メモリ１０２をワーキングメモリとして用いて処理を行う。なお、受信処理部２４のいずれかを処理するプロセッサ１０１は、確認応答パケットを処理するプロセッサを決定するプロセッサと同じであっても異なっていても良い。例えば、プロセッサ１０１ａが受信処理部２４ａとして動作するが、検出部２２や振り分け決定部２３の処理は、受信処理部２４として動作していないプロセッサ１０１ｂによって実現されてもよい。また、プロセッサ１０１ａが検出部２２、振り分け決定部２３、受信処理部２４ａとして動作しても良い。メモリ１０２は、Random Access Memory（ＲＡＭ）とRead Only Memory（ＲＯＭ）を含む。メモリ１０２は、記憶部５０、送信キュー３２ａ〜３２ｄ、受信キュー４２ａ〜４２ｄとして動作する。さらに、メモリ１０２は、プロセッサ１０１の処理に用いられるデータや、プロセッサ１０１の処理により得られたデータなどを保持する。送信スケジューラ３１と振り分け制御部４１は、プロセッサ１０１とネットワーク接続装置１０８によって実現される。タイマ１０９は、検出部２２の一部として動作してもよい。
【００２６】
バスコントローラ１０３は、プロセッサ１０１とメモリ１０２を、データの入出力が可能なように接続する。また、ストレージＩ／Ｏ１０５、ディスプレイＩ／Ｏ１０６、Ｉ／Ｏ１０７は、通信装置１０と通信装置１０に接続されたディスプレイ１１３や入力装置１１０、光学ディスクドライブ１１１を、データの入出力が可能なように接続する。光学ディスクドライブ１１１は、適宜、可搬記憶媒体１１２からのデータの読み込みや可搬記憶媒体１１２へのデータの書き込みに使用されうる。プロセッサ１０１は、可搬記憶媒体１１２に記録されたプログラムを実行しても良い。
【００２７】
＜第１の実施形態＞
以下、通信装置１０が対向装置に新たなフローの送信を開始した場合を例として、第１の実施形態で行われる処理を、所定量を超えたデータ送信の検出、受信パケットの振り分けルールの決定、振り分けテーブル５２を用いた受信処理に分けて説明する。第１の実施形態では、通信装置１０は、ＣＰＵ０〜ＣＰＵ９の１０個のプロセッサ１０１を備えており、キュー０〜キュー９の１０個の受信キュー４２を備えている場合を例として説明する。また、第１の実施形態では、通信装置１０はＴＳＯやＧＳＯに対応しており、複数のパケット中のデータに、送信フローの情報を含めた情報が、出力処理部２１に出力される場合について説明する。なお、時間の経過に従ってテーブルの内容が変化する場合、符号の最後にアンダースコアと数字を続けて、いつの時点でのテーブルの状態かを示すことがある。
【００２８】
（１）データ送信と所定量を超えたフローの検出
例えば、通信装置１０が、新たに以下の情報で特定されるフローにデータの送信を開始したとする。
送信元ＩＰアドレス  １９２．１６８．１．１３
宛先ＩＰアドレス    １０．１１１．３３．１４
送信元ポート番号    ３３４１５
宛先ポート番号      ２５３
【００２９】
通信装置１０がネットワーク中の装置への送信処理を開始すると、アプリケーション処理部１１は、送信データを、ソケット処理部１２、プロトコル処理部１３を介して、出力処理部２１に出力する。検出部２２は、出力処理部２１が送信処理部３０に出力する送信データの量をフローごとに調べ、送信データの量が所定値以上になっているフローを特定する。すなわち、第１の実施形態では、検出部２２は、送信対象となったデータの量を、フローごとの送信データ量としている。検出部２２は、送信データ量が所定値以上のフローを検出すると、そのフローが送信フローテーブル５１に登録されているかを判定する。
【００３０】
図４は、送信フローテーブル５１の例を示す図である。送信フローテーブル５１＿１には、送信データが所定値以上であるフローのうち、確認応答パケットの格納先が決定されているフローに関する情報が記録されている。送信フローテーブル５１＿１では、各エントリについて、エントリ番号、送信元ＩＰアドレス、宛先ＩＰアドレス、送信元ポート番号、宛先ポート番号、最終送信時刻が記録されている。送信元ＩＰアドレス、宛先ＩＰアドレス、送信元ポート番号、宛先ポート番号の組み合わせは、フローの識別に使用される。最終送信時刻は、そのフローにより最後にパケットが送信された時刻である。送信フローテーブル５１＿１には、ＩＰアドレス＝１９２．１６８．１．１３の３３４１５番ポートから、ＩＰアドレス＝１０．１１１．３３．１４の２５３番ポートに向けて送信されるフローに対するエントリは含まれていない。すなわち、ＩＰアドレス＝１９２．１６８．１．１３の３３４１５番ポートから、ＩＰアドレス＝１０．１１１．３３．１４の２５３番ポートに向けて送信されたＴＣＰパケットに対する確認応答パケットの格納先は、まだ決定されていない。そこで、検出部２２は、大量のデータの送信を検出したことと、大量のデータの送信が検出されたフローの情報を振り分け決定部２３に通知する。さらに、検出部２２は、振り分け決定部２３に通知するフローの情報を送信フローテーブル５１＿１に追加する。
【００３１】
図５は、送信フローテーブル５１の例を示す図である。検出部２２は、大量送信の検出に伴い、送信フローテーブル５１＿１を送信フローテーブル５１＿２に更新する。図５の例では、エントリ番号＝３には、ＩＰアドレス＝１９２．１６８．１．１３の３３４１５番ポートから、ＩＰアドレス＝１０．１１１．３３．１４の２５３番ポートに向けたフローの情報が記録されている。
【００３２】
なお、検出部２２は、大量のデータの送信を検出しても、既に送信フローテーブル５１に登録されているフローに対する大量送信の検出である場合は、振り分け決定部２３への通知や送信フローテーブル５１の更新は行わない。
【００３３】
図６は、パケットを送信する際の通信装置の処理の例を説明するフローチャートである。検出部２２は、出力処理部２１にデータが入力されたフローでの通信に使用されているトランスポート層のプロトコルがＴＣＰであるかを判定する（ステップＳ２１）。使用されているトランスポート層のプロトコルがＴＣＰでない場合、検出部２２は処理を終了する（ステップＳ２１でＮｏ）。
【００３４】
次に、通信装置１０がＴＣＰを用いてパケットを送信する場合について述べる（ステップＳ２１でＹｅｓ）。検出部２２は、フローの送信元と宛先についての情報を用いて、処理対象のフローに対応するエントリが送信フローテーブル５１にあるかを判定する（ステップＳ２２）。処理対象のフローに対応するエントリが送信フローテーブル５１にない場合、検出部２２は、今回の送信データの量は閾値以上であるかを判定する（ステップＳ２２でＮｏ、ステップＳ２３）。送信データの量が閾値以上である場合、検出部２２は、処理対象のフローに対応するエントリを、送信フローテーブル５１中に作成する（ステップＳ２３でＹｅｓ、ステップＳ２４）。さらに、振り分け決定部２３は、送信パケットに対する確認応答パケット（Ａｃｋ）を処理するＣＰＵと確認応答パケットの振り分け先の受信キュー４２を決定する（ステップＳ２５）。振り分け決定部２３は、決定した内容を用いて、振り分けテーブル５２を設定する（ステップＳ２６）。検出部２２は、送信フローテーブル５１において、送信パケットが含まれているフローに対応付けられた最終送信時刻を現在の時刻に更新する（ステップＳ２７）。
【００３５】
一方、送信パケットに対応するエントリが送信フローテーブル５１にあると判定された場合について説明する（ステップＳ２２でＹｅｓ）。この場合、検出部２２は、送信パケットを含むフローと逆向きのフローに関する処理が振り分けテーブル５２に登録されていると判定する。そこで、検出部２２は、最終送信時刻を更新して処理を終了する（ステップＳ２７）。また、ステップＳ２３において、送信データの量が閾値未満であると判定された場合、振り分け決定部２３と検出部２２は、処理を終了する。
【００３６】
（２）受信パケットの振り分けルールの決定
検出部２２から大量のデータの送信を検出したことを通知された振り分け決定部２３は、大量のデータ送信に伴って発生する大量の確認応答パケットの処理に備えて、振り分けルールを決定すると共に、決定した振り分けルールを振り分けテーブル５２に登録する。以下、振り分けルールの決定と登録に際して行われる処理の詳細を説明する。
【００３７】
まず、振り分け決定部２３は、ＣＰＵ０〜ＣＰＵ９の処理負荷を特定する。ＣＰＵ０〜ＣＰＵ９の各々の処理負荷を取得する方法は、任意の既知の方法が適用され得る。振り分け決定部２３は、ＣＰＵ０〜ＣＰＵ９の中から、最も処理負荷の小さいプロセッサを、確認応答パケットの処理を行うプロセッサとして選択する。
【００３８】
次に、振り分け決定部２３は、選択したプロセッサに検出部２２から通知されたフローに対する確認応答パケットが含まれるフローの処理を割り当てるためには、いずれの受信キュー４２に格納すればよいかを、キューテーブル５３を参照して決定する。
【００３９】
図７は、キューテーブル５３の例を示す図である。キューテーブル５３は、キュー０〜キュー９の各々について、各キューに格納されたパケットが通信装置１０に含まれているいずれのプロセッサによって処理されるかを表している。図７の例では、キュー０に格納されたパケットはＣＰＵ０によって処理される。同様に、他のキューについても、キューテーブル５３の各キューのエントリに対応付けられているＣＰＵが、そのエントリのキューに格納されたパケットを処理する。例えば、キュー１に格納されたパケットはＣＰＵ１、キュー２に格納されたパケットはＣＰＵ２、キュー９に格納されたパケットはＣＰＵ９によって処理される。
【００４０】
例えば、ＣＰＵ０〜ＣＰＵ９のうちで、ＣＰＵ１の処理負荷が最も低いとする。この場合、振り分け決定部２３は、検出部２２から通知されたフローの確認応答パケットを含むフローの処理をＣＰＵ１に行わせるために、キュー１を用いることを決定する。ここで、送信データ量が所定量を超えたことが確認されたフロー中の送信パケットに対する確認応答パケットでは、送信元情報と宛先情報が入れ替わる。このため、振り分け先のキューを決定する対象となる確認応答パケットでは、アドレスやポート番号の情報は、以下のとおりである。
送信元ＩＰアドレス  １０．１１１．３３．１４
宛先ＩＰアドレス    １９２．１６８．１．１３
送信元ポート番号    ２５３
宛先ポート番号      ３３４１５
そこで、振り分け決定部２３は、選択したキューと、選択したキューに格納する上記確認応答パケットの識別情報を用いて、振り分けテーブル５２を更新する。
【００４１】
図８は、振り分けテーブル５２の例を示す図である。振り分けテーブル５２は、エントリ番号、送信元ＩＰアドレス、宛先ＩＰアドレス、プロトコル、送信元ポート番号、宛先ポート番号、受信キュー番号を含む。エントリ番号は、振り分けテーブル５２中のエントリの特定に使用する番号である。振り分けテーブル５２では、通信装置１０から所定量以上のデータが送信されたフローに対する確認応答パケットを抽出するための条件として、送信元ＩＰアドレス、宛先ＩＰアドレス、送信元ポート番号、宛先ポート番号、プロトコルの組合せが格納される。振り分け決定部２３は、送信元ＩＰアドレス、宛先ＩＰアドレス、送信元ポート番号、宛先ポート番号、プロトコルの組合せに対応付けて、その組合せで特定される確認応答パケットの格納先の受信キュー４２の番号を記録する。
【００４２】
例えば、図４〜図７を参照しながら説明した処理により、振り分け決定部２３は、図８中のエントリ番号＝３の条件を、振り分けテーブル５２に追加する。図８の太線で示すエントリ番号＝３の条件は、送信フローテーブル５１＿２（図５）のエントリ番号＝３で特定される送信パケットに対する確認応答パケットに適用される。すなわち、ＩＰアドレス＝１０．１１１．３３．１４の２５３番ポートから、ＩＰアドレス＝１９２．１６８．１．１３の３３４１５番ポートに向けて送信されたＴＣＰパケットの格納先は、キュー１に設定されている。
【００４３】
同様に、図８のエントリ番号＝０の条件は、送信フローテーブル５１＿２（図５）のエントリ番号＝０で特定される送信パケットに対する確認応答パケットに適用するために生成されたものである。また、図８のエントリ番号＝１の条件は、送信フローテーブル５１＿２のエントリ番号＝１の条件で特定される送信パケットに対する確認応答パケットに適用される。さらに、図８のエントリ番号＝２の条件は、送信フローテーブル５１＿２のエントリ番号＝２の条件で特定される送信パケットに対する確認応答パケットに適用される。
【００４４】
なお、振り分けテーブル５２において、確認応答パケットを特定するための情報として、処理対象のパケットに対応したプロトコルが指定される。これは、フローを識別するためのヘッダ情報の形式がプロトコル依存であるため、パケットのフロー識別にプロトコル識別子が用いられるからである。
【００４５】
（３）振り分けテーブル５２を用いた受信処理
図９は、パケットを受信する際の通信装置１０の処理の例を説明するフローチャートである。以下、図９を参照しながら、振り分けテーブル５２を用いた受信処理の例と、振り分けテーブル５２に登録されていないパケットの処理の例を説明する。
【００４６】
ステップＳ１１において、振り分け制御部４１は、ネットワーク中の他の装置から送信されてきたパケットを格納する受信キュー４２を選択するために、入力されたパケットに適用可能なエントリが振り分けテーブル５２に含まれているかを判定する。このとき、振り分け制御部４１は、入力されたパケットの送信元ＩＰアドレス、宛先ＩＰアドレス、送信元ポート番号、宛先ポート番号、プロトコルの組合せをキーとして、振り分けテーブル５２（図８）を検索する。ここで、振り分け制御部４１に入力されたパケットの送信元ＩＰアドレス、宛先ＩＰアドレス、送信元ポート番号、宛先ポート番号、プロトコルの組合せが、振り分けテーブル５２のいずれかのエントリと一致したとする（ステップＳ１１でＹｅｓ）。この場合、振り分け制御部４１は、入力されたパケットに適用可能なエントリ中の受信キューの番号を取得する（ステップＳ１２）。さらに、振り分け制御部４１は、入力されたパケットを、取得した番号で特定されるキューに格納する（ステップＳ１５）。
【００４７】
次に、振り分け制御部４１に入力されたパケットの送信元ＩＰアドレス、宛先ＩＰアドレス、送信元ポート番号、宛先ポート番号、プロトコルの組合せが、振り分けテーブル５２中のエントリと一致しない場合について述べる（ステップＳ１１でＮｏ）。振り分け制御部４１は、入力されたパケットのヘッダからハッシュ値を計算する（ステップＳ１３）。ステップＳ１３で行われるハッシュ値の計算では、任意のハッシュ関数が使用されうる。
【００４８】
ステップＳ１４において、振り分け制御部４１は、入力されたパケットのヘッダを用いてステップＳ１３で計算したハッシュ値に対応付けられた受信キュー番号を、ハッシュ値テーブル５４から取得する。その後、振り分け制御部４１は、入力されたパケットを、取得した番号で特定されるキューに格納する（ステップＳ１５）。
【００４９】
図１０は、ハッシュ値テーブル５４の例を示す図である。ハッシュ値テーブル５４は、パケットのヘッダから得られるハッシュ値のそれぞれに対応付けて、パケットの格納に使用する受信キュー４２の番号を記憶している。例えば、図１０に示すハッシュ値テーブル５４では、ヘッダから得られるハッシュ値が１であるパケットはキュー１が格納先に設定されており、ハッシュ値が５のパケットの格納先はキュー７に設定されている。
【００５０】
図９と図１０を参照しながら説明した処理により、パケットが受信キュー４２に格納される。その後、受信処理部２４は、予め、受信処理の対象として設定されている受信キュー４２からパケットを読み出して、受信処理を行う。受信処理部２４は、受信処理によって得られたパケットをプロトコル処理部１４に出力する。アプリケーション処理部１１は、プロトコル処理部１４とソケット処理部１２を介して、受信パケット中のデータを取得する。
【００５１】
以上、第１の実施形態では、通信装置１０が所定量以上のデータを送信したフローと逆向きのフローに含まれるパケットのうち、確認応答を伴うプロトコルで送信されたパケットは、振り分けテーブル５２中の条件を用いて格納先の受信キュー４２が決定される。ここで、大量のデータが送信されるフローと逆向きのフローでは、データを伴わない確認応答パケットが大量に送信される可能性が高い。従って、振り分けテーブル５２による振り分けが行われているパケットは、通信装置１０から送信したパケットに対する確認応答パケットである可能性が高い。すなわち、通信装置１０は、確認応答パケットを大量に受信する可能性の高いフローを選択した上で、選択した各フローの処理を、処理負荷の低いプロセッサに割り当てることができる。
【００５２】
さらに、ステップＳ１１、Ｓ１３〜Ｓ１５を参照しながら説明したように、確認応答パケットを大量に受信する可能性が低いフローについては、振り分けテーブル５２への登録を行わず、ハッシュ値を用いて受信キュー４２を選択する。従って、通信装置１０は、通信装置１０が保持する振り分けルールの数を削減しつつ、大量に確認応答パケットを受信することが見込まれるフローについては効率的に処理を行うことができる。
【００５３】
＜第２の実施形態＞
第２の実施形態では、振り分け決定部２３は、大量のデータの送信に伴って送信先から受信することが見込まれる確認応答パケットの処理を、データの送信処理を行ったプロセッサ１０１に割り当てる場合について説明する。確認応答パケットの処理を、データの送信処理を行ったプロセッサと同じプロセッサに割り当てることにより、キャッシュヒット率の向上やプロセッサ間通信のオーバヘッド削減などの処理の効率化や、通信を行うアプリケーション処理の影響を他の処理が受けることの回避が期待できる。なお、第２の実施形態においても、所定量を超えたデータ送信の検出と、振り分けテーブル５２を用いた受信処理は、第１の実施形態と同様に行われる。
【００５４】
検出部２２は、第１の実施形態と同様の処理により、確認応答を伴うプロトコルを用いて、所定量以上のデータ送信が行われたことを特定すると、送信フローの逆向きのフローについて振り分けテーブル５２に登録があるかを判定する。逆向きのフローについての登録が振り分けテーブル５２にない場合、検出部２２は、振り分け決定部２３に振り分けテーブル５２の更新を要求する。すると、振り分け決定部２３は、フローの送信処理を行ったプロセッサを特定する。
【００５５】
図１１は、フローの送信処理を行ったプロセッサを特定する情報の例を説明する図である。図１１に示すテーブルでは、フローの送信元ＩＰアドレス、宛先ＩＰアドレス、送信元ポート番号、宛先ポート番号の組合せに、そのフローで送信されるデータを用いた処理を実行しているプロセッサ１０１の識別子が対応付けられている。なお、実際のオペレーティングシステムの実装においては、このような単純なテーブルではなく、複数のテーブルを組み合わせ参照するのが一般的であるが、本説明では単純化のため、図１１のようなテーブルがあるとしている。
【００５６】
振り分け決定部２３は、図１１に示す情報を用いて、所定量以上のデータが送信されたフローは、いずれのプロセッサ１０１の処理により送信されているかを特定する。例えば、ＩＰアドレス＝１９２．１６８．１．１３の３３４１５番ポートから、ＩＰアドレス＝１０．１１１．３３．１４の２５３番ポートに向けた送信データ量が所定量を超えていることが特定されたとする。図１１に示す情報が通信装置１０に格納されている場合、データ送信処理の対象となっているフローのデータは、ＣＰＵ３での処理により生成されている。そこで、振り分け決定部２３は、キューテーブル５３（図７）を用いて、データ送信処理の対象となっているフロー中のパケットに対する確認応答パケットを、ＣＰＵ３に処理させるために、確認応答パケットの格納先を、キュー３に決定する。
【００５７】
図１２は、振り分けテーブル５２の例を示す図である。図１２は、図１１を参照しながら説明した処理により、振り分け決定部２３が更新した振り分けテーブル５２の例である。図１１に示す振り分けテーブル５２のエントリ番号＝３では、ＩＰアドレス＝１０．１１１．３３．１４の２５３番ポートからＩＰアドレス＝１９２．１６８．１．１３の３３４１５番ポートに向かうフローのパケットがキュー３に格納されることが記録されている。つまり、大量のデータ送信が行われるＩＰアドレス＝１９２．１６８．１．１３の３３４１５番ポートから、ＩＰアドレス＝１０．１１１．３３．１４の２５３番ポートに向けたフローに対する確認応答パケットをキュー３に格納することが登録されている。なお、振り分け決定部２３が振り分けテーブル５２の更新を行う際の処理は、第１の実施形態と同様である。
【００５８】
このように、確認応答パケットの格納先を決定すると、大量の確認応答パケットの受信に起因するプロセッサ１０１の処理負荷を、確認応答パケットで受信が通知されているパケットに関するセッションの処理を行うプロセッサ１０１に振り分けられる。従って、処理の効率化や、通信を行うアプリケーション処理の実行の局所化により、他の処理への影響の回避が期待できる。
【００５９】
＜第３の実施形態＞
第３の実施形態では、所定量を超えたデータ送信の検出方法の変形例について説明する。第３の実施形態では、所定の時間間隔以内でアプリケーション処理部１１から送信が要求された複数の送信要求について、連続的に行われる送信のデータの合計量を観測することにより、大量の送信が発生しているかを判定する。なお、受信パケットの振り分けルールの決定に際して行われる処理と、振り分けテーブル５２を用いた受信処理は、いずれも、第１または第２の実施形態と同様である。
【００６０】
図１３は、第３の実施形態にかかる送信フローテーブル５１＿１１の例を示す図である。図１３に示す送信フローテーブル５１＿１１は、各エントリについて、エントリ番号、送信元ＩＰアドレス、宛先ＩＰアドレス、送信元ポート番号、宛先ポート番号、最終送信時刻、連続送信評価値、登録状況を含む。送信元ＩＰアドレス、宛先ＩＰアドレス、送信元ポート番号、宛先ポート番号、最終送信時刻は、第１の実施形態で図４を参照しながら説明したとおりである。連続送信評価値は、そのフローを通して送信されたデータ量が所定量を超えたかの判定に使用される値である。以下、連続送信評価値は、アプリケーション処理部１１から所定の時間間隔以下で送信が要求されたデータの総量で評価する場合を例とする。登録状況は、そのフローで送信されたパケットに対する確認応答の振り分けに使用されるルールが登録されているかを示す。
【００６１】
例えば、新たに通信装置１０が送信を開始したフローでは、使用されるアドレスとポートの情報が以下のとおりであるとする。
送信元ＩＰアドレス  １９２．１６８．１．１３
宛先ＩＰアドレス    １６０．２．１．２３
送信元ポート番号    ３３０７２
宛先ポート番号      ３０４１
送信対象のデータは、出力処理部２１に出力される。
【００６２】
検出部２２は、出力処理部２１に入力されたデータが送信されるフローについて、送信元ＩＰアドレス、宛先ＩＰアドレス、送信元ポート番号、宛先ポート番号を特定し、これらの組み合わせが送信フローテーブル５１に登録されているかを判定する。送信元ＩＰアドレス、宛先ＩＰアドレス、送信元ポート番号、宛先ポート番号の組み合わせを含むエントリが送信フローテーブル５１に含まれていない場合、検出部２２は、新たなエントリを生成する。本実施例では、一回の送信処理だけで大量の送信を判定しないため、振り分けルールを作らないケースでもエントリを生成する。図４に示す送信フローテーブル５１＿１１では、新たに送信が開始されたフローの情報がエントリ番号＝３として追加されている。新たに追加されたエントリについて、検出部２２は、連続送信評価値を今回の送信処理の対象となっているデータ量に設定する。また、検出部２２は、今回の送信処理の対象となっているデータ量が所定値を超えていない場合、登録状況には未登録であることを示す情報を設定する。以下の例では、ＩＰアドレス＝１９２．１６８．１．１３の３３０７２番ポートからＩＰアドレス＝１６０．２．１．２３の３０４１番ポートに向かうフローでは、１３０８７００バイトのデータが送信されたとする。
【００６３】
その後も、ＩＰアドレス＝１９２．１６８．１．１３の３３０７２番ポートからＩＰアドレス＝１６０．２．１．２３の３０４１番ポートに向かうフローを介したデータの送信が継続されたとする。検出部２２は、送信フローテーブル５１に既にエントリがあるフローを介した送信処理が行われる際に、処理対象のフローでのデータの送信間隔を閾値と比較する。つまり、検出部２２は、処理対象となっているデータの送信フローでの前回の送信時刻から、新たに送信対象となるデータの送信時刻までの時間が閾値Ｔｈｔ未満であるかを判定する。
【００６４】
ここで、閾値Ｔｈｔは、例えば、１パケットごとに送信依頼が行われたとしても、送信データに対する確認応答パケットの処理に影響を与える可能性が発生する時間間隔である。閾値Ｔｈｔは、通信装置１０が用いているプロセッサ１０１の性能などにより変更され得る。
【００６５】
検出部２２は、処理対象となっているデータの送信フローでの前回の送信時刻から、新たに送信対象となるデータの送信時刻までの時間が閾値Ｔｈｔ未満である場合、今回の送信処理により、確認応答パケットの処理負担が累積的に増加すると判定する。そこで、検出部２２は、連続送信評価値に、今回の送信要求によって送信する送信データ量を加算する。
【００６６】
図１４は、第３の実施形態にかかる送信フローテーブル５１＿１２の例を示す図である。図１４は、１１時３１分２１．４０４８９０秒に、ＩＰアドレス＝１９２．１６８．１．１３の３３０７２番ポートからＩＰアドレス＝１６０．２．１．２３の３０４１番ポートに送信が要求された場合の例である。この例では、新たに送信が要求されたデータ量は２００００００バイトである。また、閾値Ｔｈｔは５マイクロ秒であるとする。検出部２２は、送信要求が行われたことを認識すると、前回の送信要求から今回の送信要求までの経過時間を求める。ここでは、前回の送信要求から今回の送信要求までの経過時間は４マイクロ秒であるのに対し、閾値Ｔｈｔは５マイクロ秒であるため、閾値Ｔｈｔ未満の間隔で２つの送信要求が発生している。そこで、検出部２２は、最終送信時刻を今回の送信要求の時刻に変更する。さらに、検出部２２は、連続送信評価値を、前回の送信要求を処理した際に得られた値（１３０８７００バイト）と、現在送信が要求されているデータ量（２００００００バイト）の合計値に更新する。このため、送信フローテーブル５１＿１１は送信フローテーブル５１＿１２に更新される。
【００６７】
送信フローテーブル５１の更新が終わると、検出部２２は、連続送信評価値を、所定量（閾値Ｔｈ）と比較する。検出部２２は、連続送信評価値が閾値Ｔｈ未満の場合、大量のデータが送信されていないと判定する。大量のデータが送信されていないと判定した場合、処理対象のフローに対する確認応答パケットの振り分けルールを登録しないため、処理対象のフローに関する処理は終了する。
【００６８】
一方、連続送信評価値が閾値Ｔｈ以上の場合について説明する。例えば、第３の実施形態では、閾値Ｔｈは３００００００バイトであるとする。この場合、図１４のエントリ番号＝３のエントリでは、連続送信評価値が閾値Ｔｈを超えている。そこで、検出部２２は、大量のデータの送信が検出されたフロー中の送信パケットに対する確認応答パケットの処理に用いる条件が振り分けテーブル５２に登録済みであるかを判定するために、送信フローテーブル５１＿１２の登録状況を参照する。送信フローテーブル５１＿１２（図１４）において、エントリ番号＝３のエントリでは、登録状況は未登録を表わす値である。そこで、検出部２２は、大量のデータの送信を検出したことと、大量のデータの送信が検出されたフローの情報を振り分け決定部２３に通知する。すると、受信パケットの振り分けルールの決定は、第１の実施形態と同様に行われる。
【００６９】
振り分け決定部２３は、検出部２２から通知されたフローに関連した振り分けテーブル５２の更新が終わると、検出部２２に、振り分けテーブル５２への登録が終了したことを通知する。検出部２２は、振り分けテーブル５２の登録の終了の通知を受けたエントリに対して、登録状況を登録が行われていることを示す値に変更する。
【００７０】
図１５は、第３の実施形態にかかる送信フローテーブル５１＿１３の例を示す図である。例えば、検出部２２は、ＩＰアドレス＝１６０．２．１．２３の３０４１番ポートからＩＰアドレス＝１９２．１６８．１．１３の３３０７２番ポート宛の確認応答パケットの格納先が決定されると、エントリ番号＝３のエントリの登録状況を更新する。このため、送信フローテーブル５１＿１２は、検出部２２により、送信フローテーブル５１＿１３に更新される。
【００７１】
なお、検出部２２は、大量のデータの送信を検出しても、例えば、エントリ番号＝０のエントリのように、既に振り分けテーブル５２への登録済みのフローに対する大量送信の検出である場合は、振り分け決定部２３への通知は行わない。
【００７２】
図１６は、第３の実施形態にかかる通信装置の処理の例を説明するフローチャートである。検出部２２は、出力処理部２１にデータが入力されたフローでの通信に使用されているトランスポート層のプロトコルがＴＣＰであるかを判定する（ステップＳ３１）。通信装置１０がＴＣＰを用いてパケットを送信する場合、検出部２２は、フローの送信元と宛先についての情報を用いて、処理対象のフローに対応するエントリが送信フローテーブル５１にあるかを判定する（ステップＳ３１でＹｅｓ、ステップＳ３２）。処理対象のフローに対応するエントリが送信フローテーブル５１にない場合、検出部２２は、処理対象のフローに対応するエントリを送信フローテーブル５１に作成する（ステップＳ３２でＮｏ、ステップＳ３４）。さらに、検出部２２は、連続送信評価値を今回の送信データ量に設定する（ステップＳ３５）。
【００７３】
処理対象のフローに対応するエントリが送信フローテーブル５１にある場合、検出部２２は、処理対象のフローについて、前回の送信からの経過時間は、閾値Ｔｈｔ以内であるかを判定する（ステップＳ３２でＹｅｓ、ステップＳ３３）。前回の送信からの経過時間は、閾値Ｔｈｔ以内である場合、検出部２２は、連続送信評価値に、今回の送信データ量を加算する（ステップＳ３３でＹｅｓ、ステップＳ３６）。前回の送信からの経過時間は、閾値Ｔｈｔを超えている場合、検出部２２は、連続送信評価値を今回の送信データ量に設定する（ステップＳ３３でＮｏ、ステップＳ３５）。すなわち、検出部２２は、データの送信間隔が閾値Ｔｈｔを超えると、連続送信評価値をリセットしているといえる。
【００７４】
ステップＳ３５またはＳ３６の処理が終わると、検出部２２は、処理対象のフローについて、最終送信時刻を現在の時刻に更新する（ステップＳ３７）。次に、検出部２２は、処理対象の送信フローに対する確認応答パケット（Ａｃｋ）の格納先が登録済みであるかを判定する（ステップＳ３８）。確認応答パケットの格納先が登録済みである場合、検出部２２は処理を終了する（ステップＳ３８でＹｅｓ）。
【００７５】
確認応答パケット（Ａｃｋ）の格納先が未登録である場合、検出部２２は、連続送信評価値は、所定の閾値Ｔｈ以上であるかを判定する（ステップＳ３８でＮｏ、ステップＳ３９）。連続送信評価値が閾値Ｔｈ以上である場合、振り分け決定部２３は、送信パケットに対する確認応答パケットを処理するプロセッサ１０１を決定し、振り分けテーブル５２を更新する（ステップＳ３９でＹｅｓ、ステップＳ４０、Ｓ４１）。一方、連続送信評価値が閾値Ｔｈ未満である場合、検出部２２は処理を終了する（ステップＳ３９でＮｏ）。なお、使用されているトランスポート層のプロトコルがＴＣＰでない場合、検出部２２は処理を終了する（ステップＳ２１でＮｏ）。
【００７６】
第３の実施形態では、連続送信評価値を、送信間隔が閾値Ｔｈｔ以内のデータの合計値としている。従って、第３の実施形態では、通信装置１０がＴＳＯやＧＳＯなどの送信処理負荷の軽減を行わない場合でも、連続的にパケットが送信されることにより送信データの量が所定の量を超えると、確認応答パケットに対する振り分けルールが設定される。例えば、ＴＳＯやＧＳＯに対応していない通信装置１０において、１パケットずつ送信要求が行われ、１パケットに１４６０バイトのデータが含まれているとする。この場合であっても、送信間隔が閾値Ｔｈｔ未満で２０５５個のパケットが送信されれば、連続送信評価値は３０００３００バイトになる。このため、閾値Ｔｈが３００００００バイトであれば、２０５５個のパケットの連続送信が行われた場合に、確認応答パケットの格納先が決定される。
【００７７】
ところで、パケットごとに送信要求が行われる場合、確認応答パケットを格納する受信キュー４２を決定する前に、一部の送信パケットに対する確認応答パケットを通信装置１０が受信する可能性もある。すると、受信パケットを格納する受信キュー４２を決定する前に確認応答パケットを処理したプロセッサ１０１とは異なるプロセッサ１０１がその後の確認応答パケットを処理する可能性もある。ここで、確認応答パケットを処理するプロセッサ１０１の負荷の違いによっては、パケットの受信処理の順序がパケットの送信順序と異なる可能性もある。しかし、第３の実施形態においても、第１および第２の実施形態と同様に、データを送信しているフローの確認応答パケットにデータが含まれる可能性は低く、処理順序が逆転しても、再送処理や通信速度の低下などの原因にはなりにくい。
【００７８】
なお、第３の実施形態でも、通信装置１０がＴＳＯやＧＳＯに対応した処理を行う場合についても、同様に、確認応答パケットの格納先となる受信キュー４２や、確認応答パケットを処理するプロセッサ１０１を制御することができる。
【００７９】
＜第４の実施形態＞
第３の実施形態で説明したように、連続送信評価値を用いると、複数の送信要求の対象となった送信データ量を用いて、受信パケットを処理するプロセッサ１０１や受信キュー４２を決定することができる。ここで、連続送信評価値の計算方法は、第３の実施形態で説明した方法に限られない。第４の実施形態では、一例として、リーキーバケットアルゴリズムを用いて連続送信評価値を計算する場合の処理を説明する。
【００８０】
図１７は、第４の実施形態にかかる通信装置の処理の例を説明するフローチャートである。検出部２２は、出力処理部２１にデータが入力されたフローでの通信に使用されているトランスポート層のプロトコルがＴＣＰであるかを判定する（ステップＳ５１）。通信装置１０がＴＣＰを用いてパケットを送信する場合、検出部２２は、フローの送信元と宛先についての情報を用いて、処理対象のフローに対応するエントリが送信フローテーブル５１にあるかを判定する（ステップＳ５１でＹｅｓ、ステップＳ５２）。
【００８１】
以下、処理対象のフローに対応するエントリが送信フローテーブル５１にある場合について説明する（ステップＳ５２でＹｅｓ）。検出部２２は、処理対象のフローについての連続送信評価値を、今回の送信要求での送信データ量を用いて次式に従った計算を行うことにより更新する（ステップＳ５３）。
Ｖ＝ｍａｘ（Ｄｓｕｍ−Ｔｉｎｔｖ×Ｃ，０）＋Ｌｅｎ
ここで、Ｖは連続送信評価値の計算結果、Ｄｓｕｍは前回の送信処理の際に得られた連続送信評価値の計算値である。Ｔｉｎｔｖは、前回の送信処理から今回の送信処理までの経過時間である。Ｃは、通信装置１０からの送信データのうち、確認応答パケットを受信していないデータの単位時間当たりの減少量である。Ｃの値は、通信装置１０が用いているプロセッサ１０１の性能、通信装置１０と送信データの宛先との間のＲＴＴ（Round Trip Time）、通信装置１０と送信データの宛先と間の回線での通信速度などを用いて決定される。Ｌｅｎは、今回の送信処理で送信要求の対象となっているデータの量である。なお、ｍａｘ関数は、括弧の中に記載されている複数の値のうちの最大値を指すものとする。このため、Ｄｓｕｍ−Ｔｉｎｔｖ×Ｃの計算値が正であれば、ｍａｘ（Ｄｓｕｍ−Ｔｉｎｔｖ×Ｃ，０）＝Ｄｓｕｍ−Ｔｉｎｔｖ×Ｃとなる。一方、Ｄｓｕｍ−Ｔｉｎｔｖ×Ｃが負の場合、ｍａｘ（Ｄｓｕｍ−Ｔｉｎｔｖ×Ｃ，０）＝０となる。
【００８２】
ステップＳ５４〜Ｓ６０の処理は、図１６を参照しながら説明したステップＳ３４、Ｓ３５、および、ステップＳ３７〜Ｓ４１で行われている処理と同様である。
【００８３】
第４の実施形態では、ステップＳ５３の計算により、通信装置１０からの送信対象となるデータ量の増加と、通信装置１０に確認応答パケットが受信されたデータの増加の両方に基づいて、連続送信評価値が決定される。連続送信評価値は確認応答パケットを処理するプロセッサ１０１を決定するかの指標であるので、第４の実施形態では、確認応答パケットを未受信の送信データの量に応じて、確認応答パケットを処理するプロセッサ１０１を決定しているともいえる。
【００８４】
第４の実施形態のように、２回の送信処理の間の時間の長さを用いて連続送信評価値を用いることにより、確認応答パケットによる受信処理の負荷を精度よく見積もることができる。このため、ＲＴＴが大きな通信が行われている場合に第４の実施形態を適用すると、通信装置１０は、受信処理の負荷を精度良く特定することができる。
【００８５】
＜第５の実施形態＞
図１８は、仮想マシンを運用している通信装置９０の構成の例を示す図である。第５の実施形態では、仮想マシン（virtual machine、ＶＭ）８５が動作している通信装置９０での動作を、処理負荷の低いプロセッサ１０１に、確認応答パケットの処理を割り当てる場合を例として説明する。
【００８６】
通信装置９０は、インタフェース部１６、Ｈｏｓｔカーネル６５、記憶部７０、仮想マシン８５を備える。Ｈｏｓｔカーネル６５は、送受信部２５、振り分け制御部２６、仮想化支援部６０、仮想スイッチ６４を有する。送受信部２５は、出力処理部２１、振り分け決定部２３、受信処理部２４（２４ａ〜２４ｄ）を有する。仮想化支援部６０は、仮想通信処理部６１と仮想通信処理部６３を有し、仮想通信処理部６３は検出部６２を有する。仮想マシン８５は、送受信部８０、アプリケーション処理部１１、ソケット処理部１２、プロトコル処理部１３、プロトコル処理部１４を有する。送受信部８０は、受信処理部８１と送信処理部８２を有する。記憶部７０は、送信フローテーブル７１、振り分けテーブル５２、キューテーブル５３、ハッシュ値テーブル５４、ＶＭアドレステーブル７２を記憶する。さらに、オプションとして、記憶部７０は、プロセッサテーブル７３を記憶しても良い。アプリケーション処理部１１、ソケット処理部１２、プロトコル処理部１３、プロトコル処理部１４、インタフェース部１６、出力処理部２１、受信処理部２４で行われる処理は、第１、第３、第４の実施形態のいずれかと同様である。また、振り分けテーブル５２、キューテーブル５３、ハッシュ値テーブル５４も、第１、第３、第４の実施形態のいずれかと同様である。
【００８７】
送信処理部８２は、プロトコル処理部１３から入力されたデータを仮想通信処理部６３に出力する。検出部６２は、仮想通信処理部６３に入力されたデータ量に基づいて、所定量以上のデータの送信が行われているかを判定する。検出部６２によって行われる判定方法は、第１、第３、第４の実施形態で検出部２２が行う検出処理のいずれと同様でも良い。検出部６２は、大量のデータの送信が行われたかを連続送信評価値を用いて判定する場合、適宜、送信フローテーブル７１を参照する。
【００８８】
なお、通信装置９０も、図３に示すハードウェアで実現される。プロセッサ１０１は、仮想マシン８５、Ｈｏｓｔカーネル６５の処理を実行する。メモリ１０２は記憶部７０、送信キュー３２（３２ａ〜３２ｄ）、受信キュー４２（４２ａ〜４２ｄ）として動作する。送信スケジューラ３１と振り分け制御部４１は、プロセッサ１０１とネットワーク接続装置１０８によって実現される。
【００８９】
図１９は、送信フローテーブル７１の例を示す図である。送信フローテーブル７１は、各エントリについて、エントリ番号、送信元ＩＰアドレス、宛先ＩＰアドレス、送信元ポート番号、宛先ポート番号、ＶＭ番号、最終送信時刻、連続送信評価値、登録状況を含む。エントリ番号、送信元ＩＰアドレス、宛先ＩＰアドレス、送信元ポート番号、宛先ポート番号、最終送信時刻、連続送信評価値、登録状況は、第３および第４の実施形態と同様である。ＶＭ番号は、エントリで記録しているフローの送信処理を行っている仮想マシン８５を識別する識別情報である。検出部６２は、送信フローテーブル７１に登録されていない送信フローを検出すると、検出したフローの情報を送信フローテーブル７１に登録するが、その際に、ＶＭアドレステーブル７２を用いて、フローの処理を行っている仮想マシン８５を特定する。
【００９０】
図２０は、ＶＭアドレステーブル７２の例を示す図である。ＶＭアドレステーブル７２は、仮想マシン８５での通信に使用されているＩＰアドレスを、仮想マシン８５の識別情報に対応付けている。例えば、ＶＭ番号＝０の仮想マシン（ＶＭ０）は、１０．２２．４４．５５というＩＰアドレスを用いている。同様に、ＶＭ番号＝１の仮想マシン（ＶＭ１）は、１９２．１６８．１．１３を使用し、ＶＭ番号＝２の仮想マシン（ＶＭ２）は、１０．２２．４４．１２を使用している。さらに、ＶＭ番号＝３の仮想マシン（ＶＭ３）は、１１．２２．４４．５というＩＰアドレスを使用している。検出部６２は、検出したフローの送信元アドレスをキーとして、ＶＭアドレステーブル７２を検索することにより、送信フローを処理している仮想マシンを特定する。
【００９１】
検出部６２は、送信フローテーブル７１を用いて、大量のデータを送信したフローを特定すると共に、大量のデータを送信したフローを検出したことを、そのフローの情報と共に振り分け制御部２６に通知する。振り分け制御部２６は、検出部６２から通知されたフローに対する振り分けルールが振り分けテーブル５２に登録されているかを、送信フローテーブル７１を用いて特定する。検出部６２から通知されたフローに対する振り分けルールが振り分けテーブル５２に登録されていない場合、振り分け制御部２６は、大量送信が検出されたフローの情報を振り分け決定部２３に通知する。振り分け決定部２３で行われる処理は、第１、第３、または、第４の実施形態と同様である。
【００９２】
一方、送信処理部８２から仮想通信処理部６３に出力された送信データは、仮想スイッチ６４を介して出力処理部２１に出力される。出力処理部２１は、入力されたデータを送信処理部３０に出力する。
【００９３】
次に、通信装置１０がパケットを受信するときの処理について説明する。受信パケットに対してインタフェース部１６が行う処理は、第１〜第４と同様である。このため、受信キュー４２ａ〜４２ｄに格納されたパケットは、予め、そのキューに対応付けられた受信処理部２４に入力される。受信処理部２４は、入力されたパケットを、仮想スイッチ６４を介して仮想通信処理部６１に出力する。なお、複数の仮想マシン８５が通信装置９０で動作している場合、仮想スイッチ６４を介して、受信パケットの宛先のアドレスを用いている仮想マシン８５に受信パケットが出力される。仮想通信処理部６１は、入力されたパケットを受信処理部８１に出力する。受信処理部８１は、入力されたパケットの受信処理を行って、プロトコル処理部１４に出力する。
【００９４】
このように、第５の実施形態を用いると、仮想マシンを用いている通信装置９０においても、第１〜第４の実施形態と同様に、大量に受信することが想定される確認応答パケットの処理を行うプロセッサ１０１を決定することができる。
【００９５】
＜その他＞
なお、実施形態は上記に限られるものではなく、様々に変形可能である。以下にその例をいくつか述べる。
【００９６】
仮想マシンが動作している通信装置９０においても、第２の実施形態と同様に、送信データを生成したプロセッサ１０１に確認応答パケットの処理を割り当てることもできる。
【００９７】
図２１は、プロセッサテーブル７３の例を示す図である。通信装置９０において、第２の実施形態と同様に、確認応答パケットの処理を、データの送信処理を行ったプロセッサ１０１に割り当てる場合、振り分け決定部２３は、プロセッサテーブル７３を使用する。プロセッサテーブル７３では、仮想マシンの識別情報に対応付けて、その仮想マシンを実行しているプロセッサ１０１を記録している。例えば、図２１の例では、ＶＭ０はＣＰＵ３によって実行されており、ＶＭ２はＣＰＵ７によって実行されている。振り分け決定部２３は、振り分け制御部２６から通知されたフローについて、送信フローテーブル７１を参照して、そのフローを処理している仮想マシンを特定する。次に、振り分け決定部２３は、フローを処理している仮想マシンを実行しているプロセッサを、プロセッサテーブル７３から特定する。振り分け決定部２３は、送信データを生成した仮想マシン８５が動作しているプロセッサ１０１に対して、確認応答パケットの処理を割り当てる。振り分け決定部２３は、割り当てたプロセッサ１０１に対応付けられた受信キュー４２を、キューテーブル５３を用いて特定し、第２の実施形態と同様に、振り分けテーブル５２を更新する。
【００９８】
さらに、いずれの実施形態で使用されるテーブルに含まれている情報要素も、実装に応じて変更され得る。また、以上の説明で、１つのテーブルとして説明したテーブルも、実装に応じて、複数のテーブルに分割されていていても良い。
【００９９】
いずれの実施形態においても、通信装置は、所定期間（Ｔｈｔ２）以上、送信がないフローとは逆向きのフローに関するエントリを振り分けテーブル５２から削除しても良い。例えば、検出部２２は、送信フローテーブル５１に含まれているフローのうち、Ｔｈｔ２以上の期間、送信が無いものを、振り分け決定部２３に通知できる。振り分け決定部２３は、検出部２２から通知されたフローと逆向きのフローについてのエントリを、振り分けテーブル５２から削除する。また、検出部２２も、Ｔｈｔ２以上の期間にわたって送信が無いことを振り分け決定部２３に通知したフローの情報を、送信フローテーブル５１から削除する。このように変形すると、振り分けテーブル５２に登録できるエントリ数が限られている場合でも、通信装置１０は、効果的に振り分け処理ができる。また、通信装置９０においても、検出部６２は、送信フローテーブル７１中のフローのうちで、Ｔｈｔ２以上の期間にわたって送信が無いフローを、振り分け制御部２６を介して、振り分け決定部２３に通知できる。また、検出部６２は、送信フローテーブル７１から、Ｔｈｔ２以上の期間、送信が無いフローのエントリを削除できる。従って、仮想マシンが稼動している通信装置９０においても、振り分けテーブル５２の運用を効率化できる。
【０１００】
ＴＣＰを用いた通信の場合、一定期間送信がなかった場合、通信の再開をスロースタートから開始する。従って、ＴＣＰを用いた通信を行っている装置間では、所定期間以上にわたって通信が行われないと、大量のデータの送受信はすぐには行われないので、このような処理により、効率的に振り分け処理が行われる。
【０１０１】
上述の第１〜第５の実施形態を含む実施形態に関し、さらに以下の付記を開示する。
（付記１）
ネットワーク中の装置からの受信パケットを格納する複数の受信キューと、
前記複数の受信キューの少なくとも１つが受信処理の対象に設定されたプロセッサを含む複数のプロセッサと、
前記ネットワーク中の装置に宛てた送信パケットを送信する送信処理部
を備え、
送信データ量が所定値を超えた通信先宛ての送信パケットに対する確認応答の受信処理を行うプロセッサを、前記複数のプロセッサから選択すると共に、選択したプロセッサによって受信処理が行われる受信キューを、前記確認応答の格納先に設定する処理を、前記複数のプロセッサのいずれかが行う
ことを特徴とするパケット通信装置。
（付記２）
前記確認応答の受信処理を行うプロセッサを選択するプロセッサは、前記送信処理部に対する１回の送信要求で送信が要求されたデータ量が前記所定値を超えると、前記通信先に宛てた送信データ量が前記所定値を超えたと判定する
ことを特徴とする付記１に記載のパケット通信装置。
（付記３）
前記確認応答の受信処理を行うプロセッサを選択するプロセッサは、
前記通信先宛の前回の送信要求が行われた時刻から前記通信先宛の新たな送信要求が行われた時刻までの期間の長さが閾値未満の場合、前記新たな送信要求を行う前の送信データ量に前記新たな送信要求の対象となったデータ量を加えた値を、前記新たな送信要求後での送信データ量とし、
前記期間の長さが前記閾値を超えると、前記新たな送信要求の対象となったデータ量を、前記新たな送信要求後での送信データ量とする
ことを特徴とする付記１に記載のパケット通信装置。
（付記４）
前記確認応答の受信処理を行うプロセッサを選択するプロセッサは、
前記通信先宛の前回の送信要求が行われた時刻から、前記通信先宛の新たな送信要求が行われた時刻までの期間を求め、
前記通信先への送信要求の対象となったデータのうちで前記確認応答を受信していないデータ量の前記期間での減少量と、前記新たな送信処理で送信が要求されたデータ量の関数として、前記送信データ量を求め、
前記送信データ量が前記所定値を超えると、前記確認応答の受信処理を行うプロセッサを選択する
ことを特徴とする付記１に記載のパケット通信装置。
（付記５）
前記複数のプロセッサのうち、処理負荷が相対的に低いプロセッサほど、優先的に、前記確認応答の受信処理を行うプロセッサに選択される
ことを特徴とする付記１〜４のいずれか１項に記載のパケット通信装置。
（付記６）
前記通信先に宛てた送信データを生成したプロセッサほど、優先的に、前記確認応答の受信処理を行うプロセッサに選択される
ことを特徴とする付記１〜４のいずれか１項に記載のパケット通信装置。
（付記７）
ネットワーク中の装置からの受信パケットを格納する複数の受信キューと、前記複数の受信キューの少なくとも１つが受信処理の対象に設定されたプロセッサを含む複数のプロセッサを備えるパケット通信装置に、
送信データ量が所定値を超えた通信先宛ての送信パケットに対する確認応答の受信処理を行うプロセッサを、前記複数のプロセッサから選択し、
選択したプロセッサによって受信処理が行われる受信キューを、前記確認応答の格納先に設定する
処理を行わせることを特徴とするパケット受信処理方法。
（付記８）
前記パケット通信装置は、前記通信先に対する１回の送信処理で送信するデータ量が前記所定値を超えると、前記通信先に宛てた送信データ量が前記所定値を超えたと判定する
ことを特徴とする付記７に記載のパケット受信処理方法。
（付記９）
前記パケット通信装置は、
前記通信先宛の前回の送信処理が行われた時刻から前記通信先宛の新たな送信処理を行う時刻までの期間の長さが閾値未満の場合、前記新たな送信処理を行う前の送信データ量に前記新たな送信処理の対象となったデータ量を加えた値を、前記新たな送信処理の際の送信データ量とし、
前記期間の長さが前記閾値を超えると、前記新たな送信処理の対象となったデータ量を、前記新たな送信処理の際の送信データ量とする
ことを特徴とする付記７に記載のパケット受信処理方法。
（付記１０）
前記パケット通信装置は、
前記通信先宛の前回の送信処理が行われた時刻から、前記通信先宛の新たな送信処理を行う時刻までの期間を求め、
前記通信先への送信処理の対象となったデータのうちで前記確認応答を受信していないデータ量の前記期間での減少量と、前記新たな送信処理の対象となったデータの量の関数として、前記送信データ量を求め、
前記送信データ量が前記所定値を超えると、前記確認応答の受信処理を行うプロセッサを選択する
ことを特徴とする付記７に記載のパケット受信処理方法。
（付記１１）
前記複数のプロセッサのうち、処理負荷が相対的に低いプロセッサほど、優先的に、前記確認応答の受信処理を行うプロセッサに選択される
ことを特徴とする付記７〜１０のいずれか１項に記載のパケット受信処理方法。
（付記１２）
前記通信先に宛てた送信データを生成したプロセッサほど、優先的に、前記確認応答の受信処理を行うプロセッサに選択される
ことを特徴とする付記７〜１０のいずれか１項に記載のパケット受信処理方法。
【符号の説明】
【０１０２】
１０、９０  通信装置
１１  アプリケーション処理部
１２  ソケット処理部
１３、１４  プロトコル処理部
１５、６５  Ｈｏｓｔカーネル
１６  インタフェース部
２０、２５、８０  送受信部
２１  出力処理部
２２、６２  検出部
２３  振り分け決定部
２４、８１  受信処理部
３０、８２  送信処理部
３１  送信スケジューラ
３２  送信キュー
４１  振り分け制御部
４２  受信キュー
５０、７０  記憶部
５１、７１  送信フローテーブル
５２  振り分けテーブル
５３  キューテーブル
５４  ハッシュ値テーブル
６０  仮想化支援部
６１、６３  仮想通信処理部
６４  仮想スイッチ
７２  ＶＭアドレステーブル
７３  プロセッサテーブル
１０１  プロセッサ
１０２  メモリ
１０３  バスコントローラ
１０４  ストレージ装置
１０５  ストレージＩ／Ｏ
１０６  ディスプレイＩ／Ｏ
１０７  Ｉ／Ｏ
１０８  ネットワーク接続装置
１０９  タイマ
１１０  入力装置
１１１  光学ディスクドライブ
１１２  可搬記憶媒体
【図１】
2016149698.tif 000003
【図２】
2016149698.tif 000004
【図３】
2016149698.tif 000005
【図４】
2016149698.tif 000006
【図５】
2016149698.tif 000007
【図６】
2016149698.tif 000008
【図７】
2016149698.tif 000009
【図８】
2016149698.tif 000010
【図９】
2016149698.tif 000011
【図１０】
2016149698.tif 000012
【図１１】
2016149698.tif 000013
【図１２】
2016149698.tif 000014
【図１３】
2016149698.tif 000015
【図１４】
2016149698.tif 000016
【図１５】
2016149698.tif 000017
【図１６】
2016149698.tif 000018
【図１７】
2016149698.tif 000019
【図１８】
2016149698.tif 000020
【図１９】
2016149698.tif 000021
【図２０】
2016149698.tif 000022
【図２１】
2016149698.tif 000023