JP2005184846A - 接続管理システムおよびトランスポートオフロードエンジン - Google Patents

Abstract

【課題】
ネットワーク過負荷の問題を避ける様式でネットワーク接続試行を管理するより有効な技法を提供すること。
【解決手段】
本発明は、ネットワーク接続を確立するための方法であって：ネットワーク上の接続を確立するための試行を識別する工程；および該接続に関連するデータを記憶するためのメモリの部分を割り当てる工程、を包含する、方法を提供する。メモリ過負荷の派生を避けながらネットワーク接続を確立するためのオフロードサブシステムであって：ネットワーク上の接続を確立する試行を識別し、かつ該接続と関連するデータを記憶するためのメモリの部分を割り当てるためのオフロードエンジンを備え、ここで、該メモリの部分が、該メモリの過負荷をされるために上書きされる、オフロードサブシステムもまた提供される。
【選択図】 図２

Description

（発明の分野）
本発明は、ネットワーク通信を管理すること、そしてより詳細には、ネットワーク接続管理に関する。

（発明の背景）
先行技術の図１は、先行技術によってネットワーク通信が確立される方法１００を示す。種々のプロトコル（ＴＣＰなど）を利用するネットワーク通信（例えば、インターネット通信など）は、しばしば、接続を確立するための努力で開始される。

ＴＣＰ接続試行が始まるとき、デスティネーションホストは、操作１０２に示されるように、ソースホストから同期（ＳＹＮ）パケットを受ける。このようなＳＹＮパケットを受信することに応答して、代表的には限定サイズの指定されたメモリが接続の確立を探知するために割り当てられる。操作１０３に注目のこと。

その後、操作１０４で、デスティネーションホストは、ＳＹＮ受取りパケット（ＳＹＮ／ＡＣＫ）を送り返す。このデスティネーションホストは、次いで、決定１０６に提示されるように、接続が確立する前にハンドシェイクＡＣＫの受信を待たなければならない。これは、代表的には、「ＴＣＰ三方向オープンハンドシェイク」と呼ばれる。

ハンドシェイクＡＣＫを待つ間、デスティネーションホストの限定サイズのメモリは、終了されるのを待つその他の接続の探知を維持する。これは、代表的には、エンプティを迅速に待ち行列に入れる。なぜなら、ハンドシェイクＡＣＫは、ＳＹＮ／ＡＣＫパケットが送信された後数ミリ秒で到着することが予想されるからである。

ハンドシェイクＡＣＫを受信すると、この接続はオープンであり、そして限定サイズのメモリの関連する部分は、現在オープンの接続を探知かつ維持するために用いられる。操作１１０を注目のこと。その一方、ハンドシェイクＡＣＫが所定のタイムアウト期間内に受信されない場合（決定１０８に注目のこと）、最大数のＳＹＮ／ＡＣＫ再送信が生じたか否かを決定するための試験がなされる（決定１１２に注目のこと）。この最大数の再送信がまだ生じていない場合、ＳＹＮ／ＡＣＫパケットが再送信される。操作１１４に注目のこと。この最大数の再送信が生じた場合、このプロセスは終了し、そしてメモリの割り当ては解かれる。操作１１６に注目のこと。

サービス否認（ＤｏＳ）アタックは、ビクティムデスティネーションホストに向かうランダムソースＩＰアドレスおよびソースポートをもつ、攻撃ソースホスト発生ＴＣＰ ＳＹＮパケットを有することにより、この設計を開発する。このビクティムデスティネーションホストは、次に、ランダムソースアドレスに戻るＳＹＮ／ＡＣＫパケットを送信し（図１の方法１００の操作１０４に従う）、そしてメモリの接続待ち行列へのエントリーを付加する。

このＳＹＮ／ＡＣＫは、不正確または不在ホストに向かうことになっているので、「三方向オープンハンドシェイク」の最後の部分は、決して終わることはなく、メモリは、この接続試行に割り当てられたままであり、そして上記エントリーは、最大数の再試行が送信され、そしてタイマーの期限が切れるまで（代表的には約１分）接続待ち行列（キュー）中に残る。ランダムアドレスから偽ＴＣＰ ＳＹＮパケットを高速で生成することにより、メモリの接続キューを充填することが可能であり、そして正規ユーザーへのＴＣＰサービス（ｅメール、ファイル移送、ＷＷＷなど）を否認することが可能である。

この攻撃の発信者を探知する容易な方法はない。なぜなら、このソースのＩＰアドレスは、代表的には、偽造されているからである。従って、これらおよびその他の因子に起因するネットワーク過負荷の問題を避ける様式でネットワーク接続試行を管理するより有効な技法に対する必要性が存在する。

（発明の要旨）
ネットワーク接続を確立するためのシステムおよび方法が提供される。最初に、ネットワーク上の接続を確立するための試行が識別される。次いで、メモリの一部分が、この接続に関連するデータを記憶するために割り当てられる。

１つの実施形態では、このメモリの部分は、接続を確立するための第２の試行が先の試行と関連する少なくとも１つの局面を有する場合上書きされ得る。このような局面は、制限されずに、ＩＰアドレス、ＴＣＰポートなどを含む接続の任意の局面を含み得る。

必要に応じて、ネットワーク上の接続を確立するための各試行は、パケット［すなわち、同期（ＳＹＮ）パケットなど］を利用して識別され得る。なおさらに、このシステムおよび方法は、同期／受取り（ＳＹＮ／ＡＣＫ）パケットでこのパケットに応答し得る。

別の実施形態では、ハシュが、ネットワーク上の接続を確立する試行と対応する各パケットと関連して生成され得る。このようなハシュは、次に、接続を確立するための第２の試行が前記の様式で先の試行と関連する少なくとも１つの局面を有するか否かを決定するために利用される。

