JP2012216230A - ネットワーク・サーバ用の事前パケット化キャッシングの方法及び装置 - Google Patents

Abstract

【課題】ネットワーク・サーバ上に記憶された、クライアント・ノードの要求データをキャッシュする方法及び装置を提供すること。
【解決手段】 本方法及び装置は、事前パケット化レベルでサーバ応答をキャッシュし、それにより、パケット処理のオーバヘッドを最小限に抑え、ディスク・ファイルの読取りを減らし、ディスク・バッファからネットワーク・インターフェースへのメモリのコピーを少なくすることによって応答時間を短縮するステップを含む。
【選択図】図３

Description

本発明は、通信ネットワーク上の情報を管理する分野に関し、より詳細には、パケット交換通信ネットワーク環境内の情報のキャッシングに関する。

Ｗｅｂサーバ、ビデオ・サーバ、ファイル・サーバなど典型的なネットワーク・サーバ、ならびにローカル・オペレーション・システムは、クライアント情報要求またはクライアント・データ要求にできるだけ迅速に応答するように設計されている。キャッシング、すなわち次の要求を見越して、最近要求のあった情報、例えばデータ・ファイルをメモリ・バッファに記憶することは、ネットワーク・サーバ及びローカル・オペレーション・システムによってサーバ応答時間を短縮するために使用される一般的な手法である。

例えば、Ｗｅｂサーバは、最近要求されたＨＴＭＬコンテンツを、ディスク上ではなく主記憶装置バッファ内に記憶することによって、ディスク・キャッシュを多用する。この種の記憶域の構成は、参照局所性の原則に従ってうまく働く。すなわち、最近記憶されたコンテンツは、すぐにまた要求される可能性が高い。

一般的に、イーサネット型ローカル・エリア・ネットワーク（ＬＡＮ）やインターネットなどのパケット交換通信ネットワークは、ホスト／ホスト環境またはサーバ／クライアント環境で使用される。その情報が次回要求されたときに容易にアクセスされスループットが向上するように、通常はサーバによって取り出し済みの、以前に要求された情報がキャッシュされる。しかし、要求されたデータがキャッシュされていたとしても、同一またはほぼ同一なデータに対する新しい要求があるたびに、サーバが、送信のためにネットワーク・インターフェースに送るべき新しいパケット（ペイロードとしてキャッシュ済みデータを含む）を作成せざるを得なくなる。

例えば、Ｗｅｂサーバの場合、既知のシステムは、ＵＲＬ解決（例えばＵＲＬの、ディスク上のファイルへのマッピング）の結果をキャッシュし、ＨＴＴＰ ２００ ＯＫ応答といったＨＴＴＰ応答及び最終変更日付などを含み得るＨＴＴＰ応答ヘッダを、文書ごとにキャッシュする。従って、これらの既知のシステムでは、静的コンテンツ（例えばＨＴＴＰ応答ヘッダ及び本体）のキャッシングを実行することができる。静的コンテンツは通常、すべてのクライアントについて同じコンテンツである。

典型的なサーバ／クライアント・パケット交換通信ネットワークでは、クライアントはデータ要求をサーバに送信することができる。クライアント要求に基づいて、サーバはハード・ドライブまたはフロッピー・ディスクからデータ・ファイルを取り出し、データ・ファイルをパケットに分割し、そのパケットをクライアントへ応答として送信する。パケットを送信する前に、サーバは各パケットごとに１つずつメモリ・バッファを割り当てて、応答データを一時的に格納する必要がある。このプロセスでは、サーバがハード・ドライブまたはフロッピー・ディスクからのデータ・ファイル全体をローカル・メモリにコピーし、そのデータをパケット化し、各パケットを別々のバッファに記憶する必要がある。要求された情報のすべてのバイトをヘッダ情報と共にメモリ・バッファ内にコピーするには、著しく時間がかかる。

従って、前述のキャッシング技法によってパケット交換通信ネットワークなどにおける応答時間を短縮することができるが、ネットワーク・サーバの平均応答時間を短縮し、パケット交換ネットワーク内のスループットを改善する方法及び装置が依然として求められている。

ネットワーク・サーバのハードウェアを必ずしも増強することなく、パケット交換ネットワーク・サーバの応答の平均応答時間を短縮し、比較的多くのクライアント・ノードがネットワーク・サーバに接続できるようにスループットを改善する方法及び装置に関する本発明によって、従来技術における様々な欠点は、対処される。

本発明の一態様によれば、サーバ応答データをキャッシュする方法が提供される。この方法は、サーバからデータを取り出すステップと、取り出したデータを、静的コンテンツ及び動的コンテンツを含む複数の応答パケットに分割するステップと、少なくとも１つの応答パケットの動的フィールドを所定の固定値に設定するステップと、少なくとも１つの応答パケットの動的フィールド及び静的フィールドをメモリ・バッファにキャッシュするステップと、メモリ・バッファからの得られた少なくとも１つの応答パケットを、通信ネットワークを介して送信するためにネットワーク・インターフェースに供給するステップとを含んでいる。
本発明の諸態様の教示内容は、以下の詳細な説明を添付の図面と共に考察すれば容易に理解することができる。

