エンドポイント間認証状態を保ったデータ・パケットの圧縮
エンドポイント間の単一通信セッションの連続データ・パケットを圧縮用に収集し、少なくともそのペイロードを単一圧縮可能バッファを介して集合的に圧縮する。圧縮してもしなくてもよい元のヘッダと、圧縮されたペイロードとは、送信側のパケット圧縮装置から受信側のパケット圧縮装置に送信される。この受信側のパケット圧縮装置は、圧縮されたペイロードに対して解凍を行い、送信側で圧縮されていればヘッダも解凍することができる。ヘッダとペイロードを含む元の連続データ・パケットを、ヘッダと対応するペイロードを照合することによって、受信側のパケット圧縮装置で再構築することができる。再構築されたデータ・パケットは単一の通信セッションに投入され、再構築されたデータ・パケットに元のヘッダが存在することによって、エンドポイント間の認証プロトコルを維持することができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、エンドポイント間認証状態を保ったデータ・パケットの圧縮に関する。
【背景技術】
【０００２】
コンピュータは、通常、ネットワークを介してデータ・パケットを交換することによって通信する。ネットワークでは、或るエンドポイントから別のエンドポイントへデータ・パケットを伝送するために利用できる帯域幅は限られている。その利用可能な帯域幅によって、コンピュータがデータ・パケットを交換できる速度は制限される。結果として、データ・パケットの伝送速度が不十分であると効率が落ちてしまう。非営利のユーザにとって、伝送速度が不十分だと苛立つこととなろう。また商業利用の場合、伝送が遅いと生産性や利益率が低下する。
【０００３】
企業においては、例えば複数の物理的位置の間で、エンド・ツー・エンド接続を維持していることが多い。例えば、本部や幾つかの支部が存在する。データ・パケットのスループットを上げるため、各エンドポイントは、送信装置と受信装置の間に論理的に配置されたアクセラレータ装置を使用する。当該アクセラレータ装置は、下流の装置を宛先とするデータ・パケットを受信するという点でネットワーク透過な装置であり、パケットを変えずにそのまま通すか、パケットを収集して圧縮し、圧縮状態で送信する。
【０００４】
アクセラレータ装置は、スループットを増大させユーザ・エクスペリエンスを高めるためにデータ・パケットのペイロードを圧縮する。しかし、アクセラレータ装置は、元のヘッダを破棄することによって着信パケットのトランスポート層ストリームを止め、ペイロードを送達するプロキシ・サービスとして行動する。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
アクセラレータ装置は所望の圧縮を提供できるが、トランスポート層ストリームの停止は問題を引き起こす。１つの具体的な例として、ＩＰＳｅｃ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｉｔｙ）やＳＭＢ（Ｓｅｒｖｅｒ Ｍｅｓｓａｇｅ Ｂｌｏｃｋ）署名のようなエンドポイント間認証プロトコルが最早利用できなくなる。
【課題を解決するための手段】
【０００６】
実施形態では、エンドポイント間の認証プロトコルを維持できるように通信セッションの元のヘッダを保存しつつ、エンドポイント間の単一通信セッションの連続データ・パケットを圧縮する。当該連続データ・パケットの少なくともペイロードを、少なくとも１つの圧縮可能バッファを介して圧縮し、それによって当該連続データ・パケットのペイロードを個別にではなく１つのグループとして集合的に圧縮する。第１の単一通信セッションの連続データ・パケットの圧縮されたヘッダと元のヘッダを伝送するために、送信装置と受信装置の間の第２の単一通信セッションに対応する別のデータ・パケットを受信装置に送信する。受信装置は少なくとも圧縮されたペイロードを解凍し、次いで元のヘッダを元のペイロードと照合することによって、エンドポイント間の第１の単一通信セッションの元の連続データ・パケットを再構築する。次いで、再構築した連続データ・パケットをエンドポイント間の第１の単一通信セッションに受信装置側で挿入して、受信装置から連続データ・パケットの各々を、元の連続データ・パケットの宛先であるエンドポイント装置に送達することができる。
【０００７】
本要約は、選択した概念を簡潔な形で紹介するために与えた。その概念は、後で「発明を実施するための形態」でさらに説明する。本要約はクレーム主題の主要な特徴または本質的な特徴を特定しようとするものではなく、クレーム主題の範囲を限定するために使用しようとするものでもない。
【図面の簡単な説明】
【０００８】
【図１Ａ】データ・パケット圧縮装置の様々な実施形態向けの例示的な環境を示す図である。
【図１Ｂ】２つのデータ・パケット圧縮装置がネットワークを介して通信する例示的な実施形態を示す図である。
【図２Ａ】エンドポイント間の単一通信セッションにおける１組の連続データ・パケットの少なくともペイロードを集合的に圧縮するための１組の論理動作の例を示す図である。
【図２Ｂ】１組の連続データ・パケットの少なくともペイロードを解凍し、当該連続データ・パケットを元の形に再構築するための１組の論理動作の例を示す図である。
【図３Ａ】図２Ａの論理動作中のように、着信データ・パケットを圧縮できることを分析するための１組の論理動作の例を示す図である。
【図３Ｂ】図２Ａの論理動作中のように、１組の着信連続データ・パケットの少なくともペイロードを含む少なくとも１つの圧縮可能バッファの圧縮開始を決定するための１組の論理動作の例を示す図である。
【図４Ａ】エンドポイント間の単一通信セッションにおける１組の連続データ・パケットが、未圧縮状態で収集されてから圧縮され送信されるまでの進展を示す図である。
【図４Ｂ】エンドポイント間の単一通信セッションにおける１組の連続データ・パケットを圧縮状態で受信してから解凍して、元の形で単一通信セッションの出て行くストリームに投入するまでの進展を示す図である。
【発明を実施するための形態】
【０００９】
実施形態では、エンドポイント間の単一通信セッションにおける１組の連続データ・パケットを圧縮し、圧縮した１組のデータ・パケットを受信装置に送信する。圧縮には、ペイロードのみの圧縮、またはヘッダとペイロードの両方の圧縮を含めることができる。圧縮したペイロードと元のヘッダは双方とも、圧縮されるかまたは圧縮されずに受信装置へと伝送され、次いで、当該受信装置は少なくともペイロードを解凍し元の１組の連続データ・パケットを再構築する。圧縮の前に、圧縮可能な連続データ・パケットを選択し、少なくとも１つの圧縮可能バッファに含まれるデータの量を最大化する論理を使用することができる。
【００１０】
図１Ａは様々な例示的な実施形態に対する動作環境の１例を示す。本例では、幾つかのピア・デバイスは様々な場所に存在でき、ネットワーク１０６を通して、他所にある様々なピア・デバイスと継続して通信できる。例示のために、第１の場所には、ネットワーク・スイッチのようなノード１０１に接続された第１のピア・デバイス１０２と第３のピア・デバイス１０３がある。ノード１０１は、第１のピア・デバイス１０２と第３のピア・デバイス１０３から送られたデータ・パケットを受信する。次いで、ノード１０１は他所宛てのデータ・パケットを第１のパケット圧縮装置１０４に転送する。ノード１０１は、また、第１のパケット圧縮装置１０４からデータ・パケットを受信して、当該パケットを第１のピア・デバイス１０２か第３のピア・デバイス１０３宛に送ることができる。
【００１１】
第１のパケット圧縮装置１０４は、ネットワーク透過な装置である。なぜなら、第１のピア・デバイス１０２と第３のピア・デバイス１０３からのパケットの宛先は第１のパケット圧縮装置１０４ではなく、当該パケットはネットワーク１０６を通ってさらに遠くへ送達するために第１のパケット圧縮装置１０４を通るからである。様々な数のピア・デバイスがこの場所に存在でき、第１のピア・デバイス１０２のみが存在する場合は、第１のピア・デバイス１０２を第１のパケット圧縮装置１０４に直接接続できることは理解されよう。さらに、本例で示すように、第１のパケット圧縮装置１０４をスタンドアロンの装置とせず、第１のパケット圧縮装置１０４の機能を第１のピア・デバイス１０２に統合してもよい。
【００１２】
また、例示のために、第２の場所にはノード１０９に接続された第２のピア.デバイス１１０と第４のピア・デバイス１１１がある。ノード１０９は、第２のピア・デバイス１１０と第４のピア・デバイス１１１からデータ・パケットを受信する。次いで、ノード１０９は、他所宛てのデータ・パケットを第２のパケット圧縮装置１０８に転送する。ノード１０９は、また、データ・パケットを第２のパケット圧縮装置１０８から受信し、当該データ・パケットを第２のピア・デバイス１１０または第４のピア・デバイス１１１宛に送ることができる。
【００１３】
第１のパケット圧縮装置１０４と同様、第２のパケット圧縮装置もネットワーク透過な装置である。なぜなら、第２のピア・デバイス１１０と第４のピア・デバイス１１１からのパケットの宛先は、第２のパケット圧縮装置１０８ではなく、これらのパケットはネットワーク１０６を通ってさらに遠くへ送達するために、第２のパケット圧縮装置１０８を通るからである。様々な数のピア・デバイスがこの場所に存在でき、第２のピア・デバイス１１０のみが存在する場合は、第２のピア・デバイス１１０は第２のパケット圧縮装置１０８に直接接続できることは理解されよう。さらに、本例で示すように、第２のパケット圧縮装置１０８をスタンドアロンの装置とせず、第２のパケット圧縮装置１０８の機能を第２のピア・デバイス１１０に統合してもよい。
【００１４】
第１のピア・デバイス１０２が、第２のピア・デバイス１１０または第４のピア・デバイス１１１宛てのデータ・パケットを送る場合、パケット圧縮装置１０４は第１のピア・デバイス１０２によって送られている１組の連続データ・パケットを、少なくとも１つの単一圧縮可能バッファの単一データ・セットとして圧縮することができる。圧縮には、連続データ・パケットのペイロードの圧縮か、当該連続データ・パケットのヘッダとペイロードの圧縮を含めることができる。次いで、ヘッダと圧縮されたペイロードを第２のパケット圧縮装置１０８に送信し、そこでペイロードを解凍し、必要ならばヘッダを解凍する。次いで、ヘッダをペイロードと照合し、第１のピア・デバイス１０２から送られた元のデータ・パケットを再構築する。次いで、第２のパケット圧縮装置１０８は、再構築された元のデータ・パケットを第１のピア・デバイス１０２と第２のピア・デバイス１１０または第４のピア・デバイス１１１の間の通信セッションに投入して、元のデータ・パケットを目的の宛先に送達する。
【００１５】
同じ働きを逆方向に行うことができる。この場合、第２のピア・デバイス１１０がデータ・パケットを第１のピア・デバイス１０２か第３のピア・デバイス１０３に送っている。第２のパケット圧縮装置１０８は、少なくともペイロードを圧縮し、元のヘッダと圧縮されたペイロードを第１のパケット圧縮装置１０４に送信する。次いで、第１のパケット圧縮装置１０４は、必要ならばペイロードとヘッダを解凍し、第２のピア・デバイス１１０から送られた元のパケットを再構築する。
【００１６】
例示のために、第１のピア・デバイス１０２が第２のピア・デバイス１１０と通信している場合は、これらのエンドポイント間で第１の通信セッション１１３が、例えばそれらの間でネットワーク１０６を介してトランスポート層ストリームを生成することによって確立されている。第１のピア・デバイス１０２がネットワーク１０６を介してデータを第２のピア・デバイス１１０に送ろうとすると、連続的なバイト・ストリームが第１の通信セッション１１３を通って流れる。この場合、当該バイト・ストリームは、それぞれがヘッダとペイロードを有するデータ・パケットのシーケンスを形成する。トランスポート層ストリームは、バイト・ストリームのこれらのデータ・パケット内部に存在するトランスポート層ヘッダによって維持される。
【００１７】
さらに、例示のために、パケット圧縮装置１０４がネットワーク１０６を介して、第１の通信セッション１１３のパケットを送信し続けるために受信している場合は、パケット圧縮装置１０４は当該パケットのうち少なくとも幾つかを圧縮用に収集することができる。次いで、圧縮されたデータ・パケットを、ネットワーク１０６を介して、パケット圧縮装置１０４とパケット圧縮装置１０８の間に確立された第２の通信セッション１１５を介して送信することができる。この第２の通信セッション１１５は、パケット圧縮装置１０４とパケット圧縮装置１０８の間で維持されるトランスポート層ストリームとして生成することができる。
【００１８】
図１Ｂは、第１のパケット圧縮装置１０４と第２のパケット圧縮装置１０８の１つの例示的な実装形態を示す。本例では、第１のパケット圧縮装置１０４と第２のパケット圧縮装置１０８は、第１のピア.デバイス１０２と第２のピア・デバイス１１０の間で行われるデータ通信に対して圧縮サービスを提供するために存在する。
【００１９】
この第１のパケット圧縮装置１０４の例示的な実装形態は、処理システムを形成する様々な構成要素を含む。本例では、第１のパケット圧縮装置１０４の処理システムが、カーネル・モード部１３４とユーザ・モード部１３２を含んでいる。カーネル・モード部１３４は、データ・パケットが第１のピア・デバイス１０２と第１のパケット圧縮装置１０４の間で交換されるように、第１のピア・デバイス１０２への物理接続または何らかの中間装置への物理接続を提供する第１のＮＩＣ（ｎｅｔｗｏｒｋ ｉｎｔｅｒｆａｃｅ ｃａｒｄ）１１２を介して、データを送受信する。ＮＤＩＳ（ｎｅｔｗｏｒｋ ｄｒｉｖｅｒ ｉｎｔｅｒｆａｃｅ ｓｐｅｃｉｆｉｃａｔｉｏｎ）層のようなデータ・リンク層１１４は、ＮＩＣ１１２と共に動作して、パケットをブリッジ１２０を介してデータ・リンク層１１８に渡す。データ・リンク層１１８は、当該パケットをネットワークおよびトランスポート層１２２へ渡す。ネットワークおよびトランスポート層１２２は、ネットワーク層向けのＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）、関連するトランスポート層向けのＴＣＰ（ｔｒａｎｓｍｉｓｓｉｏｎ ｃｏｎｔｒｏｌ ｐｒｏｔｏｃｏｌ）またはＵＤＰ（ｕｓｅｒ ｄａｔａｇｒａｍ ｐｒｏｔｏｃｏｌ）のようなプロトコルを利用することができる。データ・リンク層、ネットワーク層、およびトランスポート層の他の例もまた、上記の様々な実施形態に適用可能である。
【００２０】
この特定の例では、第１のパケット圧縮装置１０４は第１のピア・デバイス１０２とネットワーク１０６の間にあるデータ経路内に物理的に配置されている。従って、カーネル・モード部１３４は、第２のＮＩＣ１１６を介してデータを送受信し、パケットをネットワークおよびトランスポート層１２２に提供する関連データ・リンク層１１８を含む。ＮＩＣ１１６はパケットを、第１のピア・デバイス１０２のローカル・ネットワークを第２のピア・デバイス１１０のローカル・ネットワークに相互接続する広域ネットワークのようなネットワーク１０６を介して交換する。
【００２１】
第１のパケット圧縮装置１０４のデータ・リンク層１１８には、第１のピア・デバイス１０２から送られたパケットをデータ・セットに収集し、当該データ・セットをユーザ・モード部１３２の少なくとも１つの単一圧縮可能バッファ１２７に提供する収集エンジン１２４が接続されている。当該収集エンジンは、第１のパケット圧縮装置１０４のオペレーティング・システム・プラットフォームに応じて、ＮＤＩＳフィルタ・ドライバまたはＮＤＩＳ中間（ＩＭ）ドライバのようなドライバが可能である。
【００２２】
この例示的な実装形態の収集エンジン１２４は、カーネル部とユーザ・モード部を含む。カーネル・モード部は、連続データ・パケットをエンドポイント間の特定の入って来る通信セッションから収集し、収集した１組の連続データ・パケットを、ペイロードから分離されたヘッダを含むセグメントに分離する。カーネル部は当該セグメントをユーザ・モード部に渡す。当該ユーザ・モード部は、少なくともペイロードを圧縮すべき単一のデータ・セットとして少なくとも１つの単一圧縮可能バッファ１２７にロードすることを管理する。それにより、ユーザ・モード部１３２で、圧縮すべきセグメントを含むデータ・セットにバッファ１２７からアクセスし、当該データ・セットを圧縮し、第２のパケット圧縮装置１０８に送信することができる。
【００２３】
この例示的な実装形態のデータ・リンク層１１８は、また、第１のパケット圧縮装置１０４と第２のパケット圧縮装置１０８の間のストリームへ出て行くＤＳＣＰ値をマークするために使用されるＤＳＣＰ（ｄｉｆｆｅｒｅｎｔｉａｔｅｄ ｓｅｒｖｉｃｅｓ ｃｏｄｅ ｐｏｉｎｔ）マーカ１３６のようなＱｏＳ（ｑｕａｌｉｔｙ ｏｆ ｓｅｒｖｉｃｅ）マーカを維持することができる。発信パケットをマークして、圧縮されている元のデータ・パケット向けのサービス品質を保存することは、以下でさらに論ずる。
【００２４】
第１のパケット圧縮装置１０４のこの例示的な実装形態のユーザ・モード部１３２は、また、様々な構成要素を含む処理システムを形成する。上述のように、収集エンジン１２４は、エンドポイント間の所与の入って来る通信ストリームから、ＮＩＣ１１２を介して少なくともペイロードをバッファするユーザ・モード部を備える。次いで、収集エンジン１２４のユーザ・モード部は、少なくとも１組のペイロードを、少なくとも１つの単一圧縮可能バッファ１２７の単一のデータ・セットとして、圧縮エンジン１２８に提供する。
【００２５】
圧縮エンジン１２８は、少なくとも当該ペイロードを、少なくとも１つの単一圧縮可能バッファ１２７の単一のデータ・セットとして、収集エンジン１２４から受け取り、少なくとも１つの単一圧縮可能バッファ１２７から得た少なくともペイロードを単一データ・セットとして圧縮するための１つまたは複数の圧縮アルゴリズムを実行する。少なくとも１つの単一圧縮可能バッファから得た少なくともペイロードを、単一のデータ・セットとして圧縮することによって、圧縮エンジン１２８は個別ではなく集合的にペイロードを圧縮している。圧縮されている単一のデータ・セットのサイズを増加させることによって、圧縮率を高めることができる。
【００２６】
圧縮エンジン１２８は、以前に参照したデータと、様々な圧縮アルゴリズムを実行するときに利用できる他の参照情報とから成る辞書を維持するため、記憶装置１３０を利用できる。さらに、圧縮エンジン１２８は、少なくとも１つの単一圧縮可能バッファのペイロードの内容に対して或るアルゴリズムを使用することができ、ヘッダを含む別の単一圧縮可能バッファに対して別のアルゴリズムを使用することができる。
【００２７】
ヘッダを含む圧縮可能バッファのヘッダ内容に適用できる圧縮アルゴリズムの例には、様々な差分アルゴリズムおよび様々なステートレス圧縮アルゴリズムがある。差分アルゴリズムの例には、ＲＦＣ（Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔ）１１４４、２５０７、２５０８、２５０９、３０９５、および４８１５に記載されているものがあり、これらは引用によって本明細書に取り込まれる。ステートレス圧縮アルゴリズムの例にはＬＺＷ（Ｌｅｍｐｅｌ−Ｚｉｖ−Ｗｅｌｃｈ）またはハフマン符号化が含まれる。
【００２８】
ペイロードを含む圧縮可能バッファの内容に適用できる圧縮アルゴリズムの例には、様々なステートフル差分アルゴリズムや様々なステートレス圧縮アルゴリズムがある。ステートフル差分アルゴリズムの例には、ＤＦＳＲ（Ｄｉｓｔｒｉｂｕｔｅｄ Ｆｉｌｅ Ｓｙｓｔｅｍ Ｒｅｐｌｉｃａｔｉｏｎ）で使用されるＲＤＣ（Ｒｅｍｏｔｅ Ｄｉｆｆｅｒｅｎｔｉａｌ Ｃｏｍｐｒｅｓｓｉｏｎ）が含まれる。ステートレス圧縮アルゴリズムの例には、ＬＺＷやハフマン符号化が含まれる。
【００２９】
送信エンジン１２６は、圧縮されたデータ・セットを圧縮エンジン１２８から受け取る。次に、送信エンジン１２６は、第１のパケット圧縮装置１０４と第２のパケット圧縮装置１０８の間にある第２の通信セッションを介してデータ・セットを送る。送信エンジン１２６は、ネットワークおよびトランスポート層１２２を利用してデータ・セットをパケット化し、結果として得たパケットをデータ・リンク層１１８およびＮＩＣｌ１６を介して、第２の通信セッションを通して第２のパケット圧縮装置１０８に送ることができる。従って、圧縮されたパケットは集合的に圧縮された形で、ネットワーク１０６を介してトンネリングする。
【００３０】
本例に対して示した第１のパケット圧縮装置１０４の構成要素は、第１のピア・デバイス１０２から入って来るデータ・パケットの収集、圧縮、送信に関連する構成要素である。第１のパケット圧縮装置１０４と第２のパケット圧縮装置１０８は、１方向に流れるデータに対して、第１のパケット圧縮装置１０４が、収集、分割、圧縮、および送信を行うことができ、第２のパケット圧縮装置１０８が、受信、解凍、再構築、および第２のピア・デバイス１１０へのストリームに再び投入する補完機能を行うという意味で、互いに補完する装置になれることは理解されよう。逆方向に流れるデータに対しては、第２のパケット圧縮装置１０８が、収集、分割、圧縮、および送信を行い、第１のパケット圧縮装置１０４が、受信、解凍、再構築、および第１のピア・デバイス１０２へのストリームに再び投入することができる。
【００３１】
従って、第１のパケット圧縮装置１０４を１組の構成要素で示し、第２のパケット圧縮装置１０８を別の補完的な組の構成要素で示してあるが、第１のパケット圧縮装置１０４は第２のパケット圧縮装置１０８に対して示した構成要素を含んでもよく、第２のパケット圧縮装置１０８は第１のパケット圧縮装置１０４に対して示した構成要素を含んでもよいことは理解されよう。
【００３２】
第２のパケット圧縮装置１０８に対して示した例示的な実装形態は、また、カーネル・モード部、ネットワーク１０６とインタフェースするためのＮＩＣ１３８、および第２のピア・デバイス１１０とインタフェースするためのＮＩＣ１４６を備える。第２のパケット圧縮装置１０８は、データ・リンク層１４０および１４８、分配エンジン（ｓｃａｔｔｅｒ ｅｎｇｉｎｅ）１３９、ブリッジ１５０、ならびにネットワークおよびトランスポート層１４２を備える。この例示的な実装形態のユーザ・モード部は、受信エンジン１４４、解凍エンジン１５２、および記憶装置１５４を備える。
【００３３】
第１のパケット圧縮装置１０４との第２の通信セッションから取得され、従って宛先がこの第２のパケット圧縮装置１０８であるパケットは、ＮＩＣ１３８を介して第１の圧縮装置から受信され、ネットワークおよびトランスポート層１４２（例えば、ＴＣＰ／ＩＰ）に渡される。このネットワークおよびトランスポート層１４２は、次いで、パケットのペイロードを抽出し指定の順番でペイロードを繋ぎ合せることによってパケットを分解する。さらに、このネットワークおよびトランスポート層１４２は、アプリケーション・データを受信エンジン１４４に提供する。この情報は、第１のパケット圧縮装置１０４の送信エンジン１２６から送信された圧縮されたデータ・セットであり、この場合、当該圧縮されたデータ・セットは、第１のピア・デバイス１０２から得た元のパケットの、圧縮されたヘッダか圧縮されていないヘッダのいずれか１つ、および圧縮されたペイロードを含む。受信エンジン１４４はこのデータ・セットを解凍エンジン１５２に提供する。
【００３４】
第２のパケット圧縮装置１０８の解凍エンジン１５２は、第１のパケット圧縮装置１０４の圧縮エンジン１２８が使用する圧縮アルゴリズム（複数可）に対して補完的な解凍アルゴリズム（複数可）を利用してデータ・セットを解凍する。解凍する際、解凍エンジン１５２は、第１のパケット圧縮装置１０４の記憶装置１３０のものに対して補完的な辞書および他の参照情報を含む、記憶装置１５４の辞書および他の参照情報を参酌することができる。
【００３５】
解凍エンジン１５２は、元のデータ・パケットのヘッダと解凍されたペイロードとを含むセグメントを、分配エンジン１３９のユーザ・モード部によって管理されるバッファに提供する。分配エンジン１３９は、最終的に、通信セッションが割り込まれないように、解凍されたパケットをパケットの発生源であるエンドポイント間の通信セッションに割り振り戻す。分配エンジン１３９のユーザ・モード部は、元のパケットの解凍されたヘッダ、ペイロード、および他の任意の部分を、例示的な実装形態の分配エンジンのカーネル・モード部に提供する。分配エンジン１３９は解凍したペイロードとヘッダを照合して元のパケットを再構築する。次いで、分配エンジン１３９は、その再構築された元のパケットを、ブリッジ１５０を介して第２のピア・デバイス１１０へのストリームに投入する。
【００３６】
図１Ｂの第１のパケット圧縮装置１０４と第２のパケット圧縮装置１０８は、例示の目的のために示したものであり、限定しようとするものではない。例えば、第１のパケット圧縮装置１０４と第２のパケット圧縮装置１０８をスタンドアロン構造として示したが、これらの装置を代わりにエンドポイントに組み込んでもよい。例えば、第１のパケット圧縮装置１０４を第１のピア・デバイス１０２の構造に組み込んで、ＮＩＣ１１２を削除してもよい。
【００３７】
さらに、第１のパケット圧縮装置および第２のパケット圧縮装置の実装形態は、幾つかのカーネル・モード要素と幾つかのユーザ・モード要素を含んでいたが、様々な構成要素とそれらの機能を代替構成で実装してもよいことは理解されよう。例えば、当該構成要素およびそれらの機能の全てをカーネル・モード内部で実装してもよい。
【００３８】
第１のパケット圧縮装置１０４および第２のパケット圧縮装置１０８の構成要素を、記憶装置１３０または１５４等のようなメモリに記憶したプログラムを実装する、ハードワイヤードロジック、ファームウェア、汎用のプログラム可能プロセッサで構成することができる。第１のパケット圧縮装置１０４および第２のパケット圧縮装置１０８を含む図１Ｂの装置と同様に、第１のピア・デバイス１０２および第２のピア・デバイス１１０は、様々なコンピュータ可読媒体を含むことができる。係るコンピュータ可読媒体は、本明細書で論じた装置を動作させ、本明細書で論じた実施形態を実装するための命令を含む。コンピュータ可読媒体は、コンピュータ・システムがアクセスできる任意の使用可能な媒体で可能であり、揮発性媒体および不揮発性媒体、取外し可能媒体および取外し不可能媒体の両方を含む。限定ではなく例として、コンピュータ可読媒体はコンピュータ記憶媒体および通信媒体を含むことができる。
【００３９】
コンピュータ記憶媒体には、コンピュータ可読命令、データ構造、プログラム・モジュール、または他のデータのような情報を記憶するための任意の方法または技術で実装した揮発性媒体および不揮発性媒体、取外し可能媒体および取外し不可能媒体が含まれる。コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、ＤＶＤ（ｄｉｇｉｔａｌ ｖｅｒｓａｔｉｌｅ ｄｉｓｋ）もしくは他の光ディスク記憶、磁気カセット、磁気テープ、磁気ディスク記憶もしくは他の磁気記憶装置、または所望の情報の記憶に使用でき、コンピュータ・システムによりアクセス可能な他の任意の媒体が含まれるがこれらに限らない。
【００４０】
通信媒体は、一般にコンピュータ可読命令、データ構造、プログラム・モジュール、または他のデータを搬送波または他の伝送機構のような変調データ信号で具現化し、任意の情報送達媒体を含む。「変調データ信号」という用語は、１つまたは複数のその特性集合を含むか、信号内の情報を符号化するように変化した信号を意味する。限定ではなく例として、通信媒体には有線ネットワークまたは直接配線接続のような有線媒体、ならびに音響、ＲＦ、赤外線、および他の無線媒体のような無線媒体が含まれる。以上の何れかの組合せもコンピュータ可読媒体の範囲に含まれるべきである。
【００４１】
図２Ａ〜図３Ｂは、データ・パケットを圧縮または解凍するための動作フローを示す。以下の図２Ａ〜図３Ｂの説明は、図１の圧縮装置１０４、１０８を参照して行う。しかし、図２Ａ〜図３Ｂを参照して説明するフローを圧縮装置１０４、１０８、または圧縮装置１０４、１０８の任意の特定の構成要素もしくは構成要素群によって実行されるものに限定しようとはしていないことは理解されよう。さらに、図２Ａ〜図３Ｂの動作フローは、特定のステップ順序を示すが、他の実装形態では当該動作を別の順序で行い、動作を追加し、且つ／または幾つかの動作を省略してもよいことは理解されよう。
【００４２】
図２Ａは、着信データ・パケットを圧縮するためにパケット圧縮装置の１つまたは複数の実施形態によって実行できる１組の論理動作を示す。本論理動作では、先ず分析動作２０２で、第１のパケット圧縮装置１０４のようなパケット圧縮装置および特に収集エンジン１２４が、ローカル・ピアからの着信パケットを圧縮できるかどうかを分析する。分析動作２０２で、宛先のピア・デバイスに対して、第２のパケット圧縮装置１０８のような受信側のパケット圧縮装置へ正しく送信するために必要な情報に関して当該着信パケットをさらに分析する。
【００４３】
暗号化されたもののような或る種のパケットは圧縮できない。なぜならば、効果的とするため圧縮せずにそれらのパケットを、受信側のパケット圧縮装置へ通す必要があり得るからである。分析動作２０２で、これらの圧縮できないパケットを発見して通過させることができる。分析動作２０２の１実装形態のさらなる詳細は後で図３Ａを参照して論ずる。
【００４４】
この時点で、圧縮可能な場合は正しく送信し、その圧縮可能なデータ・パケットを圧縮するために必要な情報を収集することができる。この情報には、パケットが属するトランスポート層ストリームを特定する４つ組の送信ポート、送信アドレス、宛先ポート、および宛先アドレスを含めることができる。圧縮するか否かを判定し、他のパケットと共に集合的な圧縮を編成するために必要な情報をこの時点で得ることもできる。当該情報には、各パケット内部のヘッダの位置、各パケット内部のペイロードの位置、および存在するかもしれない任意のトレーラの位置が含まれる。
【００４５】
収集動作２０４で、着信パケットの圧縮可能性の分析完了後に所与のトランスポート層ストリーム（例えば、ＴＣＰまたはＵＤＰストリーム）の圧縮可能パケットを、やはり圧縮可能な当該ストリームの他のパケットと共に圧縮可能バッファ１２７に収集する。これらの圧縮可能データ・パケットをデータ・セットへ収集することによって、全体のパケットまたはその選択されたセグメント（例えば、ペイロード）を少なくとも１つの単一圧縮可能バッファ１２７内部で提供することができる。ここで、圧縮可能パケットを、ヘッダ、ペイロード、および、もしあればトレーラに分解することができ、各セグメントは同一ストリームの類似するセグメント・タイプである他のデータ・パケットと共に別々にバッファされる。収集動作２０４の１実装形態のさらなる詳細は後で図３Ｂに関連して論ずる。
【００４６】
エンドポイント間接続の劣化を最小化するために、パケットを圧縮用にデータ・セットへ収集することは制限される必要があるかもしれない。例えば、少なくとも１つの単一圧縮可能バッファ１２７が埋まるのを待ってパケットの転送をあまりにも長時間遅らせると、トランスポート層でタイムアウトする恐れがある。従って、この時点で、エンドポイント間接続を劣化させずに圧縮率を望ましいレベルに保つため、当該データ・セットが圧縮を開始すべき点に達したかどうかを判定する。１実装形態に従うこの判定の詳細も後で図３Ｂに関連して論ずる。
【００４７】
次いで、圧縮を開始すべきと決定すると、１組のデータ・パケットまたはセグメントを少なくとも１つの単一圧縮可能バッファ１２７の内容として圧縮エンジン１２８に渡す。或る特定の状況下では、例えばその単一パケットの目的が新しいトランスポート層ストリームの開始か既存のトランスポート層ストリームの停止である場合、単一のパケットを圧縮エンジン１２８に直接渡して即座に圧縮し受信側の圧縮装置に送信してもよい。
【００４８】
少なくとも１つの単一圧縮可能バッファ１２７の内容を圧縮エンジン１２８に渡した後、その内容を圧縮動作２０６で圧縮する。この圧縮は、圧縮アルゴリズムが、１度に単一のパケットまたは単一のパケットのセグメントに作用するのではなく、少なくとも１つの単一圧縮可能バッファ１２７の複数のパケット、または複数のパケットのセグメントに作用して圧縮された出力を生成するという意味で集合的である。複数のデータ・パケットまたは複数のデータ・パケットのセグメントを含む少なくとも１つの単一圧縮可能バッファ１２７の内容を圧縮する場合、多くのデータに作用して圧縮結果を生成するので、圧縮率を高くすることができる。圧縮されたデータ・セットが圧縮エンジン１２８によって生成される。異なるアルゴリズムが異なるセグメント・タイプに使用される実施形態の場合は、セグメント・タイプごとに圧縮された１つのデータ・セットがあってもよい。あるいは、ペイロードを圧縮したデータ・セットを、ヘッダを含むデータ・セットと連結し、連結したデータを圧縮してもよい。
【００４９】
圧縮されたデータ・セットを生成した後、送信動作２０８で送信エンジン１２６は当該圧縮されたデータ・セットを受信側の圧縮装置に送信する。ここで、当該データ・セットはネットワークおよびトランスポート層１２２（例えば、ＴＣＰ／ＩＰ）に導入され、そこでパケット化され、受信側の圧縮装置との通信セッションを介して送信される。受信側の圧縮装置に送信されているこれらのパケットは、その中の圧縮データ・パケットが配信されているトンネルを提供しているので、トンネル・パケットである。圧縮および送信の例示的な１実装形態の諸工程は後で図４Ａに関連してより詳細に説明する。
【００５０】
圧縮されたデータ・セットを含む第１のパケット圧縮装置１０４から送られているデータ・パケットは、パケットが十分な優先度で送信されていることを保証するためのＱｏＳマーキングを有することができる。これらの発信パケットに対するＱｏＳマーキングを、ローカル・ピアから受け取った元のパケットのＱｏＳマーキングに基づいて選択することができる。例えば、着信パケットが特定のＱｏＳ優先度を有する場合、そのＱｏＳマーキング、例えばＤＳＣＰマーキングをメモリに記憶することができる。受信側の圧縮装置に送信されているトンネル・パケットを、同一のＤＳＣＰマーキングにより元のパケットとしてマークして、エンド・ツー・エンド接続に対する圧縮装置の透過性をさらに維持する。代替手段として、発信パケットに対するＱｏＳマーキングを元のデータ・パケットのＱｏＳマーキング以外の何らかの基準に基づいて選択してもよい。
【００５１】
図２Ｂは、着信データ・パケットのデータを解凍し、解凍したデータから元のパケットを再構築するための、圧縮装置の１つまたは複数の実施形態によって実行される１組の論理動作を示す。当該論理動作では、先ず、受信動作２１０で、第２のパケット圧縮装置１０８のような受信側の圧縮装置が、第１のパケット圧縮装置１０４のような送信側の圧縮装置によって送られたトンネル・パケットを受信する。トンネル・パケットの宛先が受信側の装置なので、パケットは受信側の圧縮装置のローカル・ピアへ渡されずにプロトコル層へ渡される。
【００５２】
ネットワークおよびトランスポート層１４２はパケットを受信し、それらをパケット動作２１２で分解して、送信側の圧縮装置によって以前に生成および送信された、圧縮されたデータ・セットを取り出す。受信エンジン１４４は、データ・セットを構成する圧縮されたデータを受け取る。ヘッダおよびペイロードを別々に圧縮した実施形態の場合は、当該データ・セットは別々のヘッダのデータ・セットとペイロードのデータ・セットを含む。受信エンジン１４４はこれらのデータ・セットを解凍エンジン１５２に渡す。
【００５３】
解凍動作２１４で、解凍エンジン１５２はデータ・セットを解凍する。送信側の圧縮装置によって実行された圧縮に補完的な解凍が使用される。圧縮されたデータ・セットは、圧縮アルゴリズムによって生成され、利用した圧縮技術を特定するヘッダを含むことができ、それによって解凍エンジン１５２は、圧縮されたデータ・セットからそのヘッダを読み、適切な解凍アルゴリズムを用いて解凍することができる。さらに、２つの補完的な圧縮装置の間には、どの圧縮アルゴリズムが利用されるかを記述する高レベルの取り決めが適切に存在してもよい。次いで、解凍されたデータ・セットは分配エンジン１３９に渡され、そこでパケットを再構築することができる。
【００５４】
再構築動作２１６で、分配エンジン１３９は、ヘッダ、ペイロード、および任意のトレーラを照合することによって元のデータ・パケットを再構築する。ここで、分配エンジン１３９は、解凍されたデータ・セットのメタデータを参照することによって、ヘッダをその対応するペイロードと照合して、セグメントのオフセットと厳密な長さに基づいてヘッダとペイロードの位置を特定する。ここで、ヘッダの順序はペイロードの順序と一致する。分配エンジン１３９は、また、必要に応じて、伝送されていないデータを付加することができる。例えば、イーサネット・ヘッダおよびＩＰＳｅｃ ＥＳＰのトレーラパディングを付加することができる。これらの何れも、分配エンジン１３９に既知な情報である。
【００５５】
元のデータ・パケットを再構築した後、投入動作２１８で、分配エンジン１３９は当該元のデータ・パケットを、受信側の圧縮エンジンにローカルなピア・デバイスに向けられたエンド・ツー・エンドのストリームに投入する。当該元のデータ・パケットを既存のエンド・ツー・エンドのストリームに投入することによって、ピア・デバイスは元のパケットを元のヘッダおよびペイロードと共に受け取り、エンド・ツー・エンドの認証は維持される。受信したパケットを解凍し、元の連続データ・パケットを再構築する１つの例示的な実装形態の諸工程は、後で図４Ｂを参照してより詳細に論ずる。
【００５６】
図３Ａは、様々な実施形態で実行可能な、図２Ａの分析動作２０２を実行するための例示的な１組の論理動作を示す。本例の目標は、どのパケットが圧縮可能かを決定し、トランスポート層のタイムアウトまたは他の影響が大きい遅延に起因するエンドポイント間接続の劣化を回避しつつ、パケットの効率的な圧縮および送信を可能とするのに必要な情報を取り出すことである。これらの論理動作は例示のために提供したものであり、限定しようとするものではない。様々な代替手段が存在することは理解されよう。
【００５７】
本例の論理動作では、先ず、タイプ動作３０２で、パケットのデータ・リンク・ヘッダをチェックすることによって、収集エンジン１２４が着信パケットのネットワーク層のタイプを検出する。選択肢として、或る種のタイプのネットワーク層プロトコルのパケット、例えば、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）のパケットのみを圧縮可能としてもよい。その場合、問合せ動作３０４で、現在のパケットのタイプが圧縮可能かどうかを検出し、圧縮可能でなければ、受渡し動作３０６で、当該パケットを圧縮せずに受信側の圧縮装置に渡す。
【００５８】
問合せ動作３０４が、パケットが圧縮可能なネットワーク層タイプを有さないことを検出した場合、タイプ動作３０８で、ネットワーク層ヘッダをチェックすることによって、トランスポート層プロトコルのような、パケットの次のプロトコルをチェックする。問合せ動作３１０は、この次のプロトコル・タイプが圧縮可能かどうかを検出し、圧縮可能でなければ、受渡し動作３０６で、当該パケットを圧縮せずに受信側の圧縮装置に渡す。さらなる選択肢として、ネットワーク層より上にある或る種のプロトコル・タイプのパケットのみが圧縮可能であるとしてもよい。例えば、問合せ動作３１０では、ＴＣＰパケット、ＵＤＰパケット、ＩＰＳｅｃ ＡＨ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｉｔｙ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｈｅａｄｅｒ）パケット、および／またはＩＰＳｅｃ ＥＳＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｉｔｙ Ｅｎｃａｐｓｕｌａｔｉｎｇ Ｓｅｃｕｒｉｔｙ Ｐａｙｌｏａｄ）パケットをチェックすることができる。例示のため、圧縮可能なタイプがＴＣＰ、ＩＰＳｅｃ ＡＨ、およびＩＰＳｅｃ ＥＳＰであるとして議論を進めるが、他のタイプも圧縮可能でありうることは理解されよう。
【００５９】
問合せ動作３１２で、ＩＰＳｅｃ ＡＨまたはＩＰＳｅｃ ＥＳＰに対するセキュリティ・ヘッダが存在するかどうかを判定することによって、パケットがＴＣＰ、ＩＰＳｅｃ ＡＨ、またはＩＰＳｅｃ ＥＳＰであるかどうかを検出する。当該次のプロトコルがＴＣＰである場合、収集エンジン１２４は、取出し動作３１４で、４つ組の送信アドレス、送信ポート、宛先アドレス、および宛先ポートを含む、圧縮および送信に必要な情報を取り出す。本例では、圧縮可能なＴＣＰパケットであるパケットに基づいて、ヘッダおよびペイロードの位置、ならびにネットワーク層ヘッダのＱｏＳマーキングを含む追加の情報も取り出される。次いで、収集動作３１６で、収集エンジン１２４によって収集される当該パケットが提供される。これは、例えば収集エンジン１２４のカーネル・モード部からユーザ・モード部へ当該パケットを渡すことによって行われ、この場合、圧縮エンジン１２８に入力する前に、少なくとも１つの単一圧縮可能バッファ１２７の待ち行列に当該パケットを入れることができる。次いで、着信データ・パケットが図３Ａの論理動作によって処理される。
【００６０】
問合せ動作３１２でパケットがＩＰＳｅｃ ＡＨであることが検出された場合、収集エンジン１２４は、タイプ動作３１８で、ＩＰＳｅｃ ＡＨの場合は認証ヘッダであるセキュリティ・ヘッダを調べて、次のプロトコルのタイプをチェックする。次いで、問合せ動作３２０で、この次のプロトコルがＴＣＰであるかどうかを検出する。ＴＣＰでなければ、受渡し動作３０６で当該パケットを圧縮せずに通過させる。このパケットがＴＣＰパケットである場合、取出し動作３１４で当該情報を取り出し、収集動作３１６で当該パケットを少なくとも１つの単一圧縮可能バッファ１２７に含める。
【００６１】
問合せ動作３１２で当該パケットがＩＰＳｅｃ ＥＳＰであることが検出された場合、このパケットが暗号化パケットか認証パケットかを検出するための判定が必要となることがある。選択肢として、暗号化パケットが圧縮されず、認証パケットが圧縮されることは可能である。パケットが暗号化または認証されているかどうかを経験的に判定するために、以下の論理動作を実行することができる。
【００６２】
収集エンジン１２４は、署名動作３２２で、パケットのＥＳＰ署名が特定のサイズであることを想定する。このサイズは、パケットを送るピア・デバイスのオペレーティング・システムおよびハードウェアのバージョンに依存して様々となろう。例えば、ＥＳＰ署名は、送信ピアのオペレーティング・システムに応じて、１２バイトもしくは１６バイト、または他のサイズで可能である。次に、収集エンジン１２４は、オフセット動作３２４で、パケットの終端に関する署名のサイズに基づいた、パケットのオフセットを見出す。次に、問合せ動作３２６で、このオフセット位置にあるプロトコル番号が、当該パケットがＴＣＰパケットであることを示すかどうかを検出する。問合せ動作３２６で収集エンジン１２４が、最初の想定した署名のサイズに対して、当該オフセット位置で指定されたプロトコルがＴＣＰでないことを検出した場合、動作フローは直接署名動作３３６に進む。署名動作３３６は後で論ずる。
【００６３】
パケットがＴＣＰパケットであると収集エンジン１２４が判定した場合、ステップ動作３２８で、収集エンジン１２４はパケット内で１バイト、即ち、ＥＳＰトレーラ内のパディングの長さだけ戻る。パディングが正規パターン（ｒｅｇｕｌａｒ ｐａｔｔｅｒｎ）、即ち、１、２、等を有する場合、パディング値を検証する試行を検証動作３３０で行う。認証されたＥＳＰデータ・パケットの場合は、４バイトに等しいパケット・サイズ全体を整列させるためにパディングが使用されることが期待される。パディングの詳細は、引用により本明細書に取り込まれるＲＦＣ２４０６に記載されている。
【００６４】
問合せ動作３３２で、パディング値の検証が成功したか失敗したかを検出する。検証が成功した場合、当該パケットがＩＰＳｅｃ ＥＳＰの認証パケットであると想定でき、取出し動作３１４で情報を取り出し、収集動作３１６で当該パケットを少なくとも１つの単一圧縮可能バッファ１２７に含めることができる。検証が失敗した場合、問合せ動作３３４で、想定される代替的な署名のサイズに基づいて、この試行が最初であったか２回目であったかを検出する。例示の目的でのみ、これらの論理動作では、２つの想定される署名のサイズで試行したことに留意されたい。追加の署名のサイズが可能である場合、追加の署名のサイズを同様に試行することができることは理解されよう。
【００６５】
これが２回目の試行であり両方の想定した署名のサイズでパディング値の検証に失敗した場合、本例では受渡し動作３０６でパケットを圧縮せずに通過させる。これが最初の試行に過ぎず代替の署名のサイズをまだ試行していない場合は、動作フローは署名動作３３６へ進む。署名動作３３６で、収集エンジンは代替の署名のサイズを想定する。次に、オフセット動作３３８は、パケットの終端に関する想定される代替的署名のサイズに基づいて、パケットのオフセットを見出す。次いで、問合せ動作３４０で、このオフセット位置にあるプロトコル番号が、当該パケットがＴＣＰであると示すかどうかを検出する。当該パケットがＴＣＰでなければ、本例では、試行用の他の署名のサイズがないので、受渡し動作３０６でパケットを圧縮せずに通過させる。当該オフセット位置がＴＣＰを示す場合、動作フローは動作３２８に進み、そこで動作フローは上述のように進む。
【００６６】
プロトコル・タイプをＴＣＰと一致させパディング値を検証した後でも、ＥＳＰの暗号化パケットを認証パケットと取り違えることは、可能性が低くとも考えられることである。このＥＳＰの暗号化パケットを圧縮しようとすることを避けるため、当該パケットを待ち行列に入れておき、次の数個、例えば３〜４個のパケットも調べて、それらのパケットもＥＳＰの認証パケットであってＥＳＰの暗号化パケットではないことを検証することができる。これらの後続パケットもＥＳＰの認証パケットであることが検証されると、待ち行列に入れたパケットを少なくとも１つの単一圧縮可能バッファ１２７に後続のパケットと共に渡すことができる。なぜなら、それらのパケットも同様にＥＳＰの認証パケットであることが殆ど確実であるからである。
【００６７】
図３Ｂは、図２Ａの収集動作２０４と同様に、収集エンジン１２４によって実行される、連続するパケットまたはそのペイロード・セグメントを少なくとも１つの単一圧縮可能バッファ１２７に収集するための論理動作の例を示す。本例では、目標は、例えば出来るだけ多くのデータ・パケットまたはそのペイロード・セグメントを少なくとも１つの単一圧縮可能バッファ１２７に収集し、圧縮エンジン１２８へ渡されているデータ・セットを出来るだけ大きくすることである。さらなる目標は、例えば、ユーザ・アプリケーションのタイムアウト、待ち時間、および応答速度低下のようなエンドポイント間ストリームに及ぼす悪影響を最小化することである。これらの論理動作も例示のために与えたものであって限定しようとするものではない。これらの動作に対しても様々な代替手段が存在することは理解されよう。
【００６８】
本論理動作は先ず問合せ動作３４２で、現在のパケットがストリームの先頭パケットまたは終点パケットであるかどうかを検出する。例えば、収集エンジン１２４は、ヘッダをチェックして、ＳＹＮ、ＦＩＮ、またはＲＳＴ ＴＣＰフラグが設定されているかどうかを確認することができる。設定されていれば、圧縮動作３４８で、当該パケットを少なくとも１つの単一圧縮可能バッファ１２７内にある現在のデータ・セットに追加し、少なくとも１つの単一圧縮可能バッファ１２７の内容を即座に圧縮エンジン１２８に送って圧縮および送信し、リモート・ピアへデータ・パケットを送達する際に遅延がさらに発生することを回避する。前述のように、データ・パケットを少なくとも１つの単一圧縮可能バッファ１２７に追加することには、当該パケットを様々なセグメントに分割し、データ・パケットを最も効率的に圧縮するために異なる圧縮アルゴリズムを異なるセグメント・タイプに適用できるように、各セグメント・タイプを別々にバッファした状態にすることを含めることができる。この分割処理中に、ヘッダおよびペイロードの順序と長さを指定するメタデータも同様に収集およびバッファすることができる。
【００６９】
現在のパケットがストリームの先頭パケットでも終点パケットでもない場合は、問合せ動作３４５で、現在のパケットが長さ零のペイロードを有するかどうかを検出する。ＴＣＰ ＡＣＫパケットのような長さ零のペイロードを有する場合は、当該パケットを少なくとも１つの単一圧縮可能バッファ１２７内にある現在のデータ・セットに追加する。圧縮動作３４８で、少なくとも１つの単一圧縮可能バッファ１２７の内容は、即座に圧縮エンジン１２８に送られて圧縮および送信され、リモート・ピアへ送達する際に遅延がさらに発生することを回避する。現在のパケットが長さ零のパケットを有しない場合は、動作フローは問合せ動作３４６に進む。
【００７０】
問合せ動作３４６は、現在のデータ・パケットの順序が、このエンドポイント間ストリームに対して受信したパケットのシーケンス内で狂っているかどうかを検出する。この検出は、最後に待ち行列に収集したパケットのＴＣＰシーケンス番号に対する、現在のパケットのＴＣＰシーケンス番号に基づいて行うことができる。現在のデータ・パケットの順序が狂っている場合は、少なくとも１つの単一圧縮可能バッファ１２７内部にある現在のデータ・パケットまたはそのペイロード・セグメントのデータ・セットを、圧縮動作３５４で圧縮するために提供し、収集動作３５６で現在のデータ・パケットを少なくとも１つの単一圧縮可能バッファ１２７の新しいインスタンスに追加して、新しい１組のパケットを開始する。これは、シーケンスから大量のパケットを受信側のパケット圧縮装置に送り、それによってエンドポイント間の通信セッションが過度に劣化しうることを回避するために行われる。
【００７１】
現在のデータ・パケットの順序が狂っていない場合は、問合せ動作３５０で、少なくとも１つの単一圧縮可能バッファ１２７内のデータ・パケットの何れかに対して、ＴＣＰタイムアウトのようなタイムアウト閾値に達しようとしているかどうかを検出する。これを、少なくとも１つの単一圧縮可能バッファ１２７の各データ・パケットを、最初に受け取った時刻を反映するタイムスタンプを記憶し、次いでそのタイムスタンプを現在時刻と比較することによって判定することができる。当該タイムアウト閾値に達しようとしている場合は、圧縮動作３４８で、現在のデータ・パケットを少なくとも１つの単一圧縮可能バッファ１２７に追加し、次いで少なくとも１つの単一圧縮可能バッファ１２７を圧縮エンジン１２８に渡して圧縮することができる。
【００７２】
タイムアウト閾値に達していない場合、問合せ動作３５２で、現在のデータ・パケットまたはそのペイロード・セグメントを少なくとも１つの単一圧縮可能バッファ１２７に追加すると、圧縮すべきデータ・セットに対する所定の最大サイズ、例えば６４キロバイトを超えるかどうかを検出する。超過する場合は、現在の少なくとも１つの単一圧縮可能バッファ１２７を、圧縮動作３５４で圧縮するために提供し、次いで収集動作３５６で現在のデータ・パケットを少なくとも１つの圧縮可能バッファ１２７の新しいインスタンスに追加して新しい１組のパケットを開始する。
【００７３】
現在のデータ・パケットを追加することにより少なくとも１つの単一圧縮可能バッファ１２７に対する所定の最大サイズを超過しない場合、収集動作３５８で、現在のデータ・パケットを少なくとも１つの単一圧縮可能バッファ１２７に追加する。次いで動作フローは問合せ動作３６０に進む。動作フローは、また、収集動作３５６を完了した後に問合せ動作３６０に進む。問合せ動作３６０は、このストリームに対して最後のデータ・パケットを少なくとも１つの単一圧縮可能バッファ１２７の待ち行列に入れて以降、遅延タイマ閾値を超過しているかどうかを検出する。１例として遅延タイマ閾値は固定の３ミリ秒であり、別の例では２つの圧縮装置間のリンクのＲＲＴ（Ｒｏｕｎｄ−Ｔｒｉｐ Ｔｉｍｅ）に従って調節可能な動的な値である。最後のデータ・パケットに対するタイムスタンプを現在時刻と比較することができる。遅延タイマ閾値を超過した場合、圧縮動作３６２で、現在のデータ・セットが圧縮エンジン１２８に提供される。遅延タイマ閾値を超過していない場合は、収集エンジン１２４は次のデータ・パケットか、収集したパケットを圧縮エンジン１２８に送ることを引き起こす別のタイマ・イベントを待つ。
【００７４】
上述のように、様々な変形を適用することができる。例えば、ＴＣＰ再試行に着目しない場合は、問合せ動作３５０を省略することができる。別の例として、遅延タイマは待ち行列の最後ではなく最初のデータ・パケットまたはそのペイロード・セグメントに基づくことができ、この場合、遅延タイマの閾値はＴＣＰタイムアウト閾値とは異なる値に設定される。遅延タイマ閾値を例えば３ミリ秒を上回るか下回る値に設定してもよい。さらに別の例として、問合せ動作３４５を省略できるように、零のペイロード・パケットをあたかもペイロードを有するかのように扱ってもよい。さらに、単一圧縮可能バッファを、着信パケットのＰＳＨ ＴＣＰフラグが設定されているかどうかを検出するによって圧縮エンジンに渡してもよく、これは、アプリケーション・レベルの確認が期待される場合はユーザ・アプリケーションの最適化を支援するはずであるが、アプリケーション・レベルの確認が期待されない場合はアプリケーションに対する圧縮率を低下させる恐れがある。
【００７５】
図４Ａは、１つの例示的な実施形態に従ってデータ・パケットとそのセグメントが圧縮および送信の段階を経て進む、諸工程を示す。最初に、データ・パケットをピア・デバイスから受け取り、圧縮可能なデータ・パケットを１組の連続データ・パケット４０２として収集する。データ・パケットはヘッダＨl〜ＨNと、対応するペイロードＰ1〜ＰNを含む。本実施形態では、別々の圧縮アルゴリズムを各ヘッダ４０３と各ペイロード４０５に対して使用してそれぞれに対する圧縮効率を最大化し、従って、この１組の連続データ・パケット４０２のパケットは１組のヘッダ４０４と１組のペイロード４０６を形成するように分割される。さらに、ヘッダとペイロードの各々の厳密な長さと順序を指定するためにメタデータ４０８を生成することができる。圧縮されたペイロードのデータ・セット４１０を形成するための圧縮アルゴリズムへ入力される１組のペイロード４０６は、少なくとも１つの単一圧縮可能バッファ１２７に記憶される。
【００７６】
本例では、次いでメタデータ４０８および１組のヘッダ４０４を、圧縮されたペイロードのデータ・セット４１０と連結して、連結された１組のデータ・セット４１１を形成する。さらに、本実施形態によると、連結されたデータ・セット４１１をＬＺＷのような圧縮技術を用いて圧縮して、圧縮されたデータ・セット４１２を形成する。セグメント・タイプごとに少なくとも１つの単一圧縮可能バッファ１２７の別々のインスタンスを用いて３つの部分の各々を別々に圧縮し、次いで結果を連結して圧縮されたデータ・セットを形成するような、代替的な圧縮方法も存在することは理解されよう。さらに、連結されたデータ・セット４１１を送信できるようにヘッダおよび／またはメタデータを未圧縮のままにしてもよいことは理解されよう。
【００７７】
本実施形態の圧縮されたデータ・セット４１２を送信するために、当該データ・セットをパケット化して１組のトンネル・パケット４１４を形成する。１組のトンネル・パケット４１４のトンネル・パケットは、それ自体のヘッダＨ11〜ＨNNと、対応するペイロードＰ11〜ＰNNを含む。次いでネットワーク１０６を介してこれらのトンネル・パケットを受信側の圧縮装置に送信する。１組のヘッダおよび１組の圧縮されたペイロードに対して別々のトンネル・パケットを生成するような、ヘッダおよび圧縮されたペイロードの代替的な転送方法も可能であることは理解されよう。
【００７８】
図４Ｂは、１つの例示的な実施形態に従って、データ・パケットとそのセグメントが、受信、解凍、および再構築段階を経て進む、諸工程を示す。最初に、１組のトンネル・パケット４１４を送信側の圧縮装置から受け取る。次に、１組のトンネル・パケット４１４の各トンネル・パケットを分解して圧縮されたデータ・セット４１２を再生成する。連結されたデータ・セット４１１を圧縮して圧縮されたデータ・セット４１２を生成するこのような実施形態の場合、その圧縮されたデータ・セット４１２を、次に解凍エンジン１５２により解凍して、１組のヘッダ４０４、メタデータ４０８、および圧縮されたペイロードのデータ・セット４１０を生成する。次いで、圧縮されたペイロードのデータ・セット４１０を少なくとも１つの単一の解凍バッファとして解凍エンジン１５２に提供し、そこで解凍して１組のペイロード４０６を生成する。
【００７９】
次に、これらの解凍された１組のヘッダ４０４、１組のペイロード４０６、およびメタデータ４０８を分配エンジン１３９に提供する。次に、分配エンジン１３９はメタデータ４０８で指定された長さと順序に従って、１組のヘッダ４０４の各ヘッダを１組のペイロード４０６のその対応するペイロードと照合する。分配エンジン１３９は、イーサネット・ヘッダおよびＩＰＳｅｃ ＥＳＰパディングのような任意のさらなるデータを追加する。当該任意の追加のデータは送信されないが分配エンジン１３９に既知であり、それにより各ヘッダ４０３とそれぞれの対応するペイロード４０５を含む１組の連続データ・パケット４０２を再構築することができる。次いで、分配エンジン１３９は１組の連続データ・パケット４０２の個々のデータ・パケットを、受信側のパケット圧縮装置に対してローカルなピア・デバイスへのエンド・ツー・エンドのストリームに投入する。
【００８０】
以上、本発明を構造的特徴および／または方法論的行動に特有な言葉で説明したが、添付の特許請求の範囲で定義した主題は必ずしも上述の特定の特徴または行動に限定されないことは理解されよう。そうではなく、上述の特定の特徴および行動は諸請求項を実装する形態の例として開示してある。
【技術分野】
【０００１】
本発明は、エンドポイント間認証状態を保ったデータ・パケットの圧縮に関する。
【背景技術】
【０００２】
コンピュータは、通常、ネットワークを介してデータ・パケットを交換することによって通信する。ネットワークでは、或るエンドポイントから別のエンドポイントへデータ・パケットを伝送するために利用できる帯域幅は限られている。その利用可能な帯域幅によって、コンピュータがデータ・パケットを交換できる速度は制限される。結果として、データ・パケットの伝送速度が不十分であると効率が落ちてしまう。非営利のユーザにとって、伝送速度が不十分だと苛立つこととなろう。また商業利用の場合、伝送が遅いと生産性や利益率が低下する。
【０００３】
企業においては、例えば複数の物理的位置の間で、エンド・ツー・エンド接続を維持していることが多い。例えば、本部や幾つかの支部が存在する。データ・パケットのスループットを上げるため、各エンドポイントは、送信装置と受信装置の間に論理的に配置されたアクセラレータ装置を使用する。当該アクセラレータ装置は、下流の装置を宛先とするデータ・パケットを受信するという点でネットワーク透過な装置であり、パケットを変えずにそのまま通すか、パケットを収集して圧縮し、圧縮状態で送信する。
【０００４】
アクセラレータ装置は、スループットを増大させユーザ・エクスペリエンスを高めるためにデータ・パケットのペイロードを圧縮する。しかし、アクセラレータ装置は、元のヘッダを破棄することによって着信パケットのトランスポート層ストリームを止め、ペイロードを送達するプロキシ・サービスとして行動する。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
アクセラレータ装置は所望の圧縮を提供できるが、トランスポート層ストリームの停止は問題を引き起こす。１つの具体的な例として、ＩＰＳｅｃ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｉｔｙ）やＳＭＢ（Ｓｅｒｖｅｒ Ｍｅｓｓａｇｅ Ｂｌｏｃｋ）署名のようなエンドポイント間認証プロトコルが最早利用できなくなる。
【課題を解決するための手段】
【０００６】
実施形態では、エンドポイント間の認証プロトコルを維持できるように通信セッションの元のヘッダを保存しつつ、エンドポイント間の単一通信セッションの連続データ・パケットを圧縮する。当該連続データ・パケットの少なくともペイロードを、少なくとも１つの圧縮可能バッファを介して圧縮し、それによって当該連続データ・パケットのペイロードを個別にではなく１つのグループとして集合的に圧縮する。第１の単一通信セッションの連続データ・パケットの圧縮されたヘッダと元のヘッダを伝送するために、送信装置と受信装置の間の第２の単一通信セッションに対応する別のデータ・パケットを受信装置に送信する。受信装置は少なくとも圧縮されたペイロードを解凍し、次いで元のヘッダを元のペイロードと照合することによって、エンドポイント間の第１の単一通信セッションの元の連続データ・パケットを再構築する。次いで、再構築した連続データ・パケットをエンドポイント間の第１の単一通信セッションに受信装置側で挿入して、受信装置から連続データ・パケットの各々を、元の連続データ・パケットの宛先であるエンドポイント装置に送達することができる。
【０００７】
本要約は、選択した概念を簡潔な形で紹介するために与えた。その概念は、後で「発明を実施するための形態」でさらに説明する。本要約はクレーム主題の主要な特徴または本質的な特徴を特定しようとするものではなく、クレーム主題の範囲を限定するために使用しようとするものでもない。
【図面の簡単な説明】
【０００８】
【図１Ａ】データ・パケット圧縮装置の様々な実施形態向けの例示的な環境を示す図である。
【図１Ｂ】２つのデータ・パケット圧縮装置がネットワークを介して通信する例示的な実施形態を示す図である。
【図２Ａ】エンドポイント間の単一通信セッションにおける１組の連続データ・パケットの少なくともペイロードを集合的に圧縮するための１組の論理動作の例を示す図である。
【図２Ｂ】１組の連続データ・パケットの少なくともペイロードを解凍し、当該連続データ・パケットを元の形に再構築するための１組の論理動作の例を示す図である。
【図３Ａ】図２Ａの論理動作中のように、着信データ・パケットを圧縮できることを分析するための１組の論理動作の例を示す図である。
【図３Ｂ】図２Ａの論理動作中のように、１組の着信連続データ・パケットの少なくともペイロードを含む少なくとも１つの圧縮可能バッファの圧縮開始を決定するための１組の論理動作の例を示す図である。
【図４Ａ】エンドポイント間の単一通信セッションにおける１組の連続データ・パケットが、未圧縮状態で収集されてから圧縮され送信されるまでの進展を示す図である。
【図４Ｂ】エンドポイント間の単一通信セッションにおける１組の連続データ・パケットを圧縮状態で受信してから解凍して、元の形で単一通信セッションの出て行くストリームに投入するまでの進展を示す図である。
【発明を実施するための形態】
【０００９】
実施形態では、エンドポイント間の単一通信セッションにおける１組の連続データ・パケットを圧縮し、圧縮した１組のデータ・パケットを受信装置に送信する。圧縮には、ペイロードのみの圧縮、またはヘッダとペイロードの両方の圧縮を含めることができる。圧縮したペイロードと元のヘッダは双方とも、圧縮されるかまたは圧縮されずに受信装置へと伝送され、次いで、当該受信装置は少なくともペイロードを解凍し元の１組の連続データ・パケットを再構築する。圧縮の前に、圧縮可能な連続データ・パケットを選択し、少なくとも１つの圧縮可能バッファに含まれるデータの量を最大化する論理を使用することができる。
【００１０】
図１Ａは様々な例示的な実施形態に対する動作環境の１例を示す。本例では、幾つかのピア・デバイスは様々な場所に存在でき、ネットワーク１０６を通して、他所にある様々なピア・デバイスと継続して通信できる。例示のために、第１の場所には、ネットワーク・スイッチのようなノード１０１に接続された第１のピア・デバイス１０２と第３のピア・デバイス１０３がある。ノード１０１は、第１のピア・デバイス１０２と第３のピア・デバイス１０３から送られたデータ・パケットを受信する。次いで、ノード１０１は他所宛てのデータ・パケットを第１のパケット圧縮装置１０４に転送する。ノード１０１は、また、第１のパケット圧縮装置１０４からデータ・パケットを受信して、当該パケットを第１のピア・デバイス１０２か第３のピア・デバイス１０３宛に送ることができる。
【００１１】
第１のパケット圧縮装置１０４は、ネットワーク透過な装置である。なぜなら、第１のピア・デバイス１０２と第３のピア・デバイス１０３からのパケットの宛先は第１のパケット圧縮装置１０４ではなく、当該パケットはネットワーク１０６を通ってさらに遠くへ送達するために第１のパケット圧縮装置１０４を通るからである。様々な数のピア・デバイスがこの場所に存在でき、第１のピア・デバイス１０２のみが存在する場合は、第１のピア・デバイス１０２を第１のパケット圧縮装置１０４に直接接続できることは理解されよう。さらに、本例で示すように、第１のパケット圧縮装置１０４をスタンドアロンの装置とせず、第１のパケット圧縮装置１０４の機能を第１のピア・デバイス１０２に統合してもよい。
【００１２】
また、例示のために、第２の場所にはノード１０９に接続された第２のピア.デバイス１１０と第４のピア・デバイス１１１がある。ノード１０９は、第２のピア・デバイス１１０と第４のピア・デバイス１１１からデータ・パケットを受信する。次いで、ノード１０９は、他所宛てのデータ・パケットを第２のパケット圧縮装置１０８に転送する。ノード１０９は、また、データ・パケットを第２のパケット圧縮装置１０８から受信し、当該データ・パケットを第２のピア・デバイス１１０または第４のピア・デバイス１１１宛に送ることができる。
【００１３】
第１のパケット圧縮装置１０４と同様、第２のパケット圧縮装置もネットワーク透過な装置である。なぜなら、第２のピア・デバイス１１０と第４のピア・デバイス１１１からのパケットの宛先は、第２のパケット圧縮装置１０８ではなく、これらのパケットはネットワーク１０６を通ってさらに遠くへ送達するために、第２のパケット圧縮装置１０８を通るからである。様々な数のピア・デバイスがこの場所に存在でき、第２のピア・デバイス１１０のみが存在する場合は、第２のピア・デバイス１１０は第２のパケット圧縮装置１０８に直接接続できることは理解されよう。さらに、本例で示すように、第２のパケット圧縮装置１０８をスタンドアロンの装置とせず、第２のパケット圧縮装置１０８の機能を第２のピア・デバイス１１０に統合してもよい。
【００１４】
第１のピア・デバイス１０２が、第２のピア・デバイス１１０または第４のピア・デバイス１１１宛てのデータ・パケットを送る場合、パケット圧縮装置１０４は第１のピア・デバイス１０２によって送られている１組の連続データ・パケットを、少なくとも１つの単一圧縮可能バッファの単一データ・セットとして圧縮することができる。圧縮には、連続データ・パケットのペイロードの圧縮か、当該連続データ・パケットのヘッダとペイロードの圧縮を含めることができる。次いで、ヘッダと圧縮されたペイロードを第２のパケット圧縮装置１０８に送信し、そこでペイロードを解凍し、必要ならばヘッダを解凍する。次いで、ヘッダをペイロードと照合し、第１のピア・デバイス１０２から送られた元のデータ・パケットを再構築する。次いで、第２のパケット圧縮装置１０８は、再構築された元のデータ・パケットを第１のピア・デバイス１０２と第２のピア・デバイス１１０または第４のピア・デバイス１１１の間の通信セッションに投入して、元のデータ・パケットを目的の宛先に送達する。
【００１５】
同じ働きを逆方向に行うことができる。この場合、第２のピア・デバイス１１０がデータ・パケットを第１のピア・デバイス１０２か第３のピア・デバイス１０３に送っている。第２のパケット圧縮装置１０８は、少なくともペイロードを圧縮し、元のヘッダと圧縮されたペイロードを第１のパケット圧縮装置１０４に送信する。次いで、第１のパケット圧縮装置１０４は、必要ならばペイロードとヘッダを解凍し、第２のピア・デバイス１１０から送られた元のパケットを再構築する。
【００１６】
例示のために、第１のピア・デバイス１０２が第２のピア・デバイス１１０と通信している場合は、これらのエンドポイント間で第１の通信セッション１１３が、例えばそれらの間でネットワーク１０６を介してトランスポート層ストリームを生成することによって確立されている。第１のピア・デバイス１０２がネットワーク１０６を介してデータを第２のピア・デバイス１１０に送ろうとすると、連続的なバイト・ストリームが第１の通信セッション１１３を通って流れる。この場合、当該バイト・ストリームは、それぞれがヘッダとペイロードを有するデータ・パケットのシーケンスを形成する。トランスポート層ストリームは、バイト・ストリームのこれらのデータ・パケット内部に存在するトランスポート層ヘッダによって維持される。
【００１７】
さらに、例示のために、パケット圧縮装置１０４がネットワーク１０６を介して、第１の通信セッション１１３のパケットを送信し続けるために受信している場合は、パケット圧縮装置１０４は当該パケットのうち少なくとも幾つかを圧縮用に収集することができる。次いで、圧縮されたデータ・パケットを、ネットワーク１０６を介して、パケット圧縮装置１０４とパケット圧縮装置１０８の間に確立された第２の通信セッション１１５を介して送信することができる。この第２の通信セッション１１５は、パケット圧縮装置１０４とパケット圧縮装置１０８の間で維持されるトランスポート層ストリームとして生成することができる。
【００１８】
図１Ｂは、第１のパケット圧縮装置１０４と第２のパケット圧縮装置１０８の１つの例示的な実装形態を示す。本例では、第１のパケット圧縮装置１０４と第２のパケット圧縮装置１０８は、第１のピア.デバイス１０２と第２のピア・デバイス１１０の間で行われるデータ通信に対して圧縮サービスを提供するために存在する。
【００１９】
この第１のパケット圧縮装置１０４の例示的な実装形態は、処理システムを形成する様々な構成要素を含む。本例では、第１のパケット圧縮装置１０４の処理システムが、カーネル・モード部１３４とユーザ・モード部１３２を含んでいる。カーネル・モード部１３４は、データ・パケットが第１のピア・デバイス１０２と第１のパケット圧縮装置１０４の間で交換されるように、第１のピア・デバイス１０２への物理接続または何らかの中間装置への物理接続を提供する第１のＮＩＣ（ｎｅｔｗｏｒｋ ｉｎｔｅｒｆａｃｅ ｃａｒｄ）１１２を介して、データを送受信する。ＮＤＩＳ（ｎｅｔｗｏｒｋ ｄｒｉｖｅｒ ｉｎｔｅｒｆａｃｅ ｓｐｅｃｉｆｉｃａｔｉｏｎ）層のようなデータ・リンク層１１４は、ＮＩＣ１１２と共に動作して、パケットをブリッジ１２０を介してデータ・リンク層１１８に渡す。データ・リンク層１１８は、当該パケットをネットワークおよびトランスポート層１２２へ渡す。ネットワークおよびトランスポート層１２２は、ネットワーク層向けのＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）、関連するトランスポート層向けのＴＣＰ（ｔｒａｎｓｍｉｓｓｉｏｎ ｃｏｎｔｒｏｌ ｐｒｏｔｏｃｏｌ）またはＵＤＰ（ｕｓｅｒ ｄａｔａｇｒａｍ ｐｒｏｔｏｃｏｌ）のようなプロトコルを利用することができる。データ・リンク層、ネットワーク層、およびトランスポート層の他の例もまた、上記の様々な実施形態に適用可能である。
【００２０】
この特定の例では、第１のパケット圧縮装置１０４は第１のピア・デバイス１０２とネットワーク１０６の間にあるデータ経路内に物理的に配置されている。従って、カーネル・モード部１３４は、第２のＮＩＣ１１６を介してデータを送受信し、パケットをネットワークおよびトランスポート層１２２に提供する関連データ・リンク層１１８を含む。ＮＩＣ１１６はパケットを、第１のピア・デバイス１０２のローカル・ネットワークを第２のピア・デバイス１１０のローカル・ネットワークに相互接続する広域ネットワークのようなネットワーク１０６を介して交換する。
【００２１】
第１のパケット圧縮装置１０４のデータ・リンク層１１８には、第１のピア・デバイス１０２から送られたパケットをデータ・セットに収集し、当該データ・セットをユーザ・モード部１３２の少なくとも１つの単一圧縮可能バッファ１２７に提供する収集エンジン１２４が接続されている。当該収集エンジンは、第１のパケット圧縮装置１０４のオペレーティング・システム・プラットフォームに応じて、ＮＤＩＳフィルタ・ドライバまたはＮＤＩＳ中間（ＩＭ）ドライバのようなドライバが可能である。
【００２２】
この例示的な実装形態の収集エンジン１２４は、カーネル部とユーザ・モード部を含む。カーネル・モード部は、連続データ・パケットをエンドポイント間の特定の入って来る通信セッションから収集し、収集した１組の連続データ・パケットを、ペイロードから分離されたヘッダを含むセグメントに分離する。カーネル部は当該セグメントをユーザ・モード部に渡す。当該ユーザ・モード部は、少なくともペイロードを圧縮すべき単一のデータ・セットとして少なくとも１つの単一圧縮可能バッファ１２７にロードすることを管理する。それにより、ユーザ・モード部１３２で、圧縮すべきセグメントを含むデータ・セットにバッファ１２７からアクセスし、当該データ・セットを圧縮し、第２のパケット圧縮装置１０８に送信することができる。
【００２３】
この例示的な実装形態のデータ・リンク層１１８は、また、第１のパケット圧縮装置１０４と第２のパケット圧縮装置１０８の間のストリームへ出て行くＤＳＣＰ値をマークするために使用されるＤＳＣＰ（ｄｉｆｆｅｒｅｎｔｉａｔｅｄ ｓｅｒｖｉｃｅｓ ｃｏｄｅ ｐｏｉｎｔ）マーカ１３６のようなＱｏＳ（ｑｕａｌｉｔｙ ｏｆ ｓｅｒｖｉｃｅ）マーカを維持することができる。発信パケットをマークして、圧縮されている元のデータ・パケット向けのサービス品質を保存することは、以下でさらに論ずる。
【００２４】
第１のパケット圧縮装置１０４のこの例示的な実装形態のユーザ・モード部１３２は、また、様々な構成要素を含む処理システムを形成する。上述のように、収集エンジン１２４は、エンドポイント間の所与の入って来る通信ストリームから、ＮＩＣ１１２を介して少なくともペイロードをバッファするユーザ・モード部を備える。次いで、収集エンジン１２４のユーザ・モード部は、少なくとも１組のペイロードを、少なくとも１つの単一圧縮可能バッファ１２７の単一のデータ・セットとして、圧縮エンジン１２８に提供する。
【００２５】
圧縮エンジン１２８は、少なくとも当該ペイロードを、少なくとも１つの単一圧縮可能バッファ１２７の単一のデータ・セットとして、収集エンジン１２４から受け取り、少なくとも１つの単一圧縮可能バッファ１２７から得た少なくともペイロードを単一データ・セットとして圧縮するための１つまたは複数の圧縮アルゴリズムを実行する。少なくとも１つの単一圧縮可能バッファから得た少なくともペイロードを、単一のデータ・セットとして圧縮することによって、圧縮エンジン１２８は個別ではなく集合的にペイロードを圧縮している。圧縮されている単一のデータ・セットのサイズを増加させることによって、圧縮率を高めることができる。
【００２６】
圧縮エンジン１２８は、以前に参照したデータと、様々な圧縮アルゴリズムを実行するときに利用できる他の参照情報とから成る辞書を維持するため、記憶装置１３０を利用できる。さらに、圧縮エンジン１２８は、少なくとも１つの単一圧縮可能バッファのペイロードの内容に対して或るアルゴリズムを使用することができ、ヘッダを含む別の単一圧縮可能バッファに対して別のアルゴリズムを使用することができる。
【００２７】
ヘッダを含む圧縮可能バッファのヘッダ内容に適用できる圧縮アルゴリズムの例には、様々な差分アルゴリズムおよび様々なステートレス圧縮アルゴリズムがある。差分アルゴリズムの例には、ＲＦＣ（Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔ）１１４４、２５０７、２５０８、２５０９、３０９５、および４８１５に記載されているものがあり、これらは引用によって本明細書に取り込まれる。ステートレス圧縮アルゴリズムの例にはＬＺＷ（Ｌｅｍｐｅｌ−Ｚｉｖ−Ｗｅｌｃｈ）またはハフマン符号化が含まれる。
【００２８】
ペイロードを含む圧縮可能バッファの内容に適用できる圧縮アルゴリズムの例には、様々なステートフル差分アルゴリズムや様々なステートレス圧縮アルゴリズムがある。ステートフル差分アルゴリズムの例には、ＤＦＳＲ（Ｄｉｓｔｒｉｂｕｔｅｄ Ｆｉｌｅ Ｓｙｓｔｅｍ Ｒｅｐｌｉｃａｔｉｏｎ）で使用されるＲＤＣ（Ｒｅｍｏｔｅ Ｄｉｆｆｅｒｅｎｔｉａｌ Ｃｏｍｐｒｅｓｓｉｏｎ）が含まれる。ステートレス圧縮アルゴリズムの例には、ＬＺＷやハフマン符号化が含まれる。
【００２９】
送信エンジン１２６は、圧縮されたデータ・セットを圧縮エンジン１２８から受け取る。次に、送信エンジン１２６は、第１のパケット圧縮装置１０４と第２のパケット圧縮装置１０８の間にある第２の通信セッションを介してデータ・セットを送る。送信エンジン１２６は、ネットワークおよびトランスポート層１２２を利用してデータ・セットをパケット化し、結果として得たパケットをデータ・リンク層１１８およびＮＩＣｌ１６を介して、第２の通信セッションを通して第２のパケット圧縮装置１０８に送ることができる。従って、圧縮されたパケットは集合的に圧縮された形で、ネットワーク１０６を介してトンネリングする。
【００３０】
本例に対して示した第１のパケット圧縮装置１０４の構成要素は、第１のピア・デバイス１０２から入って来るデータ・パケットの収集、圧縮、送信に関連する構成要素である。第１のパケット圧縮装置１０４と第２のパケット圧縮装置１０８は、１方向に流れるデータに対して、第１のパケット圧縮装置１０４が、収集、分割、圧縮、および送信を行うことができ、第２のパケット圧縮装置１０８が、受信、解凍、再構築、および第２のピア・デバイス１１０へのストリームに再び投入する補完機能を行うという意味で、互いに補完する装置になれることは理解されよう。逆方向に流れるデータに対しては、第２のパケット圧縮装置１０８が、収集、分割、圧縮、および送信を行い、第１のパケット圧縮装置１０４が、受信、解凍、再構築、および第１のピア・デバイス１０２へのストリームに再び投入することができる。
【００３１】
従って、第１のパケット圧縮装置１０４を１組の構成要素で示し、第２のパケット圧縮装置１０８を別の補完的な組の構成要素で示してあるが、第１のパケット圧縮装置１０４は第２のパケット圧縮装置１０８に対して示した構成要素を含んでもよく、第２のパケット圧縮装置１０８は第１のパケット圧縮装置１０４に対して示した構成要素を含んでもよいことは理解されよう。
【００３２】
第２のパケット圧縮装置１０８に対して示した例示的な実装形態は、また、カーネル・モード部、ネットワーク１０６とインタフェースするためのＮＩＣ１３８、および第２のピア・デバイス１１０とインタフェースするためのＮＩＣ１４６を備える。第２のパケット圧縮装置１０８は、データ・リンク層１４０および１４８、分配エンジン（ｓｃａｔｔｅｒ ｅｎｇｉｎｅ）１３９、ブリッジ１５０、ならびにネットワークおよびトランスポート層１４２を備える。この例示的な実装形態のユーザ・モード部は、受信エンジン１４４、解凍エンジン１５２、および記憶装置１５４を備える。
【００３３】
第１のパケット圧縮装置１０４との第２の通信セッションから取得され、従って宛先がこの第２のパケット圧縮装置１０８であるパケットは、ＮＩＣ１３８を介して第１の圧縮装置から受信され、ネットワークおよびトランスポート層１４２（例えば、ＴＣＰ／ＩＰ）に渡される。このネットワークおよびトランスポート層１４２は、次いで、パケットのペイロードを抽出し指定の順番でペイロードを繋ぎ合せることによってパケットを分解する。さらに、このネットワークおよびトランスポート層１４２は、アプリケーション・データを受信エンジン１４４に提供する。この情報は、第１のパケット圧縮装置１０４の送信エンジン１２６から送信された圧縮されたデータ・セットであり、この場合、当該圧縮されたデータ・セットは、第１のピア・デバイス１０２から得た元のパケットの、圧縮されたヘッダか圧縮されていないヘッダのいずれか１つ、および圧縮されたペイロードを含む。受信エンジン１４４はこのデータ・セットを解凍エンジン１５２に提供する。
【００３４】
第２のパケット圧縮装置１０８の解凍エンジン１５２は、第１のパケット圧縮装置１０４の圧縮エンジン１２８が使用する圧縮アルゴリズム（複数可）に対して補完的な解凍アルゴリズム（複数可）を利用してデータ・セットを解凍する。解凍する際、解凍エンジン１５２は、第１のパケット圧縮装置１０４の記憶装置１３０のものに対して補完的な辞書および他の参照情報を含む、記憶装置１５４の辞書および他の参照情報を参酌することができる。
【００３５】
解凍エンジン１５２は、元のデータ・パケットのヘッダと解凍されたペイロードとを含むセグメントを、分配エンジン１３９のユーザ・モード部によって管理されるバッファに提供する。分配エンジン１３９は、最終的に、通信セッションが割り込まれないように、解凍されたパケットをパケットの発生源であるエンドポイント間の通信セッションに割り振り戻す。分配エンジン１３９のユーザ・モード部は、元のパケットの解凍されたヘッダ、ペイロード、および他の任意の部分を、例示的な実装形態の分配エンジンのカーネル・モード部に提供する。分配エンジン１３９は解凍したペイロードとヘッダを照合して元のパケットを再構築する。次いで、分配エンジン１３９は、その再構築された元のパケットを、ブリッジ１５０を介して第２のピア・デバイス１１０へのストリームに投入する。
【００３６】
図１Ｂの第１のパケット圧縮装置１０４と第２のパケット圧縮装置１０８は、例示の目的のために示したものであり、限定しようとするものではない。例えば、第１のパケット圧縮装置１０４と第２のパケット圧縮装置１０８をスタンドアロン構造として示したが、これらの装置を代わりにエンドポイントに組み込んでもよい。例えば、第１のパケット圧縮装置１０４を第１のピア・デバイス１０２の構造に組み込んで、ＮＩＣ１１２を削除してもよい。
【００３７】
さらに、第１のパケット圧縮装置および第２のパケット圧縮装置の実装形態は、幾つかのカーネル・モード要素と幾つかのユーザ・モード要素を含んでいたが、様々な構成要素とそれらの機能を代替構成で実装してもよいことは理解されよう。例えば、当該構成要素およびそれらの機能の全てをカーネル・モード内部で実装してもよい。
【００３８】
第１のパケット圧縮装置１０４および第２のパケット圧縮装置１０８の構成要素を、記憶装置１３０または１５４等のようなメモリに記憶したプログラムを実装する、ハードワイヤードロジック、ファームウェア、汎用のプログラム可能プロセッサで構成することができる。第１のパケット圧縮装置１０４および第２のパケット圧縮装置１０８を含む図１Ｂの装置と同様に、第１のピア・デバイス１０２および第２のピア・デバイス１１０は、様々なコンピュータ可読媒体を含むことができる。係るコンピュータ可読媒体は、本明細書で論じた装置を動作させ、本明細書で論じた実施形態を実装するための命令を含む。コンピュータ可読媒体は、コンピュータ・システムがアクセスできる任意の使用可能な媒体で可能であり、揮発性媒体および不揮発性媒体、取外し可能媒体および取外し不可能媒体の両方を含む。限定ではなく例として、コンピュータ可読媒体はコンピュータ記憶媒体および通信媒体を含むことができる。
【００３９】
コンピュータ記憶媒体には、コンピュータ可読命令、データ構造、プログラム・モジュール、または他のデータのような情報を記憶するための任意の方法または技術で実装した揮発性媒体および不揮発性媒体、取外し可能媒体および取外し不可能媒体が含まれる。コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、ＤＶＤ（ｄｉｇｉｔａｌ ｖｅｒｓａｔｉｌｅ ｄｉｓｋ）もしくは他の光ディスク記憶、磁気カセット、磁気テープ、磁気ディスク記憶もしくは他の磁気記憶装置、または所望の情報の記憶に使用でき、コンピュータ・システムによりアクセス可能な他の任意の媒体が含まれるがこれらに限らない。
【００４０】
通信媒体は、一般にコンピュータ可読命令、データ構造、プログラム・モジュール、または他のデータを搬送波または他の伝送機構のような変調データ信号で具現化し、任意の情報送達媒体を含む。「変調データ信号」という用語は、１つまたは複数のその特性集合を含むか、信号内の情報を符号化するように変化した信号を意味する。限定ではなく例として、通信媒体には有線ネットワークまたは直接配線接続のような有線媒体、ならびに音響、ＲＦ、赤外線、および他の無線媒体のような無線媒体が含まれる。以上の何れかの組合せもコンピュータ可読媒体の範囲に含まれるべきである。
【００４１】
図２Ａ〜図３Ｂは、データ・パケットを圧縮または解凍するための動作フローを示す。以下の図２Ａ〜図３Ｂの説明は、図１の圧縮装置１０４、１０８を参照して行う。しかし、図２Ａ〜図３Ｂを参照して説明するフローを圧縮装置１０４、１０８、または圧縮装置１０４、１０８の任意の特定の構成要素もしくは構成要素群によって実行されるものに限定しようとはしていないことは理解されよう。さらに、図２Ａ〜図３Ｂの動作フローは、特定のステップ順序を示すが、他の実装形態では当該動作を別の順序で行い、動作を追加し、且つ／または幾つかの動作を省略してもよいことは理解されよう。
【００４２】
図２Ａは、着信データ・パケットを圧縮するためにパケット圧縮装置の１つまたは複数の実施形態によって実行できる１組の論理動作を示す。本論理動作では、先ず分析動作２０２で、第１のパケット圧縮装置１０４のようなパケット圧縮装置および特に収集エンジン１２４が、ローカル・ピアからの着信パケットを圧縮できるかどうかを分析する。分析動作２０２で、宛先のピア・デバイスに対して、第２のパケット圧縮装置１０８のような受信側のパケット圧縮装置へ正しく送信するために必要な情報に関して当該着信パケットをさらに分析する。
【００４３】
暗号化されたもののような或る種のパケットは圧縮できない。なぜならば、効果的とするため圧縮せずにそれらのパケットを、受信側のパケット圧縮装置へ通す必要があり得るからである。分析動作２０２で、これらの圧縮できないパケットを発見して通過させることができる。分析動作２０２の１実装形態のさらなる詳細は後で図３Ａを参照して論ずる。
【００４４】
この時点で、圧縮可能な場合は正しく送信し、その圧縮可能なデータ・パケットを圧縮するために必要な情報を収集することができる。この情報には、パケットが属するトランスポート層ストリームを特定する４つ組の送信ポート、送信アドレス、宛先ポート、および宛先アドレスを含めることができる。圧縮するか否かを判定し、他のパケットと共に集合的な圧縮を編成するために必要な情報をこの時点で得ることもできる。当該情報には、各パケット内部のヘッダの位置、各パケット内部のペイロードの位置、および存在するかもしれない任意のトレーラの位置が含まれる。
【００４５】
収集動作２０４で、着信パケットの圧縮可能性の分析完了後に所与のトランスポート層ストリーム（例えば、ＴＣＰまたはＵＤＰストリーム）の圧縮可能パケットを、やはり圧縮可能な当該ストリームの他のパケットと共に圧縮可能バッファ１２７に収集する。これらの圧縮可能データ・パケットをデータ・セットへ収集することによって、全体のパケットまたはその選択されたセグメント（例えば、ペイロード）を少なくとも１つの単一圧縮可能バッファ１２７内部で提供することができる。ここで、圧縮可能パケットを、ヘッダ、ペイロード、および、もしあればトレーラに分解することができ、各セグメントは同一ストリームの類似するセグメント・タイプである他のデータ・パケットと共に別々にバッファされる。収集動作２０４の１実装形態のさらなる詳細は後で図３Ｂに関連して論ずる。
【００４６】
エンドポイント間接続の劣化を最小化するために、パケットを圧縮用にデータ・セットへ収集することは制限される必要があるかもしれない。例えば、少なくとも１つの単一圧縮可能バッファ１２７が埋まるのを待ってパケットの転送をあまりにも長時間遅らせると、トランスポート層でタイムアウトする恐れがある。従って、この時点で、エンドポイント間接続を劣化させずに圧縮率を望ましいレベルに保つため、当該データ・セットが圧縮を開始すべき点に達したかどうかを判定する。１実装形態に従うこの判定の詳細も後で図３Ｂに関連して論ずる。
【００４７】
次いで、圧縮を開始すべきと決定すると、１組のデータ・パケットまたはセグメントを少なくとも１つの単一圧縮可能バッファ１２７の内容として圧縮エンジン１２８に渡す。或る特定の状況下では、例えばその単一パケットの目的が新しいトランスポート層ストリームの開始か既存のトランスポート層ストリームの停止である場合、単一のパケットを圧縮エンジン１２８に直接渡して即座に圧縮し受信側の圧縮装置に送信してもよい。
【００４８】
少なくとも１つの単一圧縮可能バッファ１２７の内容を圧縮エンジン１２８に渡した後、その内容を圧縮動作２０６で圧縮する。この圧縮は、圧縮アルゴリズムが、１度に単一のパケットまたは単一のパケットのセグメントに作用するのではなく、少なくとも１つの単一圧縮可能バッファ１２７の複数のパケット、または複数のパケットのセグメントに作用して圧縮された出力を生成するという意味で集合的である。複数のデータ・パケットまたは複数のデータ・パケットのセグメントを含む少なくとも１つの単一圧縮可能バッファ１２７の内容を圧縮する場合、多くのデータに作用して圧縮結果を生成するので、圧縮率を高くすることができる。圧縮されたデータ・セットが圧縮エンジン１２８によって生成される。異なるアルゴリズムが異なるセグメント・タイプに使用される実施形態の場合は、セグメント・タイプごとに圧縮された１つのデータ・セットがあってもよい。あるいは、ペイロードを圧縮したデータ・セットを、ヘッダを含むデータ・セットと連結し、連結したデータを圧縮してもよい。
【００４９】
圧縮されたデータ・セットを生成した後、送信動作２０８で送信エンジン１２６は当該圧縮されたデータ・セットを受信側の圧縮装置に送信する。ここで、当該データ・セットはネットワークおよびトランスポート層１２２（例えば、ＴＣＰ／ＩＰ）に導入され、そこでパケット化され、受信側の圧縮装置との通信セッションを介して送信される。受信側の圧縮装置に送信されているこれらのパケットは、その中の圧縮データ・パケットが配信されているトンネルを提供しているので、トンネル・パケットである。圧縮および送信の例示的な１実装形態の諸工程は後で図４Ａに関連してより詳細に説明する。
【００５０】
圧縮されたデータ・セットを含む第１のパケット圧縮装置１０４から送られているデータ・パケットは、パケットが十分な優先度で送信されていることを保証するためのＱｏＳマーキングを有することができる。これらの発信パケットに対するＱｏＳマーキングを、ローカル・ピアから受け取った元のパケットのＱｏＳマーキングに基づいて選択することができる。例えば、着信パケットが特定のＱｏＳ優先度を有する場合、そのＱｏＳマーキング、例えばＤＳＣＰマーキングをメモリに記憶することができる。受信側の圧縮装置に送信されているトンネル・パケットを、同一のＤＳＣＰマーキングにより元のパケットとしてマークして、エンド・ツー・エンド接続に対する圧縮装置の透過性をさらに維持する。代替手段として、発信パケットに対するＱｏＳマーキングを元のデータ・パケットのＱｏＳマーキング以外の何らかの基準に基づいて選択してもよい。
【００５１】
図２Ｂは、着信データ・パケットのデータを解凍し、解凍したデータから元のパケットを再構築するための、圧縮装置の１つまたは複数の実施形態によって実行される１組の論理動作を示す。当該論理動作では、先ず、受信動作２１０で、第２のパケット圧縮装置１０８のような受信側の圧縮装置が、第１のパケット圧縮装置１０４のような送信側の圧縮装置によって送られたトンネル・パケットを受信する。トンネル・パケットの宛先が受信側の装置なので、パケットは受信側の圧縮装置のローカル・ピアへ渡されずにプロトコル層へ渡される。
【００５２】
ネットワークおよびトランスポート層１４２はパケットを受信し、それらをパケット動作２１２で分解して、送信側の圧縮装置によって以前に生成および送信された、圧縮されたデータ・セットを取り出す。受信エンジン１４４は、データ・セットを構成する圧縮されたデータを受け取る。ヘッダおよびペイロードを別々に圧縮した実施形態の場合は、当該データ・セットは別々のヘッダのデータ・セットとペイロードのデータ・セットを含む。受信エンジン１４４はこれらのデータ・セットを解凍エンジン１５２に渡す。
【００５３】
解凍動作２１４で、解凍エンジン１５２はデータ・セットを解凍する。送信側の圧縮装置によって実行された圧縮に補完的な解凍が使用される。圧縮されたデータ・セットは、圧縮アルゴリズムによって生成され、利用した圧縮技術を特定するヘッダを含むことができ、それによって解凍エンジン１５２は、圧縮されたデータ・セットからそのヘッダを読み、適切な解凍アルゴリズムを用いて解凍することができる。さらに、２つの補完的な圧縮装置の間には、どの圧縮アルゴリズムが利用されるかを記述する高レベルの取り決めが適切に存在してもよい。次いで、解凍されたデータ・セットは分配エンジン１３９に渡され、そこでパケットを再構築することができる。
【００５４】
再構築動作２１６で、分配エンジン１３９は、ヘッダ、ペイロード、および任意のトレーラを照合することによって元のデータ・パケットを再構築する。ここで、分配エンジン１３９は、解凍されたデータ・セットのメタデータを参照することによって、ヘッダをその対応するペイロードと照合して、セグメントのオフセットと厳密な長さに基づいてヘッダとペイロードの位置を特定する。ここで、ヘッダの順序はペイロードの順序と一致する。分配エンジン１３９は、また、必要に応じて、伝送されていないデータを付加することができる。例えば、イーサネット・ヘッダおよびＩＰＳｅｃ ＥＳＰのトレーラパディングを付加することができる。これらの何れも、分配エンジン１３９に既知な情報である。
【００５５】
元のデータ・パケットを再構築した後、投入動作２１８で、分配エンジン１３９は当該元のデータ・パケットを、受信側の圧縮エンジンにローカルなピア・デバイスに向けられたエンド・ツー・エンドのストリームに投入する。当該元のデータ・パケットを既存のエンド・ツー・エンドのストリームに投入することによって、ピア・デバイスは元のパケットを元のヘッダおよびペイロードと共に受け取り、エンド・ツー・エンドの認証は維持される。受信したパケットを解凍し、元の連続データ・パケットを再構築する１つの例示的な実装形態の諸工程は、後で図４Ｂを参照してより詳細に論ずる。
【００５６】
図３Ａは、様々な実施形態で実行可能な、図２Ａの分析動作２０２を実行するための例示的な１組の論理動作を示す。本例の目標は、どのパケットが圧縮可能かを決定し、トランスポート層のタイムアウトまたは他の影響が大きい遅延に起因するエンドポイント間接続の劣化を回避しつつ、パケットの効率的な圧縮および送信を可能とするのに必要な情報を取り出すことである。これらの論理動作は例示のために提供したものであり、限定しようとするものではない。様々な代替手段が存在することは理解されよう。
【００５７】
本例の論理動作では、先ず、タイプ動作３０２で、パケットのデータ・リンク・ヘッダをチェックすることによって、収集エンジン１２４が着信パケットのネットワーク層のタイプを検出する。選択肢として、或る種のタイプのネットワーク層プロトコルのパケット、例えば、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）のパケットのみを圧縮可能としてもよい。その場合、問合せ動作３０４で、現在のパケットのタイプが圧縮可能かどうかを検出し、圧縮可能でなければ、受渡し動作３０６で、当該パケットを圧縮せずに受信側の圧縮装置に渡す。
【００５８】
問合せ動作３０４が、パケットが圧縮可能なネットワーク層タイプを有さないことを検出した場合、タイプ動作３０８で、ネットワーク層ヘッダをチェックすることによって、トランスポート層プロトコルのような、パケットの次のプロトコルをチェックする。問合せ動作３１０は、この次のプロトコル・タイプが圧縮可能かどうかを検出し、圧縮可能でなければ、受渡し動作３０６で、当該パケットを圧縮せずに受信側の圧縮装置に渡す。さらなる選択肢として、ネットワーク層より上にある或る種のプロトコル・タイプのパケットのみが圧縮可能であるとしてもよい。例えば、問合せ動作３１０では、ＴＣＰパケット、ＵＤＰパケット、ＩＰＳｅｃ ＡＨ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｉｔｙ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｈｅａｄｅｒ）パケット、および／またはＩＰＳｅｃ ＥＳＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｉｔｙ Ｅｎｃａｐｓｕｌａｔｉｎｇ Ｓｅｃｕｒｉｔｙ Ｐａｙｌｏａｄ）パケットをチェックすることができる。例示のため、圧縮可能なタイプがＴＣＰ、ＩＰＳｅｃ ＡＨ、およびＩＰＳｅｃ ＥＳＰであるとして議論を進めるが、他のタイプも圧縮可能でありうることは理解されよう。
【００５９】
問合せ動作３１２で、ＩＰＳｅｃ ＡＨまたはＩＰＳｅｃ ＥＳＰに対するセキュリティ・ヘッダが存在するかどうかを判定することによって、パケットがＴＣＰ、ＩＰＳｅｃ ＡＨ、またはＩＰＳｅｃ ＥＳＰであるかどうかを検出する。当該次のプロトコルがＴＣＰである場合、収集エンジン１２４は、取出し動作３１４で、４つ組の送信アドレス、送信ポート、宛先アドレス、および宛先ポートを含む、圧縮および送信に必要な情報を取り出す。本例では、圧縮可能なＴＣＰパケットであるパケットに基づいて、ヘッダおよびペイロードの位置、ならびにネットワーク層ヘッダのＱｏＳマーキングを含む追加の情報も取り出される。次いで、収集動作３１６で、収集エンジン１２４によって収集される当該パケットが提供される。これは、例えば収集エンジン１２４のカーネル・モード部からユーザ・モード部へ当該パケットを渡すことによって行われ、この場合、圧縮エンジン１２８に入力する前に、少なくとも１つの単一圧縮可能バッファ１２７の待ち行列に当該パケットを入れることができる。次いで、着信データ・パケットが図３Ａの論理動作によって処理される。
【００６０】
問合せ動作３１２でパケットがＩＰＳｅｃ ＡＨであることが検出された場合、収集エンジン１２４は、タイプ動作３１８で、ＩＰＳｅｃ ＡＨの場合は認証ヘッダであるセキュリティ・ヘッダを調べて、次のプロトコルのタイプをチェックする。次いで、問合せ動作３２０で、この次のプロトコルがＴＣＰであるかどうかを検出する。ＴＣＰでなければ、受渡し動作３０６で当該パケットを圧縮せずに通過させる。このパケットがＴＣＰパケットである場合、取出し動作３１４で当該情報を取り出し、収集動作３１６で当該パケットを少なくとも１つの単一圧縮可能バッファ１２７に含める。
【００６１】
問合せ動作３１２で当該パケットがＩＰＳｅｃ ＥＳＰであることが検出された場合、このパケットが暗号化パケットか認証パケットかを検出するための判定が必要となることがある。選択肢として、暗号化パケットが圧縮されず、認証パケットが圧縮されることは可能である。パケットが暗号化または認証されているかどうかを経験的に判定するために、以下の論理動作を実行することができる。
【００６２】
収集エンジン１２４は、署名動作３２２で、パケットのＥＳＰ署名が特定のサイズであることを想定する。このサイズは、パケットを送るピア・デバイスのオペレーティング・システムおよびハードウェアのバージョンに依存して様々となろう。例えば、ＥＳＰ署名は、送信ピアのオペレーティング・システムに応じて、１２バイトもしくは１６バイト、または他のサイズで可能である。次に、収集エンジン１２４は、オフセット動作３２４で、パケットの終端に関する署名のサイズに基づいた、パケットのオフセットを見出す。次に、問合せ動作３２６で、このオフセット位置にあるプロトコル番号が、当該パケットがＴＣＰパケットであることを示すかどうかを検出する。問合せ動作３２６で収集エンジン１２４が、最初の想定した署名のサイズに対して、当該オフセット位置で指定されたプロトコルがＴＣＰでないことを検出した場合、動作フローは直接署名動作３３６に進む。署名動作３３６は後で論ずる。
【００６３】
パケットがＴＣＰパケットであると収集エンジン１２４が判定した場合、ステップ動作３２８で、収集エンジン１２４はパケット内で１バイト、即ち、ＥＳＰトレーラ内のパディングの長さだけ戻る。パディングが正規パターン（ｒｅｇｕｌａｒ ｐａｔｔｅｒｎ）、即ち、１、２、等を有する場合、パディング値を検証する試行を検証動作３３０で行う。認証されたＥＳＰデータ・パケットの場合は、４バイトに等しいパケット・サイズ全体を整列させるためにパディングが使用されることが期待される。パディングの詳細は、引用により本明細書に取り込まれるＲＦＣ２４０６に記載されている。
【００６４】
問合せ動作３３２で、パディング値の検証が成功したか失敗したかを検出する。検証が成功した場合、当該パケットがＩＰＳｅｃ ＥＳＰの認証パケットであると想定でき、取出し動作３１４で情報を取り出し、収集動作３１６で当該パケットを少なくとも１つの単一圧縮可能バッファ１２７に含めることができる。検証が失敗した場合、問合せ動作３３４で、想定される代替的な署名のサイズに基づいて、この試行が最初であったか２回目であったかを検出する。例示の目的でのみ、これらの論理動作では、２つの想定される署名のサイズで試行したことに留意されたい。追加の署名のサイズが可能である場合、追加の署名のサイズを同様に試行することができることは理解されよう。
【００６５】
これが２回目の試行であり両方の想定した署名のサイズでパディング値の検証に失敗した場合、本例では受渡し動作３０６でパケットを圧縮せずに通過させる。これが最初の試行に過ぎず代替の署名のサイズをまだ試行していない場合は、動作フローは署名動作３３６へ進む。署名動作３３６で、収集エンジンは代替の署名のサイズを想定する。次に、オフセット動作３３８は、パケットの終端に関する想定される代替的署名のサイズに基づいて、パケットのオフセットを見出す。次いで、問合せ動作３４０で、このオフセット位置にあるプロトコル番号が、当該パケットがＴＣＰであると示すかどうかを検出する。当該パケットがＴＣＰでなければ、本例では、試行用の他の署名のサイズがないので、受渡し動作３０６でパケットを圧縮せずに通過させる。当該オフセット位置がＴＣＰを示す場合、動作フローは動作３２８に進み、そこで動作フローは上述のように進む。
【００６６】
プロトコル・タイプをＴＣＰと一致させパディング値を検証した後でも、ＥＳＰの暗号化パケットを認証パケットと取り違えることは、可能性が低くとも考えられることである。このＥＳＰの暗号化パケットを圧縮しようとすることを避けるため、当該パケットを待ち行列に入れておき、次の数個、例えば３〜４個のパケットも調べて、それらのパケットもＥＳＰの認証パケットであってＥＳＰの暗号化パケットではないことを検証することができる。これらの後続パケットもＥＳＰの認証パケットであることが検証されると、待ち行列に入れたパケットを少なくとも１つの単一圧縮可能バッファ１２７に後続のパケットと共に渡すことができる。なぜなら、それらのパケットも同様にＥＳＰの認証パケットであることが殆ど確実であるからである。
【００６７】
図３Ｂは、図２Ａの収集動作２０４と同様に、収集エンジン１２４によって実行される、連続するパケットまたはそのペイロード・セグメントを少なくとも１つの単一圧縮可能バッファ１２７に収集するための論理動作の例を示す。本例では、目標は、例えば出来るだけ多くのデータ・パケットまたはそのペイロード・セグメントを少なくとも１つの単一圧縮可能バッファ１２７に収集し、圧縮エンジン１２８へ渡されているデータ・セットを出来るだけ大きくすることである。さらなる目標は、例えば、ユーザ・アプリケーションのタイムアウト、待ち時間、および応答速度低下のようなエンドポイント間ストリームに及ぼす悪影響を最小化することである。これらの論理動作も例示のために与えたものであって限定しようとするものではない。これらの動作に対しても様々な代替手段が存在することは理解されよう。
【００６８】
本論理動作は先ず問合せ動作３４２で、現在のパケットがストリームの先頭パケットまたは終点パケットであるかどうかを検出する。例えば、収集エンジン１２４は、ヘッダをチェックして、ＳＹＮ、ＦＩＮ、またはＲＳＴ ＴＣＰフラグが設定されているかどうかを確認することができる。設定されていれば、圧縮動作３４８で、当該パケットを少なくとも１つの単一圧縮可能バッファ１２７内にある現在のデータ・セットに追加し、少なくとも１つの単一圧縮可能バッファ１２７の内容を即座に圧縮エンジン１２８に送って圧縮および送信し、リモート・ピアへデータ・パケットを送達する際に遅延がさらに発生することを回避する。前述のように、データ・パケットを少なくとも１つの単一圧縮可能バッファ１２７に追加することには、当該パケットを様々なセグメントに分割し、データ・パケットを最も効率的に圧縮するために異なる圧縮アルゴリズムを異なるセグメント・タイプに適用できるように、各セグメント・タイプを別々にバッファした状態にすることを含めることができる。この分割処理中に、ヘッダおよびペイロードの順序と長さを指定するメタデータも同様に収集およびバッファすることができる。
【００６９】
現在のパケットがストリームの先頭パケットでも終点パケットでもない場合は、問合せ動作３４５で、現在のパケットが長さ零のペイロードを有するかどうかを検出する。ＴＣＰ ＡＣＫパケットのような長さ零のペイロードを有する場合は、当該パケットを少なくとも１つの単一圧縮可能バッファ１２７内にある現在のデータ・セットに追加する。圧縮動作３４８で、少なくとも１つの単一圧縮可能バッファ１２７の内容は、即座に圧縮エンジン１２８に送られて圧縮および送信され、リモート・ピアへ送達する際に遅延がさらに発生することを回避する。現在のパケットが長さ零のパケットを有しない場合は、動作フローは問合せ動作３４６に進む。
【００７０】
問合せ動作３４６は、現在のデータ・パケットの順序が、このエンドポイント間ストリームに対して受信したパケットのシーケンス内で狂っているかどうかを検出する。この検出は、最後に待ち行列に収集したパケットのＴＣＰシーケンス番号に対する、現在のパケットのＴＣＰシーケンス番号に基づいて行うことができる。現在のデータ・パケットの順序が狂っている場合は、少なくとも１つの単一圧縮可能バッファ１２７内部にある現在のデータ・パケットまたはそのペイロード・セグメントのデータ・セットを、圧縮動作３５４で圧縮するために提供し、収集動作３５６で現在のデータ・パケットを少なくとも１つの単一圧縮可能バッファ１２７の新しいインスタンスに追加して、新しい１組のパケットを開始する。これは、シーケンスから大量のパケットを受信側のパケット圧縮装置に送り、それによってエンドポイント間の通信セッションが過度に劣化しうることを回避するために行われる。
【００７１】
現在のデータ・パケットの順序が狂っていない場合は、問合せ動作３５０で、少なくとも１つの単一圧縮可能バッファ１２７内のデータ・パケットの何れかに対して、ＴＣＰタイムアウトのようなタイムアウト閾値に達しようとしているかどうかを検出する。これを、少なくとも１つの単一圧縮可能バッファ１２７の各データ・パケットを、最初に受け取った時刻を反映するタイムスタンプを記憶し、次いでそのタイムスタンプを現在時刻と比較することによって判定することができる。当該タイムアウト閾値に達しようとしている場合は、圧縮動作３４８で、現在のデータ・パケットを少なくとも１つの単一圧縮可能バッファ１２７に追加し、次いで少なくとも１つの単一圧縮可能バッファ１２７を圧縮エンジン１２８に渡して圧縮することができる。
【００７２】
タイムアウト閾値に達していない場合、問合せ動作３５２で、現在のデータ・パケットまたはそのペイロード・セグメントを少なくとも１つの単一圧縮可能バッファ１２７に追加すると、圧縮すべきデータ・セットに対する所定の最大サイズ、例えば６４キロバイトを超えるかどうかを検出する。超過する場合は、現在の少なくとも１つの単一圧縮可能バッファ１２７を、圧縮動作３５４で圧縮するために提供し、次いで収集動作３５６で現在のデータ・パケットを少なくとも１つの圧縮可能バッファ１２７の新しいインスタンスに追加して新しい１組のパケットを開始する。
【００７３】
現在のデータ・パケットを追加することにより少なくとも１つの単一圧縮可能バッファ１２７に対する所定の最大サイズを超過しない場合、収集動作３５８で、現在のデータ・パケットを少なくとも１つの単一圧縮可能バッファ１２７に追加する。次いで動作フローは問合せ動作３６０に進む。動作フローは、また、収集動作３５６を完了した後に問合せ動作３６０に進む。問合せ動作３６０は、このストリームに対して最後のデータ・パケットを少なくとも１つの単一圧縮可能バッファ１２７の待ち行列に入れて以降、遅延タイマ閾値を超過しているかどうかを検出する。１例として遅延タイマ閾値は固定の３ミリ秒であり、別の例では２つの圧縮装置間のリンクのＲＲＴ（Ｒｏｕｎｄ−Ｔｒｉｐ Ｔｉｍｅ）に従って調節可能な動的な値である。最後のデータ・パケットに対するタイムスタンプを現在時刻と比較することができる。遅延タイマ閾値を超過した場合、圧縮動作３６２で、現在のデータ・セットが圧縮エンジン１２８に提供される。遅延タイマ閾値を超過していない場合は、収集エンジン１２４は次のデータ・パケットか、収集したパケットを圧縮エンジン１２８に送ることを引き起こす別のタイマ・イベントを待つ。
【００７４】
上述のように、様々な変形を適用することができる。例えば、ＴＣＰ再試行に着目しない場合は、問合せ動作３５０を省略することができる。別の例として、遅延タイマは待ち行列の最後ではなく最初のデータ・パケットまたはそのペイロード・セグメントに基づくことができ、この場合、遅延タイマの閾値はＴＣＰタイムアウト閾値とは異なる値に設定される。遅延タイマ閾値を例えば３ミリ秒を上回るか下回る値に設定してもよい。さらに別の例として、問合せ動作３４５を省略できるように、零のペイロード・パケットをあたかもペイロードを有するかのように扱ってもよい。さらに、単一圧縮可能バッファを、着信パケットのＰＳＨ ＴＣＰフラグが設定されているかどうかを検出するによって圧縮エンジンに渡してもよく、これは、アプリケーション・レベルの確認が期待される場合はユーザ・アプリケーションの最適化を支援するはずであるが、アプリケーション・レベルの確認が期待されない場合はアプリケーションに対する圧縮率を低下させる恐れがある。
【００７５】
図４Ａは、１つの例示的な実施形態に従ってデータ・パケットとそのセグメントが圧縮および送信の段階を経て進む、諸工程を示す。最初に、データ・パケットをピア・デバイスから受け取り、圧縮可能なデータ・パケットを１組の連続データ・パケット４０２として収集する。データ・パケットはヘッダＨl〜ＨNと、対応するペイロードＰ1〜ＰNを含む。本実施形態では、別々の圧縮アルゴリズムを各ヘッダ４０３と各ペイロード４０５に対して使用してそれぞれに対する圧縮効率を最大化し、従って、この１組の連続データ・パケット４０２のパケットは１組のヘッダ４０４と１組のペイロード４０６を形成するように分割される。さらに、ヘッダとペイロードの各々の厳密な長さと順序を指定するためにメタデータ４０８を生成することができる。圧縮されたペイロードのデータ・セット４１０を形成するための圧縮アルゴリズムへ入力される１組のペイロード４０６は、少なくとも１つの単一圧縮可能バッファ１２７に記憶される。
【００７６】
本例では、次いでメタデータ４０８および１組のヘッダ４０４を、圧縮されたペイロードのデータ・セット４１０と連結して、連結された１組のデータ・セット４１１を形成する。さらに、本実施形態によると、連結されたデータ・セット４１１をＬＺＷのような圧縮技術を用いて圧縮して、圧縮されたデータ・セット４１２を形成する。セグメント・タイプごとに少なくとも１つの単一圧縮可能バッファ１２７の別々のインスタンスを用いて３つの部分の各々を別々に圧縮し、次いで結果を連結して圧縮されたデータ・セットを形成するような、代替的な圧縮方法も存在することは理解されよう。さらに、連結されたデータ・セット４１１を送信できるようにヘッダおよび／またはメタデータを未圧縮のままにしてもよいことは理解されよう。
【００７７】
本実施形態の圧縮されたデータ・セット４１２を送信するために、当該データ・セットをパケット化して１組のトンネル・パケット４１４を形成する。１組のトンネル・パケット４１４のトンネル・パケットは、それ自体のヘッダＨ11〜ＨNNと、対応するペイロードＰ11〜ＰNNを含む。次いでネットワーク１０６を介してこれらのトンネル・パケットを受信側の圧縮装置に送信する。１組のヘッダおよび１組の圧縮されたペイロードに対して別々のトンネル・パケットを生成するような、ヘッダおよび圧縮されたペイロードの代替的な転送方法も可能であることは理解されよう。
【００７８】
図４Ｂは、１つの例示的な実施形態に従って、データ・パケットとそのセグメントが、受信、解凍、および再構築段階を経て進む、諸工程を示す。最初に、１組のトンネル・パケット４１４を送信側の圧縮装置から受け取る。次に、１組のトンネル・パケット４１４の各トンネル・パケットを分解して圧縮されたデータ・セット４１２を再生成する。連結されたデータ・セット４１１を圧縮して圧縮されたデータ・セット４１２を生成するこのような実施形態の場合、その圧縮されたデータ・セット４１２を、次に解凍エンジン１５２により解凍して、１組のヘッダ４０４、メタデータ４０８、および圧縮されたペイロードのデータ・セット４１０を生成する。次いで、圧縮されたペイロードのデータ・セット４１０を少なくとも１つの単一の解凍バッファとして解凍エンジン１５２に提供し、そこで解凍して１組のペイロード４０６を生成する。
【００７９】
次に、これらの解凍された１組のヘッダ４０４、１組のペイロード４０６、およびメタデータ４０８を分配エンジン１３９に提供する。次に、分配エンジン１３９はメタデータ４０８で指定された長さと順序に従って、１組のヘッダ４０４の各ヘッダを１組のペイロード４０６のその対応するペイロードと照合する。分配エンジン１３９は、イーサネット・ヘッダおよびＩＰＳｅｃ ＥＳＰパディングのような任意のさらなるデータを追加する。当該任意の追加のデータは送信されないが分配エンジン１３９に既知であり、それにより各ヘッダ４０３とそれぞれの対応するペイロード４０５を含む１組の連続データ・パケット４０２を再構築することができる。次いで、分配エンジン１３９は１組の連続データ・パケット４０２の個々のデータ・パケットを、受信側のパケット圧縮装置に対してローカルなピア・デバイスへのエンド・ツー・エンドのストリームに投入する。
【００８０】
以上、本発明を構造的特徴および／または方法論的行動に特有な言葉で説明したが、添付の特許請求の範囲で定義した主題は必ずしも上述の特定の特徴または行動に限定されないことは理解されよう。そうではなく、上述の特定の特徴および行動は諸請求項を実装する形態の例として開示してある。
【特許請求の範囲】
【請求項１】
データ・パケット送信を圧縮する方法であって、
エンドポイント（１０２、１１０）間の第１の単一通信セッション（１１３）のバイト・ストリーム内で連続し、それぞれがヘッダ（４０３）とペイロード（４０５）を含む複数の連続データ・パケット（４０２）を第１の組に収集するステップ（２０４）と、
前記第１の組の連続データ・パケット（４０２）のうち少なくともペイロード（４０５）を少なくとも１つのバッファ（１２７）にグループ化するステップ（３４８）と、
前記少なくとも１つのバッファ（１２７）の少なくとも複数のペイロード（４０５）を単一のデータ・セットとして圧縮して（２０６）、圧縮されたデータ・セット（４１０）を生成するステップと、
前記連続データ・パケット（４０２）の前記圧縮されたデータ・セット（４１０）およびヘッダ（４０３）をパケット化して第２の組のデータ・パケット（４１４）を形成するステップであって、前記第２の組のデータ・パケット（４１４）は前記第１の組（４０２）のヘッダ（４０３）とは異なるヘッダ（４１５）を有するステップと、
前記第２の組のデータ・パケット（４１４）をエンドポイント（１０４、１０８）間の第２の単一通信セッション（１１５）を介して送信するステップ（２０８）と
を含むことを特徴とする方法。
【請求項２】
前記第１の組のデータ・パケットごとに、前記ヘッダを前記ペイロードから分離するステップと、
前記ヘッダを前記圧縮されたデータ・セットと連結して、連結されたデータ・セットを生成し、前記連結されたデータ・セットを圧縮して前記第２の組のデータ・パケットが１組の圧縮されたヘッダと１組の圧縮されたペイロードとを含むようにするステップと
をさらに含むことを特徴とする請求項１に記載の方法。
【請求項３】
データ・パケットを複数の追加の通信セッションから受け取るステップをさらに含み、前記複数の連続データ・パケットを前記第１の組へ収集するステップは、エンドポイント間の前記第１の単一通信セッションから受け取ったデータ・パケットを特定するステップを含むことを特徴とし、前記第１の単一の通信セッションとは異なるエンドポイント間の単一通信セッションから受け取ったデータ・パケットを特定するステップと、前記異なる単一の通信セッションから受け取った前記データ・パケットを前記第１の組とは異なる組に含めるステップとをさらに含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記１組の連続データ・パケットのうち少なくともペイロードを前記単一圧縮可能バッファにグループ化するステップは、ペイロードを前記単一圧縮可能バッファに追加することを停止し、前記単一圧縮可能バッファの圧縮を開始するかどうかを判定するステップを含むことを特徴とする請求項３に記載の方法。
【請求項５】
ペイロードの追加を停止するかどうかを判定するステップは、少なくとも１つの閾値に到達したかどうかを検出するステップを含み、前記１つの閾値は、トランスポート層タイムアウト、単一圧縮可能バッファの最大サイズ、および前のペイロードを前記単一圧縮可能バッファに追加した時点からの所定の遅延のうち少なくとも１つを含むことを特徴とする請求項４に記載の方法。
【請求項６】
前記複数の連続データ・パケットを前記第１の組に収集するステップは、
エンドポイント間の前記第１の通信セッションの任意のデータ・パケットがセキュリティ・ヘッダを含むかどうかを判定するステップと、
エンドポイント間の前記第１の通信セッションのデータ・パケットがセキュリティ・ヘッダを含む場合、前記セキュリティ・ヘッダを伴う前記データ・パケットが暗号化されたデータ・パケットか認証されたデータ・パケットかを判定するステップと、
前記データ・パケットが認証されたデータ・パケットであると判定された場合は、前記データ・パケットを前記第１の組に含め、前記データ・パケットが暗号化されたデータ・パケットであると判定された場合は、前記データ・パケットを圧縮せずにエンドポイント間の前記第１の通信セッションを介して転送するステップと
を含むことを特徴とする請求項１に記載の方法。
【請求項７】
前記受け取ったデータ・パケットの何れかがセキュリティ・ヘッダを含むかどうかを判定するステップは、前記パケットがＩＰＳｅｃ ＥＳＰパケットかどうかを検出するステップを含み、前記パケットがＩＰＳｅｃ ＥＳＰパケットである場合は、前記ＩＰＳｅｃ ＥＳＰパケットが暗号化されたパケットであるか認証されたパケットであるかを、想定したＩＰＳｅｃ ＥＳＰ署名のサイズを用いて前記パケットの検証を試行することによって判定するステップを含むことを特徴とする請求項６に記載の方法。
【請求項８】
前記第１の組の連続データ・パケットを収集するステップは、各データ・パケットを分析して前記パケットが送信制御プロトコルのパケットであるかどうかを検出するステップと、送信制御プロトコルのパケットであるデータ・パケットを前記第１の組に含めるステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項９】
前記第１の通信セッションの前記連続データ・パケットの少なくとも１つのヘッダから優先度設定を取得するステップと、
前記第２の組のデータ・パケットの少なくとも１つのヘッダに対して、前記取得した優先度設定を指定するステップと
をさらに含むことを特徴とする請求項１に記載の方法。
【請求項１０】
動作を実装時に実行する命令を自身の上に符号化した形で含むコンピュータ可読媒体であって、
それぞれがヘッダ（４１５）とペイロード（４１７）を含む、エンドポイント（１０４、１０８）間の第２の通信セッション（１１５）の複数のデータ・パケット（４１４）を受け取るステップ（２１０）と、
前記受け取ったデータ・パケット（４１４）を分解（２１２）して、エンドポイント（１０２、１１０）間の第１の単一通信セッション（１１３）のバイト・ストリーム内で連続する１組の連続データ・パケット（４０２）のヘッダ（４０３）を取り出し、エンドポイント（１０２、１１０）間の前記第１の単一通信セッション（１１３）の前記１組の連続データ・パケット（４０２）の圧縮されたペイロード（４１０）を含む単一の圧縮されたデータ・セット（４１１）を取り出すステップであって、前記１組の連続データ・パケット（４０２）の前記ヘッダ（４０３）は前記受け取った複数のデータ・パケット（４１４）の前記ヘッダ（４１５）とは異なるステップと、
前記圧縮されたデータ・セット（４１１）を解凍（２１４）して、前記１組の連続データ・パケット（４０２）の前記ペイロード（４０５）を取り出すステップと、
前記１組の連続データ・パケット（４０２）の前記ヘッダ（４０３）を前記１組の連続データ・パケット（４０２）の解凍したペイロード（４０５）と照合することによって、前記１組の連続データ・パケット（４０２）を再構築するステップ（２１６）と、
前記再構築した１組の連続データ・パケット（４０２）を前記第１の単一通信セッション（１１３）に所定の順序で投入するステップ（２１８）と
を含むことを特徴とするコンピュータ可読媒体。
【請求項１１】
各連続データ・パケットのヘッダは送信制御プロトコルのヘッダであることを特徴とする請求項１０に記載のコンピュータ可読媒体。
【請求項１２】
前記複数のデータ・パケットは、前記第１の通信セッションからのヘッダとペイロードのシーケンシャルな順序を指定するメタデータを含み、前記１組の連続データ・パケットを再構築するステップは、前記メタデータに従ってヘッダおよびペイロードを取得するステップを含むことを特徴とする請求項１０に記載のコンピュータ可読媒体。
【請求項１３】
前記所定の順序は、エンドポイント間の前記第１の単一通信セッションの前記１組の連続データ・パケットの順序と一致することを特徴とする請求項１０に記載のコンピュータ可読媒体。
【請求項１４】
データ・パケットを圧縮するための装置（１０４）であって、
少なくとも１つのネットワーク接続機器（１１２）と、
第１の単一通信セッション（１１３）のエンドポイント（１１０）宛ての着信パケットを前記少なくとも１つのネットワーク接続機器（１１２）を介して受け取り、前記着信パケットを、前記第１の単一通信セッション（１１３）のバイト・ストリーム内で連続しており、圧縮し送信すべきである第１の組の連続データ・パケット（４０２）に含めることが可能かどうかを判定し、前記第１の組の連続データ・パケット（４０２）の少なくともペイロード（４０５）を少なくとも１つのバッファ（１２７）に提供する、収集エンジン（１２４）と、
前記少なくとも１つのバッファ（１２７）の少なくとも複数のペイロード（４０５）を単一データとして圧縮して、圧縮されたデータ・セット（４１０）を形成する圧縮エンジン（１２８）と、
前記圧縮されたデータ・セット（４１０）、および前記第１の組（４０２）の前記連続データ・パケットのトランスポート層ヘッダ（４０３）を第２の組のデータ・パケット（４１４）にパケット化し、前記第２の組（４１４）を第２の通信セッション（１１５）上で別の装置（１０８）に送信する送信エンジン（１２６）と
を備えることを特徴とする装置。
【請求項１５】
着信パケットを前記少なくとも１つのネットワーク接続を介して前記第２の通信セッション上で他の装置から受け取り、前記着信パケットを分解して前記トランスポート層ヘッダおよび圧縮されたデータ・セットを取り出す受信エンジンと、
前記圧縮されたデータ・セットを受け取り、前記圧縮されたデータ・セットを解凍して前記第１の組の連続データ・パケットのペイロードを取り出す解凍エンジンと、
ヘッダおよび解凍されたペイロードを取得して、前記第１の組の連続データ・パケットを、ヘッダを解凍したペイロードと照合することによって再構築する分配エンジンと
をさらに備えることを特徴とする請求項１４に記載の装置。
【請求項１６】
前記分配エンジンは前記再構築された第１の組の連続データ・パケットを前記エンドポイントとの第２の通信セッションに投入することを特徴とする請求項１４に記載の装置。
【請求項１７】
前記収集エンジンは、
何れかの着信データ・パケットがセキュリティ・ヘッダを含むかどうかを判定するステップと、
着信データ・パケットがセキュリティ・ヘッダを含む場合は、前記セキュリティ・ヘッダを伴う前記着信データ・パケットが暗号化されたパケットか認証されたパケットかを判定するステップと、
認証されたデータ・パケットを前記第１の組に含め、一方で前記暗号化されたパケットは圧縮せずに通過させるステップと、
によって前記連続データ・パケットを前記第１の組に収集することを特徴とする請求項１４に記載の装置。
【請求項１８】
前記収集エンジンが前記着信データ・パケットの何れかがセキュリティ・ヘッダを含むかどうかを検出するステップは、前記パケットがＩＰＳｅｃ ＥＳＰパケットかどうかを検出し、前記パケットがＩＰＳｅｃ ＥＳＰパケットである場合は、前記収集エンジンは、前記ＩＰＳｅｃ ＥＳＰパケットが暗号化されたパケットか認証されたパケットかを、想定したＩＰＳｅｃ ＥＳＰ署名のサイズを用いて前記パケットの検証を試行することによって判定するステップを備えることを特徴とする請求項１７に記載の装置。
【請求項１９】
前記収集エンジンは、着信データ・パケットを、各データ・パケットを分析して前記パケットが送信制御プロトコルのパケットかどうかを検出し、送信制御プロトコルのパケットであるデータ・パケットを含めることによって、前記第１の組の連続データ・パケットに収集することを特徴とする請求項１４に記載の装置。
【請求項２０】
前記収集エンジンは、前記第１の通信セッションの前記連続データ・パケットのヘッダから優先度設定を取得し、前記送信エンジンは、前記第２の組のデータ・パケットのヘッダに対して、前記取得した優先度設定を指定することを特徴とする請求項１４に記載の装置。
【請求項１】
データ・パケット送信を圧縮する方法であって、
エンドポイント（１０２、１１０）間の第１の単一通信セッション（１１３）のバイト・ストリーム内で連続し、それぞれがヘッダ（４０３）とペイロード（４０５）を含む複数の連続データ・パケット（４０２）を第１の組に収集するステップ（２０４）と、
前記第１の組の連続データ・パケット（４０２）のうち少なくともペイロード（４０５）を少なくとも１つのバッファ（１２７）にグループ化するステップ（３４８）と、
前記少なくとも１つのバッファ（１２７）の少なくとも複数のペイロード（４０５）を単一のデータ・セットとして圧縮して（２０６）、圧縮されたデータ・セット（４１０）を生成するステップと、
前記連続データ・パケット（４０２）の前記圧縮されたデータ・セット（４１０）およびヘッダ（４０３）をパケット化して第２の組のデータ・パケット（４１４）を形成するステップであって、前記第２の組のデータ・パケット（４１４）は前記第１の組（４０２）のヘッダ（４０３）とは異なるヘッダ（４１５）を有するステップと、
前記第２の組のデータ・パケット（４１４）をエンドポイント（１０４、１０８）間の第２の単一通信セッション（１１５）を介して送信するステップ（２０８）と
を含むことを特徴とする方法。
【請求項２】
前記第１の組のデータ・パケットごとに、前記ヘッダを前記ペイロードから分離するステップと、
前記ヘッダを前記圧縮されたデータ・セットと連結して、連結されたデータ・セットを生成し、前記連結されたデータ・セットを圧縮して前記第２の組のデータ・パケットが１組の圧縮されたヘッダと１組の圧縮されたペイロードとを含むようにするステップと
をさらに含むことを特徴とする請求項１に記載の方法。
【請求項３】
データ・パケットを複数の追加の通信セッションから受け取るステップをさらに含み、前記複数の連続データ・パケットを前記第１の組へ収集するステップは、エンドポイント間の前記第１の単一通信セッションから受け取ったデータ・パケットを特定するステップを含むことを特徴とし、前記第１の単一の通信セッションとは異なるエンドポイント間の単一通信セッションから受け取ったデータ・パケットを特定するステップと、前記異なる単一の通信セッションから受け取った前記データ・パケットを前記第１の組とは異なる組に含めるステップとをさらに含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記１組の連続データ・パケットのうち少なくともペイロードを前記単一圧縮可能バッファにグループ化するステップは、ペイロードを前記単一圧縮可能バッファに追加することを停止し、前記単一圧縮可能バッファの圧縮を開始するかどうかを判定するステップを含むことを特徴とする請求項３に記載の方法。
【請求項５】
ペイロードの追加を停止するかどうかを判定するステップは、少なくとも１つの閾値に到達したかどうかを検出するステップを含み、前記１つの閾値は、トランスポート層タイムアウト、単一圧縮可能バッファの最大サイズ、および前のペイロードを前記単一圧縮可能バッファに追加した時点からの所定の遅延のうち少なくとも１つを含むことを特徴とする請求項４に記載の方法。
【請求項６】
前記複数の連続データ・パケットを前記第１の組に収集するステップは、
エンドポイント間の前記第１の通信セッションの任意のデータ・パケットがセキュリティ・ヘッダを含むかどうかを判定するステップと、
エンドポイント間の前記第１の通信セッションのデータ・パケットがセキュリティ・ヘッダを含む場合、前記セキュリティ・ヘッダを伴う前記データ・パケットが暗号化されたデータ・パケットか認証されたデータ・パケットかを判定するステップと、
前記データ・パケットが認証されたデータ・パケットであると判定された場合は、前記データ・パケットを前記第１の組に含め、前記データ・パケットが暗号化されたデータ・パケットであると判定された場合は、前記データ・パケットを圧縮せずにエンドポイント間の前記第１の通信セッションを介して転送するステップと
を含むことを特徴とする請求項１に記載の方法。
【請求項７】
前記受け取ったデータ・パケットの何れかがセキュリティ・ヘッダを含むかどうかを判定するステップは、前記パケットがＩＰＳｅｃ ＥＳＰパケットかどうかを検出するステップを含み、前記パケットがＩＰＳｅｃ ＥＳＰパケットである場合は、前記ＩＰＳｅｃ ＥＳＰパケットが暗号化されたパケットであるか認証されたパケットであるかを、想定したＩＰＳｅｃ ＥＳＰ署名のサイズを用いて前記パケットの検証を試行することによって判定するステップを含むことを特徴とする請求項６に記載の方法。
【請求項８】
前記第１の組の連続データ・パケットを収集するステップは、各データ・パケットを分析して前記パケットが送信制御プロトコルのパケットであるかどうかを検出するステップと、送信制御プロトコルのパケットであるデータ・パケットを前記第１の組に含めるステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項９】
前記第１の通信セッションの前記連続データ・パケットの少なくとも１つのヘッダから優先度設定を取得するステップと、
前記第２の組のデータ・パケットの少なくとも１つのヘッダに対して、前記取得した優先度設定を指定するステップと
をさらに含むことを特徴とする請求項１に記載の方法。
【請求項１０】
動作を実装時に実行する命令を自身の上に符号化した形で含むコンピュータ可読媒体であって、
それぞれがヘッダ（４１５）とペイロード（４１７）を含む、エンドポイント（１０４、１０８）間の第２の通信セッション（１１５）の複数のデータ・パケット（４１４）を受け取るステップ（２１０）と、
前記受け取ったデータ・パケット（４１４）を分解（２１２）して、エンドポイント（１０２、１１０）間の第１の単一通信セッション（１１３）のバイト・ストリーム内で連続する１組の連続データ・パケット（４０２）のヘッダ（４０３）を取り出し、エンドポイント（１０２、１１０）間の前記第１の単一通信セッション（１１３）の前記１組の連続データ・パケット（４０２）の圧縮されたペイロード（４１０）を含む単一の圧縮されたデータ・セット（４１１）を取り出すステップであって、前記１組の連続データ・パケット（４０２）の前記ヘッダ（４０３）は前記受け取った複数のデータ・パケット（４１４）の前記ヘッダ（４１５）とは異なるステップと、
前記圧縮されたデータ・セット（４１１）を解凍（２１４）して、前記１組の連続データ・パケット（４０２）の前記ペイロード（４０５）を取り出すステップと、
前記１組の連続データ・パケット（４０２）の前記ヘッダ（４０３）を前記１組の連続データ・パケット（４０２）の解凍したペイロード（４０５）と照合することによって、前記１組の連続データ・パケット（４０２）を再構築するステップ（２１６）と、
前記再構築した１組の連続データ・パケット（４０２）を前記第１の単一通信セッション（１１３）に所定の順序で投入するステップ（２１８）と
を含むことを特徴とするコンピュータ可読媒体。
【請求項１１】
各連続データ・パケットのヘッダは送信制御プロトコルのヘッダであることを特徴とする請求項１０に記載のコンピュータ可読媒体。
【請求項１２】
前記複数のデータ・パケットは、前記第１の通信セッションからのヘッダとペイロードのシーケンシャルな順序を指定するメタデータを含み、前記１組の連続データ・パケットを再構築するステップは、前記メタデータに従ってヘッダおよびペイロードを取得するステップを含むことを特徴とする請求項１０に記載のコンピュータ可読媒体。
【請求項１３】
前記所定の順序は、エンドポイント間の前記第１の単一通信セッションの前記１組の連続データ・パケットの順序と一致することを特徴とする請求項１０に記載のコンピュータ可読媒体。
【請求項１４】
データ・パケットを圧縮するための装置（１０４）であって、
少なくとも１つのネットワーク接続機器（１１２）と、
第１の単一通信セッション（１１３）のエンドポイント（１１０）宛ての着信パケットを前記少なくとも１つのネットワーク接続機器（１１２）を介して受け取り、前記着信パケットを、前記第１の単一通信セッション（１１３）のバイト・ストリーム内で連続しており、圧縮し送信すべきである第１の組の連続データ・パケット（４０２）に含めることが可能かどうかを判定し、前記第１の組の連続データ・パケット（４０２）の少なくともペイロード（４０５）を少なくとも１つのバッファ（１２７）に提供する、収集エンジン（１２４）と、
前記少なくとも１つのバッファ（１２７）の少なくとも複数のペイロード（４０５）を単一データとして圧縮して、圧縮されたデータ・セット（４１０）を形成する圧縮エンジン（１２８）と、
前記圧縮されたデータ・セット（４１０）、および前記第１の組（４０２）の前記連続データ・パケットのトランスポート層ヘッダ（４０３）を第２の組のデータ・パケット（４１４）にパケット化し、前記第２の組（４１４）を第２の通信セッション（１１５）上で別の装置（１０８）に送信する送信エンジン（１２６）と
を備えることを特徴とする装置。
【請求項１５】
着信パケットを前記少なくとも１つのネットワーク接続を介して前記第２の通信セッション上で他の装置から受け取り、前記着信パケットを分解して前記トランスポート層ヘッダおよび圧縮されたデータ・セットを取り出す受信エンジンと、
前記圧縮されたデータ・セットを受け取り、前記圧縮されたデータ・セットを解凍して前記第１の組の連続データ・パケットのペイロードを取り出す解凍エンジンと、
ヘッダおよび解凍されたペイロードを取得して、前記第１の組の連続データ・パケットを、ヘッダを解凍したペイロードと照合することによって再構築する分配エンジンと
をさらに備えることを特徴とする請求項１４に記載の装置。
【請求項１６】
前記分配エンジンは前記再構築された第１の組の連続データ・パケットを前記エンドポイントとの第２の通信セッションに投入することを特徴とする請求項１４に記載の装置。
【請求項１７】
前記収集エンジンは、
何れかの着信データ・パケットがセキュリティ・ヘッダを含むかどうかを判定するステップと、
着信データ・パケットがセキュリティ・ヘッダを含む場合は、前記セキュリティ・ヘッダを伴う前記着信データ・パケットが暗号化されたパケットか認証されたパケットかを判定するステップと、
認証されたデータ・パケットを前記第１の組に含め、一方で前記暗号化されたパケットは圧縮せずに通過させるステップと、
によって前記連続データ・パケットを前記第１の組に収集することを特徴とする請求項１４に記載の装置。
【請求項１８】
前記収集エンジンが前記着信データ・パケットの何れかがセキュリティ・ヘッダを含むかどうかを検出するステップは、前記パケットがＩＰＳｅｃ ＥＳＰパケットかどうかを検出し、前記パケットがＩＰＳｅｃ ＥＳＰパケットである場合は、前記収集エンジンは、前記ＩＰＳｅｃ ＥＳＰパケットが暗号化されたパケットか認証されたパケットかを、想定したＩＰＳｅｃ ＥＳＰ署名のサイズを用いて前記パケットの検証を試行することによって判定するステップを備えることを特徴とする請求項１７に記載の装置。
【請求項１９】
前記収集エンジンは、着信データ・パケットを、各データ・パケットを分析して前記パケットが送信制御プロトコルのパケットかどうかを検出し、送信制御プロトコルのパケットであるデータ・パケットを含めることによって、前記第１の組の連続データ・パケットに収集することを特徴とする請求項１４に記載の装置。
【請求項２０】
前記収集エンジンは、前記第１の通信セッションの前記連続データ・パケットのヘッダから優先度設定を取得し、前記送信エンジンは、前記第２の組のデータ・パケットのヘッダに対して、前記取得した優先度設定を指定することを特徴とする請求項１４に記載の装置。
【図１Ａ】
【図１Ｂ】
【図２Ａ】
【図２Ｂ】
【図３Ａ】
【図３Ｂ】
【図４Ａ】
【図４Ｂ】
【図１Ｂ】
【図２Ａ】
【図２Ｂ】
【図３Ａ】
【図３Ｂ】
【図４Ａ】
【図４Ｂ】
【公表番号】特表２０１０−５２９７０４（Ｐ２０１０−５２９７０４Ａ）
【公表日】平成２２年８月２６日（２０１０．８．２６）
【国際特許分類】
【出願番号】特願２０１０−５０６３６６（Ｐ２０１０−５０６３６６）
【出願日】平成２０年３月２５日（２００８．３．２５）
【国際出願番号】ＰＣＴ／ＵＳ２００８／０５８１３８
【国際公開番号】ＷＯ２００８／１３４１５７
【国際公開日】平成２０年１１月６日（２００８．１１．６）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．イーサネット
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
【公表日】平成２２年８月２６日（２０１０．８．２６）
【国際特許分類】
【出願日】平成２０年３月２５日（２００８．３．２５）
【国際出願番号】ＰＣＴ／ＵＳ２００８／０５８１３８
【国際公開番号】ＷＯ２００８／１３４１５７
【国際公開日】平成２０年１１月６日（２００８．１１．６）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．イーサネット
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
[ Back to top ]