なおさらに、このハシュは、上記メモリの部分に記憶されたデータへのポインタとして供され得、ここで、このデータは、コントロールブロックを含む。必要に応じて、半オープン状態にある接続と関連する複数のコントロールブロックは、オープン接続と関連する複数のコントロールブロックに対してより小さいサイズであり得る。さらに、もこのコントロールブロックは、接続、ＩＰアドレス、ポート番号、タイムスタンプなどを識別するために用いられるハンドルを含み得る。半オープン状態は、第１のＳＹＮが、リモートホストから少なくとも受信されたが、対応するハンドシェイクＡＣＫがいまだ受信されていない接続試行として規定される。

なおさらなる別の実施形態では、上記メモリは、半オープン接続と関連するデータに割り当てられる第１のメモリを含み得る。さらに、この第１のメモリから論理的または物理的に分離された第２のメモリが、この第１のメモリの過剰負荷がオープンソケットに影響しないように、オープン接続と関連するデータに割り当てられ得る。必要に応じて、先に記載のように、上記第２のメモリは、上記第１のメモリが割り当てられる第１のタイプのコントロールブロックに対してより大きいサイズである第２のタイプのコントロールブロックのために割り当てられ得る。

使用において、上記メモリの部分は、接続試行のハンドシェイクＡＣＫの受信に際して割り当てを解かれ得る。なおさらに、別のメモリの部分（すなわち、第２のメモリ、など）が、上記接続試行が成功する際、オープン接続のために割り当てられ得る。

本発明は、以下を提供する。

（１）ネットワーク接続を確立するための方法であって：
ネットワーク上の接続を確立するための試行を識別する工程；および
上記接続に関連するデータを記憶するためのメモリの部分を割り当てる工程、を包含する、方法。

（２）項１に記載の方法であって、接続を確立するための第２の試行が先の試行と関連する少なくとも１つの局面を有する場合に、上記メモリの部分がメモリ過負荷を避けるために上書きされる、方法。

（３）上記ネットワーク上の接続を確立するための各々の試行が、パケットを識別することにより実施される、項２に記載の方法。

（４）上記パケットが、同期パケットである、項３に記載の方法。

（５）上記パケットにパケット受取りで応答する工程をさらに包含する、項３に記載の方法。

（６）上記ネットワーク上の接続を確立するための試行と関連する各パケットと関連するハシュを生成する工程をさらに包含する、項３に記載の方法。

（７）上記ハシュが、接続を確立するための次の試行が、先の試行と関連する少なくとも１つの局面を有するか否かを決定するために利用される、項６に記載の方法。

（８）上記少なくとも１つの局面が、ＩＰアドレスを含む、項７に記載の方法。

（９）上記少なくとも１つの局面が、ＴＣＰポートを含む、項７に記載の方法。

（１０）上記ハシュが上記メモリの部分に記憶されたデータへのポインタとして供され、そして上記データがコントロールブロックを含む、項７に記載の方法。

（１１）接続試行と関連する複数のコントロールブロックが、オープン接続と関連する複数のコントロールブロックに対してサイズがより小さい、項１０に記載の方法。

（１２）上記コントロールブロックが、ハンドル、ＩＰアドレス、ＴＣＰポート、およびタイムスタンプを含む、項１０に記載の方法。

（１３）上記メモリが、接続試行と関連するデータのために割り当てられる第１のメモリを含む、項１に記載の方法。

（１４）上記第１のメモリから論理的に分離された第２のメモリが、オープン接続と関連するデータのために割り当てられ、上記第１のメモリの過負荷が上記オープン接続に影響しない、項１３に記載の方法。

（１５）上記第２のメモリが、上記第１のメモリが割り当てられる第１のタイプのコントロールブロックに対してサイズがより大きい第２のタイプのコントロールブロックに対し割り当てられる、項１４に記載の方法。

（１６）上記接続試行のハンドシェイク受取りの受信に際し、上記メモリの部分の割り当てを解く工程をさらに包含する、項１に記載の方法。

（１７）上記接続試行が成功する際に、オープン接続のために別のメモリ部分を割り当てる工程をさらに包含する、項１６に記載の方法。

（１８）上記メモリ過負荷が、サービス否認アタックから生じる、項２に記載の方法。

（１９）上記ネットワーク上の接続を確立する各試行が、プロセッサに同期パケットを送信することにより処理され、上記同期パケットが受取りされるか否かを決定する、項１に記載の方法。

（２０）上記ネットワーク上の接続を確立する各試行が、オフロードエンジンを利用することにより処理され、同期パケットが受取りされるか否かを決定する、項１に記載の方法。

（２１）メモリ過負荷の派生を避けながらネットワーク接続を確立するためのオフロードサブシステムであって：
ネットワーク上の接続を確立する試行を識別し、かつ上記接続と関連するデータを記憶するためのメモリの部分を割り当てるためのオフロードエンジンを備え、
ここで、上記メモリの部分が、上記メモリの過負荷をされるために上書きされる、オフロードサブシステム。

（２２）メモリ過負荷の問題を避けながらネットワーク接続を確立するためのシステムであって：
プロセッサ；
バスを経由して上記プロセッサおよびネットワークと通信するオフロードエンジンであって、上記ネットワーク上の接続を確立する試行を識別し、かつ上記接続と関連するデータを記憶するためのメモリの部分を割り当てるためのオフロードエンジン；を備え、
ここで、上記メモリの部分が、上記メモリの過負荷をされるために上書きされる、システム。

ネットワーク過負荷の問題を避ける様式でネットワーク接続試行を管理するより有効な技法が提供される。

（詳細な説明）
図２は、１つの実施形態による、ネットワークシステム２００を示す。示されるようにネットワーク２０２が提供される。本発明のネットワークシステム２００の文脈では、ネットワーク２０２は、制限されないで、ローカルエリアネットワーク（ＬＡＮ）、インターネットのようなワイドエリアネットワーク（ＷＡＮ）などを含む任意の形態をとり得る。