本発明の諸態様に従って動作する通信ネットワーク・アーキテクチャの機能ブロック図である。 本発明の諸態様に関連して使用されるサンプルＴＣＰ／ＩＰスタックを示す図である。 図１の通信ネットワーク・システムによって生成し、図２ＡのＴＣＰ／ＩＰプロトコルを使用して送信することができる、サンプルＨＴＴＰ応答パケットを示す図である。 本発明の諸態様による方法の流れ図である。

理解を容易にするために、諸図に共通する同じ要素を示すのに、可能な限り同じ参照番号を繰り返し使用する。
本発明の諸態様は、以下では主として、ＨＴＭＬページを送信するＷｅｂベースのサーバ向けのＴＣＰ／ＩＰプロトコル群の文脈で論じる。しかし、本発明の諸態様の方法を、ストリーム・ビデオを送信するためのユーザ・データグラム・プロトコル（ＵＤＰ）（トランスポート）など他のパケット交換トランスポート／ネットワーク・プロトコルにも容易に適用できることが理解されよう。また、これらの例は、ＩＰ ｖ４プロトコルに関して説明してあるが、本発明の諸態様を他のＩＰバージョン、例えばＩＰ ｖ６にも容易に適用することができる。

本発明の諸態様では、クライアント・ノード要求への応答パケットを送信する前に、要求された情報の既知の静的フィールド及び動的フィールドを所定の形式でキャッシュしておくことによって、サーバ応答時間を改善する。静的コンテンツは通常、すべてのクライアントに対して同じコンテンツである。また、動的コンテンツは通常、クライアントまたはクライアント要求ごとに異なるコンテンツである。従って、本発明の諸態様により、要求されるたびにすべてのバイトの応答データを読み取り、取り出す必要が減り、これにより、応答時間が改善され、クライアント要求あたりのスループットが増大する。

図１に、本発明の実施形態を利用できるデータ通信ネットワーク１００を示す。図１は、可能な複数のデータ通信ネットワーク構成の一変形形態を示している。例えば、図１のネットワーク１００は、任意選択で、複数のホスト・サーバ１０６及び／またはいくつかのクライアント・ノードもしくはクライアント・コンピュータ１０２を含む。わかりやすくするため、１つのホスト・サーバ１０６と１つのクライアント・コンピュータ１０２だけが示してある。

データ通信ネットワーク１００は、クライアント・ノード（またはクライアント・コンピュータ）１０２とホスト・サーバ１０６を含んでおり、これらは従来のパケット交換データ通信ネットワーク１０４（例えばインターネット、広域ネットワーク（ＷＡＮ）、イーサネット（ＬＡＮ）、またはＷｉ−Ｆｉネットワークなどの無線ネットワーク）を介して通信する。ホスト・サーバ１０６は、アプリケーション・サービス及びデータ・サービス、ならびにその他のリソース・サービスをクライアント・コンピュータ１０２に提供するために、ネットワーク・インターフェース・カード（ＮＩＣ）１０５を介してネットワーク１０４に結合されている。また、クライアント・コンピュータ１０２は、表示装置１３２にも接続されている。

ホスト・サーバ１０６は、少なくとも１つの中央処理装置（ＣＰＵ）１１０、サポート回路１１２、及びメモリ１１４を含んでいる。ＣＰＵ１１０は、従来から入手可能な１つまたは複数のマイクロプロセッサを含むことができる。サポート回路１１２は、ＣＰＵ１１０の機能を向上させるために使用される周知の回路である。こうした回路には、キャッシュ・メモリ、電源、クロック回路、入出力（Ｉ／Ｏ）回路などが含まれ得るが、それだけに限定されない。メモリ１１４は、ＣＰＵ１００に結合されており、ランダム・アクセス・メモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、取外し可能ディスク・メモリ、フラッシュ・メモリ、及びこの種のメモリの様々な組合せを含むことができる。メモリ１１４は主記憶と呼ばれることがあり、その一部に、データ・ファイルを求めるクライアント要求に応答してパケット形式の取り出し済みデータを一時的に格納するためのキャッシュ・メモリまたはメモリ・バッファ１１５の記憶場所を含むことができる。

また、メモリ１１４は通常、サーバ１０６のオペレーション・システム・ソフトウェア１１６と、様々な形態のアプリケーション・ソフトウェア１０８及びデータ１１８も記憶する。オペレーション・システム１１６は、サン・マイクロシステムズ社のＳｏｌａｒｉｓ、ＩＢＭ社のＡＩＸ、ヒューレット・パッカード社のＨＰ−ＵＸ、レッドハット・ソフトウェア社のＬｉｎｕｘ、マイクロソフト社のＷｉｎｄｏｗｓ２０００など、市販のいくつかのオペレーション・システムのうちの１つとすることができる。

