ネットワークセッション再構築
コンピュータアプリケーションと直列にサービスを提供する存在を配置するよりもむしろ、サービスプロバイダをアプリケーションと並行に配置する。これは、アプリケーションとの各セッションをミラーリングするために、サービスプロバイダとの並行セッションを作成するセッションリコンストラクタによって達成される。
【発明の詳細な説明】
【背景技術】
【０００１】
発明の背景
本発明は、コンピュータネットワークにおけるセッションの再構築に関する。
【０００２】
コンピュータネットワークでは、情報はパケット形式で通常伝送される。情報の流れは、通常、コンピュータアプリケーションに対して為されるリクエストとアプリケーションによる該リクエストへの応答の形式である。パケットが、信頼されていない送信元（例えば、公衆インターネット）から来た場合、それらがコンピュータアプリケーションへの不正なリクエストを含んでいる（ｃｏｍｐｒｉｓｅ又はｃｏｎｔａｉｎ）危険性がある。そのような不正なリクエストは、所有者の情報へアクセスしようとする未許可の試み、情報を改竄しようとする未許可の試み、又はアプリケーションの通常の動作に干渉しようとする試み（所謂、「ＤｏＳ攻撃」）を構成しうる。
【０００３】
コンピュータ上のアプリケーションは、アプリケーションに向けられたパケットをフィルタリングするコンピュータファイアウォールによって、不正なリクエストから保護されうる。より詳細には、ファイアウォールはパケットを検証し、予め定義されたアクセスルールのセットにそれらが一致するかどうかによって、それらをアプリケーションへと受け渡すかまたはそれらを破棄する。公知のパケットフィルタリングファイアウォールは、使用されているプロトコルを検証するために、１つ以上のリンク層、ネットワーク層及びトランスポート層のパケットヘッダにルールを適用しうる。
【０００４】
不正なリクエストからアプリケーションを保護するための別のアプローチには、プロキシファイアウォールの採用がある。プロキシファイアウォールは、公衆ネットワークを介して到達するパケットの宛先として機能し、各パケットから公衆ネットワークを介するパケットの方向付けに使用されたオーバーヘッドを取り除く。このアプローチにより、パケットのネットワークオーバーヘッドを使用するいずれの攻撃も回避される。公知のプロキシファイアウォールはまた、アプリケーションプロトコルを検証するために、ルールを適用しうる。
【０００５】
コンピュータアプリケーションに対する不正なリクエストの複雑さは拡大し続けている。その対処は、ファイアウォールに、リクエストを選別するためのますます高度な技術を供給することである。さらに、公衆インターネットを介したトラフィック量、故に、公衆インターネットを介してアクセス可能なコンピュータアプリケーションへのトラフィック量は増加し続けている。これらの両傾向の結果、ファイアウォールはますますボトルネックになりえ、このことは、コンピュータアプリケーションの見かけ上の応答時間を低下させる。さらに、ファイアウォールに関する信頼性の問題が、コンピュータアプリケーションの信頼性に悪影響を与えうる（例えば、ファイアウォールがクラッシュした場合、コンピュータアプリケーションは利用できなくなるかもしれない）。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
一態様では、本発明は、コンピュータアプリケーションを不正なリクエストから守るための公知のアプローチの欠点を克服することを試みている。より一般的には、本発明は、ボトルネックを生じることなく、そして、コンピュータアプリケーションの信頼性を低下させることなく、コンピュータアプリケーションに関するサービスを提供することを可能にすることを試みている。
【課題を解決するための手段】
【０００７】
発明の要旨
サービスを提供する存在（ｓｅｒｖｉｃｅ ｐｒｏｖｉｄｉｎｇ ｅｎｔｉｔｙ）をコンピュータアプリケーションと直列に配置するよりもむしろ、サービスプロバイダ（ｓｅｒｖｉｃｅ ｐｒｏｖｉｄｅｒ）をアプリケーションと並列に配置する。これは、アプリケーションとの各セッションをミラーリングするため、サービスプロバイダとの並行セッションを作成するセッションリコンストラクタによって、達成される。
【０００８】
例えば、サービスプロバイダは、不正なリクエスト用のスクリーン（ｓｃｒｅｅｎ）でありうる。このような場合、リクエストが不正なものであるとスクリーンが決定したときには、それは、セッション終了コマンドを送信するなどの適切な処置をとりうる。（並行セッションにおいて作成された）このコマンドは、その後、セッションリコンストラクタによってオリジナルセッションに導入され、両エンドポイントに送信される。別の例として、サービスプロバイダは、規制遵守又は法執行のために、電子メールメッセージ又はインスタントメッセージなどのメッセージの内容を保持する、記録を保持する物（ｒｅｃｏｒｄ ｋｅｅｐｅｒ）でありうるかもしれない。さらなる例として、サービスプロバイダは、運用上の問題を識別し修正するためにネットワーク通信をモニタリングし再構築するデバッガでありうるかもしれない。
【０００９】
本発明によれば、セッション指向ネットワークにおいて使用するための方法が提供され、該方法は、所定のエンドポイントを有する各セッションについて、該所定のエンドポイントに向けられた該各セッションのすべてのペイロードデータをミラーリングするペイロードデータを有する並行セッションを作成することを含み、該各セッションが、該所定のエンドポイントと別のエンドポイントとの間で交換されるパケットを含み、該パケットが、コントロール及びペイロードデータの一方又は両方を有する。セッション指向ネットワークに接続されたプロセッサに該方法を行わせるためのコンピュータ実行可能な命令を含むコンピュータ読取可能な媒体も提供される。
【００１０】
本発明の別の態様によれば、セッションリコンストラクタが提供され、該セッションリコンストラクタは、セッション指向ネットワークに接続するためのインターフェースを含み、所定のエンドポイントに接続するためのインターフェースを含み、該所定のエンドポイントに向けられた各セッションのすべてのペイロードデータをミラーリングするペイロードデータを有する並行セッションを作成するためのプロセッサを含み、該所定のエンドポイントを有する該各セッションについて、該各セッションが、該所定のエンドポイントと別のエンドポイントとの間で交換されるパケットを含み、該パケットが、コントロール及びペイロードデータの一方又は両方を有する。
【００１１】
他の特徴及び利点は、図面とともに、以下の説明を参照することによって、明らかになるだろう。
【発明を実施するための最良の形態】
【００１２】
詳細な説明
図１を参照して、本発明に従い構築されたコンピュータネットワーク１０は、ネットワーク１２（例えば、公衆インターネット又は民間企業のネットワーク）を含む。多数のエンドポイント（例えば、パーソナルコンピュータ１４及び他のプロセッサ１６）がネットワーク１２に接続される。プロセッサ２０上で実行されるコンピュータアプリケーション２２であるエンドポイント２６は、通信路２４を介してネットワークに接続される。セッションリコンストラクタ３０もまた、通信路２４に接続され、サービスプロバイダ３２は、セッションリコンストラクタに接続される。セッションリコンストラクタは、例えば、ディスク、読み出し専用メモリ、又はリモートソースからダウンロードされたファイルでありうるコンピュータ読取可能な媒体３４からのソフトウェアを用いて動作するように構成されうる。
【００１３】
図２に見られるように、セッションリコンストラクタは、プロセッサ３６（これは、通信路２４及びサービスプロバイダの両方に接続される）とメモリ３８とを含む。明らかになる理由により、メモリ３８は、コンピュータアプリケーション２２とのセッションに関する特定の情報を持つテーブル４０を保持している。
【００１４】
通常どおり、コンピュータネットワーク１０は、パケット指向ネットワークである。ネットワーク１２を横断して伝送されるパケットは、上位のリンク層、中位のネットワーク層、より下位のトランスポート層、及び下位のアプリケーション層を含む。各層において、パケットのようなエンティティは、下位の層によって提供されるエンベロープ内にネストされる。従って、リンク層は、ヘッダと、ネットワーク層パケットを含むデータとを有するパケットであり、ネットワーク層パケットは、ヘッダと、トランスポート層パケットを含むデータとを有する。リンク層のヘッダは、パケットが従うプロトコルがインターネットプロトコル（ＩＰ）であることをほぼ常に示している（より旧式のプロトコルは、現在はほとんど廃れており、いずれにしても公衆インターネットでは使用されていない）。パケットがＩＰパケットである場合、ネットワーク層は、ＩＰデータグラムとして知られている。トランスポート層のヘッダは、伝送プロトコルを示し、ＩＰの伝送制御プロトコル（ＴＣＰ）は、ウェブブラウジング、電子メール、及び、ウェブサービスに使用されているので、明らかに最も一般的な伝送プロトコルである。（当業者により理解されるように、ウェブサービスは機械間の対話であって、それにより、あるアプリケーションが別のアプリケーションのリクエストを作成しうる）。他に、ずっとより使用頻度の低い伝送プロトコルとして、ユーザデータグラムプロトコル（ＵＤＰ）及びストリーム制御伝送プロトコル（ＳＣＴＰ）が挙げられる。
【００１５】
トランスポート層パケットのデータは、アプリケーション層を含む（これは通常、複数のトランスポート層パケットにわたって分散されている）。トランスポート層におけるポート番号、及び／又はコンテキストは、アプリケーション層プロトコルを示している。伝送プロトコルがＴＣＰである場合、アプリケーション層プロトコルは様々なアプリケーション層プロトコルのいずれであってもよいが、最も重要なのは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、セキュアＨＴＴＰ（ＨＴＴＰＳ）、ファイル転送プロトコル（ＦＴＰ）、及び簡易メール転送プロトコル（ＳＭＴＰ）である。
【００１６】
伝送プロトコルがＴＣＰである場合、伝送されるパケットは、インターネットデータグラムとして送信される。インターネットプロトコルヘッダは、送信元及び宛先のＩＰアドレスを含む、いくつかの情報フィールドを持つ。ＴＣＰヘッダは、図３に図解したフォーマットに従う。従って、各パケット５０は、送信元ポートフィールド５２、宛先ポートフィールド５４、シーケンス番号フィールド５６、確認応答番号フィールド５８、同期（ＳＹＮ）フラグ６０及びデータ領域６２、ならびに、その他の情報用の６４で通常示されるフィールドを含む。
【００１７】
あるエンドポイント（例えば、コンピュータ１４）が、別のエンドポイント（例えば、プロセッサ２０上で実行されるコンピュータアプリケーション２２）との通信セッションを確立したいときにはいつでも、イニシャルパケットがコンピュータ１４から送信される。パケットの送信元ポートフィールド５２は、セッションに使用されるコンピュータ１４上のポートを特定し、宛先ポートフィールドは、パケットが方向付けられうるアプリケーション２０の既知のポートを特定する。セッションにおけるコンピュータ１４からの最初のパケットについて、ＳＹＮフラグ６０がセットされ、シーケンス番号フィールド５６は、イニシャルシーケンス番号を保持する。コンピュータ１４が使用されたい確認応答番号は、確認応答番号フィールド５８に記憶される。
【００１８】
アプリケーション２２がコンピュータ１４からこの最初のパケットを受信したとき、それは、イニシャルシーケンス番号を記憶し、応答パケットを確立しうる。応答パケット（アプリケーション２２からの最初のパケットである）は、ＳＹＮフラグセット、それ自身のフィールド５６中のイニシャルシーケンス番号及びフィールド５８中の確認応答番号を有する。この応答パケットのデータは、コンピュータ１４からの最初のパケット中の確認応答番号を、この最初のパケットの受信の確認応答を提供するために含む。
【００１９】
コンピュータ１４は、応答パケットを受信すると、アプリケーション２２のイニシャルシーケンス番号を記憶し、次いで、コンピュータ１４がその最初のパケット中に供給したイニシャルシーケンス番号のインクリメントであるシーケンス番号を有するパケットを送り返す。このパケットのデータ部分は、アプリケーション２２からの最初のパケット中の確認応答番号を、アプリケーション２２からの最初のパケットの受信の確認応答として含む。
【００２０】
セッションがここで確立される。毎回、コンピュータ１４は、アプリケーション２２にパケットを送信し、パケットは、セッションにおいてコンピュータ１４により送信された次に前のパケットとともに送信されるシーケンス番号よりもインクリメンタルに大きいシーケンス番号を有する。アプリケーション２２は常に最後のシーケンス番号を記憶し、これを受信した現在のパケットのシーケンス番号と比較する。この新しいシーケンス番号が最後のシーケンス番号のインクリメントである場合、新しいシーケンス番号は、前のシーケンス番号の代わりに、単に記憶される。しかし、新しいシーケンス番号が前のシーケンス番号のインクリメントではない場合、これは、順番が狂ってパケットが受信されていることを示し、シーケンス番号がそれらを適切に並び替えるのに使用される。同様に、毎回、アプリケーション２２は、パケットを送信し、パケットは、アプリケーション２２によって送信された、次の前のパケットとともに送信されたシーケンス番号よりもインクリメンタルに大きいシーケンス番号を有し、コンピュータ１４は常に最後のシーケンス番号を記憶し、これを、受信した現在のパケットのシーケンス番号と比較する。
【００２１】
セッション中のエンドポイントによって送信された任意の所定のパケットについて、エンドポイントが予想された時間内に応答（パケット内に埋め込まれた予想される確認応答番号有するパケットを受信することによって決定される）を受信しない場合、エンドポイントはパケットを再送信する。これは、パケットが最終的にエンドポイントに異なる順番で到着しうる１つの経路であることは明らかである。
【００２２】
コンピュータアプリケーション２２へのＴＣＰパケットは、通信路２４に沿って通過する。セッションリコンストラクタ３０はこの通信路に接続されているので、アプリケーション２２へのこれらのＴＣＰパケットもまた、セッションリコンストラクタ３０により受信される。同様に、アプリケーション２２からのＴＣＰパケットは、ネットワーク１２へ通過するだけではなく、セッションリコンストラクタへも通過する。
【００２３】
セッションリコンストラクタは、アプリケーション２２へと向けられたＴＣＰパケットに基づき、サービスプロバイダ３２を用いてセッションを構築する。従って、アプリケーション２２とのオリジナルセッションのパケットからの特定の情報は、リコンストラクタ３０とサービスプロバイダ３２との間の並行であるが異なるセッションの部分を形成する新たなＴＣＰパケットへとコピーされる。より詳細には、例えば、新たなセッションを確立するために、プロセッサ１６が最初のＴＣＰパケットをコンピュータアプリケーション２２へと方向付けた場合、セッションリコンストラクタ３０はこのパケットを受信する。パケットのＳＹＮフラグがセットされている事実から、リコンストラクタ３０は、これが新たなセッションを確立する試みであることを認識する。セッションリコンストラクタは、メモリ３８のセッションテーブル４０に新しい列（例えば、列ＩＩ）を作成しうる。リコンストラクタは、送信元ＩＰアドレスを「リモートＩＰアドレス」行に、送信元ポート番号を「リモートポート番号」行に、パケットのイニシャルシーケンス番号をこの列の「リモートシーケンス番号」行に、宛先ポートを「コンピュータアプリケーションポート番号」行に、格納しうる。
【００２４】
次に、リコンストラクタは、並行ＴＣＰパケットを構築し、データ６２、及び、プロセッサ１６からのオリジナルパケット由来のその他の情報６４を並行パケットにコピーしうる。並行パケットのＳＹＮフラグ６０がセットされ、リコンストラクタが、フィールド５６にそれ自身のイニシャルシーケンス番号を、フィールド５８に確認応答番号を選択する。宛先ポートは、サービスプロバイダ３２についての既知の宛先ポートである。この宛先ポートを、セッションリコンストラクタによって使用される送信元ポートとともに、サービスプロバイダ３２からのパケットと、それが関連するオリジナルセッションとのマッチングを容易にするために、テーブル４０の列ＩＩに格納してもよい（その理由は説明する）。並行セッションの確立を継続するために、ＴＣＰセッションが確立される標準的な様式に従い、サービスプロバイダ３２は、応答パケットをセッションリコンストラクタに送信する。
【００２５】
新たなセッションの確立を継続するために、コンピュータアプリケーション２２が、プロセッサ１６からのイニシャルパケットに応答するためＴＣＰパケットを送信するとき、セッションリコンストラクタは、応答パケットを受信し、列ＩＩに、アプリケーションによって選択されたイニシャルシーケンス番号を格納しうる。しかし、セッションリコンストラクタは、いずれの並行パケットもサービスプロバイダ３２に送信しない。
【００２６】
同一セッションに関連するプロセッサ１６からの各引き続くパケットについて、リコンストラクタは、送信元アドレスフィールドにマッチするリモートＩＰアドレス及び当該引き続くパケットの送信元ポートフィールド５２にマッチするリモートポート番号を有する列についてセッションテーブル４０をサーチすることによって、当該パケットが関連するセッションを決定する。マッチが見つかったら、当該引き続くパケットのフィールド５６中のシーケンス番号が、その列中の予め存在するシーケンス番号のインクリメントである場合、リコンストラクタは、予め存在するシーケンス番号を、当該引き続くパケットのフィールド５６からのシーケンス番号と置き換える。リコンストラクタはまた、当該引き続くパケットの送信元ポート、データ、及びその他の情報のコピーを有する並行パケットを作成し、この並行パケットをサービスプロバイダ３２に方向付ける。パケットのシーケンス番号が、列に格納された予め存在するシーケンス番号のインクリメントではない場合、セッションリコンストラクタは、サービスプロバイダに送信された前のパケットのシーケンス番号と並行関係を有するシーケンス番号を持つ並行パケットを作成する。このようにして、サービスプロバイダは、順番が狂ったパケットを再び順序付けてもよい。
【００２７】
セッションに関連するコンピュータアプリケーション２２からの引き続くパケットは、当該セッションについてアプリケーションにより使用されている最新のシーケンス番号を有するテーブル４０の列ＩＩをアップデートするのに使用される。しかし、アプリケーションからのパケットが、セッションを変更するコントロール情報を含んでいない場合、サービスプロバイダに対して並行パケットは全く作成されない。より詳細には、セッションを終了するためのコントロール情報を有するパケットをアプリケーション２２が送信する場合、リコンストラクタ３０は、サービスプロバイダとの並行セッションを終了するために、並行パケットを送信する。
【００２８】
サービスプロバイダは様々な目的で使用されうる。例えば、サービスプロバイダは、アプリケーション２２への不正なリクエストをスクリーニングするためのルールを含みうる。適切なルールセットは、２００３年１０月１日に出願された国際出願番号ＰＣＴ／ＣＡ２００３／００１５０７（その内容は、本明細書に参照によって援用される）に記載されている様式で、作成されうる。そのようなルールセットは、一旦作成されたら、２００３年９月１２日に出願された国際出願番号ＰＣＴ／ＣＡ２００３／００１３３３（その内容は、本明細書に参照によって援用される）に記載されている様式で、不正なリクエストをスクリーニングしうる。
【００２９】
サービスプロバイダが、（セッションの一連のＴＣＰパケット中に示された）リクエストが不正なものであると決定した場合、それは警告を発しうる。代替的に、又は追加的に、それは、セッションを終了させることを命令するコントロール情報を含むパケットを、リコンストラクタ３０に送信しうる。このパケットは、パケットが関連するオリジナルセッションについての列を決定するために、セッションリコンストラクタがテーブル４０にアクセスすることを可能とする送信元及び宛先ポートを含む。次いで、リコンストラクタは、カレントのリモートシーケンス番号をこの列から読み出し、このシーケンス番号とセッションの終了を要求するコントロール情報とを含む、プロセッサ１６に向けたＴＣＰパケットを作成する。同様にして、リコンストラクタは、カレントのコンピュータアプリケーションシーケンス番号をこの列から読み出し、このシーケンス番号とセッションの終了を要求するコントロール情報とを含む、アプリケーション２２に向けたＴＣＰパケットを作成する。両方のパケットが、通信路２４に投入される。このようにして、リコンストラクタは、プロセッサ１６とアプリケーション２２との間の不正なリクエスト含んでいたセッションを取り去ることができる。
【００３０】
上述したことから、セッションリコンストラクタ及びサービスプロバイダが、コンピュータアプリケーションと並行に動作することは明らかである。その結果、リコンストラクタ及びサービスプロバイダは、アプリケーション２２の応答性に影響を与えない（すなわち、これらは、アプリケーションを妨げず、またその信頼性も低下させない）。
【００３１】
コンピュータアプリケーション２２は、クライアントからのブラウザベースのリクエストを満たすためのサーバとして動作するように、プロセッサ２０を適合できるだろう。コンピュータ１４は、例えば、そのようなブラウザベースのリクエストを作成するように適合されうる。あるいは、アプリケーション２２は、ウェブサービスを提供するようにプロセッサ２０を適合しえ、プロセッサ１６は、例えば、そのようなウェブサービスを要求するように適合されうる。
【００３２】
他の実施形態では、サービスプロバイダ３２は、記録保持又は証拠収集の機能に適合されうる。例えば、サービスプロバイダ３２は、電子メールセッション又はインスタンス（ｉｎｓｔａｎｃｅ）メッセージングセッションなどの特定のタイプのセッションを認識しうる。そのような状況で、サービスプロバイダは、電子メール、又はインスタンスメッセージ、マネージメントサービス（例えば、多数の電子メールのロギング、又は、送信者の記憶されたリスト中のエントリとマッチする送信者を有する電子メールなどのイベントのスクリーニング）を提供するために使用されうる。エントリとマッチする電子メールが見つかったら、サービスプロバイダは、警告を発するなどの適切なアクションをとるように適合されうる。サービスプロバイダはまた、デバッガ（動作上の問題を識別し修正するために、ネットワーク通信をモニタリングし再構築する）でもありうるだろう。
【００３３】
とりわけ、サービスプロバイダ３２について予定されうるサービスの多くについて、サービスプロバイダは、それがオリジナルセッションよりむしろ再構築されたセッションのハンドリングであるという認識は必要としない。例えば、これは、モニタリング（例えば、記録保持、証拠収集、又はデバッギング）サービスなどの、オリジナルセッションに情報を投入する必要がない任意のサービスに当てはまる。そのような場合、任意の予め存在する標準サービスプロバイダが、セッションリコンストラクタ３０とともに、サービスプロバイダ３２に変更を加えることなく、使用されうる。
【００３４】
他の変更は当業者に明らかであり、従って、本発明は、特許請求の範囲に定義される。
【図面の簡単な説明】
【００３５】
本発明の実施例の態様を説明する図面において、
【図１】図１は、本発明に従い構成されたネットワークの概略図であり、
【図２】図２は、図１のセッションリコンストラクタの図式的な詳細図であり、
【図３】図３は、ＴＣＰセグメントの概略図である。
【背景技術】
【０００１】
発明の背景
本発明は、コンピュータネットワークにおけるセッションの再構築に関する。
【０００２】
コンピュータネットワークでは、情報はパケット形式で通常伝送される。情報の流れは、通常、コンピュータアプリケーションに対して為されるリクエストとアプリケーションによる該リクエストへの応答の形式である。パケットが、信頼されていない送信元（例えば、公衆インターネット）から来た場合、それらがコンピュータアプリケーションへの不正なリクエストを含んでいる（ｃｏｍｐｒｉｓｅ又はｃｏｎｔａｉｎ）危険性がある。そのような不正なリクエストは、所有者の情報へアクセスしようとする未許可の試み、情報を改竄しようとする未許可の試み、又はアプリケーションの通常の動作に干渉しようとする試み（所謂、「ＤｏＳ攻撃」）を構成しうる。
【０００３】
コンピュータ上のアプリケーションは、アプリケーションに向けられたパケットをフィルタリングするコンピュータファイアウォールによって、不正なリクエストから保護されうる。より詳細には、ファイアウォールはパケットを検証し、予め定義されたアクセスルールのセットにそれらが一致するかどうかによって、それらをアプリケーションへと受け渡すかまたはそれらを破棄する。公知のパケットフィルタリングファイアウォールは、使用されているプロトコルを検証するために、１つ以上のリンク層、ネットワーク層及びトランスポート層のパケットヘッダにルールを適用しうる。
【０００４】
不正なリクエストからアプリケーションを保護するための別のアプローチには、プロキシファイアウォールの採用がある。プロキシファイアウォールは、公衆ネットワークを介して到達するパケットの宛先として機能し、各パケットから公衆ネットワークを介するパケットの方向付けに使用されたオーバーヘッドを取り除く。このアプローチにより、パケットのネットワークオーバーヘッドを使用するいずれの攻撃も回避される。公知のプロキシファイアウォールはまた、アプリケーションプロトコルを検証するために、ルールを適用しうる。
【０００５】
コンピュータアプリケーションに対する不正なリクエストの複雑さは拡大し続けている。その対処は、ファイアウォールに、リクエストを選別するためのますます高度な技術を供給することである。さらに、公衆インターネットを介したトラフィック量、故に、公衆インターネットを介してアクセス可能なコンピュータアプリケーションへのトラフィック量は増加し続けている。これらの両傾向の結果、ファイアウォールはますますボトルネックになりえ、このことは、コンピュータアプリケーションの見かけ上の応答時間を低下させる。さらに、ファイアウォールに関する信頼性の問題が、コンピュータアプリケーションの信頼性に悪影響を与えうる（例えば、ファイアウォールがクラッシュした場合、コンピュータアプリケーションは利用できなくなるかもしれない）。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
一態様では、本発明は、コンピュータアプリケーションを不正なリクエストから守るための公知のアプローチの欠点を克服することを試みている。より一般的には、本発明は、ボトルネックを生じることなく、そして、コンピュータアプリケーションの信頼性を低下させることなく、コンピュータアプリケーションに関するサービスを提供することを可能にすることを試みている。
【課題を解決するための手段】
【０００７】
発明の要旨
サービスを提供する存在（ｓｅｒｖｉｃｅ ｐｒｏｖｉｄｉｎｇ ｅｎｔｉｔｙ）をコンピュータアプリケーションと直列に配置するよりもむしろ、サービスプロバイダ（ｓｅｒｖｉｃｅ ｐｒｏｖｉｄｅｒ）をアプリケーションと並列に配置する。これは、アプリケーションとの各セッションをミラーリングするため、サービスプロバイダとの並行セッションを作成するセッションリコンストラクタによって、達成される。
【０００８】
例えば、サービスプロバイダは、不正なリクエスト用のスクリーン（ｓｃｒｅｅｎ）でありうる。このような場合、リクエストが不正なものであるとスクリーンが決定したときには、それは、セッション終了コマンドを送信するなどの適切な処置をとりうる。（並行セッションにおいて作成された）このコマンドは、その後、セッションリコンストラクタによってオリジナルセッションに導入され、両エンドポイントに送信される。別の例として、サービスプロバイダは、規制遵守又は法執行のために、電子メールメッセージ又はインスタントメッセージなどのメッセージの内容を保持する、記録を保持する物（ｒｅｃｏｒｄ ｋｅｅｐｅｒ）でありうるかもしれない。さらなる例として、サービスプロバイダは、運用上の問題を識別し修正するためにネットワーク通信をモニタリングし再構築するデバッガでありうるかもしれない。
【０００９】
本発明によれば、セッション指向ネットワークにおいて使用するための方法が提供され、該方法は、所定のエンドポイントを有する各セッションについて、該所定のエンドポイントに向けられた該各セッションのすべてのペイロードデータをミラーリングするペイロードデータを有する並行セッションを作成することを含み、該各セッションが、該所定のエンドポイントと別のエンドポイントとの間で交換されるパケットを含み、該パケットが、コントロール及びペイロードデータの一方又は両方を有する。セッション指向ネットワークに接続されたプロセッサに該方法を行わせるためのコンピュータ実行可能な命令を含むコンピュータ読取可能な媒体も提供される。
【００１０】
本発明の別の態様によれば、セッションリコンストラクタが提供され、該セッションリコンストラクタは、セッション指向ネットワークに接続するためのインターフェースを含み、所定のエンドポイントに接続するためのインターフェースを含み、該所定のエンドポイントに向けられた各セッションのすべてのペイロードデータをミラーリングするペイロードデータを有する並行セッションを作成するためのプロセッサを含み、該所定のエンドポイントを有する該各セッションについて、該各セッションが、該所定のエンドポイントと別のエンドポイントとの間で交換されるパケットを含み、該パケットが、コントロール及びペイロードデータの一方又は両方を有する。
【００１１】
他の特徴及び利点は、図面とともに、以下の説明を参照することによって、明らかになるだろう。
【発明を実施するための最良の形態】
【００１２】
詳細な説明
図１を参照して、本発明に従い構築されたコンピュータネットワーク１０は、ネットワーク１２（例えば、公衆インターネット又は民間企業のネットワーク）を含む。多数のエンドポイント（例えば、パーソナルコンピュータ１４及び他のプロセッサ１６）がネットワーク１２に接続される。プロセッサ２０上で実行されるコンピュータアプリケーション２２であるエンドポイント２６は、通信路２４を介してネットワークに接続される。セッションリコンストラクタ３０もまた、通信路２４に接続され、サービスプロバイダ３２は、セッションリコンストラクタに接続される。セッションリコンストラクタは、例えば、ディスク、読み出し専用メモリ、又はリモートソースからダウンロードされたファイルでありうるコンピュータ読取可能な媒体３４からのソフトウェアを用いて動作するように構成されうる。
【００１３】
図２に見られるように、セッションリコンストラクタは、プロセッサ３６（これは、通信路２４及びサービスプロバイダの両方に接続される）とメモリ３８とを含む。明らかになる理由により、メモリ３８は、コンピュータアプリケーション２２とのセッションに関する特定の情報を持つテーブル４０を保持している。
【００１４】
通常どおり、コンピュータネットワーク１０は、パケット指向ネットワークである。ネットワーク１２を横断して伝送されるパケットは、上位のリンク層、中位のネットワーク層、より下位のトランスポート層、及び下位のアプリケーション層を含む。各層において、パケットのようなエンティティは、下位の層によって提供されるエンベロープ内にネストされる。従って、リンク層は、ヘッダと、ネットワーク層パケットを含むデータとを有するパケットであり、ネットワーク層パケットは、ヘッダと、トランスポート層パケットを含むデータとを有する。リンク層のヘッダは、パケットが従うプロトコルがインターネットプロトコル（ＩＰ）であることをほぼ常に示している（より旧式のプロトコルは、現在はほとんど廃れており、いずれにしても公衆インターネットでは使用されていない）。パケットがＩＰパケットである場合、ネットワーク層は、ＩＰデータグラムとして知られている。トランスポート層のヘッダは、伝送プロトコルを示し、ＩＰの伝送制御プロトコル（ＴＣＰ）は、ウェブブラウジング、電子メール、及び、ウェブサービスに使用されているので、明らかに最も一般的な伝送プロトコルである。（当業者により理解されるように、ウェブサービスは機械間の対話であって、それにより、あるアプリケーションが別のアプリケーションのリクエストを作成しうる）。他に、ずっとより使用頻度の低い伝送プロトコルとして、ユーザデータグラムプロトコル（ＵＤＰ）及びストリーム制御伝送プロトコル（ＳＣＴＰ）が挙げられる。
【００１５】
トランスポート層パケットのデータは、アプリケーション層を含む（これは通常、複数のトランスポート層パケットにわたって分散されている）。トランスポート層におけるポート番号、及び／又はコンテキストは、アプリケーション層プロトコルを示している。伝送プロトコルがＴＣＰである場合、アプリケーション層プロトコルは様々なアプリケーション層プロトコルのいずれであってもよいが、最も重要なのは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、セキュアＨＴＴＰ（ＨＴＴＰＳ）、ファイル転送プロトコル（ＦＴＰ）、及び簡易メール転送プロトコル（ＳＭＴＰ）である。
【００１６】
伝送プロトコルがＴＣＰである場合、伝送されるパケットは、インターネットデータグラムとして送信される。インターネットプロトコルヘッダは、送信元及び宛先のＩＰアドレスを含む、いくつかの情報フィールドを持つ。ＴＣＰヘッダは、図３に図解したフォーマットに従う。従って、各パケット５０は、送信元ポートフィールド５２、宛先ポートフィールド５４、シーケンス番号フィールド５６、確認応答番号フィールド５８、同期（ＳＹＮ）フラグ６０及びデータ領域６２、ならびに、その他の情報用の６４で通常示されるフィールドを含む。
【００１７】
あるエンドポイント（例えば、コンピュータ１４）が、別のエンドポイント（例えば、プロセッサ２０上で実行されるコンピュータアプリケーション２２）との通信セッションを確立したいときにはいつでも、イニシャルパケットがコンピュータ１４から送信される。パケットの送信元ポートフィールド５２は、セッションに使用されるコンピュータ１４上のポートを特定し、宛先ポートフィールドは、パケットが方向付けられうるアプリケーション２０の既知のポートを特定する。セッションにおけるコンピュータ１４からの最初のパケットについて、ＳＹＮフラグ６０がセットされ、シーケンス番号フィールド５６は、イニシャルシーケンス番号を保持する。コンピュータ１４が使用されたい確認応答番号は、確認応答番号フィールド５８に記憶される。
【００１８】
アプリケーション２２がコンピュータ１４からこの最初のパケットを受信したとき、それは、イニシャルシーケンス番号を記憶し、応答パケットを確立しうる。応答パケット（アプリケーション２２からの最初のパケットである）は、ＳＹＮフラグセット、それ自身のフィールド５６中のイニシャルシーケンス番号及びフィールド５８中の確認応答番号を有する。この応答パケットのデータは、コンピュータ１４からの最初のパケット中の確認応答番号を、この最初のパケットの受信の確認応答を提供するために含む。
【００１９】
コンピュータ１４は、応答パケットを受信すると、アプリケーション２２のイニシャルシーケンス番号を記憶し、次いで、コンピュータ１４がその最初のパケット中に供給したイニシャルシーケンス番号のインクリメントであるシーケンス番号を有するパケットを送り返す。このパケットのデータ部分は、アプリケーション２２からの最初のパケット中の確認応答番号を、アプリケーション２２からの最初のパケットの受信の確認応答として含む。
【００２０】
セッションがここで確立される。毎回、コンピュータ１４は、アプリケーション２２にパケットを送信し、パケットは、セッションにおいてコンピュータ１４により送信された次に前のパケットとともに送信されるシーケンス番号よりもインクリメンタルに大きいシーケンス番号を有する。アプリケーション２２は常に最後のシーケンス番号を記憶し、これを受信した現在のパケットのシーケンス番号と比較する。この新しいシーケンス番号が最後のシーケンス番号のインクリメントである場合、新しいシーケンス番号は、前のシーケンス番号の代わりに、単に記憶される。しかし、新しいシーケンス番号が前のシーケンス番号のインクリメントではない場合、これは、順番が狂ってパケットが受信されていることを示し、シーケンス番号がそれらを適切に並び替えるのに使用される。同様に、毎回、アプリケーション２２は、パケットを送信し、パケットは、アプリケーション２２によって送信された、次の前のパケットとともに送信されたシーケンス番号よりもインクリメンタルに大きいシーケンス番号を有し、コンピュータ１４は常に最後のシーケンス番号を記憶し、これを、受信した現在のパケットのシーケンス番号と比較する。
【００２１】
セッション中のエンドポイントによって送信された任意の所定のパケットについて、エンドポイントが予想された時間内に応答（パケット内に埋め込まれた予想される確認応答番号有するパケットを受信することによって決定される）を受信しない場合、エンドポイントはパケットを再送信する。これは、パケットが最終的にエンドポイントに異なる順番で到着しうる１つの経路であることは明らかである。
【００２２】
コンピュータアプリケーション２２へのＴＣＰパケットは、通信路２４に沿って通過する。セッションリコンストラクタ３０はこの通信路に接続されているので、アプリケーション２２へのこれらのＴＣＰパケットもまた、セッションリコンストラクタ３０により受信される。同様に、アプリケーション２２からのＴＣＰパケットは、ネットワーク１２へ通過するだけではなく、セッションリコンストラクタへも通過する。
【００２３】
セッションリコンストラクタは、アプリケーション２２へと向けられたＴＣＰパケットに基づき、サービスプロバイダ３２を用いてセッションを構築する。従って、アプリケーション２２とのオリジナルセッションのパケットからの特定の情報は、リコンストラクタ３０とサービスプロバイダ３２との間の並行であるが異なるセッションの部分を形成する新たなＴＣＰパケットへとコピーされる。より詳細には、例えば、新たなセッションを確立するために、プロセッサ１６が最初のＴＣＰパケットをコンピュータアプリケーション２２へと方向付けた場合、セッションリコンストラクタ３０はこのパケットを受信する。パケットのＳＹＮフラグがセットされている事実から、リコンストラクタ３０は、これが新たなセッションを確立する試みであることを認識する。セッションリコンストラクタは、メモリ３８のセッションテーブル４０に新しい列（例えば、列ＩＩ）を作成しうる。リコンストラクタは、送信元ＩＰアドレスを「リモートＩＰアドレス」行に、送信元ポート番号を「リモートポート番号」行に、パケットのイニシャルシーケンス番号をこの列の「リモートシーケンス番号」行に、宛先ポートを「コンピュータアプリケーションポート番号」行に、格納しうる。
【００２４】
次に、リコンストラクタは、並行ＴＣＰパケットを構築し、データ６２、及び、プロセッサ１６からのオリジナルパケット由来のその他の情報６４を並行パケットにコピーしうる。並行パケットのＳＹＮフラグ６０がセットされ、リコンストラクタが、フィールド５６にそれ自身のイニシャルシーケンス番号を、フィールド５８に確認応答番号を選択する。宛先ポートは、サービスプロバイダ３２についての既知の宛先ポートである。この宛先ポートを、セッションリコンストラクタによって使用される送信元ポートとともに、サービスプロバイダ３２からのパケットと、それが関連するオリジナルセッションとのマッチングを容易にするために、テーブル４０の列ＩＩに格納してもよい（その理由は説明する）。並行セッションの確立を継続するために、ＴＣＰセッションが確立される標準的な様式に従い、サービスプロバイダ３２は、応答パケットをセッションリコンストラクタに送信する。
【００２５】
新たなセッションの確立を継続するために、コンピュータアプリケーション２２が、プロセッサ１６からのイニシャルパケットに応答するためＴＣＰパケットを送信するとき、セッションリコンストラクタは、応答パケットを受信し、列ＩＩに、アプリケーションによって選択されたイニシャルシーケンス番号を格納しうる。しかし、セッションリコンストラクタは、いずれの並行パケットもサービスプロバイダ３２に送信しない。
【００２６】
同一セッションに関連するプロセッサ１６からの各引き続くパケットについて、リコンストラクタは、送信元アドレスフィールドにマッチするリモートＩＰアドレス及び当該引き続くパケットの送信元ポートフィールド５２にマッチするリモートポート番号を有する列についてセッションテーブル４０をサーチすることによって、当該パケットが関連するセッションを決定する。マッチが見つかったら、当該引き続くパケットのフィールド５６中のシーケンス番号が、その列中の予め存在するシーケンス番号のインクリメントである場合、リコンストラクタは、予め存在するシーケンス番号を、当該引き続くパケットのフィールド５６からのシーケンス番号と置き換える。リコンストラクタはまた、当該引き続くパケットの送信元ポート、データ、及びその他の情報のコピーを有する並行パケットを作成し、この並行パケットをサービスプロバイダ３２に方向付ける。パケットのシーケンス番号が、列に格納された予め存在するシーケンス番号のインクリメントではない場合、セッションリコンストラクタは、サービスプロバイダに送信された前のパケットのシーケンス番号と並行関係を有するシーケンス番号を持つ並行パケットを作成する。このようにして、サービスプロバイダは、順番が狂ったパケットを再び順序付けてもよい。
【００２７】
セッションに関連するコンピュータアプリケーション２２からの引き続くパケットは、当該セッションについてアプリケーションにより使用されている最新のシーケンス番号を有するテーブル４０の列ＩＩをアップデートするのに使用される。しかし、アプリケーションからのパケットが、セッションを変更するコントロール情報を含んでいない場合、サービスプロバイダに対して並行パケットは全く作成されない。より詳細には、セッションを終了するためのコントロール情報を有するパケットをアプリケーション２２が送信する場合、リコンストラクタ３０は、サービスプロバイダとの並行セッションを終了するために、並行パケットを送信する。
【００２８】
サービスプロバイダは様々な目的で使用されうる。例えば、サービスプロバイダは、アプリケーション２２への不正なリクエストをスクリーニングするためのルールを含みうる。適切なルールセットは、２００３年１０月１日に出願された国際出願番号ＰＣＴ／ＣＡ２００３／００１５０７（その内容は、本明細書に参照によって援用される）に記載されている様式で、作成されうる。そのようなルールセットは、一旦作成されたら、２００３年９月１２日に出願された国際出願番号ＰＣＴ／ＣＡ２００３／００１３３３（その内容は、本明細書に参照によって援用される）に記載されている様式で、不正なリクエストをスクリーニングしうる。
【００２９】
サービスプロバイダが、（セッションの一連のＴＣＰパケット中に示された）リクエストが不正なものであると決定した場合、それは警告を発しうる。代替的に、又は追加的に、それは、セッションを終了させることを命令するコントロール情報を含むパケットを、リコンストラクタ３０に送信しうる。このパケットは、パケットが関連するオリジナルセッションについての列を決定するために、セッションリコンストラクタがテーブル４０にアクセスすることを可能とする送信元及び宛先ポートを含む。次いで、リコンストラクタは、カレントのリモートシーケンス番号をこの列から読み出し、このシーケンス番号とセッションの終了を要求するコントロール情報とを含む、プロセッサ１６に向けたＴＣＰパケットを作成する。同様にして、リコンストラクタは、カレントのコンピュータアプリケーションシーケンス番号をこの列から読み出し、このシーケンス番号とセッションの終了を要求するコントロール情報とを含む、アプリケーション２２に向けたＴＣＰパケットを作成する。両方のパケットが、通信路２４に投入される。このようにして、リコンストラクタは、プロセッサ１６とアプリケーション２２との間の不正なリクエスト含んでいたセッションを取り去ることができる。
【００３０】
上述したことから、セッションリコンストラクタ及びサービスプロバイダが、コンピュータアプリケーションと並行に動作することは明らかである。その結果、リコンストラクタ及びサービスプロバイダは、アプリケーション２２の応答性に影響を与えない（すなわち、これらは、アプリケーションを妨げず、またその信頼性も低下させない）。
【００３１】
コンピュータアプリケーション２２は、クライアントからのブラウザベースのリクエストを満たすためのサーバとして動作するように、プロセッサ２０を適合できるだろう。コンピュータ１４は、例えば、そのようなブラウザベースのリクエストを作成するように適合されうる。あるいは、アプリケーション２２は、ウェブサービスを提供するようにプロセッサ２０を適合しえ、プロセッサ１６は、例えば、そのようなウェブサービスを要求するように適合されうる。
【００３２】
他の実施形態では、サービスプロバイダ３２は、記録保持又は証拠収集の機能に適合されうる。例えば、サービスプロバイダ３２は、電子メールセッション又はインスタンス（ｉｎｓｔａｎｃｅ）メッセージングセッションなどの特定のタイプのセッションを認識しうる。そのような状況で、サービスプロバイダは、電子メール、又はインスタンスメッセージ、マネージメントサービス（例えば、多数の電子メールのロギング、又は、送信者の記憶されたリスト中のエントリとマッチする送信者を有する電子メールなどのイベントのスクリーニング）を提供するために使用されうる。エントリとマッチする電子メールが見つかったら、サービスプロバイダは、警告を発するなどの適切なアクションをとるように適合されうる。サービスプロバイダはまた、デバッガ（動作上の問題を識別し修正するために、ネットワーク通信をモニタリングし再構築する）でもありうるだろう。
【００３３】
とりわけ、サービスプロバイダ３２について予定されうるサービスの多くについて、サービスプロバイダは、それがオリジナルセッションよりむしろ再構築されたセッションのハンドリングであるという認識は必要としない。例えば、これは、モニタリング（例えば、記録保持、証拠収集、又はデバッギング）サービスなどの、オリジナルセッションに情報を投入する必要がない任意のサービスに当てはまる。そのような場合、任意の予め存在する標準サービスプロバイダが、セッションリコンストラクタ３０とともに、サービスプロバイダ３２に変更を加えることなく、使用されうる。
【００３４】
他の変更は当業者に明らかであり、従って、本発明は、特許請求の範囲に定義される。
【図面の簡単な説明】
【００３５】
本発明の実施例の態様を説明する図面において、
【図１】図１は、本発明に従い構成されたネットワークの概略図であり、
【図２】図２は、図１のセッションリコンストラクタの図式的な詳細図であり、
【図３】図３は、ＴＣＰセグメントの概略図である。
【特許請求の範囲】
【請求項１】
セッション指向ネットワークにおいて使用するための方法であって、
所定のエンドポイントを有する各セッションについて、該所定のエンドポイントに向けられた該各セッションの全てのペイロードデータをミラーリングするペイロードデータを有する並行セッションを作成することを含み、
該各セッションが、該所定のエンドポイントと別のエンドポイントとの間で交換されるパケットを含み、該パケットが、コントロール及びペイロードデータの一方又は両方を有する、方法。
【請求項２】
所定のエンドポイントを有する前記各セッションがオリジナルセッションであり、
さらに、
所定の並行セッションにおいて、コントロール情報を受信すること、及び
そこから該所定の並行セッションが生じた特定のオリジナルセッションについて、該特定のオリジナルセッションについての該所定のエンドポイント及び前記別のエンドポイントに向けられた該特定のオリジナルセッション中に該コントロール情報を挿入すること
を含む、請求項１に記載の方法。
【請求項３】
前記並行セッションを作成することが、さらに、
前記各オリジナルセッションの全てのコントロール情報をミラーリングするコントロール情報を有する該並行セッションを作成すること
を含む、請求項２に記載の方法。
【請求項４】
前記特定のオリジナルセッションに挿入された前記コントロール情報が、セッション終了コマンドである、請求項３に記載の方法。
【請求項５】
前記ネットワークがインターネットプロトコルに従う、請求項４に記載の方法。
【請求項６】
前記ネットワークが伝送制御プロトコルに従う、請求項５に記載の方法。
【請求項７】
前記特定のオリジナルセッションのシーケンス番号をトラッキングすることをさらに含み、該特定のオリジナルセッションに前記コントロール情報を挿入することが、予想されるシーケンス番号とともにコントロール情報を挿入することを含む、請求項６に記載の方法。
【請求項８】
前記所定のエンドポイントが、ブラウザベースのリクエストを満たすためのサーバである、請求項７に記載の方法。
【請求項９】
前記所定のエンドポイントが、ウェブサービスを提供するためのサーバである、請求項７に記載の方法。
【請求項１０】
所定のエンドポイントを有する前記各セッションがオリジナルセッションであり、所定の並行セッションが、そこから該所定の並行セッションが生ずる特定のオリジナルセッションのイニシャルシーケンス番号とは異なるイニシャルシーケンス番号を有する、請求項１に記載の方法。
【請求項１１】
さらに、前記ペイロードデータを不正なリクエストについてスクリーニングすることを含む、請求項１に記載の方法。
【請求項１２】
所定のエンドポイントを有する前記各セッションがオリジナルセッションであり、
所定のオリジナルセッションについて不正なリクエストを見つけた際、該特定のオリジナルセッションについての該所定のエンドポイント及び前記別のエンドポイントに向けられた該所定のオリジナルセッション中にセッション終了コマンドを挿入することをさらに含む、請求項１１に記載の方法。
【請求項１３】
イベントについての前記ペイロードデータをスクリーニングすることをさらに含む、請求項１に記載の方法。
【請求項１４】
所定のエンドポイントを有する前記各セッションがオリジナルセッションであり、
所定のオリジナルセッションについてのイベントを決定する際に、該イベントをロギングすることをさらに含む、請求項１３に記載の方法。
【請求項１５】
前記イベントが特定のパラメータを有する電子メールメッセージである、請求項１４に記載の方法。
【請求項１６】
セッションリコンストラクタであって、
セッション指向ネットワークへの接続用のインターフェースを含み、
所定のエンドポイントへの接続用のインターフェースを含み、
該所定のエンドポイントを有する各セッションについて、該所定のエンドポイントへ向けられた該各セッションの全てのペイロードデータをミラーリングするペイロードデータを有する並行セッションを作成するためのプロセッサを含み、該各セッションが、該所定のエンドポイントと別のエンドポイントとの間で交換されるパケットを含み、該パケットが、コントロール及びペイロードデータの一方又は両方を有する、
セッションリコンストラクタ。
【請求項１７】
前記各セッションについての情報を有するテーブルを記憶するためのメモリをさらに含み、該情報が、前記別のエンドポイントのアドレス、該別のエンドポイントのポート番号、該別のエンドポイントのシーケンス番号、前記所定のエンドポイントのポート番号、及び該所定のポイントのシーケンス番号を含む、請求項１６に記載のセッションリコンストラクタ。
【請求項１８】
コンピュータ読取可能な媒体であって、
セッション指向ネットワークに接続されたプロセッサに、所定のエンドポイントを有する各セッションについて、該所定のエンドポイントに向けられた該各セッションの全てのペイロードデータをミラーリングするペイロードデータを有する並行セッションを作成させるためのコンピュータ実行可能な命令を含み、
該各セッションが、該所定のエンドポイントと別のエンドポイントとの間で交換されるパケットを含み、該パケットが、コントロール及びペイロードデータの一方又は両方を有する、コンピュータ読取可能な媒体。
【請求項１】
セッション指向ネットワークにおいて使用するための方法であって、
所定のエンドポイントを有する各セッションについて、該所定のエンドポイントに向けられた該各セッションの全てのペイロードデータをミラーリングするペイロードデータを有する並行セッションを作成することを含み、
該各セッションが、該所定のエンドポイントと別のエンドポイントとの間で交換されるパケットを含み、該パケットが、コントロール及びペイロードデータの一方又は両方を有する、方法。
【請求項２】
所定のエンドポイントを有する前記各セッションがオリジナルセッションであり、
さらに、
所定の並行セッションにおいて、コントロール情報を受信すること、及び
そこから該所定の並行セッションが生じた特定のオリジナルセッションについて、該特定のオリジナルセッションについての該所定のエンドポイント及び前記別のエンドポイントに向けられた該特定のオリジナルセッション中に該コントロール情報を挿入すること
を含む、請求項１に記載の方法。
【請求項３】
前記並行セッションを作成することが、さらに、
前記各オリジナルセッションの全てのコントロール情報をミラーリングするコントロール情報を有する該並行セッションを作成すること
を含む、請求項２に記載の方法。
【請求項４】
前記特定のオリジナルセッションに挿入された前記コントロール情報が、セッション終了コマンドである、請求項３に記載の方法。
【請求項５】
前記ネットワークがインターネットプロトコルに従う、請求項４に記載の方法。
【請求項６】
前記ネットワークが伝送制御プロトコルに従う、請求項５に記載の方法。
【請求項７】
前記特定のオリジナルセッションのシーケンス番号をトラッキングすることをさらに含み、該特定のオリジナルセッションに前記コントロール情報を挿入することが、予想されるシーケンス番号とともにコントロール情報を挿入することを含む、請求項６に記載の方法。
【請求項８】
前記所定のエンドポイントが、ブラウザベースのリクエストを満たすためのサーバである、請求項７に記載の方法。
【請求項９】
前記所定のエンドポイントが、ウェブサービスを提供するためのサーバである、請求項７に記載の方法。
【請求項１０】
所定のエンドポイントを有する前記各セッションがオリジナルセッションであり、所定の並行セッションが、そこから該所定の並行セッションが生ずる特定のオリジナルセッションのイニシャルシーケンス番号とは異なるイニシャルシーケンス番号を有する、請求項１に記載の方法。
【請求項１１】
さらに、前記ペイロードデータを不正なリクエストについてスクリーニングすることを含む、請求項１に記載の方法。
【請求項１２】
所定のエンドポイントを有する前記各セッションがオリジナルセッションであり、
所定のオリジナルセッションについて不正なリクエストを見つけた際、該特定のオリジナルセッションについての該所定のエンドポイント及び前記別のエンドポイントに向けられた該所定のオリジナルセッション中にセッション終了コマンドを挿入することをさらに含む、請求項１１に記載の方法。
【請求項１３】
イベントについての前記ペイロードデータをスクリーニングすることをさらに含む、請求項１に記載の方法。
【請求項１４】
所定のエンドポイントを有する前記各セッションがオリジナルセッションであり、
所定のオリジナルセッションについてのイベントを決定する際に、該イベントをロギングすることをさらに含む、請求項１３に記載の方法。
【請求項１５】
前記イベントが特定のパラメータを有する電子メールメッセージである、請求項１４に記載の方法。
【請求項１６】
セッションリコンストラクタであって、
セッション指向ネットワークへの接続用のインターフェースを含み、
所定のエンドポイントへの接続用のインターフェースを含み、
該所定のエンドポイントを有する各セッションについて、該所定のエンドポイントへ向けられた該各セッションの全てのペイロードデータをミラーリングするペイロードデータを有する並行セッションを作成するためのプロセッサを含み、該各セッションが、該所定のエンドポイントと別のエンドポイントとの間で交換されるパケットを含み、該パケットが、コントロール及びペイロードデータの一方又は両方を有する、
セッションリコンストラクタ。
【請求項１７】
前記各セッションについての情報を有するテーブルを記憶するためのメモリをさらに含み、該情報が、前記別のエンドポイントのアドレス、該別のエンドポイントのポート番号、該別のエンドポイントのシーケンス番号、前記所定のエンドポイントのポート番号、及び該所定のポイントのシーケンス番号を含む、請求項１６に記載のセッションリコンストラクタ。
【請求項１８】
コンピュータ読取可能な媒体であって、
セッション指向ネットワークに接続されたプロセッサに、所定のエンドポイントを有する各セッションについて、該所定のエンドポイントに向けられた該各セッションの全てのペイロードデータをミラーリングするペイロードデータを有する並行セッションを作成させるためのコンピュータ実行可能な命令を含み、
該各セッションが、該所定のエンドポイントと別のエンドポイントとの間で交換されるパケットを含み、該パケットが、コントロール及びペイロードデータの一方又は両方を有する、コンピュータ読取可能な媒体。
【図１】
【図２】
【図３】
【図２】
【図３】
【公表番号】特表２００７−５３４２２３（Ｐ２００７−５３４２２３Ａ）
【公表日】平成１９年１１月２２日（２００７．１１．２２）
【国際特許分類】
【出願番号】特願２００６−５４０１２１（Ｐ２００６−５４０１２１）
【出願日】平成１６年１１月２３日（２００４．１１．２３）
【国際出願番号】ＰＣＴ／ＣＡ２００４／００２０１２
【国際公開番号】ＷＯ２００５／０５０９２６
【国際公開日】平成１７年６月２日（２００５．６．２）
【出願人】（５０６１７６２９４）エフエスシー インターネット コーポレイション (1)
【Ｆターム（参考）】
【公表日】平成１９年１１月２２日（２００７．１１．２２）
【国際特許分類】
【出願日】平成１６年１１月２３日（２００４．１１．２３）
【国際出願番号】ＰＣＴ／ＣＡ２００４／００２０１２
【国際公開番号】ＷＯ２００５／０５０９２６
【国際公開日】平成１７年６月２日（２００５．６．２）
【出願人】（５０６１７６２９４）エフエスシー インターネット コーポレイション (1)
【Ｆターム（参考）】
[ Back to top ]