このネットワークに接続されて、ネットワーク２０２上で通信し得るローカルホスト２０４およびリモートホスト２０６がある。本明細書の文脈では、このようなホスト２０４、２０６は、ウェブサーバー、デスクトップコンピューター、ラップトップコンピューター、ハンドヘルドコンピューター、プリンターまたは任意のその他のタイプのハードウェア／ソフトウェアを含み得る。前記のコンポーネントの各々および任意のその他の示されていないデバイスが１つ以上のネットワークにより相互接続され得ることが注記される。

図３は、例示のアーキテクチャー３００を示し、ここでは、１つの実施形態が履行され得る。１つの実施形態では、このアーキテクチャー３００は、図２のホスト２０４、２０６の１つが提示され得る。しかし、勿論、このアーキテクチャー３００は、任意の所望のコンテクストで履行され得ることに注目すべきである。

例えば、このアーキテクチャー３００は、汎用コンピューターシステム、回路基板システム、娯楽目的に供されるゲームコンソールシステム、セットトップボックス、ルータ、ネットワークシステム、ストレージシステム、アプリケーション特異的システム、またはネットワーク２０２に関連する任意のその他の所望のシステムのコンテクストで履行され得る。

示されるように、このアーキテクチャー３００は、バス３０２を経由して接続される複数のコンポーネントを含む。データを処理するための少なくとも１つのプロセッサ３０４が含められる。このプロセッサ３０４は、任意の形態をとり得るが、それは、１つの実施形態では、中央処理ユニット（ＣＰＵ）、チップセット（すなわち、関連する機能を実施するためのユニットとして作動および販売されるよう設計された集積回路の群）、またはデータを処理し得る任意のその他の所望の処理デバイス（単数または複数）の形態をとり得る。

さらに、データを記憶するために、プロセッサ３０４と通信して存在するプロセッサシステムメモリ３０６が含められる。このようなプロセッサシステムメモリ３０６は、オンボードまたはオフボードのランダムアクセスメモリ（ＲＡＭ）、ハードディスクドライブ、リムーバブル記憶デバイス（すなわち、フロッピー（登録商標）ディスク（登録商標）ドライブ、磁気テープドライブ、コンパクトディスクドライブなど）、および／またはデータを記憶し得る任意のその他のタイプの所望のメモリの形態をとり得る。

使用において、プログラム、または制御論理アルゴリズムが、必要に応じて、このプロセッサシステムメモリ３０６中に記憶され得る。このようなプログラムは、実行されるとき、アーキテクチャー３００が種々の機能を実施することを可能にする。勿論、このアーキテクチャー３００は、ハードワイヤ化されている。

さらに、このプロセッサ３０４およびネットワーク（例えば、図２のネットワーク２０２を参照のこと）と通信しているオフロードエンジン３１２が示される。１つの実施形態では、このオフロードエンジン３１２は、バス３０２を経由してプロセッサ３０４と通信して維持され得る。しかし、勿論、このオフロードエンジン３１２は、それらの間の通信を提供する任意の機構を経由して、プロセッサ３０４との通信を維持し得る。このオフロードエンジン３１２は、輸送（すなわち、ＴＣＰ／ＩＰ）オフロードエンジン（ＴＯＥ）、またはネットワーク中を送信されるデータを管理し得る任意の集積回路（単数または複数）を含み得る。

操作の間に、このオフロードエンジン３１２は、メモリ過負荷の問題［すなわち、ネットワークのサービス否認（ｄｅｎｉａｌ−ｏｆ−ｓｅｒｖｉｃｅ；ＤｏＳ）アタック、重いトラフィックなどに起因する］を避けながら、ネットワーク通信を確立するために、プロセッサ３０４と組み合わせて作動するために供される。これを達成するために、ネットワーク上の通信を確立する試行が最初に識別される。次に、メモリの一部分が、この接続に関連するデータを記憶するために割り当てられる。残り説明の文脈では、このようなメモリは、本明細書の上記に記載の任意のメモリ（すなわち、メモリ３０６など）、オフロードエンジン３１２に関連するメモリ、またはアーキテクチャー３００および／またはネットワークシステム２００と関連する全く他の任意のメモリを含み得る。

使用の間、メモリの前記部分は、メモリ過負荷を避ける特有の目的のために上書きされ得る。前記の機能性は、メモリ過負荷を避け得る任意の所望の様式で実施され得ることに注目すべきである。ここで、オフロードエンジン３１２が前記の様式でメモリを上書きする例示の方法に関するより多くの情報が提示される。

図４Ａは、１つの実施形態による、メモリ過負荷の問題を避けながら、ネットワーク接続を確立するための例示の方法４００を示す。オプションとして、この方法４００は、図３の例示のアーキテクチャー３００および図２のネットワークシステム２００のコンテクストで実施され得る。しかし、勿論、この方法４００は、任意の所望のコンテクストで履行され得ることに注目すべきである。さらに、種々の機能は、例示のコンポーネント（すなわち、本明細書で上記に提示されるようなもの）に起因し得るが、種々の機能性が任意の所望の実体により実施され得ることを理解することは重要である。

最初に、決定４０２において、サーバーソケットに関連する第１の同期（ＳＹＮ）パケットが、ローカルホスト（すなわち、例えば、図２のローカルホスト２０４を参照のこと）において、オフロードエンジン（すなわち、例えば、図３のオフロードエンジン３１２を参照のこと）によって受信されるか否かが決定される。本明細書の説明の文脈では、ＳＹＮパケットは、接続を確立するために必要な同期プロセスを開始する任意のパケット、シグナルなどを含み得る。使用において、ＳＹＮパケットは、パケット内のフラッグによりマークされ得る。さらに、サーバーソケットは、ネットワーク上で稼動する２つのプログラム間の二方向通信リンクの１つの終点である。ソケットは、ＴＣＰ層が、データが送信されることになっているアプリケーションを識別し得るように、ポート番号に結合され得る。