アプリケーション・ソフトウェア１０８には、伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）のプロトコル群を使用して「Ｗｅｂサイト」及び「Ｗｅｂページ」にアクセスし、それを記憶し、更新し、あるいはそのいずれかを行う任を負う、様々なソフトウェア・プログラムを含むＷｅｂサーバ・ソフトウェア１２０が含まれ得る。このアプリケーション・ソフトウェアはまた、ファイル転送プロトコル（ＦＴＰ）アプリケーション・プロトコルを使用して、データ・ファイルを記憶し、編成し、取得し、更新する任を負うファイル・サーバ・ソフトウェア・プログラムを含むこともできる。このアプリケーション・ソフトウェアはさらに、ユーザ・データグラム・プロトコル（ＵＤＰ）トランスポート・プロトコルを使用して、ビデオ・データ・ファイルを記憶し、編成し、取得し、送信するためのビデオ・サーバ・ソフトウェアを含むこともできる。一般に、Ｗｅｂサーバ・ソフトウェア１２０は、ホスト・サーバ１０６上に記憶されたデータ及び情報に対する、「ブラウザ」を介した、あるいはデータを取り出し転送するための他のデバイスを介した、リモート・コンピュータ（例えばクライアント・コンピュータ１０２）へのアクセスを提供する。Ｗｅｂサーバ・ソフトウェア１２０を図に示してはいるが、これには前に述べたように、ファイル・サーバ・ソフトウェア及び／またはビデオ・サーバ・ソフトウェアも含まれることが理解されよう。

クライアント・コンピュータ１０２は、中央処理装置（ＣＰＵ）１２６、サポート回路１２４、及びメモリ１２８を含んでいる。クライアント・コンピュータ１０２は、ブラウザを実行でき、またネットワーク１０４に接続できるどんなコンピュータでもよい。このようなクライアント・コンピュータには、パーソナル・コンピュータ、携帯情報端末（ＰＤＡ）、無線デバイスなどが含まれる。サポート回路１２４は、ＣＰＵ１２６の機能を向上させるために使用される周知の回路である。このような回路は、キャッシュ、電源、クロック回路、入出力インターフェース回路などを含むが、それだけに限定されない。メモリ１２８は、ＲＡＭ、ＲＯＭ、フラッシュ・メモリ、取外し可能ディスク記憶装置などのうちの１つまたは複数を含むことができる。メモリ１２８は、アプリケーション・ソフトウェア１３６やオペレーション・システム・ソフトウェア１３４など様々なソフトウェア・パッケージを記憶することができる。アプリケーション・ソフトウェア１３６には、種々のプログラムが含まれ得、それにはＷｅｂブラウザ・アプリケーション・ソフトウェア１３０が含まれるが、それだけには限定されない。また、アプリケーション・ソフトウェア１３６には、クライアント・ベース・ファイル管理ソフトウェアやビデオ管理ソフトウェアも含まれ得る。

Ｗｅｂブラウザ１３０は、ワールド・ワイド・ウェブあるいは他の通信ネットワークから、ＨＴＭＬその他のＷｅｂページをユーザが検索し表示できるようにする、どんなソフトウェア・アプリケーションでもよい。さらに、Ｗｅｂブラウザ１３０は、Ｎｅｔｓｃａｐｅ ＮａｖｉｇａｔｏｒやＭｉｃｒｏｓｏｆｔ Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒなどいくつかの市販のブラウザの１つとすることができるが、それだけには限定されない。同様に、クライアント・コンピュータ１０２は、サポート回路１２４（すなわち入出力インターフェース回路）を介して表示装置１３２に結合されている。表示装置１３２は、データまたは画像を表示するどんなスクリーン型の表示装置（すなわちＣＲＴ（ブラウン管）、プラズマ・ディスプレイ、液晶ディスプレイ（ＬＣＤ）など）でもよい。

図１に関して説明したような通信システムでは、データ・パケットを送信し受信するためのネットワーク・プロトコルを使用することができる。ネットワーク・プロトコルは通常、階層的に開発されており、各層が通信の異なる面を担当する。一例として、伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）などのプロトコル群は、様々な層における異なるプロトコルを組み合わせたものである。図２Ａに示すように、ＴＣＰ／ＩＰは通常、４階層システム２００と考えられている。

