(57)【要約】  あるセッションに関するカーネル処理とプロキシ処理とを同一のＣＰＵコア内で処理することが可能な並列化されたプロキシ装置が提供される。複数のＣＰＵコアを備えるマルチコアＣＰＵと、複数のＣＰＵコアに対応する複数のキューを具備する拡張リッスンソケットと、複数のＣＰＵコアに対応する複数のカーネルスレッド及び複数のプロキシスレッドとを備える。各カーネルスレッドは、各カーネルスレッドの動作するＣＰＵコアに割り当てられたクライアント側コネクションの確立要求パケットの受信処理を行って、確立待ちソケットを各カーネルスレッドの動作するＣＰＵコアに対応したキューに登録する。各プロキシスレッドは、各プロキシスレッドの動作するＣＰＵコアに対応するキューを参照して、確立待ちソケットが登録されている場合に第１コネクションを確立する。
2011096307.tif 000002
【特許請求の範囲】
【請求項１】
複数のＣＰＵコアを備えるマルチコアＣＰＵと、
前記複数のＣＰＵコアに対してそれぞれ設けられた複数のキューを具備する拡張リッスンソケットとを具備し、
前記複数のＣＰＵコアの各々の上でカーネルスレッドとプロキシスレッドが動作し、
前記カーネルスレッドは、前記複数のＣＰＵコアのうちの対応するものに割り当てられた、クライアントとの第１コネクションの確立要求パケットの受信処理を行い、前記第１コネクションの情報を含んだ確立待ちソケットを、前記複数のキューのうちの対応するものに登録し、
前記プロキシスレッドは、前記対応するキューを参照し、前記対応するキューに前記確立待ちソケットが登録されている場合に、前記確立待ちソケットに基づいて前記第１コネクションを確立する
プロキシ装置。
【請求項２】
請求項１に記載のプロキシ装置であって、
前記クライアントと接続され、前記クライアントからクライアント側パケットを受信すると、前記クライアント側パケットのヘッダ情報に基づいて、前記複数のＣＰＵコアのうちから、前記クライアント側パケットの処理を行うものを、第１指定ＣＰＵコアとして決定する第１ＮＩＣ（Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ  Ｃａｒｄ）と、
サーバと接続されて、前記サーバからサーバ側パケットを受信すると、前記サーバ側パケットのヘッダ情報に基づいて前記複数のＣＰＵコアのうちから、前記サーバ側パケットの処理を行うものとして、第２指定ＣＰＵコアを決定する第２ＮＩＣと、
前記第１ＮＩＣが前記第１指定ＣＰＵコアを決定するときの前記クライアント側パケットのヘッダ情報に対するマスクである第１マスク設定を保持する第１マスク保持部と、
前記第２ＮＩＣが前記第２指定ＣＰＵコアを決定するときの前記サーバ側パケットのヘッダ情報に対するマスクである第２マスク設定を保持する第２マスク保持部と
を更に備え、
前記第１マスク設定と前記第２マスク設定は、前記第１ＮＩＣと前記第２ＮＩＣがそれぞれ同一の情報に基づいて前記第１、第２指定ＣＰＵコアを決定するように設定される
プロキシ装置。
【請求項３】
請求項２に記載のプロキシ装置であって、
前記第１マスク設定は、前記クライアント側パケットのヘッダ情報において、送信元ポート番号をマスクするように設定され、
前記第２マスク設定は、前記サーバ側パケットのヘッダ情報において、送信先ポート番号をマスクするように設定される
プロキシ装置。
【請求項４】
請求項１に記載のプロキシ装置であって、
前記プロキシスレッドは、前記第１コネクションと対となる前記サーバとの第２コネクションを確立するときに、前記第１コネクションにおける送信元ポート番号を前記第２コネクションにおける送信元ポート番号に設定する
プロキシ装置。
【請求項５】
複数のＣＰＵコアを備えるマルチコアＣＰＵと、前記複数のＣＰＵコアの各々の上でカーネルスレッドとプロキシスレッドが動作し、
前記複数のＣＰＵコアに対してそれぞれ設けられた複数のキューを具備する拡張リッスンソケットと、
を備えるプロキシ装置において、
前記カーネルスレッドにより、前記複数のＣＰＵコアのうちの対応するものに割り当てられた、クライアントとの第１コネクションの確立要求パケットの受信処理を行うステップと、
前記カーネルスレッドにより、前記第１コネクションの情報を含んだ確立待ちソケットを、前記複数のキューのうちの対応するものに登録するステップと、
前記プロキシスレッドにより前記対応するキューを参照するステップと、
前記対応するキューに前記確立待ちソケットが登録されている場合に、前記確立待ちソケットに基づいて前記第１コネクションを確立するステップと
を備える
プロキシ装置の動作方法。
【請求項６】
請求項５に記載のプロキシ装置の動作方法であって、
前記クライアントと接続された第１ＮＩＣ（Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ  Ｃａｒｄ）により、前記クライアントからクライアント側パケットを受信するステップと、
前記第１ＮＩＣにより、前記クライアント側パケットのヘッダ情報に対して第１マスクを設定するステップと、
前記第１ＮＩＣにより、前記クライアント側パケットのマスクされたヘッダ情報に基づいて、前記複数のＣＰＵコアのうちから、前記クライアント側パケットの処理を行うものを、第１指定ＣＰＵコアとして決定するステップと、
サーバと接続された第２ＮＩＣにより、前記サーバからサーバ側パケットを受信するステップと、
前記第２ＮＩＣにより前記サーバ側パケットのヘッダ情報に対して第２マスクを設定するステップと、
前記第２ＮＩＣにより、前記サーバ側パケットのマスクされたヘッダ情報に基づいて前記複数のＣＰＵコアのうちから、前記サーバ側パケットの処理を行うものとして、第２指定ＣＰＵコアを決定するステップと、
を更に備える
プロキシ装置の動作方法。
【請求項７】
請求項６に記載のプロキシ装置の動作方法であって、
前記第１マスクを設定するステップは、
前記クライアント側パケットのヘッダ情報の送信元ポート番号をマスクするように前記第１マスクを設定するステップを備え、
前記第２マスクを設定するステップは、
前記サーバ側パケットのヘッダ情報の送信先ポート番号をマスクするように前記第２マスクを設定するステップを備える
プロキシ装置の動作方法。
【請求項８】
請求項５に記載のプロキシ装置の動作方法であって、
前記プロキシスレッドは、前記第１コネクションと対となる前記サーバとの第２コネクションを確立するときに、前記第１コネクションにおける送信元ポート番号を前記第２コネクションにおける送信元ポート番号に設定するステップ
を更に備える
プロキシ装置の動作方法。
【請求項９】
請求項５から請求項８までのいずれかに記載のプロキシ装置の動作方法を実現するための、計算機実行可能なプログラムコードが記録された計算機読み取り可能な固定的な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチコアＣＰＵを備え、並列処理を行うプロキシ装置に関する。
【背景技術】
【０００２】
ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）における動作周波数の向上が、限界に近づいている。そのため、ＣＰＵの発展は、動作周波数の向上から、コアの増加に向かっている。こうした状況の下、複数のコアを備えたマルチコアＣＰＵが普及してきている。【０００３】
プロキシ装置は、クライアントとサーバとの間に設けられて、クライアント側コネクションとサーバ側コネクションを中継する。ここで、クライアント側コネクションは、クライアントとプロキシ装置間のコネクションである。サーバ側コネクションは、サーバとプロキシ装置間のコネクションである。このプロキシ装置においても、マルチコアＣＰＵを備える装置が増加している。そして、マルチコアＣＰＵをより効率的に運用するアーキテクチャや実装方式が提案されている。【０００４】
また、並列性は、マルチコアＣＰＵを用いて高いスケーラビリティを得るために重要である。マルチコアＣＰＵでは、コア間における同期処理が処理能力に影響を及ぼす。そのため、プロキシ装置においても、ＣＰＵコア間の同期が発生しないような制御を必要とする。【０００５】
プロキシ装置が、クライアント側コネクションとサーバ側コネクションの２つでの処理を２つのセッションとして扱う場合、複数のセッション間で共有すべきデータはほとんど存在しない。そのため、このような通信における並列化に最も有効な方法は、セッション毎に処理を行うＣＰＵコアを分ける手法であることが知られている。以下、このような、手法をセッション分散と呼ぶ。【０００６】
特許文献１は、ＮＡＴ（Ｎｅｔｗｏｒｋ  Ａｄｄｒｅｓｓ  Ｔｒａｎｓｌａｔｉｏｎ）処理を行うセキュリティゲートウェイにおいて、処理を行う資源の割り当てを決定するディスパッチャがクライアント側コネクションとサーバ側コネクションの２つのコネクションで伝送されるパケットが同じＣＰＵコアで処理されるように、サーバ側コネクションのプロキシのアドレスを選択する技術を開示している。【０００７】
特許文献１によれば、ディスパッチャが２つのコネクションで伝送されるパケットを同一のＣＰＵコアに割り振るため、セッション分散が実現されており、それにより他ＣＰＵコアとの同期が不要となり、スケーラビリティを向上できる。【０００８】
一方、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）コネクションを終端するようなプロキシ装置も存在する。このようなプロキシ装置は、ソケットを利用したユーザ空間のアプリケーションとして実現される。【０００９】
プロキシ装置においてプロキシ処理を行うスレッド（以下、プロキシスレッドと呼ぶ。）は、クライアントからのＴＣＰコネクションを確立して、このコネクションに関するソケットを取得する。続いて、プロキシスレッドは、ソケットからデータを取得して、データの検査や、加工処理や、あるいはキャッシュの有無の判断等の所定の処理を実行する。その後、プロキシスレッドは、サーバ側のコネクションに関するソケットを生成して、サーバとのコネクションを確立して、ソケットにデータを送信する。【００１０】
このようなプロキシ装置においてセッション分散を実現する場合、システムは、ＣＰＵコアの数と同数のプロキシスレッドを生成する。システムは、それぞれのプロキシスレッドをＣＰＵコア上に固定的に割り当てる。こうして、あるセッションに関連するクライアント側コネクションとサーバ側コネクションに関する２つのソケット処理が、同一のＣＰＵコア上で動作するプロキシスレッドにより実行される。【００１１】
この処理において、クライアント側コネクションのソケットの情報は、コネクションが確立可能な状態となると、リッスンソケットのキューに追加される。プロキシスレッドは、コネクションを確立するためにａｃｃｅｐｔ関数の呼び出しを行う。これによって、確立されるべきコネクションに対応するソケットがキューから取り出されてコネクションを確立する。この後、一度確立されたコネクションの処理は、コネクションを確立したプロキシスレッドが行う。【００１２】
従って、あるクライアント側コネクションを処理するＣＰＵコアは、コネクションの確立時に決定される。また、プロキシスレッドがクライアント側コネクションを確立した後に、サーバ側コネクションは確立されるので、あるセッションに関連するクライアント側コネクションとサーバ側コネクションの２つのコネクションは、同じＣＰＵコア上に固定的に割り当てられたプロキシスレッドで処理される。【００１３】
このようにして、ユーザ空間でのプロキシ処理の並列化が実現されて、マルチコアＣＰＵを生かした高いスケーラビリティを得ることができる。【００１４】
最近、マルチコアＣＰＵを搭載したＷｅｂサーバの性能向上のために、受信されるパケットを処理の空いているＣＰＵコアへ動的に分散するＲｅｃｅｉｖｅ  Ｓｉｄｅ  Ｓｃａｌｉｎｇや、Ｒｅｃｅｉｖｅ  Ｐａｃｋｅｔ  Ｓｔｅｅｒｉｎｇ（以下、これらの機能をまとめてＲＳＳと呼ぶ。）といった機能を備えるＮＩＣ（Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ  Ｃａｒｄ）が登場してきている。【００１５】
このような、ＲＳＳ搭載ＮＩＣは、受信パケットのヘッダに含まれる情報に基づいてハッシュ値を算出して、ハッシュ値に基づいて割り込みを対象となるＣＰＵコアを決定する機能を有する。【００１６】
あるコネクション上で伝送されるパケットは、同じヘッダ情報を備えているので、そのパケットは、全て同じＣＰＵコアに対して割り込みを発生する。すなわち、ＲＳＳ搭載ＮＩＣでのパケットの受信に応答してカーネルスレッドが受信パケットに関するプロトコル処理を行い、対応するソケットのバッファにパケットデータを登録するまでの処理を１つのＣＰＵコアで行うことができる。【００１７】
このように、ＲＳＳ搭載ＮＩＣを用いることで、カーネルスレッドの処理もコネクション毎に並列処理することができるようになり、マルチコアＣＰＵを活かした高いスケーラビリティを得ることができる。【００１８】
しかしながら、特許文献１に記載された手法を用いて、ＲＳＳ搭載ＮＩＣでのパケット受信からユーザ空間でのプロキシ処理までを同一ＣＰＵコアにより処理するようなプロキシ装置を実現するときには、以下のような課題が存在する。【００１９】
まず、第１課題は、あるコネクションに対して処理を行うカーネルスレッドが動作するＣＰＵコアと、プロキシスレッドが動作するＣＰＵコアとが同一とは限らない点である。これは、プロキシスレッドがコネクションを確立する際に、カーネルスレッドが動作するＣＰＵコアとは別のＣＰＵコアで動作するプロキシスレッドが先にａｃｃｅｐｔ関数の呼び出しを行ってコネクションを確立してしまう可能性があるからである。【００２０】
一度、別のＣＰＵコアに固定的に割り当てられたプロキシスレッドがコネクションを確立すると、その後、そのコネクションに関する処理は、そのプロキシスレッドが処理する。そのプロキシスレッドとカーネルスレッドとが動作するＣＰＵコアは異なるため、ＣＰＵキャッシュを活かした高速な処理を実現できない。【００２１】
従って、あるコネクションの処理を行うカーネルスレッドとプロキシスレッドを同一のＣＰＵコアで実行されるためには、プロキシスレッドがクライアント側コネクションを確立する際に、クライアント側コネクションの確立処理を行ったカーネルスレッドと同一のＣＰＵコアで動作するプロキシスレッドがサーバ側コネクションを確立する仕組みが必要となる。【００２２】
第２課題は、クライアント側コネクションとサーバ側コネクションの２つのコネクションに属するパケットのヘッダに含まれる情報が異なるので、ＲＳＳ搭載ＮＩＣを用いたとしても、２つのコネクション上で伝送されるパケットが同じＣＰＵコアで動作するカーネルスレッドで処理されるとは限らない点である。【００２３】
プロキシ装置に備えられるＲＳＳ搭載ＮＩＣは、通常、サードベンダー製品が用いられる。サードベンダー製品では、ＲＳＳ搭載ＮＩＣによる割り込み先となるＣＰＵコアを決定するアルゴリズムが不明であることも多い。そのため、特許文献１に示された手法のように、ＲＳＳ搭載ＮＩＣが、クライアント側コネクションうえのパケットとサーバ側コネクション上のパケットとを同一ＣＰＵコアに割り当てられるように、サーバ側コネクションの処理を行うＣＰＵコアのアドレスを選択することは難しい。【００２４】
仮に、ＲＳＳ搭載ＮＩＣによりサーバ側コネクションが別のＣＰＵコアで動作するカーネルスレッドに割り当てられた場合、プロキシスレッドは、２つのコネクション上のパケット受信処理において、別のＣＰＵコアで動作するカーネルスレッドとの同期が必要となる。一般に、同一ＣＰＵコア内での同期処理よりも、異なるＣＰＵコア間での同期処理のほうが処理コストは大きくなるので、処理の並列性が低下してしまう。また、同一ＣＰＵコアでないので、キャッシュのローカリティが低下して性能が劣化してしまう。【００２５】
なお、関連技術として、マルチコアＣＰＵを用いた装置における処理速度の向上に関する技術が、特許文献２、３、４に開示されている。
【先行技術文献】
【特許文献】
【００２６】
【特許文献１】国際公開第２００９／０７３２９５号パンフレット
【特許文献２】特開２００９−１９９４３３号公報
【特許文献３】特表２００８−５１２９５０号公報
【特許文献４】特開２００８−１３４７７５号公報
【発明の概要】
【００２７】
本発明の主題は、あるセッションに関するカーネル処理とプロキシ処理とを同一のＣＰＵコア内で処理することが可能な並列化されたプロキシ装置を実現することである。
【００２８】
本発明のプロキシ装置は、複数のＣＰＵコアを備えるマルチコアＣＰＵと、複数のＣＰＵコアの各々に対応して設けられた複数のキューを具備する拡張リッスンソケットと、複数のＣＰＵコアの各々に対応して設けられて、対応するＣＰＵコアに処理を割り当てられたクライアントとの第１コネクションの確立要求パケットの受信処理を行って、第１コネクションの情報を含んだ確立待ちソケットを、複数のキューのうちからそれぞれの動作するＣＰＵコアに対応したキューに登録する複数のカーネルスレッドと、各ＣＰＵコアに対応して設けられて、複数のキューのうちからそれぞれに対応したＣＰＵコアに対応するキューを参照して、確立待ちソケットが登録されている場合に、確立待ちソケットに基づいて第１コネクションを確立する複数のプロキシスレッドとを備える。
【００２９】
本発明のプロキシ方法は、複数のＣＰＵコアを備えるマルチコアＣＰＵと、複数のＣＰＵコアの各々に対応して設けられた複数のキューを具備する拡張リッスンソケットと、複数のＣＰＵコアの各々に対応して設けられた複数のカーネルスレッドと、各ＣＰＵコアに対応して設けられた複数のプロキシスレッドとを備えるプロキシ装置において、対応するＣＰＵコアに処理を割り当てられたクライアントとの第１コネクションの確立要求パケットの受信処理を行うステップと、第１コネクションの情報を含んだ確立待ちソケットを、複数のキューのうちからそれぞれの動作するＣＰＵコアに対応したキューに登録するステップと、複数のキューのうちからそれぞれに対応したＣＰＵコアに対応するキューを参照するステップと、確立待ちソケットが登録されている場合に確立待ちソケットに基づいて第１コネクションを確立するステップとを備える。
【００３０】
本発明によれば、マルチコアＣＰＵを用いて、あるセッションに関するカーネル処理とプロキシ処理とを同一のＣＰＵコア上で処理することが可能なプロキシ装置を実現できる。
【図面の簡単な説明】
【００３１】
【図１】図１は、本発明の実施形態におけるプロキシ装置１００の構成を示す図である。
【図２】図２は、本発明の実施形態におけるプロキシ装置１００の機能ブロック図である。
【図３】図３は、本発明の実施形態における拡張リッスンソケット１３０の構成を示す図である。
【図４】図４は、本発明の実施形態におけるプロキシ装置１００の動作を示すシーケンス図である。
【発明を実施するための形態】
【００３２】
添付図面を参照して、本発明によるプロキシ装置を以下に説明する。
【００３３】
［概要］
本発明のプロキシ装置は、ネットワーク内において、クライアントとサーバの間に設けられ、クライアントとサーバの間の通信を中継する機能を有する。プロキシ装置は、マルチコアＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）を備えている。プロキシ装置は、各ＣＰＵコア上で動作するカーネルスレッドとプロキシスレッドとを備え、さらに、リッスンソケットに各ＣＰＵコアに対応したキューを備えている。カーネルスレッドは、受信されたパケットのプロトコル処理等の受信処理を終えると、当該カーネルスレッドの動作するＣＰＵコアに対応するリッスンソケットのキューに、接続待ちとなるソケットを登録する。また、プロキシスレッドは、当該プロキシスレッドの動作するＣＰＵコアに対応するリッスンソケットのキューから接続待ちのソケットを取得して、コネクションの接続処理を実行する。
【００３４】
このように、本発明のプロキシ装置では、カーネルスレッドとプロキシスレッドとは、それらが動作するＣＰＵコアに対応するリッスンソケットのキューに対してソケットの登録処理と取得処理を行う。接続が確立されたソケットの通信は、その後も、同じカーネルスレッドとプロキシスレッドとにより処理が行われるため、同一のＣＰＵコア上で処理される。
【００３５】
また、本発明のプロキシ装置は、受信されたパケットの受信処理を各ＣＰＵコアへ振り分けるＲＳＳ（ＲＳＳ：Ｒｅｃｅｉｖｅ  Ｓｉｄｅ  Ｓｃａｌｉｎｇ、本発明では、Ｒｅｃｅｉｖｅ  Ｐａｃｋｅｔ  Ｓｔｅｅｒｉｎｇ等の同様の機能を含めてＲＳＳと記載する。）搭載ＮＩＣ（Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ  Ｃａｒｄ）を備える。ＲＳＳ搭載ＮＩＣは、受信されたパケットのヘッダ情報に基づいて、振り分け先のＣＰＵコアを決定する。本発明のプロキシ装置では、ＲＳＳ搭載ＮＩＣが参照するヘッダ情報に所定のマスクが設定される。これにより、ＲＳＳ搭載ＮＩＣは、クライアント側及びサーバ側のいずれから受信されたパケットに対しても、ヘッダ情報の同じ情報に基づいて振り分け先ＣＰＵコアを決定する処理を行うことができる。そのため、一つの通信セッションに対して、クライアント側及びサーバ側のいずれから受信されたパケットも、同じＣＰＵコアへ処理を割り振ることができる。
【００３６】
これらの構成によって、本発明のプロキシ装置は、クライアントとサーバの間で行われる通信において、クライアント側コネクション及びサーバ側コネクションのいずれから受信されたパケットに対しても、同一ＣＰＵコアで処理を行うことが可能となり、ＣＰＵコア間の同期が必要とならず、高いスケーラビリティを実現することができる。
【００３７】
以下に、本発明の一実施形態によるプロキシ装置の構成及び動作を詳細に説明する。
【００３８】
［構成］
はじめに、本実施形態におけるプロキシ装置の構成を説明する。図１は、本実施形態におけるプロキシ装置１００の構成を示すブロック図である。本実施形態のプロキシ装置１００は、処理部１０と、記憶部２０と、通信部３０とを備えている。処理部１０、記憶部２０、及び通信部３０は、それぞれバス１を介して接続されており、データの送受信が可能である。
【００３９】
まず、記憶部２０は、プロキシ装置１００の機能を実現するためのコンピュータプログラムや各種データを記憶する。記憶部２０は、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）や、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）や、ＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）に例示されるような主記憶装置及び補助記憶装置により構成される。記憶部２０は、コンピュータプログラムとして、プロキシ装置１００を制御するオペレーティングシステム（以下、ＯＳ）２１、及びＯＳ２１上で動作するアプリケーションプログラム２２を記憶する。
【００４０】
次に、処理部１０は、記憶部２０に記憶されたコンピュータプログラムを実行することで、プロキシ装置１００の機能を実現する。処理部１０は、複数のコアを備えるマルチコアＣＰＵにより例示される。本実施形態において、処理部１０は、４つのＣＰＵコア１１〜１４を備える。なお、以下の説明において、処理部１０は４つのＣＰＵコア１１〜１４を備えたマルチコアＣＰＵとして説明を行うが、ＣＰＵコアの数は、４つに限定せず、４つより多くとも、少なくとも構わない。
【００４１】
次に、通信部３０は、プロキシ装置１００における外部装置との通信インターフェースである。通信部３０は、ＲＳＳ搭載ＮＩＣ３１、ＲＳＳ搭載ＮＩＣ３２を備える。ＲＳＳ搭載ＮＩＣ３１は、図示されないネットワークを介してクライアント２００と接続されて、データの送受信が可能である。ＲＳＳ搭載ＮＩＣ３２は、図示されないネットワークを介してサーバ３００と接続されて、データの送受信が可能である。なお、図１において、クライアント２００とサーバ３００とは、それぞれ１台づつ記載されているが、実際には、多数のクライアント２００及びサーバ３００が、ネットワークを介してＲＳＳ搭載ＮＩＣ３１、及び３２と接続される。ＲＳＳ搭載ＮＩＣ３１、３２は、クライアント２００、及びサーバ３００からパケットを受信して、処理部１０のＣＰＵコア１１〜１４のうちから当該パケットの受信処理を行うＣＰＵコアを決定する。
【００４２】
ここで、記憶部２０に記憶されたコンピュータプログラムは、固定的な記録媒体に記録されている。ここで、記録媒体とは、ＣＤ（Ｃｏｍｐａｃｔ  Ｄｉｓｋ）や、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ）インターフェースを搭載したフラッシュメモリ（ＵＳＢメモリ）等に例示される。コンピュータプログラムは、このような記録媒体により流通が可能である。コンピュータプログラムは、図示されないプロキシ装置１００のＣＤドライブや、ＵＳＢインターフェースを介して、プロキシ装置１００へインストールされる。また、コンピュータプログラムは、図示されないネットワークに接続されたアプリケーションサーバのＨＤＤにダウンロード可能に記憶されていてもよい。この場合、コンピュータプログラムは、ネットワークを介して、プロキシ装置へ導入される。
【００４３】
続いて、図２は、本実施形態におけるプロキシ装置１００の機能ブロック図である。本実施形態におけるプロキシ装置１００は、プロキシプロセス１１０と、カーネル１２０と、ＲＳＳ搭載ＮＩＣ３１、３２と、マスク設定の保持部３５、３６とを備える。
【００４４】
まず、カーネル１２０は、パケットの受信処理を行う。カーネル１２０は、ＯＳ２１のカーネルである。カーネル１２０は、カーネルスレッド１２１〜１２４と、拡張リッスンソケット１３０と、ソケット１４０〜１４６とを備える。
【００４５】
カーネルスレッド１２１〜１２４は、それぞれＣＰＵコア１１〜１４に対応して設けられる。すなわち、カーネルスレッド１２１は、ＣＰＵコア１１上に固定的に割り当てられ、動作する。同様にカーネルスレッド１２２、１２３、１２４は、それぞれＣＰＵコア１２、１３、１４上に固定的割り当てられ、動作する。カーネルスレッド１２１〜１２４は、それぞれ、ＣＰＵ１１〜１４に割り当てられた受信パケットのプロトコル処理等の受信処理を行う。
【００４６】
拡張リッスンソケット１３０には、接続の確立を待つソケットが登録される。拡張リッスンソケット１３０は、ｓｏｃｋｅｔ関数の呼び出しを行うことより生成される。図３は、本実施形態における拡張リッスンソケット１３０の構成を示す図である。本実施形態の拡張リッスンソケット１３０は、ＣＰＵコア１１〜１４に対応して設けられたキュー１３１〜１３４を備える。キュー１３１〜１３４は、それぞれ対応するＣＰＵコア１１〜１４上で動作するカーネルスレッド１２１〜１２４により処理されたソケットを記憶する。
【００４７】
ソケット１４０〜１４６は、プロキシ装置１００におけるコネクションの処理に用いられる。図２には、７つのソケット１４０〜１４６が記載されているが、ソケット１４０〜１４６は、プロキシ装置１００が処理するコネクション数に対応して生成されるため、全く存在しない（０個）場合や、より多くの数のソケットが存在する場合がある。
【００４８】
次に、プロキシプロセス１０は、コネクション間を接続するプロキシ処理を行う。プロキシプロセス１０は、ＯＳ２１のアプリケーションである。プロキシプロセス１０は、プロキシスレッド１１１〜１１４を備える。プロキシスレッド１１１〜１１４は、それぞれＣＰＵコア１１〜１４に対応して設けられる。すなわち、プロキシスレッド１１１は、ＣＰＵコア１１上に固定的に割当てられて動作する。同様に、プロキシスレッド１１２、１１３、１１４は、それぞれＣＰＵコア１２、１３、１４上に固定的に割当てられて動作する。
【００４９】
プロキシスレッド１１１〜１１４は、それぞれが動作するＣＰＵコア１１〜１４に対応する拡張リッスンソケット１３０のキュー１３１〜１３４に格納された接続確立待ちのコネクションに対してプロキシ処理を行う。
【００５０】
ＲＳＳ搭載ＮＩＣ３１、３２は、前述の通り、クライアント２００及びサーバ３００からパケットを受信して、処理部１０のＣＰＵコア１１〜１４のうちから当該パケットの受信処理を行うＣＰＵコアを決定する。ＲＳＳ搭載ＮＩＣ３１、３２は、それぞれ、マスク設定３５、３６に基づいてマスクされたヘッダ情報をハッシュのキーとして利用する。
【００５１】
保持部に保持されたマスク設定３５、３６は、それぞれ、ＲＳＳ搭載ＮＩＣ３１、３２が受信処理を行う際に、パケットのヘッダ部に行うマスク設定を保持する。マスク設定３５、３６は、設定ファイルやコマンドとして与えられる。本実施形態において、マスク設定３５は、ＲＳＳ搭載ＮＩＣ３１がクライアント側のコネクションから受信されるパケットに対して、パケットの送信元ポート番号をマスクする設定である。また、マスク設定３６は、ＲＳＳ搭載ＮＩＣ３２がサーバ側のコネクションから受信されるパケットに対して、パケットの送信先ポート番号をマスクする設定である。
【００５２】
ここで、以下の説明において、プロキシスレッド１１２とクライアント２００の間には、クライアント側コネクションであるコネクション５００が確立され、プロキシスレッド１１２とサーバ３００との間には、サーバ側コネクションであるコネクション５１０が確立される。コネクション５００、５１０は、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）やＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）によるコネクションである。また、クライアント２００には、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）アドレス「ＩＰ１００」が設定されている。ＲＳＳ搭載ＮＩＣ３１には、ＩＰアドレス「ＩＰ０」、ＲＳＳ搭載ＮＩＣ３２には、ＩＰアドレス「ＩＰ１」が設定されている。サーバ３００には、ＩＰアドレス「ＩＰ２００」が設定されている。
【００５３】
また、コネクション５００において、クライアント２００がポート番号「１００」を使用し、プロキシスレッド１１２がポート番号「０」を使用する。コネクション５１０において、サーバ３００がポート番号「２００」を使用し、プロキシスレッド１１２がポート番号「１」を使用する。
【００５４】
このような設定状態において、ＲＳＳ搭載ＮＩＣ３１が、コネクション５００から受信するパケットは、パケット５０１のようなヘッダ情報を格納する。つまり、パケット５０１は、ヘッダ情報として、送信先ＩＰアドレス「ＩＰ０」、送信先ポート番号「０」、送信元ＩＰアドレス「ＩＰ１００」、送信元ポート番号「１００」を格納する。また、ＲＳＳ搭載ＮＩＣ３２が、コネクション５１０から受信するパケットは、パケット５１１のようなヘッダ情報を格納する。つまり、パケット５１１は、ヘッダ情報として、送信先ＩＰアドレス「ＩＰ１」、送信先ポート番号「１」、送信元ＩＰアドレス「ＩＰ２００」、送信元ポート番号「２００」を格納する。なお、これらの設定は、あくまで一例であり、このような設定には限定しない。
【００５５】
以上が、本実施形態におけるプロキシ装置１００の構成の説明であるが、このような構成のプロキシ装置は、概略、次のように動作する。クライアント２００は、新規のコネクション５００の接続要求のためパケット５０１を送信する。この場合、パケット５０１のヘッダ情報は、図２に示すとおりである。ＲＳＳ搭載ＮＩＣ３１は、パケット５００を受信すると、パケット５００のヘッダ情報に基づいて、ＣＰＵコア１１〜１４から割り込み先のＣＰＵコアを決定する。ここで、ＲＳＳ搭載ＮＩＣ３１がＣＰＵコア１２を割り込み先として決定したとする。ＣＰＵコア１２上で動作するカーネルスレッド１２２が、パケット５００のプロトコル処理等の受信処理を行う。カーネルスレッド１２２は、コネクション５００の接続確立の準備ができた段階で、拡張リッスンソケット１３０のキュー１３１〜１３４のうち、ＣＰＵコア１２に対応するキュー１３２へコネクション５００に関するソケットを登録する。
【００５６】
一方、ＣＰＵコア１２上で動作するプロキシスレッド１１２は、新規コネクションを受け付けるために、ａｃｃｅｐｔ関数の呼び出しをおこなう。ａｃｃｅｐｔ関数の呼び出しを受けて、プロキシスレッド１１２は、ＣＰＵコア１２に対応する拡張リッスンソケット１３０のキュー１３２を参照し、キュー１３２にコネクションの接続確立待ちのソケットが存在するか否かを確認する。キュー１３２にはコネクション５００の接続確立待ちのソケットが存在するとき、プロキシスレッド１１２は、ａｃｃｅｐｔ関数の呼び出しの結果として、新規コネクションであるコネクション５００に関するソケットを取得する。
【００５７】
続いて、プロキシスレッド１１２は、コネクション５００に関するソケットからデータを読み出して、データの検査、変更、キャッシュの有無の確認等の所定の処理を実行する。その後、プロキシスレッド１１２は、サーバ側のコネクションであるコネクション５１０の確立を開始する。プロキシスレッド１１２は、コネクション５００の送信元ポート番号「１００」を取得する。プロキシスレッド１１２は、サーバ側コネクションであるコネクション５１０のソケットを生成する際に、当該ソケットの送信元ポート番号がコネクション５００における送信元ポート番号「１００」と同じ番号になるように、生成されたソケットに対してｂｉｎｄ関数の呼び出しを行う。その後、プロキシスレッド１１２は、生成されたソケットに対して、ｃｏｎｎｅｃｔ関数の呼び出しを行うことでサーバ側コネクション５１０を確立する。
【００５８】
コネクション５１０は、ＲＳＳ搭載ＮＩＣ３２とマスク設定３６によって、送信先ポート番号がハッシュのキーとして利用される。そのため、ＲＳＳ搭載ＮＩＣ３２は、コネクション５１０から受信されたパケット５１１を、ＣＰＵコア１２へ割り当てる。これにより、パケット５１１は、ＣＰＵコア１２で処理を行われる。
【００５９】
［動作］
次に、上述のように構成されたプロキシ装置１００の動作を説明する。図４は、本実施形態におけるプロキシ装置１００の動作を示すシーケンス図である。
【００６０】
ＲＳＳ搭載ＮＩＣ３１は、クライアント２００から新規のコネクション５００の確立を要求するパケット５０１を受信する（ステップＳ１００）。パケット５０１は、図２に示すように、ヘッダ情報として、送信先ＩＰアドレス「ＩＰ０」、送信先ポート番号「０」、送信元ＩＰアドレス「ＩＰ１００」、送信元ポート番号「１００」を保持している。
【００６１】
ＲＳＳ搭載ＮＩＣ３１は、パケット５０１のヘッダ情報に基づいて、ＣＰＵコア１１〜１４のうちから割り込み先のＣＰＵコアを決定する（ステップＳ１０１）。ＲＳＳ搭載ＮＩＣ３１は、マスク設定３５によりマスクされたヘッダ情報に基づいて割り込み先のＣＰＵコアを決定する。本実施形態において、マスク設定３５は、パケット５０１のヘッダ情報において、送信元ポート番号をマスクする設定である。そのため、ＲＳＳ搭載ＮＩＣ３１は、パケット５０１の送信元ポート番号をハッシュのキーとして、割り込み先のＣＰＵコアを決定する。ここでは、ＲＳＳ搭載ＮＩＣは、ＣＰＵコア１２を割り込み先として決定したとする。
【００６２】
ＣＰＵコア１２上で動作するカーネルスレッド１２２は、ＲＳＳ搭載ＮＩＣ３１からパケット５０１を取得してプロトコル処理等の受信処理を行う。カーネルスレッド１２２は、コネクション５００の確立が可能になるまで、ステップＳ１００〜ステップＳ１０１を繰り返す。カーネルスレッド１２２は、コネクション５００の確立が可能となると、コネクション５００に関するソケット情報を拡張リッスンソケット１３０へ格納する（ステップＳ１０２）。この時カーネルスレッド１２２は、拡張リッスンソケット１３０のキュー１３１〜１３４のうち、カーネルスレッド１２２が動作するＣＰＵコア１２に対応するキュー１３２へコネクション５００に関する情報を含んだソケット情報を格納する。
【００６３】
一方、プロキシスレッド１１１〜１１４は、拡張リッスンソケット１３０のキュー１３１〜１３４に対して、ｐｏｌｌ関数や、ｓｅｌｅｃｔ関数の呼び出しを行って定期的に参照することにより確認動作を行う。プロキシスレッド１１２は、キュー１３２において新規のコネクション５００の確立のためのソケット情報が格納されたことを検知すると、拡張リッスンソケット１３０に対して、ａｃｃｅｐｔ関数の呼び出しを行う（ステップＳ２００）
【００６４】
プロキシスレッド１１２は、ａｃｃｅｐｔ関数の呼び出しが成功すると、拡張リッスンソケット１３０から新規のコネクション５００のソケットを受け取る（ステップＳ２０１）。ここでは、ソケット１４０をコネクション５００のソケットとする。プロキシスレッド１１２は、以後、コネクション５００における通信に関してソケット１４０に対してデータの読み書きを行う（ステップＳ２０２）。以後、クライアント２００との間の通信には、ソケット１４０が利用される。ソケット１４０は、ソケット１４０を引き取ったプロキシスレッド１１２により処理される。
【００６５】
続いて、クライアント２００は、コネクション５００を通じてパケット５０１によりデータを送信する（ステップＳ３００）。ＲＳＳ搭載ＮＩＣ３１は、クライアント２００からパケット５０１を受信する。ＲＳＳ搭載ＮＩＣ３１は、クライアント２００から受信されたパケット５０１に格納されたヘッダ情報のうち、マスク設定３５に従って、送信元ポート番号に基づいて割り込み先ＣＰＵコアを決定する。ＲＳＳ搭載ＮＩＣ３１は、ステップＳ１０１と同様に、送信元ポート番号をハッシュの器として割り込み先ＣＰＵコアを決定するため、前述と同様に、ＣＰＵコア１２を割り込み先として決定する。
【００６６】
ＲＳＳ搭載ＮＩＣ３１によりＣＰＵコア１２に割り込みが発生すると、ＣＰＵコア１２上で動作するカーネルスレッド１２２は、パケット５０１を受けて、パケット５０１に対してプロトコル処理等の受信処理を行う（ステップＳ３０１）。カーネルスレッド１２２は、コネクション５００に対応するソケット１４０に、パケット５０１に関するデータを書き込む（ステップＳ３０２）。
【００６７】
プロキシスレッド１１２は、ソケット１４０からデータを読み込んで、データの検証や、セキュリティチェックや、キャッシュの有無といった所定の処理を行う（ステップＳ３０３）。
【００６８】
プロキシスレッド１１２は、サーバ側のコネクションであるコネクション５１０を確立する前に、ソケット１４０からクライアント側のコネクションであるコネクション５００の送信元ポート番号を取得する（ステップＳ３０４）。
【００６９】
プロキシスレッド１１２は、コネクション５１０のソケットを生成する。ここでは、プロキシスレッド１１２が、ソケット１４１を生成したとする。プロキシスレッド１１２は、ソケット１４１に対して、ｂｉｎｄ関数の呼び出しを行うことで、ステップＳ３０４で取得したコネクション５００の送信元ポート番号を、コネクション５１０の送信元ポート番号に設定する（ステップＳ３０５）。
【００７０】
プロキシスレッド１１２は、コネクション５００の送信元ポート番号と同じポート番号が設定されたソケット１４１に対して、ｃｏｎｎｅｃｔ関数の呼び出しを行うことでコネクション５１０の確立を開始する（ステップＳ３０６）。ソケット１４１のシステムコールが呼び出された後は、送信時のカーネル内のプロトコル処理は、プロキシスレッド１１２のコンテキストで実行される場合や、あるいはカーネルスレッド１２２のコンテキストで実行される場合もあるが、いずれの場合においても、ＣＰＵコア１２での処理となる。
【００７１】
続いて、サーバ３００は、確立されたコネクション５１０を通じてパケット５１１によりデータを送信する（ステップＳ４００）。ＲＳＳ搭載ＮＩＣ３２は、サーバ３００から受信されたパケット５１１に格納されたヘッダ情報のうち、マスク設定３６に従って、送信先ポート番号に基づいて割り込み先ＣＰＵコアを決定する。このとき、パケット５１１に格納される送信先ポート番号は、パケット５０１に格納される送信元ポート番号と同一である。そのため、ＲＳＳ搭載ＮＩＣ３２は、ＣＰＵコア１２を割り込み先のＣＰＵコアとして決定する。これにより、クライアント２００からコネクション５００を通じて受信されるパケット５０１も、サーバ３００からのコネクション５１０を通じて受信されるパケット５１１も、同様のＣＰＵコア１２により処理が行われることとなる。
【００７２】
ＲＳＳ搭載ＮＩＣ３２によりＣＰＵコア１２に割り込みが発生すると、ＣＰＵコア１２上で動作するカーネルスレッド１２２は、パケット５１１を入力して、パケット５１１に対してプロトコル処理等の受信処理を行う（ステップＳ４０１）。カーネルスレッド１２２は、コネクション５１０に対応するソケット１４１に、パケット５１１に関するデータを書き込む（ステップＳ４０２）。
【００７３】
プロキシスレッド１１２は、ソケット１４１からデータを読み込んで、サーバから送信されたデータを受信する（ステップＳ４０３）。その後、プロキシスレッド１１２は、クライアント２００へコネクション５００を通じて、サーバからのデータを送信する。以上が、本実施形態におけるプロキシ装置の動作の説明である。
【００７４】
ここまで、本実施形態におけるプロキシ装置の説明を行ってきた。本発明のプロキシ装置によれば、ＲＳＳ搭載ＮＩＣを用いた環境において、あるコネクションが同一のＣＰＵコア上で動作するカーネルスレッドとプロキシスレッドとにより処理が行われる。そのため、ＣＰＵコアのキャッシュのローカリティが向上し、低オーバーヘッド処理を実現することができる。それは、拡張リッスンソケットが、ＣＰＵコアに対応させて、ＣＰＵコアと同数のキューを備えるからである。これにより、プロキシスレッドは、クライアントからのコネクションを確立する際のａｃｃｅｐｔ関数の呼び出しにおいて、当該プロキシスレッドの動作するＣＰＵコアに対応して設けられた拡張リッスンソケットのキューに対して処理を行うことになる。
【００７５】
また、本発明のプロキシ装置によれば、ＲＳＳ搭載ＮＩＣを用いた環境において、異なるＣＰＵコア上で動作するプロキシスレッドとカーネルスレッド間での同期が不要になることで並列性が向上し、かつ、同一ＣＰＵコア上で処理されることにより、ＣＰＵのキャッシュのローカリティが向上してプロキシの性能が向上する。それは、プロキシ装置が、クライアント側コネクションとサーバ側コネクションをそれぞれ専用に処理する２つのＲＳＳ搭載ＮＩＣを備えるからである。クライアント側コネクション用のＲＳＳ搭載ＮＩＣは、パケットのヘッダ情報において送信元ポート番号をハッシュのキーとして利用するようにマスク設定される。また、サーバ側コネクション用のＲＳＳ搭載ＮＩＣは、パケットのヘッダ情報において送信先ポート番号をハッシュのキーとして利用するようにマスク設定される。さらに、プロキシスレッドは、サーバ側コネクションの接続確立を行う際に、クライアント側コネクションの送信元ポート番号を引き継いで、サーバ側コネクションのソケットにおける送信元ポート番号として、ｂｉｎｄ関数の呼び出しを行うことより設定する。そのため、クライアントとサーバ間のセッションに関する２つのコネクションが、同じＣＰＵコア上のカーネルスレッドで処理されることになる。
【００７６】
これまで、実施形態を参照して本願発明の説明を行ってきたが、本願発明は、上記の実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明の範囲内で当業者が理解し得る様々な変更を行うことが可能である。
【００７７】
この出願は、２０１０年２月３日に出願された日本出願特願２０１０−０２２１０７を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【図１】
2011096307.tif 000003
【図２】
2011096307.tif 000004
【図３】
2011096307.tif 000005
【図４】
2011096307.tif 000006
【国際調査報告】
2011096307.tif 000007
2011096307.tif 000008
2011096307.tif 000009
2011096307.tif 000010