ＳＹＮパケットが決定４０２について受信されない場合、他のパケットタイプが操作４０４で処理される。その場合、しかし、ローカルホストのプロセッサ（すなわち、例えば、図２のプロセッサ３０４を参照のこと）によって、第１のＳＹＮパケットが受容されているか否かが決定される。決定４０６に注目のこと。上記の決定は、ＳＹＮパケットと関連するデスティネーションポート、および／またはＳＹＮパケットが受信されたインターフェースに基づいて実施され得ることに注目すべきである。

あるいは、第１のＳＹＮパケットを受容する決定４０６は、オフロードエンジンによってのみなされ得る。上記の決定は、再び、ＳＹＮパケットと関連するデスティネーションポート、および／またはＳＹＮパケットが受信されたインターフェースに基づいて実施され得る。

第１のＳＹＮパケットが受容されるべきでないことが決定されると、リセット（ＲＳＴ）パケットが生成される。操作４１４を注目のこと。ＲＳＴパケットは、次いで、第１のＳＹＮパケットをもたらしたリモートホストに送信されて戻る。操作４１６を注目のこと。次いで方法４００はリセットされる。しかし、この第１のＳＹＮが実際に受容されることが決定されると、第１のハシュが、第１のＳＹＮパケット中に受信されたパラメータを基に操作４０８中で生成される。本明細書の文脈では、このハシュは、より短い固定長の値または当初の文字を表すキーである文字列（すなわち、この場合においては、第１のＳＹＮパケット中のＩＰアドレスおよびポート番号）を含み得る。このハュは、この第１のパケットの少なくとも１つの局面と関連する任意の識別子をさらに含み得ることに注目すべきである。例えば、このハシュは、インターネットプロトコール（ＩＰ）アドレスと第１のＳＹＮパケットと関連するポートのペアに基づいて生成され得る。

次に、操作４１０において、第１のメモリの第１の部分が、第１タイプのコントロールブロック（すなわち、「半オープン」コントロールブロックまたはＨＯ−ＣＢ）のためのサーバーソケットについて割り当てられる。再び、このようなメモリは、本明細書で上記に記載の任意のメモリ（すなわち、図３のメモリ３０６など）、オフロードエンジンに関連するメモリ、またはアーキテクチャー３００および／またはネットワークシステム２００と関連する全く他のメモリを含み得る。

本明細書の文脈では、コントロールブロックは、接続試行および／または接続を探知するために用いられ得る任意の情報を含み得る。さらに、この第１タイプのコントロールブロックは、特に、接続試行を探知するために用いられ得る任意の情報を含み得る。例示のみの目的で、この第１タイプのコントロールブロックは、ハンドル、ＩＰアドレス、ポート番号、タイムスタンプ、および／またはＳＹＮパケットと関連する任意の情報を含み得る。

前記の割り当て操作４１０を開始するために、プロセッサは、第１タイプのコントロールブロックを生成するために必要な情報を提供する目的のために、オフロードエンジンに指示ブロック（ＩＢ）を発行し得る。このＩＢが与えられれば、オフロードエンジンは、前述の様式で第１のメモリの第１の部分を割り当て得る。間もなく明らかになるように、このハシュは、第１タイプのコントロールブロックへのポインタとして利用され得る。

あるいは、オフロードエンジンそれ自身が、第１のＳＹＮパケットにおける接続を受容する決定をなし得、そして第１タイプのコントロールブロックを生成するために、第１のＳＹＮパケットおよびメモリソースからすべての必要な情報を得てもよい。次いで、オフロードエンジンは、前述の様式で第１のメモリの第１の部分を割り当て得る。

第１タイプのコントロールブロックにメモリが割り当てられて、オフロードエンジンは、引き続き、第１のＳＹＮパケットについて同期受取り（ＳＹＮ／ＡＣＫ）パケットを送信する。操作４１２を注目のこと。このようなＳＹＮ／ＡＣＫパケットは、第１のＳＹＮ／ＡＣＫパケットが受信され、しかもリモートホストに戻る同期化がリクエストされたことを示す任意の信号の形態をとり得る。その後、ローカルホストは、リモートホストにおいてＳＹＮ／ＡＣＫパケットの受信を受取りする任意の信号の形態をとり得る、ハンドシェイクＡＣＫである「ＴＣＰ三方向オープンハンドシェイク」の最終コンポーネントを待つ。

この時点で、この方法４００の機能性は、ハンドシェイクＡＣＫが受信されるか、別のＳＹＮパケットが受信されるか、またはいずれもが受信されないかに基づき変動する。以下の図は、前述の場合のシナリオの各々を説明するために割り当てられる。例えば、図４Ｂは、１つの実施形態による、図４Ａの第１のＳＹＮ／ＡＣＫパケットに応答してハンドシェイクＡＣＫが受信される場合におけるネットワーク接続確立法を示す。さらに、図４Ｃおよび４Ｄは、図４Ａの第１のＳＹＮパケットの後であるが、第１のＳＹＮ／ＡＣＫパケットに応答するハンドシェイクＡＣＫが受信される前に別のＳＹＮパケットが受信される場合の、ネットワーク接続確立法を示す。なおさらに、図４Ｅは、ハンドシェイクＡＣＫも別のＳＹＮも受信されない場合のネットワーク接続確立法を示す。

前と同様に、図４Ｂ〜４Ｅの方法は、図３の例示のアーキテクチャー３００および図２のネットワークシステム２００と関連して、図４の方法４００のコンテクストで実施され得る。勿論、しかし、図４Ｂ〜４Ｅの方法は、任意の所望の独立のコンテクストで履行され得ることに注目すべきである。さらに、種々の機能は、例示のコンポーネント（すなわち、本明細書で上記に提示されたもののように）に起因し得るが、種々の機能は、任意の所望の実体によって実施され得ることを理解することが重要である。