具体的には、データ・リンク層（またはネットワーク・インターフェース層）２０２は通常、ＯＳ１１６内にデバイス・ドライバを含み、またサーバ１０６のサポート回路１２４内に対応するネットワーク・インターフェース・カード（ＮＩＣ）１０５を含む。これらは全体として、通信メディアとの物理的なインターフェースに関する、ハードウェアのすべての詳細を扱う。ネットワーク（またはインターネット）層２０４は、ネットワーク周りでのパケットの移動を扱う。例えばパケットの経路指定がここで行われる。例えば、ＩＰは、ＴＣＰ／ＩＰプロトコル群のネットワーク層を提供する。次に、トランスポート層２０６が、その上位のアプリケーション層２０８のために、２つのホスト間、あるいはホストと１つ（または複数の）クライアント・コンピュータの間のデータの流れをもたらす。

ＴＣＰ／ＩＰプロトコル群では、少なくとも２つの異なるトランスポート・プロトコル、すなわちＴＣＰ及びユーザ・データグラム・プロトコル（ＵＤＰ）が存在する。ＴＣＰは、２つのホスト間、あるいはホストとクライアント・ノード（例えばクライアント・コンピュータ）の間の信頼性のあるデータの流れをもたらす。ＴＣＰは、その下位のネットワーク層２０４のために、アプリケーション層２０８から渡されたデータを適切なサイズの部分またはパケットに分割し、受け取ったパケットの応答を返し、また相手側パケットの応答を返すためのタイムアウトを設定するなどする。この信頼性のあるデータの流れはトランスポート層２０６によってもたらされるので、アプリケーション層２０８は通常、これらの詳細をすべて無視することができる。

一方、ＵＤＰは、それよりはるかに単純なサービスをアプリケーション層２０８に提供する。ＵＤＰは、一方のホストから他のホストへ、あるいはホストからクライアント・ノード／コンピュータへ、データグラムと呼ばれるデータ・パケットを単に送信するが、データグラムが相手側に届く保証はない。信頼性が所望される場合は、アプリケーション層２０８がそれを付加しなければならない。

最後に、アプリケーション層２０８は、特定のアプリケーションの詳細を扱う。ほとんどすべての実装形態で提供されている共通のＴＣＰ／ＩＰアプリケーションが数多く存在する。例えば、ファイル転送プロトコル（ＦＴＰ）及びハイパーテキスト転送プロトコル（ＨＴＴＰ）がある。アプリケーション層２０８は、ネットワークを横切るデータの移動には関係しない。下位の３つの層は通常、アプリケーション層２０８に関する情報を受け取らず、通信のすべての詳細を扱う。全般的に、アプリケーション層２０８は通常、ユーザ・プロセスであり、一方、下位の３つの層は通常、ＯＳ１１６内に実装される。

従って、ＴＣＰ／ＩＰプロトコル・スタックは、上述したように、様々な層を含むように設計されている。既知のシステムは、各層内ですべての情報を明確に分離しておき、その層に関連しない面へのアクセスは提供しない。例えば、アプリケーション層とＩＰ層は、パケットの断片化に関する情報を共用しない。ある種のデータをどのようにパケット化すべきかに関する情報は、ＩＰ層に残されている。アプリケーション層上では、その知識は知られないはずである。その結果、例えば、クライアント・ノードのデータ・ファイル要求を満たす必要があるたびに、ホスト・サーバ１０６が、取り出されたデータ・ファイルからすべてのバイトをコピーし、ＨＴＴＰ応答パケットを作成する必要がある。これには、かなり長い時間がかかる。

本発明の様々の側面の内でもとりわけ、下位層の情報を利用し、それを転送することにより、同等以下のコンピュータ・ハードウェアを使用しても、比較的迅速な応答が可能になることが、本発明によって明らかになった。このような情報は、ＴＣＰ／ΙΡプロトコル・スタックの上位層に送られる。従って、本発明の諸側面によれば、ネットワーク層２０４はデータをどのようにパケット化するかに関する情報を有するので、この層から知識が入手される。この情報は、アプリケーション層２０８に渡され、事前に適用され、その後にこうした情報が応答として送信される。従って応答データは、事前パケット化レベルでキャッシュされる。

このパケットは、ソケット・インターフェースを使用してクライアント・ノードに送られる。ソケット・インターフェースは、クライアントとネットワーク・サーバの間の接続についての抽象概念である。ソケットの内部では、サポートできる最大パケット・サイズに関してネットワークが制限を有することがあるので、データは適切なサイズに断片化される。このサイズは、ネットワークのタイプごとに異なる。例えば、イーサネットなどのローカル・エリア・ネットワーク（ＬＡＮ）では、ペイロード・パケットあたり１５００バイトしか許容されない。

図１のデータ通信ネットワーク１００を利用できる１つのＷｅｂサーバ実施形態は、おそらくＷｅｂブラウザ・ソフトウェア１３０を使用するブラウザを介して、データ・ファイルを求めるクライアント・ノード（コンピュータ）１０２要求に応答して、図２Ｂに示したようなＨＴＴＰ応答パケット２５０を生成できるサーバ１０６を含んでいる。この具体的な例のパケット２５０は、代替案も企図されているが、イーサネット・ヘッダ２５２、ＩＰヘッダ２５４、ＴＣＰヘッダ２５６、ＨＴＴＰヘッダ２５８、及びＨＴＴＰペイロードまたはＨＴＴＰ応答本体２６０を含んでいる。