図４Ｂを参照して、操作４２０においてパケットを待った後、パケットがＡＣＫパケットを受信したか否かがオフロードエンジンによって決定される。決定４２２に注目のこと。パケットがＡＣＫパケットでない場合、どのタイプのパケットが受信されかを観察するためにさらなるチェックがなされる。図４Ｃを参照のこと。受信されたパケットがＡＣＫパケットである場合、操作４２４に示されるように、ハシュが生成される。このようなハシュは、同一でないとしても、ＳＹＮパケットに関して本明細書で上記に提示された様式と類似の様式で生成され得る。例えば、このハシュは、ＩＰアドレスおよびハンドシェイクＡＣＫパケットのペアに基づいて生成され得る。

受信されたＡＣＫパケットのハシュによって識別されたとき、第１タイプのコントロールブロック（すなわち、ＨＯ−ＣＢ）中のパラメータは、次いで、操作４２６に示されるように取り出される。前述のＨＯ−ＣＢから取り出されたパラメータは、次に、受信されたＡＣＫがハンドシェイクＡＣＫであるか否かを決定するために用いられる。そうであれば、次に、ＨＯ−ＣＢ中のパラメータは、ハンドシェイクＡＣＫパケット内に受信されたものと比較され、受信されたハンドシェイクＡＣＫパケットが識別されたＨＯ−ＣＢ中に記憶されたのと同じ接続試行に属するか否かを観察する。決定４２８を参照のこと。パラメータが一致しない場合、受信されたハンドシェイクＡＣＫは、操作４３６に示されるように棄てられ、そしてこの方法４００はリセットされて戻り、受信されたパケットを待つ。パラメータがまさに一致する場合、次いで、「ＴＣＰ三方向オープンハンドシェイク」の最終コンポーネントが終了したことが確認される。この目的に、サーバーソケットが開放されてオープンソケットを生成する。操作４３０を参照のこと。

さらに、さらなる接続試行を探知するために第１のメモリを自由にするため、第１のＳＹＮパケットに先に割り当てられた第１のメモリの部分は、ここで、割り当てを解かれる。操作４３２に注目のこと。この割り当てを解くことにより、第１タイプのコントロールブロックは無効にされる。

オープンを容易にするため、操作４２６でＨＯ−ＣＢから読み取られたパラメータは、第２タイプのコントロールブロック（すなわち、オープンコントロールブロックまたはオープンＣＢ）を生成するために用いられる。操作４３４を参照のこと。このオープンＣＢは、現在オープン接続の状態を探知するために用いられる。第１タイプのコントロールブロックと同様に、第２タイプのコントロールブロックは、オープン接続を探知かつ維持するために用いられ得る任意の情報を含み得る。しかし、オープン接続を探知するために、より多くの情報がしばしば必要であるので、第２タイプのコントロールブロックは、第１タイプのコントロールブロックよりサイズがより大きい。

さらに、第２タイプのコントロールブロックを記憶する第２のメモリは、本明細書に上記で述べた任意のメモリ（すなわち、図３のメモリ３０６など）、オフロードエンジンに関連するメモリ、またはアーキテクチャー３００および／またはネットワークシステム２００と関連する全く別の任意のその他のメモリを含み得る。しかし、この第２のメモリは、論理的に（そして恐らくは論理的に加えてさらに物理的に）、第１のメモリから、第１のメモリの過負荷（すなわち、過剰数の接続試行、アタックなどに起因する）が第２のメモリによるオープン接続の探知に影響しないように分離して維持されるか、または独立している。第２タイプのコントロールブロックは、第１タイプのコントロールブロックよりサイズがより大きいので、第２のメモリは、第１のメモリよりサイズがより大きいことでこれに順応し得る。

先に記載のように、適切なハンドシェイクＡＣＫが（図４Ｂの決定４２２で決定されるように）受信されない場合、そのときは、別のＳＹＮが受信されているか否かが決定される。

ここで、図４Ｃを参照して、最初に、別のＳＹＮパケットがオフロードエンジンによって受信されているか否かが決定される。決定４４１に注目のこと。別のＳＹＮパケットが決定４４１につき受信されていない場合、その他のパケットタイプが、操作４５４中で処理される。そうであれば、しかし、図４Ａの決定４０６と同様に、次に、次のＳＹＮパケットが決定４４２で受取りされるべきである。第１の受信されたＳＹＮパケットについて注記したように、第２の受信されたＳＹＮパケットを受取りする決定は、ローカルホストによって、またはオフロードエンジンによってなされ得る。この第２の受信されたＳＹＮパケットが受取りされない場合、操作４５０によって示されるように、ＲＳＴパケットが生成され、そしてこの第２の受信されたＳＹＮパケットをもたらしたリモートホストに送信される。操作４５２を参照のこと。次いで、この方法４００は、リセットされて戻され、操作４４０によって示されるように、次のパケットを待つ。

第２の受信されたＳＹＮパケットが決定４４２によって受容されるとき、操作４４４によって示されるように、ハシュが前述のＳＹＮパケットのために生成される。操作４４４で生成されたハシュが第１の受信されたＳＹＮパケットについて生成されたハシュと異なる場合、第１のメモリの異なる部分が第２の受信されたＳＹＮパケットに割り当てられる。操作４４６を参照のこと。

操作４４４で生成されたハシュが、第１の受信されたＳＹＮパケットについて生成されたハシュと一致する場合、第１の受信されたＳＹＮパケットについて第１のメモリ中に割り当てられたメモリの部分は、操作４４６において第２の受信されたＳＹＮパケットのための接続パラメータによって上書きされる。換言すれば、第１のＳＹＮパケットに関連する上書きされたコントロールブロックのパラメータは、ハシュ衝突の場合には、第２のＳＹＮパケットのパラメータで置換され得る。

この第２のＳＹＮパケットがリモートホストによる再送信ＳＹＮパケットである場合、これらパラメータは、ＣＢ中で上書きされない。なぜなら、この第２のＳＹＮパケットは、同じ接続試行のためであるからである。受信されたＳＹＮに対するハシュが、第１または第２の受信されたＳＹＮパケットのいずれか（または両方）に一致するときは、アタックのコンポーネントであり得るか、または、それは、ＳＹＮパケットを再送信するリモートホストによって引き起こされているかも知れない。さらにより多くのＳＹＮパケットが「ＴＣＰ三方向オープンハンドシェイク」を終了する接続なくして受信されるとき、第１のメモリは、過負荷であるリスクにある。いずれの場合にも、先に受信されたＳＹＮパケットと一致するハシュ値の引き続き受信された受取りＳＹＮパケットが、第１のメモリの対応する部分を上書きすることを可能にすることは、この第１のメモリが過負荷でないことを確実にする。

第２の受信されたＳＹＮパケットが第１の受信されたＳＹＮパケットと一致するか否かにかかわらず、ＳＹＮパケットが受取りされる場合、操作４４８に示されるように、ＳＹＮ／ＡＣＫパケットが生成され、そして第２の受信されたＳＹＮパケットをもたらしたリモートホストに戻って送信される。

ここで、図４Ｄを参照して、方法４００は、図４Ｃから継続して、操作４６０におけると同じに待つことにより、次のパケットを収容する。特に、ＳＹＮパケットに対するハンドシェイクＡＣＫが受信されたか否かが最初に決定される。決定４６２を注目のこと。ハンドシェイクＡＣＫがないとき、この方法は、操作４６４に示されるように、従って、受信されたパケットを所有している。

しかし、受信されたパケットがＡＣＫである場合、ハシュが生成される。操作４６６を参照のこと。生成されたハシュにより指定されたＨＯ−ＣＢは、次に、操作４６７に示されるように取り出される。このＨＯ−ＣＢから取り出されたパラメータは、次いで、受信されたＡＣＫがハンドシェイクＡＣＫであるか否かを決定するために用いられる。そうであれば、ハンドシェイクＡＣＫからのパラメータは、このＨＯ−ＣＢ内に含まれたパラメータと比較される。

それらが一致しない場合、ＡＣＫパケットは棄てられ、そしてこのプロセスは、パケットを待つことに復帰する。操作４７０を参照のこと。これは、第１のＳＹＮパケットについてのハンドシェイクＡＣＫが、第１の受信されたＳＹＮパケットと一致したハシュを有した第２のＳＹＮパケットを受けた後に受信される場合である。この場合、第１の受信されたＳＹＮのＨＯ−ＣＢパラメータは、第２の受信されたＳＹＮが受信されたときに上書きされていたのであろう。従って、第１の受信されたＳＹＮに対するハンドシェイクＡＣＫが受信され、そして対応するＨＯ−ＣＢが取り出され、取り出されたパラメータは、第２の受信されたＳＹＮパケットのパラメータであり得、そしてそれ故、第１の受信されたＳＹＮパケットに対するハンドシェイクＡＣＫのパラメータに一致しないであろう。

ＨＯ−ＣＢから取り出されたパラメータが、決定４６８において、受信されたハンドシェイクＡＣＫ中のパラメータにまさに一致する場合、このプロセスは、図４Ｂに概説されるのと同じステップに従う。詳細には、操作４７２においてサーバーソケットが開放される。受信されたハンドシェイクＡＣＫと関連する接続のＨＯ−ＣＢを記憶するために用いられた第１のメモリ中の部分は、操作４７４に示されるように割り当てを解かれる。さらに、第２のメモリの部分が、操作４７６に示されるように、ここで、オープン接続を探知かつ維持するために割り当てられる。

図４Ｅは、図４Ｂ／４ＤのハンドシェイクＡＣＫまたは図４Ｃの別のＳＹＮパケットのいずれもが受信されない場合を示す。使用において、さらなるＳＹＮ／ＡＣＫパケットが、適切なハンドシェイクＡＣＫ応答を引き出す目的で、ＳＹＮパケットに応答して定期的に再送信される。操作４８２に注目のこと、オプションとして、このＳＹＮ／ＡＣＫパケットは、対応するコントロールブロックと関連するタイムスタンプに基づき再送信される。多くのＳＹＮ／ＡＣＫパケットの再送信の後、ハンドシェイクＡＣＫが凝視しても受信されない場合、オフロードエンジンは、接続試行が打ち切られたと見なし得る。決定４８０を参照のこと。試行される再送信の数は、予備決定され得るか、および／またはユーザーが構成し得る。接続試行が打ち切られたと見なされる場合、この接続試行のために割り当てられた第１のメモリ中の部分は、割り当てを解かれ、そして将来の試行のために用いられるように自由になる。操作４８４を参照のこと。

図５は、例示の実施形態による、メモリ過負荷の問題を避けながら、ネットワーク接続を確立するための例示の設計および操作５００を示す。オプションとして、この設計および操作５００は、先の図に開示のコンテクストで実施され得る。しかし、勿論、この設計および操作５００は、任意の所望のコンテクストで履行され得ることに注目すべきである。最も重要なことは、この設計および操作５００は、例示目的のみのために提示され、そしていかなる様式においても限定すると解釈されるべきではない。本明細書の文脈では、ホストドライバは、オフロードエンジンと組み合わせて稼動するローカルホストにあるＳＷコンポーネント（単数または複数）として規定される。

示されるように、例示の設計および操作５００は、プロセッサと関連し、次に、複数の例示のコンポーネントを備えるオフロードエンジン５０１と通信するホストドライバ５０２を示す。例えば、このオフロードエンジン５０１は、レシーバー５１８、例外処理器５２０、コントロールブロック（ＣＢ）ポラー５１６、指示ブロック（ＩＢ）ＦＩＦＯキュー５０４、ステータスメッセージ発生器５２２、ＩＢパーサ５０６、ＣＢメモリ５１２／５１４、ＣＢインターフェース５０８、先入れ先出し（ＦＩＦＯ）バッファ５１０、およびデータパケット発生器（図示せず）を含んで示され、これらは、示されるように接続される。種々のコンポーネントの機能性は、例示の設計および操作５００の使用の論議の間に本明細書で以後により詳細に提示される。