例えば、サンプルＨＴＴＰ応答パケット２５０は約１５００バイトのＩＰパケットである。このパケットは、上述のヘッダとＨＴＴＰ応答本体２６０を含んでいる。ＩＰヘッダ２５４は、約２０バイトを含む。ＴＣＰヘッダ２５６は、約２０バイトを含む。残りの部分は、約１４６０バイトである。ＨＴＴＰヘッダは、テキスト・ベースなので、より大きいサイズである。最初のパケットだけがＨＴＴＰヘッダを含むことになる。ＨＴＴＰパケットは、複数のＩＰパケットに分割される。ＨＴＴＰヘッダが１５００バイトより大きい場合は、ヘッダをいくつかの部分に分けて複数のパケットに格納することができる。残りのＨＴＴＰ本体２６０は、一連のＩＰパケットに分けられ、１５００バイトからいくつかのヘッダ・バイト数を引いた断片に分割される。

動作においては、本発明の一態様によれば、図３の流れ図に示したように、図１の通信システム１００に関して、クライアント要求セッション３００が提供され、これはステップ３０２で開始する。ステップ３０４で、サーバ１０６は、例えばクライアント・ノード１０２から要求を受け取る。ステップ３０６で、サーバ１０６は、この要求を構文解析してどのデータ・ファイルが要求されているかを判定することによって、この要求を処理する。ステップ３０８で、応答データ・ファイルがメモリ１１４から取り出される。

ステップ３１０で、このデータ・ファイルがセグメントまたは事前パケットに分割される。ステップ３１２で、各セグメントにヘッダ情報が付加される。本発明の諸態様によれば、ステップ３１４で、セグメントごとのヘッダ情報が、ＴＣＰ／ＩＰスタック２００の下位レベル、この例ではネットワーク層またはＩＰ層２０４に送られる。

ある種の情報は、どのデータ要求でも同じであり、特に静的コンテンツがそうであり、従って、あるパケット形式にとどまることができ、バイト・レベルでキャッシュし直す必要がない。従って、ディスク上のＨＴＭＬページなどの静的コンテンツの場合、おそらく以下のフィールドを除き、応答内容は毎回ほぼ同じになる。
イーサネット宛先ＭＡＣアドレス（ただし、固定ＬＡＮゲートウェイの場合は不変になる）
ＩＰ宛先アドレス
ＴＣＰ宛先ポート
ＴＣＰシーケンス番号
ＴＣＰチェックサム（含まれる場合）：毎回更新する必要がある
例えば、データ要求の特定のＴＣＰヘッダに関連する追加の動的フィールドがあり得るが、これらは応答のコピーを、ヘッダの組合せごとに１つずつ、Ｎ個キャッシュすることによって対処することができる。例えば、あるクライアントが、ＴＣＰタイムスタンプ・ヘッダを使用して、往復伝搬時間を推定することがある。サーバは、そのクライアントについてはこのようなヘッダを含まなければならないが、それ以外のクライアントについてはその必要はない。従ってサーバは、このヘッダをもつ応答と、もたない応答の（少なくとも）２つのバージョンのパケット化された応答をキャッシュすることになる。タイムスタンプ・フィールドは、更新する必要のある動的フィールドである。一般にこのことは、応答ヘッダの可能なあらゆる組合せに当てはまる。このようなＴＣＰヘッダはしばしば任意であり、それを使用するか否かは、クライアントがそれをサポートするかどうかによる。

一例では、各クライアントは、ローカルの企業イーサネット・ネットワーク内で、（データ・リンク層２０２からの）異なるＭＡＣアドレスを有することになる。しかし、異なるリモート・ネットワークが存在する場合は、イーサネット・スイッチを通過する接続は、そのスイッチのＭＡＣアドレスである。従って、リモート・ネットワークの場合、サーバ１０６から見ると、すべてのパケットが同じイーサネットＭＡＣアドレスからやってきており、そのアドレスは固定あるいは不変である。この知識を使用して、下位のデータ・リンク層２０２からこれはイーサネット・ネットワークであるとシステムが認識した場合、最終的にどの位のデータを１つのパケットに入れることができるかがわかる。これは、データ・ファイルを分割するのに必要な情報である。