使用において、オフロードエンジン５０１は、レシーバー５１８を経由してＳＹＮパケケットを受信する。このＳＹＮパケットに関連するチェックサムが、次いで確認される。この確認が成功すると、ＳＹＮパケットは、例外パケットとして、例外処理器５２０を利用して、ホストドライバ５０２を経由しホストに送信される。ステータスメッセージがまた、ステータスメッセージ発生器５２２によって生成され、そしてＳＹＮパケットが受信されたことを示すホストドライバ５０２に送信される。

ホストにおいて、ドライバ５０２が、ＳＹＮパケットを、デスティネーションポート、ＩＰアドレス、およびＳＹＮパケットが受信されたインターフェースを再調査することによって調査し、オープンされるべき接続と関連しているか否かを決定する。インターネットプロトコールセキュリティ（ＩＰＳＥＣ）が用いられているとき、用いられている（または用いられていない）保護が、戦略テーブル中で確認される。

ドライバ５０２が即座の接続を可能にすることを希望する場合、それは、ＳＹＮＡＣＫＩＢを発行する。このＩＢは、次いで、オフロードエンジン５０１によって、最初ＦＩＦＯキュー５０４を利用して記憶／待ち行列に入れ、そして次にＩＢパーサ５０６を利用して解析されることにより、ハードウェア処理され得る。このＩＢは、一旦ソケットが確立された状態に移動すると用いられるべきＣＢハンドルを含めて、接続のために半オープン（ＨＯ）コントロールブロック（ＣＢ）を生成するために必要なすべての情報を含み得る。

オフロードエンジン５０１は、一旦、これが、ＳＹＮＡＣＫを受けると、インターフェース５０８および関連するコンポーネントを利用してＨＯＣＢを生成し得、そしてＳＹＮパケットに応答してＳＹＮ／ＡＣＫパケットを送り出す。ハンドシェイクＡＣＫが、リモートホストから受信されると、このＨＯＣＢは、提供されたハンドルを用いてオープンＣＢに移され得る。その時点で、「ソケット確立された」ステータスメッセージが生成され得る。

しかし、ホストが、先の接続が確立されたステータスに到達する前に、先に受信した接続試行と一致するハシュを生成する別のＳＹＮパケットを受信すると、先のＨＯＣＢは、新たな接続試行パラメータで上書きされる。これは、オフロードエンジン５０１のための過負荷保護を提供する。ステータスメッセージが、この状況においてホストドライバ５０２に送信され得、先のＨＯＣＢで用いられたＣＢハンドルが自由であり、かつ再び使用され得ることを示す。この時点で、ＣＢポラー５１６が、必要に応じて本明細書で上記に提示される様式で、ＳＹＮ／ＡＣＫパケット再送信を取り扱い得る。

図６は、例示の実施形態による、メモリ過負荷の問題を避けながら、ネットワーク接続を確立するための代替の設計および操作６００を示す。オプションとして、この設計および操作６００は、先の図に開示のコンテクストで実施され得る。しかし、勿論、この設計および操作６００は、任意の所望のコンテクストで履行され得ることに注目すべきである。最も重要なことは、この例示の設計および操作６００は、例示目的のみのために提示され、そしていかなる様式においても限定すると解釈されるべきではない。

示されるように、この例示の設計および操作６００は、図５に描写されるのと同じコンポーネントを示し、サーバーポートおよび情報テーブル６０２、ならびにＣＢアロケータ６０４をさらに備える。

使用において、オフロードエンジン５０１は、レシーバー５１８を経由してＳＹＮパケケットを受信する。このＳＹＮパケットに関連するチェックサムが、次いで確認される。この確認が成功すると、ＳＹＮパケットにより特定されるＴＣＰポートが、サーバーポートおよび情報テーブル６０２中でチェックされる。

ポートが接続を受取りするために許可されていると見なされると、ＨＯ−ＣＢが、ＳＹＮパケット中に受信されたパラメータおよびサーバーポート中のデスティネーションポートと関連するパラメータ、ならびに情報テーブル６０２を用いて、ＨＯＣＢメモリ５１４中に生成される。次いで、ＳＹＮ／ＡＣＫ応答が、ＦＩＦＯ５１０を経由してレシーバー５１８によってリクエストされる。この接続試行のためのハンドシェイクＡＣＫが、リモートホストから受信されるとき、ＨＯＣＢは、ＣＢアロケータ６０４によって提供されるハンドルを用いてオープンＣＢに移され得る。その時点で、「ソケット確立された」ステータスメッセージが、ステータスメッセージ発生器５２２を経由して生成され得る。

しかし、オフロードエンジン５０１が、先の接続が確立されたステータスに到達する前に、別のＳＹＮパケットを受信すると、先のＨＯＣＢは、第２の受信されたＳＹＮパケットにより生成されたハシュが先の接続試行の受信されたＳＹＮのハシュと一致する場合、新たな接続試行パラメータで上書きされ得る。これは、オフロードエンジン５０１のための過負荷保護を再び提供する。ステータスメッセージは、この場合、ホストドライバに送信される必要はなくてもよい。なぜなら、ホストドライバは、接続が確立されたときのみ情報を得ればよいからである。

種々の実施形態を上記に記載したが、それらは例示のみであって、そして限定ではなく提示されていることを理解すべきである。従って、好適な実施形態の幅および範囲は、上記の例示の実施形態のいずれによっても限定されるべきではなく、上記の請求項およびそれらの均等物に従ってのみ規定されるべきである。

（要約）
ネットワーク接続を確立するためのシステムおよび方法が提供される。最初、ネットワーク上の接続を確立するための試行が識別される。メモリの一部分が、次に、この接続に関連するデータを記憶するために割り当てられる。

ネットワーク接続を確立するためのシステムおよび方法を利用する任意の産業において有用である。

先行技術の図１は、先行技術による、ネットワーク接続が確立される方法を示す。 図２は、１つの実施形態による、ネットワークシステムを示す。 図３は、１つの実施形態が実行され得る例示のアーキテクチャーを示す。 図４Ａは、１つの実施形態による、メモリ過負荷の問題を避けながらネットワーク接続を確立するための例示の方法を示す。 図４Ｂは、１つの実施形態による、ハンドシェィク受取り（ＡＣＫ）が、図４Ａの第１の同期（ＳＹＮ）パケットＡＣＫに応答して受信される場合におけるネットワーク接続確立法を示す。 図４Ｃは、図４Ａの第１のＳＹＮパケット後、別のＳＹＮパケットが受信されるが、ハンドシェイク前に、ＡＣＫが第１のＳＹＮ／ＡＣＫに応答して受信される場合における、ネットワーク接続確立法を示す。 図４Ｄは、１つの実施形態による、図４Ｃのネットワーク接続確立法の続きを示す。 図４Ｅは、接続試行に対し、さらなるＡＣＫまたはその他のＳＹＮが受信されない場合における、ネットワーク接続確立法を示す。 図５は、ＳＹＮパケットを受取りする決定がホストドライバによって実施される場合について、例示の実施形態による、メモリ過負荷の問題を避けながら、ネットワーク接続を確立するための例示の設計および操作を示す。 図６は、ＳＹＮパケットを受取りする決定がオフロードエンジンによって実施される場合について、例示の実施形態による、メモリ過負荷の問題を避けながら、ネットワーク接続を確立するための例示の設計および操作を示す。

Claims (22)

1. ネットワーク接続を確立するための方法であって：
   ネットワーク上の接続を確立するための試行を識別する工程；および
   該接続に関連するデータを記憶するためのメモリの部分を割り当てる工程、を包含する、方法。
2. 請求項１に記載の方法であって、接続を確立するための第２の試行が先の試行と関連する少なくとも１つの局面を有する場合に、前記メモリの部分がメモリ過負荷を避けるために上書きされる、方法。
3. 前記ネットワーク上の接続を確立するための各々の試行が、パケットを識別することにより実施される、請求項２に記載の方法。
4. 前記パケットが、同期パケットである、請求項３に記載の方法。
5. 前記パケットにパケット受取りで応答する工程をさらに包含する、請求項３に記載の方法。
6. 前記ネットワーク上の接続を確立するための試行と関連する各パケットと関連するハシュを生成する工程をさらに包含する、請求項３に記載の方法。
7. 前記ハシュが、接続を確立するための次の試行が、先の試行と関連する少なくとも１つの局面を有するか否かを決定するために利用される、請求項６に記載の方法。
8. 前記少なくとも１つの局面が、ＩＰアドレスを含む、請求項７に記載の方法。
9. 前記少なくとも１つの局面が、ＴＣＰポートを含む、請求項７に記載の方法。
10. 前記ハシュが前記メモリの部分に記憶されたデータへのポインタとして供され、そして該データがコントロールブロックを含む、請求項７に記載の方法。
11. 接続試行と関連する複数のコントロールブロックが、オープン接続と関連する複数のコントロールブロックに対してサイズがより小さい、請求項１０に記載の方法。
12. 前記コントロールブロックが、ハンドル、ＩＰアドレス、ＴＣＰポート、およびタイムスタンプを含む、請求項１０に記載の方法。
13. 前記メモリが、接続試行と関連するデータのために割り当てられる第１のメモリを含む、請求項１に記載の方法。
14. 前記第１のメモリから論理的に分離された第２のメモリが、オープン接続と関連するデータのために割り当てられ、前記第１のメモリの過負荷が前記オープン接続に影響しない、請求項１３に記載の方法。
15. 前記第２のメモリが、前記第１のメモリが割り当てられる第１のタイプのコントロールブロックに対してサイズがより大きい第２のタイプのコントロールブロックに対し割り当てられる、請求項１４に記載の方法。
16. 前記接続試行のハンドシェイク受取りの受信に際し、前記メモリの部分の割り当てを解く工程をさらに包含する、請求項１に記載の方法。
17. 前記接続試行が成功する際に、オープン接続のために別のメモリ部分を割り当てる工程をさらに包含する、請求項１６に記載の方法。
18. 前記メモリ過負荷が、サービス否認アタックから生じる、請求項２に記載の方法。
19. 前記ネットワーク上の接続を確立する各試行が、プロセッサに同期パケットを送信することにより処理され、該同期パケットが受取りされるか否かを決定する、請求項１に記載の方法。
20. 前記ネットワーク上の接続を確立する各試行が、オフロードエンジンを利用することにより処理され、同期パケットが受取りされるか否かを決定する、請求項１に記載の方法。
21. メモリ過負荷の派生を避けながらネットワーク接続を確立するためのオフロードサブシステムであって：
    ネットワーク上の接続を確立する試行を識別し、かつ該接続と関連するデータを記憶するためのメモリの部分を割り当てるためのオフロードエンジンを備え、
    ここで、該メモリの部分が、該メモリの過負荷をされるために上書きされる、オフロードサブシステム。
22. メモリ過負荷の問題を避けながらネットワーク接続を確立するためのシステムであって：
    プロセッサ；
    バスを経由して該プロセッサおよびネットワークと通信するオフロードエンジンであって、該ネットワーク上の接続を確立する試行を識別し、かつ該接続と関連するデータを記憶するためのメモリの部分を割り当てるためのオフロードエンジン；を備え、
    ここで、該メモリの部分が、該メモリの過負荷をされるために上書きされる、システム。

Images