従って、ステップ３１６で、上述のものを含む動的なヘッダ・フィールドは、次回の要求に備えて、事前パケット化の形でキャッシュすることができるように、所定の値に設定される。任意選択で、この特定の例において、ＴＣＰトランスポート・プロトコルを使用した場合、ＴＣＰチェックサム値がＴＣＰヘッダに含まれる。ステップ３１８で、ＴＣＰチェックサムの有無がチェックされ、システムがＴＣＰ／ＩＰプロトコルを使用しているかどうかが示される。応答がＹｅｓの場合、ステップ３２０で、ＴＣＰチェックサム値が計算される。次いでこの方法は、ステップ３２２に進む。応答がＮｏの場合は、トランスポート層２０６がＵＤＰプロトコルを使用している可能性が高いことを示しており、ステップ３２２に直接進む。ステップ３２２で、その結果得られる、各ヘッダを含む応答パケット２５０内の静的フィールドと動的フィールドがキャッシュされる。次いでステップ３２４で、応答パケットが、データ・ファイルを要求したクライアント・ノード１０２に送信される。

ステップ３２６では、同じまたは同様のデータを求める、同じまたは異なるクライアント・ノードからの第２の要求が行われる。情報及びヘッダ・フィールドの一部はキャッシュされているので、そのデータをバイトごとに再度取り出す必要はない。そうではなく、純粋に新しい情報だけを更新すればよい。具体的には、ステップ３２８で、キャッシュ・メモリのヘッダ動的フィールドが、ヘッダ・フィールド情報の変更があった場合にそれを示す新規の所定の値に更新される。さらに、ステップ３３０で、ＴＣＰチェックサムが含まれるかどうかが問合せされる。すなわち、ステップ３２０が既に実行されていて、ＴＣＰチェックサム値が既にキャッシュ済みのパケットに含まれていた場合、ステップ３３２が実行されて、ＴＣＰチェックサム値が増分的に調整される。「増分的に」とは、パケットのすべてのバイトを足し合わせ、チェックサムを含めすべてのバイトの合計が、０か、１か、あるいはそれ以外の何らかの所定の固定値であるような、２の補数の合計を計算することを意味する。ステップ３３４で、データ・ファイルを要求している第２のクライアント・ノードに新規の応答パケットが送られる。ステップ３３６で、この方法は終了する。この処理をステップ３３６で終了せずに、継続することもできることが理解されよう。

通常のネットワークには、サポートできる最大パケット・サイズに関する制限がある。ネットワークが異なれば、制限も異なる。例えば、無線ネットワークには、約２３００バイトの制限がある。ＡＴＭネットワークは、６４バイトのセルを有する。ＩＰ層上では、標準の故に、ＩＰパケットに対して６５５３６バイトの最大サイズが存在する。しかし、下位層部分が既に非常に小さいので、ＩＰパケットは通常、ネットワークがサポートできる最大パケット・サイズに収まる。

本発明の諸態様をＷｅｂサーバ及びＨＴＭＬページに関して説明してきたが、本発明をファイル共用に使用することもできる。また、本発明は、ソフトウェア更新に使用することもでき、その場合、事前パケット化形式のセントラル・サーバがソフトウェア更新を記憶し、所与の企業のすべてのクライアントがそれをダウンロードすることができる。様々なレベルでキャッシュすることができる。ＨＴＴＰヘッダは各応答でほぼ同じなので、一部のＷｅｂサーバは、それをキャッシュする。従って、それを毎回更新する代わりに、１回生成し、単に保持する。ＨＴＴＰヘッダを再度生成する代わりに、その結果をコピーするだけでよい。

これらの処理は順次的であるので事前に行うことができ、サーバは、パケットを送信するときに、変更された事項を追加するだけでよい。従って、ＴＣＰチェックサム値に関して、本発明の諸態様による方法は、すべてのフィールドがゼロである場合にチェックサム値を計算することを含むことになり、その後、パケットをクライアントに送信するとき、それらのフィールドが記入され、変更されたビットだけが追加される。

例えば、１５００バイトのパケットを有する場合、１５００回の加算（あるいは、３２ビット・コンピュータで典型的なように４バイト加算を３２５回）を行ってチェックサム値の計算を行う必要が生じる。本発明の諸態様によれば、サーバは、この１５００回の加算のうちの１４９０回をあらかじめ行い、それを合計し、新しいフィールドを生成し、それが特にクライアント向けに設定される。例えば、ＩＰアドレス、ＴＣＰ宛先ポート、ＴＣＰシーケンス番号などである。これらは、クライアントに特有の数個のフィールドであり、クライアントごとに異なる。従って、チェックサムを更新する必要はあるが、１５００回のすべてではなく、いくつかの追加の加算についてだけ更新すればよい。

ＵＤＰでは、チェックサムはＩＰ ｖ４の場合、任意選択である。これは無効にすることができる。チェックサムが設定されていない場合、チェックサム検査はスキップされる。どんな送信エラーでも他の層（例えば、ネットワーク層またはアプリケーション層）でしか検出することができない。

従って、上記で詳細に説明したように、本発明の諸態様による方法及び装置では、クライアント・ノード要求の応答時間を短縮しようとして、事前パケット化形式でデータをキャッシュするキャッシング機能を使用した。システムは、ＩＰ層から情報を取得する。こうしてシステムは、情報がどのようにしてパケット化されるかを知る。従って、システムは、情報をアプリケーション層に渡し、それを事前に適用することができる。従って、本発明の様々な実施形態では、異なるいくつかのプロトコル層を参照し、その下位の層の知識に基づいて最適化を行う。いくつかの利点を挙げてみると、このようにすれば、ＴＣＰチェックサム計算のオーバヘッドが回避され、コンテンツ圧縮の（がある場合はその）オーバヘッドが回避され、ディスク・ファイルの読取りが回避され、またバッファ割当て及びディスク・バッファからネットワーク・インターフェースへのメモリのコピーが回避される。

本発明の諸態様によるすべてまたは一部の方法及び装置は、二次記憶装置（例えばハード・ディスク、フロッピー・ディスク、ＣＤ−ＲＯＭ、ＤＶＤなど）や、インターネットまたはその他の通信媒体から受信した搬送波や、その他の形のＲＯＭまたはＲＡＭなどのコンピュータ可読媒体上に格納し、そこから読み取ることができることが、当業者には理解されよう。最後に、データ処理システムの特定の構成要素について説明してきたが、例示的な実施形態と共に使用するのに適したデータ処理システムは、複数のプロセッサや様々な入出力装置など、追加のあるいは異なる構成要素を含むことができることが、当業者には理解されよう。一般的に、本発明の諸態様のシステム及び方法は、様々な有形及び無形の媒体、様々なコンピュータ、データ処理システムなどで実施することができる。

以上論じてきたように、本発明の一態様の利点は、オーバヘッドの削減によって明らかになる。すなわち、パケットのすべてのバイトを毎回再パケット化する必要がない。既知の処理ですべてのバイトを毎回コピーするには、時間を要する。あらかじめパケット化を実行し、キャッシングを行うことができ、それによって応答時間が短縮され、ネットワーク・サーバ１０６上の負荷が低減される。その結果、同じハードウェアが、同じ時間内により多くのクライアント・ノード（またはクライアント・コンピュータ）を処理することができる。あるいは、同じ数のクライアント・ノードを処理するのに、より少ないハードウェアで済む。

本発明の諸態様をＷｅｂサーバに関して説明してきたが、上述のような他の種類のサーバ（すなわちファイル・サーバ及びビデオ・サーバ）も企図されており、本発明の範囲に含まれることが当業者には理解されるはずである。

例えば、ビデオ・サーバは、ＵＤＰパケットを使用することができる。この場合、関与するフロー制御もデータ・パケットの動的サイズ設定もない。固定サイズのパケットだけが存在する。従って、データ・ブロック単位でビデオの事前符号化がすでにされている。例えば、同じビデオ・ファイルに、異なるクライアント向けの、品質またはＣＯＤＥＣの異なるバージョンがいくつも存在してもよい。しかし、このデータはやはり、取り出し、ＵＤＰパケットに入れ、ネットワーク上に送出する必要がある。従って、本発明の他の諸態様によれば、ビデオ・ファイルを符号化し、それをビデオ・サーバ上に事前パケット化形式で記憶する手段が提供される。各パケットは、ネットワーク・インターフェース上に容易に送出することができる。

本発明の諸態様の教示を組み込んだ様々な実施形態を本明細書で詳細に示し説明してきたが、当業者であれば、これらの教示をやはり組み込んだその他多くの様々な実施形態を容易に考案することができよう。

Claims (10)

1. 第１のクライアント・ノード要求に応答してサーバ応答データをキャッシュする方法であって、
   サーバ（１０６）から要求されたデータを取り出すステップ（３０８）と、
   該取り出されたデータを、該要求されたデータの静的コンテンツを格納するための複数の静的フィールド及び該要求されたデータの動的コンテンツを格納するための複数の動的フィールドを含む複数の応答パケットに分割するステップ（３１０）とを含み、該動的コンテンツは、該第１のクライアント・ノード要求に特有のデータであり、
   該複数の応答パケットの該複数の動的フィールドをそれぞれの所定の値に設定することによって、該要求されたデータの少なくとも一部に対する後続の要求の間に使用するように該動的フィールドを適応させるステップ（３１６）と、
   該第１のクライアント・ノードによって要求された該データの少なくとも一部に対する後続の要求の間に使用するように、該複数の応答パケットの該複数の適応させられた動的フィールド及び該複数の静的フィールドをメモリ・バッファ（１１５）にキャッシュするステップ（３２２）とを含むサーバ応答データをキャッシュする方法。
2. 請求項１に記載の方法において、
   該少なくとも１つの応答パケットのフィールド中でＴＣＰチェックサム値を設定するステップ（３１８、３２０）をさらに含む方法。
3. 請求項２に記載の方法において、
   イーサネット宛先ＭＡＣアドレス、ＩＰ宛先アドレス、ＴＣＰ宛先ポート、ＴＣＰシーケンス番号、クライアント・ノード要求からのＴＣＰヘッダ、及びＴＣＰチェックサムを含む群から該動的フィールドが選択される方法。
4. 請求項２に記載の方法において、
   第２のクライアント・ノード要求に応答して、
   少なくとも１つの該キャッシュされた動的フィールドを該第２のクライアント・ノードに特有の動的コンテンツを使用して更新するステップ（３２８）と、
   該ＴＣＰチェックサム値を増分的に調整するステップ（３２２）と、
   該更新された動的フィールドと該キャッシュされた静的フィールドと増分的に調整されたＴＣＰチェックサムとを含む少なくとも１つの応答パケットを、該第２のクライアント・ノードに提供するステップ（３３４）とをさらに含むの方法。
5. 請求項１に記載の方法において、
   該動的フィールドが該ＴＣＰヘッダを含む場合に、該少なくとも１つの応答パケットのＮ個のコピーをキャッシュするステップをさらに含み、Ｎは特定のＴＣＰヘッダの数と等しい整数である方法。
6. サーバ応答データをキャッシュするための装置であって、
   取り出されたデータを、要求されたデータの静的コンテンツを格納するための複数の静的フィールド及び該要求されたデータの動的コンテンツを格納するための複数の動的フィールドを含む複数の応答パケットに分割し、該動的コンテンツは、第１のクライアント・ノード要求に特有の情報を含み、少なくとも１つの応答パケットの該複数の動的フィールドを所定の値に設定するプロセッサ（１１０）と、後続のクライアント要求に応答して少なくとも１つのクライアント・ノードに送信する事前パケット化データを記憶するためのメモリ・バッファ（１１５）とを含んでおり、該事前パケット化データが該複数の応答パケットからの該複数の静的フィールド、及び該複数の動的フィールドを含むサーバと、
   該サーバ（１０６）を通信ネットワーク（１０４）に接続し、該サーバ（１０６）の該メモリ・バッファ（１１５）からの該複数の応答パケットを、該少なくとも１つのクライアント・ノード（１０２）に送信するためのネットワーク・インターフェース・カード（１０５）とを含む、サーバ応答データをキャッシュするための装置。
7. コンピュータ実行可能命令をその上に有するコンピュータ可読媒体であって、該コンピュータ実行可能命令は、コンピュータによって実行されたとき、第１のクライアント・ノード要求に応答して、サーバ（１０６）上で少なくとも１つの応答パケットをキャッシュする方法を該コンピュータに実施させ、該方法が、
   該少なくとも１つの応答パケットに含めるために、該サーバ（１０６）のメモリ・データベース（１１４）からデータを取り出すステップ（３０８）であって、該少なくとも１つの応答パケットは、該応答パケットの複数の静的フィールド内の該要求されたデータの静的コンテンツ及び該応答パケットの複数の動的フィールド内の該要求されたデータの動的コンテンツを含み、該動的コンテンツは、該第１のクライアント・ノード要求に特有のデータであり、
   該少なくとも１つの応答パケットの該複数の動的フィールドをそれぞれの所定のに設定することによって、該要求されたデータの少なくとも一部に対する後続の要求の間に使用するように該少なくとも１つの応答パケットの該複数の動的フィールドを適応させるステップ（３１６）と、
   該第１のクライアント・ノードによって要求されたデータの少なくとも一部に対する後続の要求の間に使用するように、該得られた少なくとも１つの応答パケットの該第１のクライアント・ノードによって要求されたデータを含む静的フィールド及び該適応された複数の動的フィールドを該サーバ（１０６）のメモリ・バッファ（１１５）にキャッシュするステップ（３２２）とを含むコンピュータ可読媒体。
8. 請求項７に記載のコンピュータ可読媒体において、
   該少なくとも１つの応答パケットのフィールド内にＴＣＰチェックサム値を設定するステップ（３１８、３２０）をさらに含むコンピュータ可読媒体。
9. 請求項７に記載のコンピュータ可読媒体において、
   イーサネット宛先ＭＡＣアドレス、ＩＰ宛先アドレス、ＴＣＰ宛先ポート、ＴＣＰシーケンス番号、クライアント要求からのＴＣＰヘッダ、及びＴＣＰチェックサムを含む群から該動的フィールドが選択されるコンピュータ可読媒体。
10. 請求項８に記載のコンピュータ可読媒体において、
    第２のクライアント・ノード要求に応答して、該方法が、
    該動的フィールドの該所定の値を該第２のクライアント・ノード要求に特有なデータを含む動的コンテンツを使用して更新するステップ（３２８）と、
    該ＴＣＰチェックサム値を増分的に調整するステップ（３３２）と、
    該更新された動的フィールドと該キャッシュされた静的フィールドと増分的に調整されたＴＣＰチェックサムとを含む少なくとも１つの応答パケットを、該第２のクライアント・ノードに提供するステップ（３３４）とをさらに含むコンピュータ可読媒体。

Images