JP5044607B2 - ウェブ・コンテンツの高性能配信の方法 - Google Patents

Description

関連出願の相互参照
本願は、２０００年２月７日出願の米国特許仮出願第６０／１８０，８１６号「Ｍｅｔｈｏｄ ｆｏｒ Ｉｍｐｒｏｖｉｎｇ Ｐｅｒｆｏｒｍａｎｃｅ ｏｆ Ｗｅｂ Ｃｏｎｔｅｎｔ Ｄｅｌｉｖｅｒｙ」、および２０００年３月１０日出願の米国特許仮特許出願第６０／１８８，６０１号「Ｍｅｔｈｏｄ ｆｏｒ Ｉｍｐｒｏｖｉｎｇ Ｐｅｒｆｏｒｍａｎｃｅ ｏｆ Ｗｅｂ Ｃｏｎｔｅｎｔ Ｄｅｌｉｖｅｒｙ」の特典を主張し、参照によりその全体を本明細書に組み込む。

発明の分野
本発明は、少なくとも一部は、コスト、帯域幅使用率、および通信待ち時間などの性能基準が考慮の対象であるインターネットまたは任意の他のネットワーク層を介して通信が実施される、ブラウザなどのウェブ・クライアントとウェブ・サーバとの間の通信に関する。

発明の背景
現在、インターネット通信の性能を高めることは、技術上および商業上の主要な課題である。インターネット・ネットワークのインフラストラクチャを改善するための投資は、２００３年までには１兆３千億ドル産業に上ると推定される（情報源：２０００年１月３１日のＮｏｒｔｅｌ Ｉｎｄｕｓｔｒｉｅｓの新聞発表）。多くのウェブ・ユーザは、ウェブ・ページのダウンロードの遅延を８秒以上は我慢できなくなり、低速のダウンロードによって危険に曝されている電子商取引の現在の金額は年間４３億５千万ドルであると推定されている（情報源：Ｚｏｎａ Ｒｅｓｅａｒｃｈ ｒｅｐｏｒｔ「Ｔｈｅ ｎｅｅｄ ｆｏｒ ｓｐｅｅｄ」、ｈｔｔｐ：／／ｗｗｗ．ｚｏｎａｒｅｓｅａｒｃｈ．ｃｏｍ／ｉｎｆｏ／ｐｒｅｓｓ／９９-ｊｕｎ３０．ｈｔｍで要約が入手可能）。このような風潮において、ウェブ・パフォーマンスを改善するための方法が緊急に求められており、単純な技術あるいは自明の技術で検討されなかったものは１つもない。

標準インターネット・プロトコル：ＨＴＴＰおよびＴＣＰ
インターネット・リンクで使用される２つの標準プロトコルであるＨＴＴＰおよびＴＣＰは、インターネット通信の速度に莫大な制約を課している。ハイパーテキスト転送プロトコル（ＨＴＴＰ）は、クライアントがウェブ・サーバに対してウェブ・コンテンツを要求する際に使用されるアプリケーション層のネットワーク・プロトコルであり、そのような要求に対して応答するウェブ・サーバによって使用されるものである。現代のネットワーク通信は階層化されている。すなわち、低レベルのプロトコル上に高性能プロトコルが構築されている（その低レベルのプロトコルはさらに別のプロトコル上に構築されている）。ＨＴＴＰは、コンテンツを要求し、コンテンツに応答し、コンテンツを送信する形式をネゴシエートするなどのコマンドを含む高性能プロトコルである。これは、一般に、低レベル・プロトコルである伝送制御プロトコル（ＴＣＰ）によって搬送される。
ＴＣＰは、インターネットの２地点間の確実な終端間接続を可能にするが、これら２地点間で送信されるコンテンツを決して翻訳することはなく、単にバイトのストリームを搬送するだけである。ＴＣＰは、一般に、インターネット・プロトコル（ＩＰ）によって搬送されるが、これは確実な配信を保証しないパケット指向のプロトコルである。

ＨＴＴＰおよびＴＣＰが、インターネット通信のための最適なプロトコルからは程遠いものであることはよく知られている。ＴＣＰは、ＨＴＴＰが発明される遥か以前に開発され、配置されたものであり、大量の双方向データ転送用に設計されたものである。ＨＴＴＰは、短い要求メッセージと、適度の長さの応答トランザクションと、非常にバースト性の高いトラフィックによって特徴付けられる。ＴＣＰがＨＴＴＰを搬送するには最適のプロトコルではないということは、広範囲に文書化されている。Ｈｅｉｄｅｍａｎｎ、Ｏｂｒａｃｚｋａ、およびＴｏｕｃｈ著、ＩＥＥＥ／ＡＣＭ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ Ｎｅｔｗｏｒｋｉｎｇ誌、１９９７年１０月、第５刊、第５号掲載の論文「Ｍｏｄｅｌｉｎｇ ｔｈｅ Ｐｅｒｆｏｒｍａｎｃｅ ｏｆ ＨＴＴＰ Ｏｖｅｒ Ｓｅｖｅｒａｌ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌｓ」は、これらの問題に取り組んだ研究を表している。著者らは、例えば次のように主張している。

「ＨＴＴＰのニーズとＴＣＰが提供するサービスとの間の不整合は、大部分のウェブ・ユーザに対して待ち時間の増大をもたらす原因となっている。基本的に、ＴＣＰは大規模な大量のデータ転送に対して最適化されているが、ＨＴＴＰは軽量の、要求／応答プロトコルを必要とする場合がよくある。」
ここで言及されている不整合は、「３方向ハンドシェーク」「スロースタート輻輳回避」および「ＴＩＭＥ＿ＷＡＩＴティアダウン遅延」として周知のものを含めて、ＴＣＰのいくつかの技術的側面に関するものである。先のＨｅｉｄｅｍａｎｎ、ＯｂｒａｃｚｋａおよびＴｏｕｃｈの論文は、このような改善されたプロトコルのいくつか、トランザクションＴＣＰ（Ｔ／ＴＣＰ）および非同期高信頼性配信プロトコル（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｒｅｌｉａｂｌｅ Ｄｅｌｉｖｅｒｙ Ｐｒｏｔｏｃｏｌ）（ＡＲＤＰ）などを議論している。ＨＴＴＰに関するＴＣＰの他の欠点には、使用されているフロー制御アルゴリズムが含まれるが、これは、ネットワーク上でノイズまたはエラーが発生する際の不要なトラフィックおよび遅延の原因となるものである。

ＨＴＴＰ自体は、進化し、改善されるプロトコルであるが、ＴＣＰとの相互関係を別にしても性能上の欠陥が認められている。Ｖ．Ｎ．Ｐａｄｍａｎａｂｈａｎによる博士論文「Ａｄｄｒｅｓｓｉｎｇ ｔｈｅ Ｃｈａｌｌｅｎｇｅｓ ｏｆ Ｗｅｂ Ｄａｔａ Ｔｒａｎｓｐｏｒｔ」（米国バークレイのカリフォルニア大学、コンピュータ・サイエンス科、１９９８年９月にＴｅｃｈｎｉｃａｌ Ｒｅｐｏｒｔ ＵＣＢ／ＣＳＤ-９８-１０１６としても出版済み）は、このうちの何点かについて議論している。一例として、ＨＴＴＰバージョン１．０（未だに幅広く使用されている）が、所与の接続を介して一度に１つの要求を送信し、継続する前に応答の完全な到着を待機し、しかも重要な性能を犠牲にするようにクライアントにいかにして強いるか（この博士論文で証明済み）を説明している。

問題は、ＨＴＴＰおよびＴＣＰよりも高性能のインターネット通信用のプロトコルが存在しない、またはそれが使用可能でないということではない。問題なのは、ＨＴＴＰおよびＴＣＰが標準であり、広範に認められ、広範に配置されているということである。事実、インターネットなどの共用ネットワークを介した通信がすべてのユーザに対して同じプロトコルを使用することを要求するので、これはやむを得ないことである。したがって、既存のプロトコルに関する問題が注目され、改善されたプロトコルが開発されたとしても、そのような改善が広範囲に配置されるまでには長期を要することがしばしばである。遅延は、改善が公衆インターネット・インフラストラクチャに到達するまで特に長期となる。一部には、この遅延は、単に大量のソフトウェアの更新が必要になると常にコストが嵩むという理由からである。誰もが一方的に更新することができない、すなわち、ネットワーク対話の両端が同一プロトコルの同一バージョンを使用する必要があるので、プロトコルを更新する場合、コストと遅延はさらに嵩む。インターネットの場合、いくつかのプロトコルの変更は、共同体規模で揃えた更新を必要とする。このような遅延の一例として、Ｐａｄｍａｎａｂｈａｎの論文から上記で引用したＨＴＴＰバージョン１．０に関する問題は、「パイプライン処理」として知られている機能が定義された次のバージョンのプロトコルで訂正されたものと想定する。この改善が最初に提案されてから数年を経てさえ、これを採用するウェブ・ブラウザはほとんどない。同様に、ＴＣＰの交換を求めるすべての提案は既に低迷しており、今のところ、すべての主要なウェブ・ブラウザおよびウェブ・サーバはＨＴＴＰ ｏｖｅｒ ＴＣＰだけをサポートしている。

標準プロトコルを変更せずにインターネット性能を改善するための１つの従来技術による手法は、ウェブ・キャッシングである。類似の手法はコンテンツ配信（ＣＤ）である。コンテンツ配信（ＣＤ）ネットワークは、インターネット・サービス・プロバイダ（ＩＳＰ）などの選択された位置でインターネットなどのより大規模なネットワークに含まれる専用ノードまたは装置の集合である。これらのノードは、コンテンツ・ディストリビュータの顧客に代わって、特定のウェブ・コンテンツを記憶している。このような記憶装置はキャッシュ、ミラー、またはリピータと呼ばれることがある。

コンテンツ配信サービスには、リダイレクション・サービスまたはインターセプション・サービスが含まれる。ウェブ・ユーザ（ブラウザなどのクライアントを使用する）がサイトに対してコンテンツを要求し、そのコンテンツが１つまたは複数のＣＤノードにキャッシュされていることが周知であるかまたは推測される場合、その要求は、ユーザに「近い」いくつかのＣＤノードに向けられる（またはリダイレクトされることになる）。近いという概念は通信性能の尺度であり、具体的には、帯域幅容量、帯域幅コスト、待ち時間、セキュリティ、管理の範囲、管理上の利便性、および様々なネットワーク経路における現行の輻輳などの尺度を使用することができる。近いＣＤノードを選択し、次いでその選択されたノードに要求を向けるための技術は様々あるが、この分野はまだ新しく、今も尚かなりの革新が進められている。

上記で議論したリダイレクションに対する１つの代替形態はインターセプションである。このインターセプションでは、ノードは、クライアントからすべてのウェブ・トラフィックが認識できるように、クライアントからのネットワーク経路に配置されている。ウェブ・プロキシまたはルータなどの他の専用デバイスは、例えばクライアントのＩＳＰに配置されており、この目的で使用することができる。この場合、ノードはすべてのトラフィックをインターセプトする。キャッシュしている（または隣接のキャッシュから簡単にフェッチすることができる）コンテンツに対する要求を認識すると、そのノードは即座にそのコンテンツを返すことができるが、そうでない場合、ノードはそのトラフィックをその宛先にそのままリレーする。プロキシの使用状況は、クライアントの制御下であっても（例えば、クライアントがプロキシを使用するように構成されなければならない場合、）、またはそのような構成をクライアントが必要としない場合は「透過的」であってもよい。

コンテンツ配信の利点は、近いＣＤノードからユーザにトラフィックを提供することが可能であり、したがって、より高速に、より安価に、より少ない帯域幅で、また、恐らくはより確実にそのユーザに応答を返すことが可能であることである。エンド・ユーザにコンテンツが提供される速度を１０倍まで改善したという報告を参照することが一般的である。

コンテンツ配信の主な欠点は、すべてのコンテンツが有効にキャッシュ可能であるわけではないということである。動的に生成されたコンテンツに対して、これは特に不適切だが、急速に変化するコンテンツおよび一部のめったにアクセスされないコンテンツに対しても無効である。ＣＤノードは、通常、イメージ、ビデオ・ファイル、サウンド・ファイル、静的テキスト・ページ、およびユーザごとにあまり変化のない他のコンテンツを記憶する。そのようなコンテンツは、要求されることを予想して（または恐らくは、既に１回は要求がある場合、さらなる要求を予想して）、ＣＤサーバに保存される。しかし、インターネット上のコンテンツの多くは顧客の要求に応じて進行中に生成される。例えば、共通ゲートウェイ・インターフェース（すなわち、「ｃｇｉ-ｂｉｎ」プログラム）を使用してサーバ・プログラムによって生成される。このようなプログラムの出力が２度と同じものではないので、または少なくとも人により、また、機会により異なる可能性があるので、このようなコンテンツを事前に準備しておくことは一般に現実的ではない。結局のところ、何億ものウェブ・ユーザが存在するので、このように多くのカスタマイズされたページを事前に生成して記憶しておくことは不可能である。ウェブ・コンテンツがユーザごとによりパーソナルで、よりカスタマイズされたものなので、このようなページの重要性はさらに高まる。ＣＤネットワークはこのようなページを予想することはできず、また、一般に、そのページが提供される速度を高めることもできない。

コンテンツ配信の第２の欠点の生じる原因は、所謂「静的な」コンテンツ、例えばイメージや固定したテキストが時折変更される場合があることである。キャッシング・ノードまたはコンテンツ配信ノードが「陳腐な」コンテンツ、すなわち起点サーバ上の確定的なコピーとは最早完全には一致しないコンテンツを供給しないように保証することが重要である。コンテンツが新鮮であることを保証するために、または陳腐なコンテンツを配信する危険性を低めるために様々な方式が使用される。成熟した分野であるキャッシング技術は、このような問題に対処する。しかし、問題の性質上、この問題には完璧な解決策は存在しない。この問題を説明するには、ウェブ・プロトコルの最新版であるハイパーテキスト転送プロトコル、バージョン１．１が、以下のように動作するキャッシングおよびコンテンツ配信へのサポートを含むと仮定する。キャッシュを有するノードは、キャッシュが保存しているウェブ・オブジェクトは実際にまだ最新のものであるかどうかを照会している起点サーバに対して短いメッセージを送信することができる。最新のものである場合、短い肯定応答がキャッシュに戻される。キャッシュ・ノードまたはＣＤノードが、クライアントにコンテンツを配信する前に常にこのような照会を行う場合、陳腐なコンテンツを配信する機会はなくなる。しかし、メッセージが起点サーバに送信され、応答が受信される際には、遅延、しかも大量である場合のある遅延がある。この方式は、ネットワークを介して送信されるトラフィック量（帯域幅消費）を低減することができるが、クライアントがコンテンツを参照するまでの遅延（待ち時間）は必ずしも低減しない。このような犠牲はどのようなキャッシングまたはコンテンツ配信技術にも、本来あるものである。

キャッシングおよびコンテンツ配信技術の第３の欠点は、クライアントの要求に備えてキャッシュがウェブ・コンテンツのコピーを保存するので、大量のコンピュータ資源が必要となることである。キャッシュは、陳腐化する前に、実際にはクライアントが要求することがなく、メモリやディスク空間等の高価な資源を消費する多くのオブジェクトを保存する場合がある。典型的なコンテンツ配信ネットワークが多数のキャッシング・ノードを有することによって、この問題はさらに深刻化する。多数のキャッシング・ノードのネットワーク全体に亘って、キャッシングされたコンテンツを慎重に配信するための高機能アルゴリズムを使用するなど、何らかの形でこの問題を緩和する多くの技術がある。しかし、大量な資源の要求は、その大部分がこの技術に元来備わっているものであり、これはこのような技術によっても低減することができるだけであって、解消することはできない。

「キャッシング」（または「プロキシ・キャッシング」）という用語は、コンテンツ配信に関係する技術に関して使用されることがよくある。これらには僅かな技術的な違いしかない。リダイレクション技術よりもインターセプション技術の方が多く使用される場合に「キャッシング」という用語はより多く聞かれる。
第２に、ノードがコンテンツの製作者の代理としてではなく、クライアントの代理として操作される場合、そのノードはキャッシュと呼ばれることが多い。関係する技術は、キャッシュ・ノードがクライアントの近くではなく、サーバの近くに配置されている、サーバ・サイド・キャッシング（「逆プロキシング」としても知られている）である。この技術は、従来のキャッシングまたはコンテンツ配信と比較して性能利得が少なくなる場合があるが、このようなノードは１つで十分なので、より安価な資源コストで配置されることがしばしばである。

キャッシングの全ての形式は、上記のコンテンツ配信の最初の２つの欠点を共有するが、最も重大なのは、動的に生成されたコンテンツを取り扱うことが不可能であることである。

したがって、インターネット通信の性能、具体的にはウェブ・クライアントとウェブ・サーバの間の通信の性能を向上させる手法が当技術分野には求められている。これは、例えば多量なコンピュータ資源を必要とせず、既存の標準プロトコルと互換性がある。

発明の概要
本発明は、メッセージを発信元から第１の専用ノードに送信するための標準プロトコルを使用し、第１の専用ノードと第２の専用ノードの間で高性能プロトコルを使用し、次いで第２の専用ノードと宛先の間で標準プロトコルを使用することによって、ネットワーク・リンクの性能を向上させる方法および装置である。

したがって、本発明は、動的に生成された、非静的なコンテンツ並びに静的なコンテンツの加速度的な配信を有利に提供する。これは、２つの専用ノード間で様々な改善されたプロトコルをリンクを介して使用することを可能にする。同時に、本発明は、発信元と宛先によって使用される標準プロトコルへの変更のどのような要求をも有利に防止する。これは、多大なインターネット性能の利得を提供し、比較的高価でないコストで短期間に配置することができ、大規模なインフラストラクチャの変更もエンド・ユーザまたはサーバ・ソフトウェアへの変更をも要しない。

本発明の一実施形態による、ネットワークの改善された通信性能を提供するシステムのブロック図である。 本発明の一実施形態によるリダイレクション・システムによって使用されるプロセスの流れ図である。 本発明の一実施形態によるリダイレクション・システムによって使用されるデータ構造を示す図面である。 本発明の一実施形態によるセレクタによって使用されるプロセスの流れ図である。 本発明の一実施形態によるセレクタによって使用されるデータ構造を示す図面である。 本発明の一実施形態によるマッピング・デバイスによって使用される別のプロセスの流れ図である。 本発明の一実施形態によるＣ-ノードによって使用されるデータ構造を示す図面である。 本発明の一実施形態によるＣ-ノードによって使用されるプロセスの流れ図である。 本発明の一実施形態によるＣ-ノードによって使用されるデータ構造を示す図面である。 本発明の一実施形態によるＳ-ノードによって使用されるプロセスの流れ図である。 本発明の好ましい実施形態による、ネットワークの改善された通信性能を提供するシステムのブロック図である。

発明の詳細な説明
方法およびシステムの一般的な説明：クライアント・ノード（「Ｃ-ノード」）およびサーバ・ノード（「Ｓ-ノード」）
本発明は、インターネット中の複数位置に配置されており、高性能プロトコルを使用して相互に通信し、通信するために他の専用ノードを選択する能力を有する専用ノードを含む。好ましい実施形態では、このような専用ノードはウェブ・サーバおよびクライアントの近くに配置されている。「近く」という用語は、ネットワーク距離、現行のネットワーク状況、および個別ノードの能力などの様々な通信性能の尺度を含むことが理解されよう。具体的には、近さは、帯域幅容量、帯域幅コスト、待ち時間、セキュリティ、管理の範囲、管理上の利便性、および様々なネットワーク経路の現行の輻輳の尺度、またはこのような尺度の組合せに基づく場合がある。専用ノードは、例えばパケット形式による情報を、クライアントなどの発信元から、サーバなどの宛先に伝達するために使用することができる。

発信元から宛先に（または逆方向に）送信される所与のパケットに対する全体の通信経路が「リンク」と呼ばれる場合、そのリンクのために１つまたは複数の尺度を考慮する通信性能のいくつかの尺度を最適化することが望ましい場合がある。別法として、そのリンク内の１つまたは複数のサブリンク、例えば第１の専用ノードから第２の専用ノードへのサブリンク、または、第１の専用ノードから第２の専用ノードへのサブリンクと組み合わせた発信元から第１の専用ノードへのサブリンクなどに対する通信性能を最適化することが望ましい場合もある。

「通信性能の尺度の最適化」は厳密な数学的意味での最適化は意味せず、帯域幅容量、帯域幅コスト、待ち時間、セキュリティ、管理の範囲、管理上の利便性、および様々なネットワーク経路の現行の輻輳などの尺度を広範に考慮することができ、最速、最短または最低コストの経路に限定されないことが理解されよう。例えば、ある種の環境下では、このような経路は厳密な数学的な意味からは「最適」から程遠いが本発明の目的に関しては依然として最適であるというように、「最適な」経路は、往復時間の制約と管理上の利便性への配慮の組合せに基づいて選択することができる。

１つのサブリンクに対して最適化されるべき通信性能の尺度は、同じリンク内の別のサブリンクに対する通信性能の尺度とは異なる場合のあることが理解されよう。例えば、キャッシングが使用される場合、要求されるウェブ・コンテンツが特定のキャッシュ内に存在する可能性は、その専用ノードからサーバへのネットワーク距離と共に、「最適な」経路を決定するために使用することができる。
通信性能の尺度は、複数の他の通信性能の尺度の組合せである場合があり、この組合せは多くの方法で作成することができること、例えば組合せは加重合計であってよいこともさらに理解されよう。この組合せは、リンク内の異なるサブリンクに対する性能の尺度の加重合計などの組合せ、または単一サブリンクに対する距離と帯域幅などの異なる尺度の加重合計などの組合せ、または異なるサブリンクに対する異なる尺度の組合せであってよい。

上記の専用ノードに加えて、システムおよび方法は、リダイレクション・システムまたはプロセス、１つまたは複数の選択システムまたは選択プロセス（「セレクタ」）、および１つまたは複数のネットワーク監視およびマッピング・システムまたはプロセス（「マッピング・デバイス」）を含むこともできる。クライアントが、ウェブ・コンテンツの要求などのインターネット・メッセージ、または「ワールドワイドウェブ・メッセージ」をサーバに送信するために、セレクタは、クライアントに近い場合のある１つのノード、またはいくつかの他の特性または通信性能に関する尺度を最適化するために選択することのできる１つのノード、例えばＣ-ノードを選択するために使用することができる。Ｃ-ノードは、すべてのＣ-ノードのサブセットである場合のある一群の候補Ｃ-ノードから選択することができるということが理解されよう。したがって、セレクタは、選択を行うために、特定のノードとデバイスの間のネットワークの近さの度合いなどの、ネットワーク性能特性に関する情報へのアクセス権を有することが必要となる場合がしばしばである。別個のマッピング・デバイスは、そのような情報を収集し、分析し、照合し、セレクタが使用可能な形式で入手可能にすることを担当することができる。使用すべきＣ-ノードをセレクタが選択すると、クライアントからの特定のメッセージが、実際には、サーバに直接的に伝わるのではなく、そのＣ-ノードに確実に向けられるようにリダイレクション・システムに要求することができる。Ｃ-ノードは、クライアントからメッセージを受信すると、そのメッセージを、ターゲット・サーバに近い場合のある第２ノード、例えばＳ-ノードに送信する必要がある。Ｓ-ノードは、次いでこのメッセージをサーバに伝達する。サーバから応答がある場合、その応答は、通常、逆経路でＳ-ノードに向かって進み、次いで選択したＣ-ノードに向かって進み、さらにクライアントに向かって進む。サーバからの応答並びにウェブ・コンテンツに対する要求は、「ワールドワイドウェブ・メッセージ」またはより広範にはインターネット・メッセージと呼ぶことができる。

Ｃ-ノードは、メッセージが最終的に所望のサーバに到達するために、複数の可能な候補の集合からＳ-ノードを選択する必要がある。このような選択が必須ならば、Ｃ-ノードは、Ｓ-ノードを選択するための第２の選択システムまたはプロセスを使用することができる。Ｓ-ノードの選択は、次いで、第２の選択システムまたはプロセスによってＣ-ノードに提供される。第２の選択プロセスが使用される場合、Ｃ-ノードを選択するために最初に使用される選択プロセスまたはセレクタとは別個である場合がある。第２の選択プロセスに対する手段が第１の選択プロセスに対する手段とは物理的に分離されている場合、Ｓ-ノードの選択は、例えばネットワークを介して第２のセレクタによってＣ-ノードに伝達さ
れる必要がある。別法として、上記の最初の選択は、Ｃ-ノードとＳ-ノードの両方の選択を含むことができ、Ｃ-ノードだけの選択を含むものではない。Ｃ-ノードがクライアントからどこにメッセージを転送するかを認識するように、Ｓ-ノードの選択は、リダイレクション・システムまたは別の方法を用いてセレクタによってＣ-ノードに提供される。

最初のセレクタは、一部の実施形態では、Ｓ-ノードとＣ-ノードの両方を選択することができるが、Ｓ-ノードの選択をＣ-ノードに伝達することは不可能である。このような実施形態では、適切なＣ-ノードとＳ-ノードの対が使用されるように、第２のセレクタまたは選択プロセスは、原則的に最初の選択プロセスと同じ情報を使用してＳ-ノード選択を再決定する。これによって、Ｓ-ノードの選択をＣ-ノードに送信することが現実的でない場合でも、例えば、発信元から宛先への合計の送信時間を最小限に抑えるなど、リンク全体の特定の特性を最適化するために両方のノードの選択が可能になる。

本発明の一実施形態の別の態様では、Ｃ-ノードを選択しているセレクタは、選択されたＣ-ノードが要求されたオブジェクトをキャッシュに有する可能性と、Ｃ-ノードからサーバへのリンク内の少なくとも１つのサブリンクに対する尺度を含む通信性能の尺度とを含めて、その選択の基礎をこれらの要因の組合せに置く。例えば、Ｃ-ノードからサーバへの距離の数字が、要求されたオブジェクトをＣ-ノードがキャッシュに有しない可能性によって重み付けされる場合、クライアントからＣ-ノードへのネットワーク距離と、Ｃ-ノードからサーバへの距離とを推定することができる。これを基礎としてＣ-ノードを選択することによって、キャッシュ内に存在しないものも含めてすべてのオブジェクトで平均した予想される通信時間を最適化することができる。たとえＣ-ノードからクライアントへの通信が中間のＳ-ノードを通過しない場合でも、また、この通信が標準プロトコルを使用する場合でも、この態様を使用することができる。すなわち、Ｃ-ノードの本質的な機能が単なるキャッシュとしてのものである場合でさえ、この実施形態は有用である。

選択、マッピング、リダイレクション等の機能を別個のデバイスまたはプロセスに配置することができ、または組み合わせることができることが理解されよう。例えば、選択とマッピングは、セレクタがマッピング・デバイスから情報を受信して、別個のデバイスによって実施することができる。あるいは、選択とマッピングは同じデバイスによって実施することもできる。さらに、専用ノードは、例えば、ウェブ・プロキシがリダイレクションに使用することができる場所など、クライアントまたはサーバと同じ場所に配置することもできる。

リダイレクション・システムは、特定のトラフィックをクライアントから選択された専用ノード（Ｃ-ノード）に向けるために好適に使用される。クライアントに近い選択されたノードは、ターゲット・サーバ、例えばＳ-ノード、に近い第２の専用ノードのようなノードが最初の選択プロセスまたはシステムで選択されていない場合、または、このような第２の専用ノードの選択が第１の専用ノード（Ｃ-ノード）に伝達されていない場合、クライアントに近い選択されたノードは、ターゲット・サーバに近い第２の専用ノードを選択することができる。第１の専用ノードは、高性能プロトコルを使用して第２の専用ノードと通信する。
第２の専用ノードは、次いで従来のウェブ・プロトコルを使用して、ターゲット・サーバと通信する。一態様では、本発明は、終端間通信を、各経路で、すなわちクライアントからＣ-ノードへ、Ｃ-ノードからＳ-ノードへ、Ｓ-ノードからサーバへ（応答の場合は対応する逆ステップ）で、３つの別個のステップまたはサブリンクに分割し、したがって、標準の、恐らくは効率の悪いプロトコルを使用する最初のステップと最後のステップは短く（従来のネットワーク距離尺度を使用して）、中間ステップは最適な効率よいプロトコルを使用する。

Ｃ-ノードとＳ-ノードの間のサブリンクは、光ファイバまたはＡＴＭ等の高性能のサブリンク専用であってよいことが理解されよう。専用のサブリンクが使用される場合でも、クライアントからＣ-ノードへの通信とサーバからＳ-ノードへの通信は依然としてインターネットを介して行われているので、通信は「インターネットを介して」行われるものと仮定される。したがって、「インターネットを介して」という用語は、終端間通信リンクにおけるすべてのサブリンクに対してインターネットを介して行われることを要求するものと解釈されるべきではない。

図１に示す一実施形態では、本発明は、インターネットの様々な地点に配置されている専用ノードの分散型ネットワークを含む。従来のコンテンツ配信システムとは異なり、本発明は、Ｃ-ノード１２とＳ-ノード１４の２つのタイプのノードを必要とする。ウェブ・クライアント１０、例えばブラウザを使用中の人物が、本発明が管理するように構成されているいくつかのウェブ・サイトに向けて要求を発行するか、あるいは、本発明が管理するように構成されているいくつかの特定のウェブ・オブジェクトに対する要求を発行する場合に、本発明は機能する。以下の議論で、クライアント１０はコンテンツを要求しているユーザまたはデバイスであり、サーバ１６は、コンテンツの確定的なコピーを含んでいるか、または生成した起点サーバであって、通常、そのコンテンツをクライアント１０に配信することを担当する起点サーバである。

本発明は、あらゆるネットワーク・コストまたは距離尺度の観点から、クライアントに近いいくつかのＣ-ノード１２を識別するための選択手段と、クライアントの要求が選択したＣ-ノード１２-１に確実に向けられるようにする手段とを好適に使用する。あるいは、本発明は、クライアント１０からのすべてのトラフィックが、確実に、いくつかの近いＣ-ノード１２を通過し、そのノードによって可能なインターセプションを受けるようにする手段を使用することができる。
コンテンツ配信またはキャッシングに対して使用される手段と類似の手段、例えば、ウェブ・プロキシを使用することができる。

Ｃ-ノードを選択しなければならない場合、Ｃ-ノード１２の選択は、性能または予想される性能に関する要因などの、Ｃ-ノード１２とクライアント１０の間のネットワーク距離の尺度以外の、またはこれらに付加的な様々な要因に依存する場合があるということが理解されよう。このような他の要因の一例は、Ｃ-ノード１２とサーバ１６の間の通信性能の任意の尺度である（必ずしもクライアント１０からＣ-ノード１２の距離を測定するために使用されるのと同じ尺度を使用する必要はない）。この実施例では、要求がクライアント１０からサーバ１６に伝わり（すなわち、本発明の他のすべての構成要素を使用しながら、要求がＣ-ノード１２を介して送信される場合）、応答が戻されるのに要する合計通信時間を推定するために、クライアント１０からＣ-ノード１２へのネットワーク距離を、Ｃ-ノード１２からサーバ１６へのネットワーク距離と組み合わせることができる。この実施例では、推定されたこの合計通信時間は、Ｃ-ノード選択に対する、また、恐らくはＳ-ノード選択に対する確定的な通信性能の尺度である。

一般に、Ｃ-ノード１２およびＳ-ノード１４の選択は、クライアント１０、Ｃ-ノード１２、Ｓ-ノード１４、およびサーバ１６のすべての４つの構成要素を必要とする全体的な通信経路またはリンクの特性に依存する場合がある。あるいは、Ｃ-ノード１２からＳ-ノード１４へのサブリンクなどの、経路の１つまたは複数のサブリンクは、Ｃ-ノード１２およびＳ-ノード１４の選択を決定付ける。したがって、本発明は、一部の所望の性能特性を最適化するために、そのような特性を評価し、Ｃ-ノード１２の中から（また、恐らくはＳ-ノード１４の中から）選択する手段を使用することができる。

選択手段と基準のどちらが使用されたとしても、次いでリダイレクション手段が使用され、選択されたＣ-ノード１２-１が要求を受信する。リンク１１を介したクライアントとＣ-ノード１２の間のすべての通信は、クライアントの選択によるネットワーク・プロトコルを使用することになり、したがって、通常、これは標準の広範に普及したプロトコルであることになる。現在、ウェブ・トラフィックにとって、これは通常、ＨＴＴＰバージョン１．０、ＨＴＴＰバージョン１．１、またはＨＴＴＰ１．１のすべての機能ではなく一部の機能を使用するいくつかの中間プロトコルであることになり、現在ではＨＴＴＰのこのようなバージョンのどれでも、一般的にＴＣＰによって実行されることになる。他のプロトコル、例えば無線アプリケーション・プロトコル（ＷＡＰ）およびセキュア・ソケット層（ＳＳＬ）を使用することもできる。本発明のこの態様は、いかなる特定のプロトコルにも限定されるものではないが、ネットワークで低性能の標準プロトコルが使用されており、高性能が望まれるときはいつでも使用することができる。「プロトコル」という用語は、ＨＴＴＰなどの単一プロトコルを意味するか、またはＨＴＴＰ ｏｖｅｒ ＴＣＰ ｏｖｅｒ ＩＰなどの複数に階層化されたプロトコルを意味するものであることが理解されよう。

Ｃ-ノード１２は、その任意選択のキャッシュまたはデータベースにあるオブジェクトに対する要求を受けると、クライアント１０に直接そのオブジェクトを戻すことができ、したがって、従来型のウェブ・キャッシュまたはコンテンツ・ディストリビュータとして、並びに、高性能プロトコルを使用することができる専用ノードとして機能することができる。Ｃ-ノード１２がこのようなキャッシュまたはデータベースを有しない場合、Ｃ-ノード１２を選択するために使用される選択手段および基準は、Ｃ-ノード１２のキャッシュに要求されたオブジェクトがある可能性の推定を含むことができる。従来型のキャッシング機能に加え、Ｃ-ノード１２は、管理するように構成されているすべてのウェブ・サイトおよびウェブ・オブジェクトに対して、そのサイトまたはウェブ・オブジェクトに対応するサーバに近いと判断されたＳ-ノード１４の識別を追跡するデータベースを維持することができ、したがって、Ｃ-ノードがＳ-ノードを選択することが可能になる。現在のシステムでは、この識別は、Ｓ-ノードに対するＩＰ（インターネット・プロトコル）アドレスまたはインターネット・ドメイン名の形式である場合がある。あるいは、Ｃ-ノード１２は、他の手段を使用して、例えばＳ-ノード１４の選択を担当するセレクタまたは選択プロセス（図示せず）を使用することによって、適切なＳ-ノード１４の識別を決定することができる。

Ｃ-ノード１２は、クライアントが使用している普及型の標準プロトコルよりも高性能になるように設計された専用プロトコルを使用して、選択したＳ-ノー
ド１４にリンク１３を介してクライアントの要求を伝達する。Ｃ-ノード１２とＳ-ノード１４の間の通信は、プロトコルのトンネル伝送に使用されるプロトコルに類似の技術を使用して達成することができる。例えば、ＨＴＴＰ／ＴＣＰはパケットまたはデータグラム指向のプロトコルなので、Ｃ-ノード１２は、受信するパケットを、「ラッパー」を使用して高性能パケットに「カプセル化する」ことができ、Ｓ-ノード１４は、元のパケットを回復するためにそのラッパーを除去することができ、次いでＨＴＴＰ／ＴＣＰを使用してそのパケットはサーバにリレーされる。

Ｃ-ノードおよびＳ-ノードが密接に結合されているので、それを採用するために、インターネットなどの残りのネットワークを必要とせずに革新的なプロトコルを使用することができることが理解されよう。例えば、Ｃ-ノードとＳ-ノードは専用の目的を有するので、例えば煩雑であるとか、大量のメモリを必要とするという理由でウェブ・クライアントまたはサーバに広範に配置することのできなかったプロトコルを使用することができる。当業者ならば、多くのそのような最適化されたプロトコルまたは高性能のプロトコルは周知であるが、但しその多くは研究機関の外部に持ち出されたことはないということを理解するだろう。本発明の態様は、特定のＣ-ノードからＳ-ノードへのプロトコルに特有のものではなく、この分野におけるさらなる開発を見込むものである。当業者ならば、いかに広範に配置され、標準化された最新のプロトコルが開発されたとしても、本発明が使用することのできる研究機関の情報ルートでは、より優れたプロトコルの革新が常に起こる可能性があるということを理解するだろう。下記の「ノード間プロトコルおよび技術」と題する節では、いくつかの好ましい最適化されたプロトコルが記述されており、本発明の別の態様が、記述されたプロトコルに対する強化を含めて開示される。

Ｃ-ノードとＳ-ノードの間の多くの強化されたプロトコルは、下記の「ノード間プロトコルおよび技術」と題した節で提供されるすべての実施例に関してその通りであるように、公衆インターネット・インフラストラクチャを介して搬送することができる。しかし、上記のように、Ｃ-ノードとＳ-ノードの間のトラフィックもまた、民間ネットワーク、例えば公衆ネットワークよりも高性能の通信のために設計されたネットワーク上で搬送することができる。Ｃ-ノードとクライアントの間のトラフィックと、Ｓ-ノードとサーバとの間のトラフィックはインターネットを介して搬送されるので、クライアントとサーバの間のリンクの一部が民間ネットワークを介したものであるとしても、通信は依然としてインターネットを介して搬送されるインターネット・メッセージと呼ばれる。

図１に戻って、選択したＳ-ノード１４は、専用の高性能プロトコルを使用して、Ｃ-ノード１２からリンク１３を介して要求を受信する。Ｓ-ノード１４は、要求されたコンテンツを、Ｓ-ノード１４の任意選択のキャッシュ内（またはアクセス権を有するキャッシュ内）で発見することができるか、あるいは、そのコンテンツを獲得するためにサーバ１６に接触する必要がある。後者の場合、Ｓ-ノード１４は、サーバの選択によるプロトコルを使用してリンク１５を介してサーバ１６と通信することができる。このプロトコルは、今のところ、典型的にはＨＴＴＰ ｏｖｅｒ ＴＣＰ１つのバージョンである。この後者の場合、Ｓ-ノード１４は、リンク１５を介してサーバ１６からの応答を取り出す。どちらの場合でも、Ｓ-ノード１４は、専用の高性能プロトコルを使用して、リンク１３を介して発信元であるＣ-ノード１２に応答を戻すことができる。Ｃ-ノード１２は、次いでリンク１１を介してクライアントの選択による標準プロトコルを使用して、受信した応答をウェブ・クライアント１０に伝達する。

好ましい一実施形態では、クライアント１０からＣ-ノード１２への距離は最低限に抑えられる。これは、高速リンク１３を介してより優れたプロトコルを配置する際に得られる利得を最大化することができるということが理解されよう。
本発明は、Ｓ-ノード１４をウェブ・サーバ１６の近くに配置し、また、Ｃ-ノード１２をクライアント１０の近くに配置することによってこれを有利に達成する。

したがって、クライアントからサーバへの終端間トランザクションを３つの部分に分割することによって大きな利益を得ることができる。３つの部分とは、クライアントからＣ-ノードへの部分を含む第１の部分と、Ｃ-ノードからＳ-ノードへの部分を含む第２の部分と、Ｓ-ノードからサーバへの部分を含む第３の部分である。Ｃ-ノードは、一般に、クライアントから比較的短いネットワーク距離であり、広範に配置された従来型プロトコル（好適にはＨＴＴＰ ｏｖｅｒ ＴＣＰ）を使用してクライアントと通信する。Ｓ-ノードは、一般に、サーバから比較的短いネットワーク距離であり、広範に配置された従来型プロトコル（好適にはＨＴＴＰ ｏｖｅｒ ＴＣＰ）を使用してサーバと通信する。Ｃ-ノードとＳ-ノードは、高性能プロトコル（好適には、下記の「ノード間プロトコルおよび技術」に記載の１つまたは複数のプロトコル）を使用して相互に通信することができる。

別の態様では、本発明はＣ-ノードとＳ-ノードのネットワークを配置し、次いで、クライアントとサーバの間のネットワーク性能の尺度を最大化することを目指して特定のＣ-ノードとＳ-ノードを選択する。近さを基準にしてＣ-ノードとＳ-ノードを選択することにより、トンネル伝送するノードをクライアントとサーバに配置することの大部分の利点が得られるが、クライアントもサーバもいかなる変更を要しない。クライアントまたはサーバのマシンに、あるいはそれらのソフトウェアに対していかなる変更も加えずに配置することができ、したがって拡張型プロトコルが配置される以前にコストおよび時間を低減することができるということは、本発明のもう１つの重要な利点である。

方法およびシステムの詳細：Ｃ-ノード、Ｓ-ノード、選択、リダイレクション、マッピング、および専用プロトコル
本発明は、専用コンピュータまたはネットワーク・ノード、Ｃ-ノードおよびＳ-ノードの分散型の集合を含んでいる。当業者であれば、両方のタイプのノードの機能が単一の物理的なデバイス内に存在することができるということを理解するだろう。下記で記述するように、本発明の特定の実施形態には、Ｃ-ノード
とＳ-ノードに加えて他の構成要素が含まれる。これらのノードは、汎用コンピュータ上で実行される、別の目的のためにも機能するコンピュータ・ソフトウェアとして実施することもでき、あるいは密接に結合された一群のコンピュータとして実施することもできる。

Ｃ-ノードは、大部分のインターネット・ユーザが、ネットワークの観点では少なくとも１つのＣ-ノードの近くにあるようにとの意図で、ネットワーク全体に分散されている。具体的には、Ｃ-ノードは、インターネット・サービス・プロバイダ（ＩＳＰ）の構内、大企業のネットワーク上、インターネットのバックボーン・ネットワーク上、およびどこにでも配置することができる。本発明の適切な動作は、Ｃ-ノードがいかに良好に配置されているかには依存しないが、但し、本発明によって提供される利益はこれに依存する場合がある。

選択システム
好ましい一実施形態では、本発明は、要求の発信元に近いＣ-ノード、すなわちクライアントを選択するための手段すなわちセレクタを含むか、またはこれを使用する。セレクタは、要求の宛先に近いＳ-ノード、すなわちサーバを選択することもできる。サーバは、インターネット・メッセージ、例えばウェブ・コンテンツの発信元として機能することができ、クライアントは、インターネットの宛先として機能することができ、またはこの逆も可能であることが理解されよう。ここで使用する近いという概念は、帯域幅容量、帯域幅コスト、待ち時間、セキュリティ、管理の範囲、管理上の利便性、様々なネットワーク経路における現行の輻輳、地理的近さなどの尺度のいかなる組合せをも含むことができるが、但し、他の要因を考慮することもできる。しかし、本発明の適切な動作は、近さのどの概念が使用されているかや、選択されたＣ-ノードが実際にどれだけ近いかに依存するものではない。

選択システムは、クライアントとＣ-ノードの間のネットワークの近さに加えて、またはその代替として、他の要因を考慮することができる。この理由は、Ｃ-ノードに関する他の要因は、達成される性能にも関係するものであるという可能性がある。一例として、１つのＣ-ノードから非常に短いネットワーク距離であるクライアントを想定し、このＣ-ノードが第１のインターネット・バックボーン・ネットワークに接続されていると想定する。この実施例におけるクライアントは、第２の別のインターネット・バックボーン・ネットワークに接続されている第２のＣ-ノードから若干延長されたが依然として短いネットワーク距離でもある。クライアントは、特定のサーバからウェブ・コンテンツを取り出すことを希望する場合があり、このサーバ（および／またはサーバに最も近いＳ-ノード）は、第１のインターネット・バックボーン・ネットワークではなく第２のインターネット・バックボーン・ネットワークに良好に接続されていることはよく知られている。現在、トラフィックが１つのバックボーンから別のバックボーンに横断する所謂「ピアリング・ポイント」は、ネットワーク・トラフィックの遅延に共通した原因である。この場合、第１のＣ-ノードではなく第２のＣ-ノードを選択することを希望することができ、したがって、バックボーンの横断を回避することができる。第１のＣ-ノードが第２であるクライアントに対して若干近い場合であっても、これは事実である。したがって、この実施例では、バックボーンの接続性の追加的な要因は、Ｃ-ノードを選択する場合に有益に考慮することができる。

このような別の要因の第２の実施例として、クライアントとサーバの間の通常のトランザクションがＣ-ノードを使用して送信され、本発明の他のすべての構成要素を使用する場合、このトランザクションに掛かる合計通信コストまたは合計通信時間を推定するような方法で、クライアントとＣ-ノードの間の推定距離を、Ｃ-ノードとサーバの間の推定距離と直接的に結合することができる。他のこのような要因の第３の実施例として、各Ｃ-ノードへの現行の負荷を監視し、他のノードよりも若干遠距離にある、比較的負荷の軽いノードの方を、負荷の重い別のＣ-ノードよりも好ましいものとして選択することができる。このような他の要因の第４の実施例として、そのキャッシュ内に要求されたコンテンツを有する可能性が比較的高いＣ-ノードに対して、付加的な好みを付与することがで
きる。

いくつかの実施形態では、選択はリダイレクション・システムによって本質的に実行することができる。別の実施形態では、Ｃ-ノードまたはＳ-ノード、またはこれらの両方を選択するために、セレクタは、マッピング・システムから得られた情報を使用することができる。上記のように、Ｃ-ノードは１つのセレクタによって選択され、Ｓ-ノードは別のセレクタによって選択される。Ｃ-ノードには、Ｓ-ノードに送信するために、Ｓ-ノード選択を提供する必要がある。したがって、Ｓ-ノードが別個のセレクタによって選択される場合、その選択はＣ-ノードに伝達される必要がある。これは、例えばクライアントによって行われる場合と、セレクタによって行われる場合がある。あるいは、単一セレクタはＣ-ノードとＳ-ノードの両方を選択することができるが、これによって、セレクタは、必要に応じて発信元から宛先へのリンク内のすべてのサブリンクの特性を考慮することができる。

リダイレクション・システム
好ましい実施形態では、本発明は、本明細書で「リダイレクション・システム」と呼ばれる手段を含むか、またはこれを使用する。したがって、ウェブ・コンテンツへの要求を含めて特定のウェブ・トラフィックは、元々そのようなコンテンツを配信したサーバに直接的に伝達されるのではなく、選択されたＣ-ノードに伝達される。このリダイレクション・システムは、クライアントに近くなるように選択されるか、または、他の類似の性能に関連した基準によって選択されたＣ-ノードにトラフィックが送信され、次いでそのようなＣ-ノードによってそのトラフィックがインターセプトされるように構成する。状況によっては、リダイレクション・システムは、選択システムの機能を実行し、また、リダイレクションを提供する。

リダイレクション・システムの次の代替形態を例示として提供する。しかし、このリストは網羅的なものであるように意図したものではなく、本発明は、これの代わりに使用することができる他の手段も予想している。さらに、当業者ならば、以下のリストの方法の多くの組合せまたは変形形態がリダイレクション手段として機能することができることを理解するだろう。

ウェブ・プロキシの提供
大部分のウェブ・クライアントはプロキシを使用するように構成されている。
このように構成された場合、クライアントは要求を、要求されたコンテンツの発信元に直接的に（例えば、コンテンツを含んでいるウェブ・サーバに）送信するのではなく、指定されたプロキシに送信する。プロキシは、次いでクライアントに代わって情報を獲得し、さらにこの応答をクライアントに戻す。クライアントの構成は手動で行うことも（すなわち、ユーザが自分のブラウザにパラメータを設定する）、自動的に行うこともでき（例えば、ブラウザが、既知の場所からプロキシの設定を含めて構成の設定をダウンロードする）、あるいはクライアント・コードに固定することも可能である。クライアントは、要求ごとに同じプロキシまで行くことも、または要求ごとにプロキシを使用するかどうか（使用する場合は、どのプロキシか）について決定を行うこともできる。したがって、プロキシが使用される場合、状況によっては、Ｃ-ノードは少なくとも動的には「選択」されず、この実施例の場合のリダイレクション・システムはリダイレクションだけでなく、Ｃ-ノードの任意の選択を含む。

クライアントの位置または相対的な距離に基づいて、近いＣ-ノードのアドレスまたは名称を決定するために人的判断またはコンピュータ・プログラムを使用することができることが理解されるだろう。この場合、手動または自動の構成を使用することによって、クライアントは、適切なウェブ・トラフィックのために、そのクライアント自体のプロキシとしてＣ-ノードを使用するように構成されている。

透過的ネットワーク・インターセプション 専用コンピュータ、または、ルータなどのネットワーク・エレメントは、特定のクライアントからのトラフィックがこのノードまで通過するようにネットワーク内に配置することができる。このノードは、すべての送出されるトラフィックを点検するハードウェアまたはソフトウェアを実行することができ、各パケットまたはトラフィックのストリームに関して、そのようなトラフィックが妨害を受けずにその通常の経路を通過するかどうかを判定することができ、あるいは、パケットが特定の処理に対してインターセプトされるかどうかを判定することができる。

このノードは、本発明が取り扱うべきウェブ要求および他のトラフィックをインターセプトするように構成されている。クライアントからのすべてのトラフィックを見ることができるようにするには、インターセプトするノードは一般にクライアントの近くにある必要がある（例えば、クライアントと同一マシン上、クライアントと物理的に同一のネットワーク上、またはクライアントのＩＳＰ上に）。したがって、このようなトラフィックをインターセプトするように構成されたノードはＣ-ノードとして機能することができる。

このインターセプション・システムの変形形態が実施されるのは、インターセプトするノード自体は、Ｃ-ノードではないが、例えばＩＰルーティングを使用し、かつ／またはＩＰパケットのカプセル化を使用し、次いでそれらＩＰパケットをＣ-ノードに転送するなどの、選択されたトラフィックを隣接のＣ-ノードに送信する機能は有している場合である。この場合、インターセプトするノードに隣接のＣ-ノードの識別を認識させるためには様々な手段を使用することができる。例えば、最も近いＣ-ノードの名称またはＩＰアドレスは、インターセプトするノード内に固定することも、またはインターセプトするノードに対してアクセス可能なデータベースに格納することもできる。あるいは、インターセプトするノードは、ネットワーク距離を分析する専用コンピュータまたはシステムを照会することができ、また、適切なＣ-ノードを識別することができる。

ＤＮＳリダイレクション
クライアントは、ウェブ要求を発行すると、一般に、その要求に対するサーバを、「ｗｗｗ．ｓｏｍｅｓｅｒｖｅｒ．ｃｏｍ」など、そのドメイン名によって識別する。インターネットでは一般に数値によるインターネット・プロトコル（ＩＰ）アドレスであるネットワーク・アドレスに、このような名称をマッピングする専用ネットワーク・エレメントが存在する。インターネットのルーティグのインフラストラクチャは、ＩＰアドレスに基づいてコンピュータおよびネットワーク・エレメントを探し出す。名称をネットワーク・アドレスにマッピングするために現在使用されている最も一般的なサービスは、ドメイン名システムまたはＤＮＳと呼ばれている。しかし、同様の目的を持った様々な競合するサービスが開発される可能性があるが、以下の記述はそのようなサービスにも同様に適用することができるものである。

通常、ＤＮＳは、ウェブ・サーバの実際のアドレスを戻すように構成されている。しかし、別のコンピュータまたはネットワーク・ノードのアドレスを戻すように構成することもできる。この場合、サーバに向けられたトラフィックは、そのサーバではなく、実際には別のノードに達する。しかし、他のサーバが対象であったサーバに代わって適切に機能することができる限り、または対象であったサーバに向けてそのトラフィックを転送することができる限り、これは許容可能である。

リダイレクションは、ＤＮＳにサーバの名称をサーバ自体のアドレスではなく、近くに配置されたＣ-ノードのアドレスにマッピングさせることによって達成することができる。この場合、ＤＮＳシステムは、特定名称に対して受信したすべての照会に対して同一のアドレスを戻す必要はないということに留意することが重要である。ＤＮＳはリクエスタ（別のＤＮＳサーバである場合がある）のＩＰアドレスを決定することができるので、要求するクライアントによって異なる可能性のあるアドレスを戻すように構成することができ、具体的にはそのクライアントに近いノードを識別することができる。要求しているクライアントに近い可能性があるＣ-ノードのＩＰアドレスを戻すには、ＤＮＳシステムを構成する
またはＤＮＳソフトウェアを書くためのいくつかの特別な方法があるが、これらの技術は、当業者にはよく知られている。

専用ドメイン名を使用するＤＮＳリダイレクション
ＤＮＳリダイレクションの変形例は、サーバのドメイン名とは別個の「ｗｗｗ．ｃｎｏｄｅ．ｃｏｍ」または「ｗｗｗ．ｓｏｍｅｓｅｒｖｅｒ-ｃｎｏｄｅ．ｃｏｍ」などの新しいドメイン名を使用することを必要とする。ＤＮＳシステムは、要求するクライアントによって異なるＩＰアドレスをこの新しい名称に戻すように構成されているが、このようなＩＰアドレスは、クライアントに近いＣ-ノードを識別するものである。この手法では、実際のサーバは、例えば「ｗｗｗ．ｓｏｍｅｓｅｒｖｅｒ．ｃｏｍ」などの元の名称を保存しており、ＤＮＳはこの名称を、（Ｃ-ノードのアドレスにではなく）サーバの正確なＩＰアドレスにマッピングする。

サーバがコンテンツを配信する場合、そのコンテンツは、さらに別のウェブ・オブジェクトへの参照を含むことができる。具体的には、ハイパーテキストマークアップ言語（ＨＴＭＬ）はサーバまたは他のどの場所にも保存される他のオブジェクトに対して参照を含むことができる。Ｒ４のこの変形形態では、サーバは、本発明によってオブジェクトが取り扱われることを希望しない場合、そのオブジェクト自体の名称（例えばオブジェクトが「ｈｏｍｅ．ｈｔｍｌ」と呼ばれ、サイトが「ｗｗｗ．ｓｏｍｅｓｅｒｖｅｒ．ｃｏｍ」という名称ならば、ＵＲＬは「ＨＴＴＰ：／／ｗｗｗ．ｓｏｍｅｓｅｒｖｅｒ．ｃｏｍ／ｈｏｍｅ．ｈｔｍｌ」である）を使用してオブジェクトを参照することができ、そのようなコンテンツを本発明によって取り扱わさせるためには、新しい名称「ＨＴＴＰ：／／ｗｗｗ．ｃｎｏｄｅ．ｃｏｍ／ｓｏｍｅｓｅｒｖｅｒ／ｈｏｍｅ．ｈｔｍｌ」または「ＨＴＴＰ：／／ｗｗｗ．ｓｏｍｅｓｅｒｖｅｒ-ｃｎｏｄｅ．ｃｏｍ／ｈｏｍｅ．ｈｔｍｌ」を使用して参照することができる。

この方法の１つの利点は、ウェブ・サーバの名称を提供するＤＮＳ検索要求が、サーバの本当のアドレスを引き換えに受信することである。

ＨＴＴＰリダイレクション
ＨＴＴＰプロトコルのバージョンには、様々な「リダイレクション」コマンドおよび応答が含まれる。クライアントは、サイトにコンテンツを要求すると、要求したコンテンツを含まず、代わりにそのコンテンツを発見することができる代替の位置を指名する応答を受信する場合がある。これらがＨＴＴＰリダイレクション応答と呼ばれるものである。大部分のウェブ・クライアントは、それ以外にユーザのフィードバックを要せずに、提案された位置に自動的に移動するように構成されている。

ＨＴＴＰリダイレクションを本発明のリダイレクション機構の一部として使用するために、要求は最初に固定した宛先に送信される。その固定した宛先は、それ自体がサーバであっても、他の専用ノードであってもよいが、必ずしもクライアントの近くのものを選択したり、性能に関する基準に従って選択したりする必要はない。このノードは、要求するクライアントのアドレスを使用してクライアントに近いＣ-ノードを選択することができ、次いで、ＨＴＴＰはそのＣ-ノードを使用するためにクライアントをリダイレクトすることができる。この選択はサーバ自体がこの目的のソフトウェアを実行することによって行うことも、またはサーバが別の専用コンピュータを照会することもできる。この方法の変形形態は、要求が最初にサーバに送信され、Ｃ-ノードを選択することができる別の専用コンピュータにＨＴＴＰが要求をリダイレクトし、次いでこの専用コンピュータが選択されたＣ-ノードに対して第２のＨＴＴＰリダイレクションを実行するというものである。

ＨＴＴＰリダイレクションおよびＵＲＬ書き換え
このリダイレクション・システムおよび方法は、ＨＴＴＰリダイレクションの変形形態である。あるＣ-ノードに要求がリダイレクトされると、そのＣ-ノードはクライアントに対して応答を返すことを担当する。要求がＨＴＭＬであり、別のオブジェクトへの参照（ＵＲＬ）を含む場合、それらの参照は元のサーバのドメイン名を含んでいる場合がある。

Ｃ-ノードはＨＴＭＬを変更してサーバの名称をＣ-ノード独自の名称またはＩＰアドレスに置換することができる。この方法で、クライアントは、参照されたオブジェクトの１つを要求することを決定し、その要求は、リダイレクションのオーバーヘッドを必然的に被るのではなく、自動的にＣ-ノードに直接送信される。

選択に使用するネットワーク・マッピングおよびその他の手段
上記のリダイレクト方法は、サーバに向けたインターネット・トラフィックを実際にまずＣ-ノードに送信する際の可能な手段である。別の課題は、クライアントに「近く」なるように、あるいはその他の性能に関連する基準に従って、Ｃ-ノードを見つけ、選択することである。ある場合には、適切なＣ-ノードを人間の判断によって、または一時的なネットワーク分析によって決定し、クライアントとＣ-ノードのマッピングを確定して、例えばウェブ・プロキシ法と同様に各クライアントのプロキシ設定を手動で設定することが可能である。他の場合には、２つのインターネット位置間のネットワーク待ち時間を変化させるネットワーク中の輻輳、時間に依存する帯域幅コスト、Ｃ-ノードが現在作動状態にある変化、およびその他の問題により、頻繁にＣ-ノードの近接度の判定に立ち戻らなければならない。

Ｃ-ノードの近接度の判定に立ち戻るために、ウェブ・トラフィックを常時監視する１つまたは複数の専用コンピュータまたはソフトウェア・システムを配置することができ、こうしたマシンは現在のネットワーク距離を示す「マップ」またはモデルを構築することができ、これらをセレクタが使用して各クライアントに適切なＣ-ノードを選択することができる。当業者には、多数のマッピングおよび監視のシステムが知られる。以下のリストは完全を期したものではなく、こうした技術のいくつかの例を示すに過ぎない。好ましい実施形態では、下記のすべての方法を組み合わせて使用する。

代表マシンからＣ-ノードに対して行われる測定
ネットワーク中の任意のマシンで実行されるソフトウェア・プログラムは、それ自体と、例えばＣ-ノードなどの第２のコンピュータ間の待ち時間を測定することができる。これは、特殊な形態の短いＩＰパケットを送信し、それに対する応答が第１のコンピュータに戻るのに要する時間を測定することによって行う（これを行う標準的なＵＮＩＸ（登録商標）プログラム「ｐｉｎｇ」にちなんで「ｐｉｎｇｉｎｇ」と呼ばれることがある）。これと同様に、ソフトウェア・プログラムは、周知の長さのより長いデータ・ストリームを送信するのにかかる時間を測定し、それを伝送時間で割ることにより帯域幅を測定することもできる。この他にも他の測定方式がよく知られる。このように、インターネット中の多くの位置にこのようなソフトウェアを配置することができ、この場合各位置は特定クラスのユーザを代表するものと考えられる。例えば、ＩＳＰのＰｏＰ（ｐｏｉｎｔ-ｏｆ-ｐｒｅｓｅｎｃｅ）施設に位置するそのようなソフトウェアが、そのエリア内のＩＳＰのユーザを表す測定値を提供すると想定することができる。インストールされたこのソフトウェアはそれぞれ、各Ｃ-ノード（またはいくつかの候補Ｃ-ノードの選択された集合）までの帯域幅と待ち時間を周期的に測定し、その結果を中央にある「マッピング」デバイスに周期的に伝え、「マッピング」デバイスはその結果を照合および分析する。

Ｃ-ノードから代表マシンに対して行う測定
上記の方法と同様にＣ-ノードもソフトウェアを含むことができ、Ｃ-ノード自体と、指定された他のコンピュータまたはネットワーク・デバイス（例えばルータ）の集合間の現在のネットワーク距離（待ち時間、帯域幅、またはその他の尺度から見た）を測定することができる。この情報は、第１のマッピング法と同様にマッピング・デバイスに送られる。

Ｃ-ノードの負荷および利用可能度
マッピング・デバイスは、周期的に各Ｃ-ノードに問い合わせて、Ｃ-ノードがなお作動状態にあるかどうかを調べることができ、作動状態にある場合は、その現在の容量および負荷についての報告をＣ-ノードから得ることができる。あるいは、Ｃ-ノードがそのような報告を周期的にマッピング・デバイスに送信してもよい。

ソース・ルーティングによるネットワーク測定
マッピング・デバイスまたは他のコンピュータは、第１のマッピング法で説明したように特殊なパケットを送信することにより、それ自体と指定されたＣ-ノード間の帯域幅および待ち時間を推定することができるが、さらに「ＩＰレベルのソース・ルーティング」を使用して、それらのパケットがＣ-ノードまでの経路上で指定された中間マシンを通過することを指定することができる。この中間マシンは、あるクラスのクライアントを表すと考えられるクライアント・コンピュータまたはネットワーク・ノードでよい。マッピング・デバイスは、複数のＣ-ノードについてこのような推定を行うことができる。マッピング・デバイスと選択された中間マシンまでの距離は、問い合わせを行うＣ-ノードに関係なく定数と見なすことができるので、異なるＣ-ノードについてのこれら測定の差を、中間マシンとクライアント間の距離を測定するのに適した尺度として使用することができる。

ルーティング情報
インターネット・ルータは、発信元コンピュータから宛先コンピュータまで効率的な経路を使用してＩＰトラフィックを送信することができるように、標準的なアルゴリズムを用いる。このルータは、このアルゴリズムの一部として、ルータからインターネット中の特定の他の位置までの距離のヒューリスティックな尺度を含むインターネット・トポロジに関する情報を保持する。この情報は抽出して、マッピング・デバイスに転送することができる。

マップ分析
マッピング・デバイスは、様々なコンピュータ・ペア間のネットワーク距離に関する情報を集めることができるが、その推定値は上記で述べた手段またはその他の同様の手段のいずれかを使用して得られる。マッピング・デバイスは、ネットワークおよび通信状態に関する他の情報のコレクタ、およびリポジトリとしても機能することができる。この情報は、ルータまたはその他の発信元から得るトポロジ情報、各種のリンクを使用する際のコスト（例えば帯域幅の負担）を含んだテーブル、ノードおよびコンピュータに関する静的な情報（どのＣ-ノードがキャッシュを含むかなど）などの情報である。実際、選択プロセスに関連すると思われる情報はいずれも収集して、マッピング・デバイスに記憶しておくことができる。

マッピング・デバイスは、収集した情報を各種の方式で分析および編成して、セレクタにとってより有用なものにすることができる。例えば、マッピング・デバイスは、リレーショナル・データベースの技術を使用して、コンピュータ・ペア間のネットワーク距離のテーブルを記憶し、それにより選択プロセスで、そのようなテーブルに対して複雑なクエリを発して非常に迅速な返答を得るのを容易にすることができる。別の例として、マッピング・デバイスは、それが記憶するデータの新しさ（ｔｉｍｅｌｉｎｅｓｓ）を把握して、特定のデータ項目を更新する、または欠けている項目を埋める必要がある際に、新しい測定を開始することができる。さらに別の例として、マッピング・デバイスは、分析アルゴリズムを用いて、それが有する生の（すなわち未処理の）データをより簡潔または有用な形態に変換することができる。このような分析を例示すると、マッピング・デバイスは、知られる「最短絡」アルゴリズムおよび「スパンニング・ツリー」アルゴリズムを使用することができる。これらのアルゴリズムは、マッピング・デバイスが、ペアになったコンピュータ間のネットワーク距離の集合である生（未処理）データを有する際に有用である。ただし、一般に、すべての可能なコンピュータ・ペア間の直接的な測定値を得ることは不可能である。したがって、生データは可能なペアのうち一部についての測定値しか含まないが、マッピング・デバイスが、直接的な測定が行われたコンピュータ・ペアだけでなく任意のコンピュータ・ペア間の距離の推定値を提供することができる場合には、選択プロセスにおいて有用なものとなりうる。直接的な推定を行うことができないコンピュータ・ペア間のネットワーク距離を推測する（またはヒューリスティックな推定を行う）ことが可能である。方策の１つは、その経路上の直接的な各接続の距離が測定されたネットワーク距離でになるように、２つのコンピュータを比較する１つまたは複数の中間ノードを含む経路を見つけるものである。経路全体にわたるそれらの距離の適切な組合せ（例えば合計）を、その経路のエンド・ポイント間の距離の尺度と見なすことができる。エンド・ポイント間のすべての可能な経路（またはそれらの代表サンプル）を考慮に入れ、その経路の中で最短の経路を考慮に入れると、その最短経路の距離を、２つのエンド・ポイント間の距離の妥当な推定値と見なすことができる。

統計的分析
Ｃ-ノードおよびＳ-ノードは、それらが伝搬するトランザクションのダウンロード時間や、その他の通信性能の態様を監視および記録することができる。したがって、時間の経過とともに、これらのノードは以前のトランザクションの特性を記録する履歴データベースを構築することができ、関連するクライアント、関連するサーバに従って、またはクライアントとサーバ両方の組合せによってこのデータベースを分類することができる。この履歴データを使用して標準的な統計的技術および／または機械学習技術を用いることにより、そのデータを要約し、かつ将来の性能を予測することが可能なモデルを構築することができる。例えば、このモデルの一態様は、特定クライアントと特定Ｃ-ノード間の平均通信時間を推定するものである。この推定値は、マッピング・ソフトウェアがそのクライアントとそのＣ-ノード間の距離の尺度として使用することができる。単一のクライアントと複数のＣ-ノード間にこのような推定値が存在する場合、マッピング・デバイスは、最も低い推定平均通信時間（またはダウンロード時間）を有するＣ-ノードを選択することにより、複数のＣ-ノードの中からそのクライアントのためのＣ-ノードを選び出すことができる。

上記で説明したような手段を使用することにより、マッピング・デバイスは、特定のコンピュータ、ネットワーク、またはルータなどのネットワーク・デバイスと、本発明が使用するノード（Ｃ-ノードおよび／またはＳ-ノード）との間の現在のインターネット近接度モデルを保持することができる。あるクライアントからの要求を受信すると、セレクタまたは選択プロセスはこのモデルを使用して、そのクライアントに近いＣ-ノードを選択することができる。セレクタにはクライアントの名前またはＩＰアドレスを告げることもでき、その名前またはＩＰアドレスがそのデバイスに知られている名前またはアドレスの中にある場合には、Ｃ-ノードのリストを調べて最も近いノードを選ぶことができる。クライアントがセレクタに直接知られていない場合、セレクタは代わりにそのクライアントに近いと思われる知られているコンピュータを選択し、そしてその選択した知られているコンピュータに近い利用可能なＣ-ノードを選ぶことができる。このような知られているコンピュータを選択する方法はいくつかあり、以下で２つの例を挙げる。

最初に、セレクタにクライアントのドメイン名を提供すると、セレクタは、それと同じトップレベル・ドメインを共有する知られているコンピュータを選ぶことができる。例えば、クライアント「ｓｉｔｅ１．ｃｏ．ｎｚ」はニュージーランドにあると思われるので、知られているコンピュータ「ｓｉｔｅ２．ｃｏ．ｎｚ」が利用可能であればそれを使用することが理にかなうものと思われる。第２に、例えば下記のようにＩＰアドレスの分析に基づいて、知られている近接のコンピュータを見つけようとすることができる。バージョン４のＩＰアドレスは、３２ビットの数として表される。ＩＰアドレスの範囲は、アドレス中の高順位（最上位）のビットによって特定のネットワーク（例えばある建物内の特定イーサネット（登録商標））が決まり、低順位ビットによって、識別されるそのネットワーク上の特定マシンまたはホストが決まるような構造になっている。この構造は、例えばサブネットワークの存在や、固定数のビットが揃わないとネットワーク部分とホスト部分との区分が行われないという事実によりさらに複雑になる。ただし、通例は、２つのマシンが同じネットワークまたはサブネットワークに接続されている場合、最も一般的に使用されるネットワークの尺度から見るとそれらのマシンは互いに非常に近いと言える。したがって、クライアントのＩＰと知られているコンピュータのＩＰアドレスを比較して、次いでネットワーク構造の知識を使用して、クライアントと同じネットワークにある知られているコンピュータを選び出すことが可能である。

上記の手法をさらに迅速にし、やや大まかにしたバージョンでは、ネットワーク番号はアドレスの高順位ビットによって定義されるという事実を使用する。クライアントのアドレスとの「最良の一致」である知られているアドレスを見つけるために、クライアントと知られているコンピュータの両方について同じように可能な限り多くの連続した高順位ビットを有するという意味で、クライアントのＩＰアドレスと知られているコンピュータのＩＰアドレスを比較することができる。このヒューリスティックな技術では、しばしば、クライアントと同じネットワークまたはサブネットワーク上の知られているコンピュータを選ぶことができる。一般に、セレクタを使用して指定クライアントに近いＣ-ノード（またはクライアントへの近接度の代わりに、あるいはそれに加えて性能に関連する他の基準を満たすＣ-ノード）を見つける、または推測することの問題点は、マッピング・デバイスまたはマッピング・システムが使用する特定の手段に左右される。
本発明は、そのような手段のいずれと併せても使用することができる。

インターネット上のコンピュータ間のネットワーク距離の測定は、事例によっては良好に行うのが難しいタスクになりうることが認識される。それでもなお、本発明は、マッピング・デバイスが非常に大雑把な、あるいはヒューリスティックな方法を使用して距離および他の関連する要因を推定する場合であっても機能する。

第２の重要な実際的問題は、例えばクライアント名もそのＩＰアドレスも入手することができないなど、事例によっては、セレクタにクライアントの正確な識別を提供することができない場合があることである。このような事例が発生する重要なケースは、ＤＮＳのリダイレクト手段に伴うものである。現在のＤＮＳシステムは本質的に階層的であり、すなわち応答を見つけるために１つのＤＮＳサーバが別のＤＮＳサーバに問い合わせを行うことがある。ＤＮＳリダイレクトの説明中で指摘したような特別に構成されたＤＮＳサーバが要求を受信する場合、その要求は、その要求を開始したクライアントから直接来たものではなく、クライアントによって接触され、その要求を専用サーバに中継した「ローカル」ＤＮＳサーバから来たものである可能性が高い。この場合、専用のＤＮＳサーバは、ローカルＤＮＳサーバのＩＰアドレスだけを見ることができ、クライアントのＩＰアドレスは見ることができない。この特定の事例では、ローカルＤＮＳサーバがクライアントにかなり近いと考えられるので、セレクタにはクライアントのＩＰアドレスではなくローカルＤＮＳサーバのＩＰアドレスを提供することが理にかなっている。この例は、クライアントの識別の代わりに、クライアントに近いと推測するのが妥当な別のコンピュータの識別を使用するものであり、クライアントの識別をセレクタに提供するという問題に対する１つの可能な一般的対応を例示している。

配置の方法に関係なく、マッピング・デバイスおよびセレクタは、Ｃ-ノードとクライアント間のネットワーク近接度の推定値以外に他の要因も考慮に入れることができる。その要因のいくつかの例はすでに述べた。具体的には、そのような要因の重要な例には、各Ｃ-ノードとターゲット・サーバ間、または各Ｃ-ノードと、ターゲット・サーバへのトラフィックを処理する可能性のあるＳ-ノード間のネットワーク近接度の推定値が含まれる。この根拠の１つは、そのような推定値をＣ-ノードからクライアントへの距離と適切に組み合わせて使用することにより、クライアントとサーバ間の通信の総コストを推定することができ、また後者の総計数値は最少にすることが望ましいと思われることである。これは、以下のより具体的な例によって例証することができる。

先に述べたように、帯域幅と待ち時間の数値の形によるＣ-ノードからクライアントまでの距離の推定値は、「ｐｉｎｇ」を行って待ち時間とタイミング伝送時間を測定することにより帯域幅を測定するなどの標準的技術によって得ることができる。待ち時間および帯域幅の数値を、ＨＴＴＰプロトコルを介して一般的なウェブ・ページをダウンロードするのにかかる時間の推定値に変換するには、知られる統計的モデルがある。クライアントとＣ-ノード間の通信がどのようにクライアントとサーバ間の総ダウンロード時間に寄与するかを推定することが可能である。第２に、所与のサーバに対する要求の処理にかかる時間を直接測定するソフトウェアと、その履歴データを使用してＣ-ノードとサーバ間（またはこの代わりに、しかし同様にＣ-ノードとＳ-ノード間）の平均的なダウンロード時間への寄与を推定する平均値を生成する他のソフトウェアを、Ｃ-ノードとＳ-ノードに配置することができる。最後に、ダウンロード時間の２つの推定値を加算して、トランザクション全体についてのダウンロード時間の推定値を得ることができる。あるいは第２の推定の１未満の倍数に以前の推定値を加えることができ、この場合、倍数は、Ｃ-ノードがコンテンツをキャッシュからクライアントに配信することができ、したがって追加的な通信を必要としない時間の分数になるように選択される。この例の変形例は、同様の技術を使用して、クライアントからＣ-ノード、Ｃ-ノードからＳ-ノード、およびＳ-ノードからサーバへの、総ダウンロード時間の３つの成分を推定し、それらを組み合わせるものである。

上記のマッピング法と、以下のマッピングおよび選択の説明は、例えば専用のマッピング・デバイスによってＣ-ノードを明示的に選択する場合を扱う。そうした明示的な選択手段に代えて使用することが可能な第２の技術は、ＩＰルータを使用して暗黙的なマッピングおよび選択を行うものである。ＩＰルータは、通信の発信元と宛先の間の最短経路を見つけることを試みるアルゴリズムと技術を含んでいる。ルーティング技術は、一般に、各ＩＰアドレスは固有のマシンに対応するという前提で設計される。しかし、同じＩＰアドレスを多数のマシンに与えることが可能であり、非常に綿密に操作した場合既存のルーティング・アルゴリズムは、特定アドレスを持つ最も近いマシンにトラフィックを送信する傾向がある。この概念は、すべてのＣ-ノード（またはすべてのＣ-ノードのサブセット）に同じＩＰアドレスを与える場合に本発明で使用することができる。この概念をウェブ・プロキシまたは透過なネットワーク・インターセプト以外の上記のリダイレクト手段のうち任意のものと組み合わせて使用した場合、サーバから本発明のＣ-ノードに向けてトラフィックをリダイレクトすれば十分であるが、リダイレクトは共通のＩＰアドレスに向けられ、どのＣ-ノードが最もクライアントに近いかを明示的に選択する必要がないということになる。既存のルーティング・インフラストラクチャはノード・セレクタとして機能することができ、自動的にトラフィックを選択して近いＣ-ノードへと向ける。この技術は「エニーキャスト」と呼ばれることがある。

一例として、図２および図３との関連で、上記のＤＮＳリダイレクトの１実施形態をさらに説明する。図のＤＮＳリダイレクトのバージョンでは、カスタム・ソフトウェアを実行する専用のＤＮＳサーバがインターネット中に位置し、ＤＮＳシステム自体は、サーバ名を解決する（すなわち、少なくとも１つの対応するＩＰアドレスを見つける）ための要求がそのようなカスタマイズされたサーバに「委ね」られるような構成にする。ＤＮＳシステムは、相互に通信しそれらの間で要求を渡し合う多数の異なるサーバを含んだ、複雑なインターネット規模の分散データベースである。この例は、ＤＮＳシステムをリダイレクト手段として使用する唯一の方式として解釈すべきではない。例えば、コンテンツ配信産業では階層的に構成したカスタム・サーバのセットを配置して、どの１つの要求もそれらサーバの連携した動作だけによって解決するのが一般的である。ただしこの例では、ただ１つの上記のような専用サーバを用いて実施することのできる解決法を示す。

図２は、そのような専用のＤＮＳサーバが、サーバ名をＩＰアドレスに変換する（すなわちサーバ名を解決する）要求を受け取った際にとるステップの概要を示す。この要求は、標準的なＤＮＳプロトコルを使用して受信される。解決プロセスは、要求を受信するステップ２００から開始し、ここで要求元のＩＰアドレスも取り込み、記録する。（これはクライアントのアドレスと思われるが、上記のように、しばしばクライアントにとってより「ローカル」な別のＤＮＳサーバのアドレスであることもある。）ステップ２０１で、専用のＤＮＳサーバはセレクタに問い合わせを送信し、要求元のＩＰアドレスとサーバ名の両方を提供する。ステップ２０２で、ＤＮＳサーバはセレクタから応答を受信するが、これは１つのＣ-ノードの名前である。専用ＤＮＳサーバは、図３に示すようなローカル・データベース３００を調べるが、このデータベースは、Ｃ-ノード名３０２とサーバ名３０１のペア方式の各組合せと、その組合せに一意のＩＰアドレス３０３を関連付ける。ステップ２０３で、ＤＮＳサーバはこのデータベース３００を使用して、マッピング・デバイスから提供されたＣ-ノード名と、元の要求中で与えられるサーバ名の組合せに対応するＩＰアドレスを選択する。この方式により、どのサーバ名が要求されたかに応じて、いくつかの異なるＩＰアドレスの１つを使用してＣ-ノードを指し示すことができる。これを行う理由はこの後説明する。次いでステップ２０４で、規格化されたＤＮＳプロトコルを使用して選択したＩＰアドレスを要求元に戻す。

一例として、図４および図５を使用して、セレクタの特定の一実施形態をさらに説明する。図４は、セレクタが、ステップ４００でＩＰアドレスとサーバ名を含んだ要求を受信し、したがって適切なＣ-ノードを指名する役割を負う際にとるステップの概要を表している。この例証では、Ｃ-ノード選択の基準は、推定される総ダウンロード時間を最少にすることであるとする。セレクタは、図５に示すデータベース５００のような記憶されたテーブルまたはデータベースを利用する。このデータベース５００は、ＩＰアドレス５０１、Ｃ-ノード名５０２、およびサーバ名５０３を含む３要素の組合せ間の関連を、対応する推定ダウンロード時間とともに記録する。推定ダウンロード時間は、指示されたＣ-ノードを使用して本発明によって要求を処理する場合の、指示されたＩＰアドレスのクライアントと指示されたサーバ間の標準的なウェブ・トランザクションについての推定時間である。

上記のデータベースのエントリは手動で追加することができ、推定ダウンロード時間は専門家の最適な判断に基づくことができる。あるいは、推定ダウンロード時間は、以前のトランザクションにかかった時間の記録などのデータや、帯域幅および待ち時間などのネットワーク測定データに基づくことができ、また上記の技術を使用して計算してもよい。この例では、各個々のＣ-ノードが、それに関連するすべての推定ダウンロード時間を編集し、それらの推定値を［ＩＰアドレス、Ｃ-ノード名、サーバ名、推定ダウンロード時間］の形の４要素の形で周期的にマッピング・デバイスに通信する役割を負うケースを考察する。セレクタの単純なリッスン・プロセスでそのようなメッセージが受信され、セレクタはメッセージを受信すると、受け取ったメッセージの内容を使用してデータベース５００を更新する。この例では、データベース５００を更新するセレクタのこのリッスン・プロセスは、各Ｃ-ノードに課される推定プロセスの動作（図６。以下で説明）と併せて、分散型のマッピング・プロセスと見なすことができる。これは、これらのプロセスがまとまって、選択プロセスで使用されるデータベース５００を作成し、正確に保持するためである。

図４は、測定および推定のプロセス、あるいはすぐ上記で説明した単純なリッスン・プロセスを詳細に扱うものではなく、セレクタがこの情報を集めるとそれをどのように使用するかを示すものである。データベース５００が、あらゆる個々のＩＰアドレスに固有の情報を含むことは通例実際的ではないので、マッピング・デバイスはまずステップ４０１で、提供されたＩＰアドレスが、対応する情報が存在するＩＰアドレスの１つであるかどうかを調べる。そのようなＩＰアドレスではない場合、デバイスはステップ４０２で上記の技術を使用して、対応する情報が知られ、提供されたＩＰアドレスに可能な限り近く一致するＩＰアドレスを選び出す。この場合ステップ４０３で、元の提供されたＩＰアドレスを、選ばれた「最良の」一致であるＩＰアドレスに置き換える。ステップ４０４でデータベース５００を再度使用して、提供されたＩＰアドレスおよび提供されたサーバ名が組合せで出現するすべてのエントリの集合を識別する。ステップ４０５で、見つけたばかりの行の集合から最少の推定ダウンロード時間を有する１行を選択する。ステップ４０６で、デバイスは、選択した行内に現れるＣ-ノードの名前を抽出し、その名前を元の要求に対する応答として戻す。

先の例の延長として、図６はＣ-ノードとともに配置することのできるソフトウェア・プロセスの一例を示す。このソフトウェア・プロセスは恐らくはＣ-ノードと同じコンピュータで実行され、ダウンロード時間を推定して、上記のようにその推定値をセレクタのリッスン・プロセスに通信する。図６に示すこのプロセスはＣ-ノードが作動状態にある限りはループで実行されるが、説明するステップを反復する前に、ステップ６００で設定可能な時間である「ｋ」分の間停止する。ステップ６０１でプロセスは単純なローカル・データベース（図示せず）を調べて、ＩＰアドレスの固定リストを受け取る。手動で入力することが可能なこれらのＩＰアドレスは、「代表的な」クライアント・コンピュータの集合であるはずである。含めるべき基準は、これらのコンピュータが標準的な「ｐｉｎｇ」コマンドに応答することである。「ｐｉｎｇ」コマンドは、「ＵＮＩＸ（登録商標）」または「Ｗｉｎｄｏｗｓ（登録商標）」オペレーティング・システムの各種バージョンを実行する大半のコンピュータで見られるもので、パケットがクライアントからコンピュータまで伝搬し、戻ってくる時間を測定するのに使用される。プロセスは、リスト中の各ＩＰアドレスを設定可能な回数である「１」回ｐｉｎｇし、その結果を平均することにより、各ＩＰアドレスとＣ-ノード自体の間の待ち時間を推定する（ステップ６０２）。ステップ６０３で、プロセスは図７に示す第２のデータベース７００を調べて、そのＣ-ノードに知られるサーバのリストを取り出す。次いでステップ６０４でそのサーバそれぞれについて、プロセスは、テストのために使用される固定ウェブ・オブジェクトをサーバから取り出すことを試み、応答が到着するまでの時間を測定する。このテスト・オブジェクトは、「ｔｅｓｔ．ｈｔｍｌ」などの固定ＵＲＬを使用して指示することができる。このテスト・オブジェクトは、指定のサーバから直接取り出しても、あるいは中間のＳ-ノードを使用してフェッチしてもよい。いずれの場合もそのテストをそれぞれ設定可能な回数である「ｍ」回にわたって行い、各サーバについての結果を平均してＣ-ノードとサーバ間のダウンロード時間の推定値を求める。プロセスは次いで、検討したばかりのリスト中のＩＰアドレスとサーバの各組合せを検討し、各組合せに対して、ＩＰアドレスとＣ-ノード間の推定ｐｉｎｇ時間と、Ｃ-ノードとサーバ間の推定ダウンロード時間とを組み合わせる式を適用する（ステップ６０５）。使用することが可能なそのような式の一例は、「ｐ」×推定ｐｉｎｇ時間＋「ｑ」×推定ダウンロード時間であり、「ｐ」および「ｑ」は手動で調整できる設定可能な数値パラメータである。最後に、プロセスは得たばかりの結果のリストを、［ＩＰアドレス、Ｃ-ノード名、サーバ名、推定ダウンロード時間］の４要素の形でセレクタのリッスン・プロセスに通信する。

Ｃ-ノードの動作
以下の説明では本発明の他の態様の説明に戻り、リダイレクト手段を用いてクライアントのウェブ要求がいずれかのＣ-ノードに通信されていると想定する。

本発明は、Ｃ-ノード内に常駐する専用のソフトウェアおよび／またはハードウェアを含む。Ｃ-ノードがクライアントからウェブ要求を受信するとき、ノードのソフトウェアはその要求をインターセプトする。Ｃ-ノードは、規格化されたウェブ通信プロトコルを理解するのに必要なソフトウェアを含み、現在このプロトコルは大半の場合ＨＴＴＰ ｏｖｅｒ ＴＣＰの各種バージョンであるが、本発明は現在および将来使用される他のプロトコルを包含する。例えば、ワイヤレス・アプリケーション・プロトコル（ＷＡＰ）はまもなく、クライアントがワイヤレス電話機、またはワイヤレス・リンクを介して通信するその他のデバイスである場合に使用される標準通信プロトコルになると思われる。

このような方式により、Ｃ-ノードはクライアントから受信する要求をインタープリトすることができ、また要求が受信されたことをクライアントに知らせるために、正しいプロトコルを使用して確認メッセージをクライアントに送信することもできる。

Ｃ-ノードの残りのソフトウェアは、要求されるコンテンツがすでにＣ-ノードにない場合はそれを入手し、クライアントが対応できる任意の規格化プロトコルを使用して応答をクライアントに送り返すという目的で設計される。このプロトコルは、通例は、元の要求を通信するのにクライアントが使用したのと同じプロトコルである。

Ｃ-ノードは、クライアントの要求を満たすのに必要なコンテンツを含んだウェブ・サーバまたはウェブ・サイトの識別を判定する手段を含む。これを実現するには、以下の２つの例を含む各種の手段がある。

ＩＰアドレスの分類
Ｃ-ノードは、複数のインターネット・プロトコル・アドレスおよびインターネット・ポート番号を有する。Ｃ-ノードが、それとの通信（Ｃ-ノード自体と要求の発信者両方について）に使用されたポートとＩＰアドレスを知ることはインターネット・プロトコルの性質である。Ｃ-ノードは、例えばデータベース中に、ＩＰアドレス（および／またはポート）と、コンテンツを含む実際のウェブ・サーバとのマッピングを保持することができる。例えば、本発明のリダイレクト段階でＤＮＳダイレクションを使用する場合、ＤＮＳは、問い合わされたサーバ名に応じて異なるＩＰアドレスを戻すように構成することができる。例を挙げると、「ｗｗｗ．ｓｉｔｅ．ｃｏｍ」に対する問い合わせには、アドレス１２３．４５．６７．８９が戻され、「ｗｗｗ．ｏｔｈｅｒｓｉｔｅ．ｃｏｍ」に対してはアドレス１５６．７８．９０．１２が戻される。両方のアドレスが同じＣ-ノードの代替アドレスである場合でも、そのＣ-ノードはしたがって元の要求が「ｓｉｔｅ」についてであったか「ｏｔｈｅｒｓｉｔｅ」についてであったかを（どのアドレスに接続されたかに応じて）区別することができる。

この方法では、Ｃ-ノードの特定のＩＰアドレスとあるサーバ名との関連は静的であっても動的であってもよい。前者の場合、関連はめったに変化せず、固定することができる（例えば手動で）。後者の場合、関連は比較的頻繁に変化し、そのサーバに対する要求が現在Ｃ-ノードに到着している場合にのみサーバに対してＩＰアドレスが割り当てられる。動的な割り当てでは、どのサーバがＣ-ノードを通じた要求の対象であるか（またはまもなく対象となる可能性が高いか）を判断するための綿密な管理が必要となり、またＤＮＳシステムとＣ-ノードが各ＩＰアドレスの現在の意味について一致するように、ＤＮＳシステムとの連携を慎重かつ密に同期させることも必要になる。ただし、動的な割り当て方式の利点は、必要とされるＩＰアドレスが少なくて済むことであると言える。

ＨＴＴＰプロトコル情報
ある状況ではサーバの名前がＨＴＴＰヘッダ情報に含まれ、Ｃ-ノードはこれを読み取ってサーバ名を判断することができる。ＨＴＴＰプロトコルは少なくとも次の３つの状況においてこの情報を提供する。ウェブ・プロキシ・リダイレクトの場合と同様にＣ-ノードをプロキシとして使用する場合。クライアントがＨＴＴＰバージョン１．１を使用して通信する場合。および、大半の場合は、ＨＴＴＰリダイレクトを使用してＨＴＴＰ要求をＣ-ノードにリダイレクトする場合。

Ｃ-ノードは任意選択で、ウェブ・ページや画像ファイルなどのウェブ・コンテンツのストアであるキャシュを使用する。このキャッシュ内の内容を使用してウェブ要求を満たすことができる場合は、Ｃ-ノードはクライアントに対するその応答を形成する際にキャッシュ内のコンテンツを使用することができる。このようなキャッシュの維持には多くの方策があり、そのいずれを採用してよい。キャッシュは、例えばローカルのハード・ディスク上やメモリ中に記憶するなど、Ｃ-ノードまたはＣ-ノードを含むデバイスの一部として含めることができる。ただし、キャッシュがＣ-ノードにとってローカルである必要はない。コンピュータまたはノードが他のキャッシング・ノードに問い合わせて、それらのノードが要求されるコンテンツを提供できるかどうかを調べる、知られた方策がある。Ｃ-ノードはそのような手段を用いて、（下記で説明する機構を使用して）サーバ自体に接触する、またはキャッシュへの接触を試みる方が効率的であるかどうかを判断することもできる。ただし、以下の説明では、Ｃ-ノードがそのキャッシュ（またはいずれの近接にあるキャッシュ）では要求を完全には満たせなかったものとする。

そのような手段を使用して要求されるコンテンツの最終的な発信元（すなわちサーバ）を判断すると、Ｃ-ノードは、そのサーバに近いことが知られているＳ-ノードを確定する。ただし先に述べたように、Ｓ-ノードの選択では、Ｓ-ノードとサーバ間の近接度に加えて、あるいはその代わりに、他の要因、具体的には性能に関連する要因を考慮に入れることもできる。

本発明のＳ-ノードは、インターネット中の選択された位置にも置かれる。具体的には、この位置は、ウェブ・サーバと同じ構内またはサブネットワーク上、商業的なウェブ・サーバの「コロケーション（ｃｏ-ｌｏｃａｔｉｏｎ）」施設内、ＩＳＰ内、インターネット・バックボーン・ネットワーク上の位置、あるいはバックボーン・ピアリング・ポイントなどである。また、Ｓ-ノードの機能を実行するプログラムをウェブ・サーバ自体と同じ物理ハードウェア上で実行することも可能であり、さらにはウェブ・サーバ・ソフトウェアと一体化することも可能である。

Ｃ-ノードは、指定されたウェブ・サーバに近いＳ-ノードを見つける手段を使用する。この手段の例には以下のものがある。最初に、Ｃ-ノードは、例えばデータベースに、サーバ名と適切なＳ-ノードの名前またはアドレスのマッピングを記憶することができる。あるいはＣ-ノードは、可能性としては上記のマッピング法および関連する技術などの技術を使用して、ネットワーク状態を監視し、それによりＣ-ノードについて上記のタイプのインターネット近接度「マップ」を構築するソフトウェアまたはシステムを含むことができる。この場合、Ｃ-ノードがすべての候補Ｓ-ノードのリストを有し、サーバ自体のアドレスを知っている場合は、そのサーバに近いＳ-ノードを選ぶことができる。データベースを使用するが、ネットワーク監視およびマッピングの結果により周期的にそのデータベースを更新するような、これらの手段の組合せを使用することができる。また、別々のマシンまたはシステムがサーバ名からＳ-ノードの名前（またはアドレス）へのマッピングを保持する役目を負い、Ｃ-ノードがそれらマシンまたは
システムの１つに問い合わせることも可能である。この問い合わせは、上記のＤＮＳリダイレクトに類似のＤＮＳを使用して行っても、何らかの他のプロトコルによって行ってもよい。さらに別の可能性は、各Ｓ-ノードがそれに近いサーバの最新リストを保持し、Ｃ-ノードがＳ-ノードとサーバの関連のデータベースを保持することができるようにＳ-ノードが周期的にこのリストを各Ｃ-ノードに通信させるものである。あるいは、専用のシステムが現在の関連セットを保持し、そのリストを周期的に各Ｃ-ノードに通信させることもできる。使用することが可能な多数の他の手段があり、具体的には、Ｃ-ノードの選択に使用できる任意のリダイレクト手段がＳ-ノードも選択するように当業者が容易に適合することができる。

本発明の異なるバージョンでは、少なくとも１つのＳ-ノードが特定サーバに向けられるすべてのトラフィックをインターセプトするようにＳ-ノードを配置する。例えば、Ｓ-ノードは、サーバと同じ物理デバイス内に配置しても、サーバのローカルな物理ネットワーク上のゲートウェイ・コンピュータ上に配置しても、サーバのＩＳＰに配置しても、あるいは同じサーバ・ソフトウェアと一体化してもよい。Ｓ-ノードのプロセスがサーバと同じマシン上にある場合、Ｓ-ノード・プロセスとサーバ間の通信は外部のネットワーク通信を一切必要とせず、代わりにそのマシン内部の論理通信経路からなる。１台のマシンにおける２つの個別のプロセス間のこのような論理接続は当業者にはよく知られるものであり、しばしば「ループバック」接続と呼ばれる。外部ネットワーク上を伝搬しないことの他にも、ループバック接続を使用した２つのプロセス間の通信は、異なるマシン上のプロセス間の通常のネットワーク通信にその他の点でも類似しており、同じプロトコルを使用することができる。Ｓ-ノードの機能をサーバ・ソフトウェアと一体化した場合は、ループバック接続の必要性も排除することができる。この場合、一体化ソフトウェア・プロセスのＳ-ノード部分とソフトウェア・プロセスのサーバ部分間の通信は単に、Ｓ-ノード部分が、サーバ部分が予期する形態、すなわちサーバ部分が予期するプロトコル形態と互換性がある形態でデータを作成し、作成したデータをサーバ部分に提供するステップを参照する。

Ｓ-ノードがインターセプタである場合、またはサーバと同じ位置にある場合、Ｃ-ノードはそのサーバに近いＳ-ノードのアドレスを識別する必要がない。Ｃ-ノードは、Ｓ-ノードに受信してもらいたい通信をいずれもそのサーバのネットワーク・アドレスに直接向けることができる。Ｓ-ノードは、そのサーバへ向かうすべてのトラフィックをインターセプトして調べる能力を有し、トラフィックがＣ-ノードからである場合Ｓ-ノードは特別な処理のためにそのトラフィックをインターセプトすることができるが、その他の場合はトラフィックを変化させずにサーバに渡す。この変形例では、Ｃ-ノードがサーバのネットワーク・アドレスを使用するにもかかわらず、実際にＣ-ノードからの通信はＳ-ノードでインターセプトされる。

明示的な選択または暗黙的なインターセプトの保証を通じてＳ-ノードを選ぶと、Ｃ-ノードは、専用のプロトコルまたはそのようなプロトコルの組合せを使用して、クライアントの要求を選択したＳ-ノードに通信する。以下では、このプロトコルをノード間プロトコルと呼ぶ。このプロトコルの目的は、より高い性能を提供することである。これは、コストの低減、帯域幅消費の低減、待ち時間の短縮、セキュリティの向上、およびその他の同様の利点、またはこれらの組合せを意味する。

Ｃ-ノードの例
一例として、図３、７、８、および９を使用してＣ-ノードの一実施形態をさらに説明する。図８は、ステップ８００でクライアントからのＨＴＴＰ要求を受信した際にＣ-ノードがとるステップの概要を表す。クライアントがＣ-ノードとの通信に使用することのできるＩＰアドレスは複数ある場合もある。しかし、一般的なネットワーク技術を使用して、マシンとの接触に使用されたＩＰアドレスを識別し記録することが可能であり、Ｃ-ノードは同じくステップ８００でこれを行う。Ｃ-ノードは、次いでその要求が対象とするサーバの名前を再構成しなければならない。Ｃ-ノードはステップ８０１でＨＴＴＰ要求のヘッダを調べ、上記でＨＴＴＰプロトコル情報の技術に関して述べたようにヘッダにサーバ名が含まれている場合、Ｃ-ノードはステップ８０２でその名前をヘッダから抽出する。その他の場合、Ｃ-ノードはステップ８０３で上記のようなＩＰアドレス分類を行う。具体的には、この場合には、Ｃ-ノードは、ＩＰアドレスとサーバ名間の関連を含んだ、図９のデータベース９００のようなローカル・テーブルまたはデータベースを調べる。このテーブルは上記のように別のプロセスによって周期的に維持することができ、この例では、専用ＤＮＳサーバが使用できる図３のデータベース３００などのデータベースと連携させ、整合した状態に保たなければならない。

Ｃ-ノードはステップ８０４でそのキャッシュを調べて、ステップ８１０でクライアントに直ちに戻すことのできる、要求されるオブジェクトの適切に新しいコピーがキャッシュに保持されているかどうかを調べる。キャッシングによって多くの知られる精製と付加が可能になることが認識され、それをここで使用することもできるが、この例証では単純なキャッシュ実装のみを考察する。キャッシュを使用して要求に応えられない場合、Ｃ-ノードは図７に示すデータベース７００などのテーブルまたはデータベースを調べる。このテーブルは、各サーバ名と、Ｓ-ノード、すなわちそのサーバを対象とする要求を送信することのできるＳ-ノードとの関連を記憶する。このようなテーブルとそれを保持する手段については先に説明した。ステップ８０５で、Ｃ-ノードはデータベース７００を使用して、先にステップ８０２およびステップ８０３で見つけたサーバ名に対応するＳ-ノードのＩＰアドレスを抽出する。ステップ８０６で、Ｃ-ノードは、例えばｇｚｉｐとして知られる標準的な圧縮アルゴリズムなどの圧縮手段を使用して要求を圧縮することができる。同じくステップ８０６で、Ｃ-ノードは、まだない場合にはサーバ名を要求ヘッダに付加する。ステップ８０７で、Ｃ-ノードは、この節の下記で説明する１つまたは複数のノード間プロトコルを使用して、選択されたＳ-ノードに要求を送信する。具体的には、規格化されているがめったに使用されないプロトコルであるトランザクション用のＴＣＰ（Ｔ／ＴＣＰ）を用いることができる。Ｃ-ノードは、ステップ８０８で、この場合もＴ／ＴＣＰ
などの１つまたは複数のノード間プロトコルを使用してＳ-ノードから応答を受信するまで待機する。Ｃ-ノードは、応答が圧縮形態で到着した場合には応答の圧縮を解除することもできる。この応答はその後ステップ８０９でＣ-ノードのキャッシュに記憶することができる。応答はまたステップ８１０でクライアントに戻して、トランザクションを完了する。

Ｓ-ノードの動作
Ｓ-ノードは、ノード間プロトコルを使用してＣ-ノードから要求を受信する。
Ｓ-ノード上の他のソフトウェアは、要求されるコンテンツがまだＳ-ノードにない場合にはそれをサーバから入手し、いずれの場合も応答をＣ-ノードに送り返すという目的で設計する。

Ｓ-ノードは、オプションのキャッシュも含むことができる。そのキャッシュ内のコンテンツを使用して完全または部分的にウェブ要求を満たすことができる場合、Ｓ-ノードはＣ-ノードに対するその応答を形成する際にキャッシュ内のコンテンツを使用することができる。

その他の場合、Ｓ-ノードはサーバと通信してコンテンツを要求する。この通信は、サーバが使用するように設計されている規格化プロトコルを使用して行うことができ、現在このプロトコルは一般にいずれかのバージョンのＨＴＴＰ ｏｖｅｒ ＴＣＰである。

このように要求されるコンテンツ、または元の要求に対するその他の適切な応答を入手すると、Ｓ-ノードは、この場合もより性能の向上のために設計された何らかのノード間プロトコルまたはそのようなプロトコルの組合せを使用して、その応答をＣ-ノードに送り返す。

Ｃ-ノードは次いで、その応答を元の要求元クライアントに転送する。Ｃ-ノードは、応答を送信する前にＳ-ノードから完全な応答を受信するのを待つように
構成することができ、あるいは、Ｃ-ノードが応答全体を受信する前であっても応答の第１の部分がクライアントに送信されるように、Ｓ-ノードからの応答が到着すると情報を送信するように構成することもできる。この応答は、クライアントが受け入れることのできる標準的プロトコルを使用して送信され、このプロトコルは現在一般にはＨＴＴＰ ｏｖｅｒ ＴＣＰの１バージョンである。

Ｓ-ノードの例
一例として、図１０を使用してＳ-ノードの特定の一実施形態をさらに説明する。図１０は、ステップ９５０でＣ-ノードから要求を受信した際にＳ-ノードがとるステップの概要を表す。必要な場合はステップ９５１で要求の圧縮を解除し、次いでステップ９５２で要求ヘッダからサーバ名を抽出する。ステップ９５３でＳ-ノードはそのキャッシュを調べて、直ちにＣ-ノードに戻すことのできる適切に新しいコピーがキャッシュに保持されているかを調べる。キャッシュ内にオブジェクトが見つからない場合、Ｓ-ノードはステップ９５４でＨＴＴＰを使用してサーバに要求を送信してオブジェクトを取り出す。ステップ９５５で、Ｓ-ノードは、要求したオブジェクトを含む応答をサーバから受信する。ステップ９５６で、Ｓ-ノードは標準的なアルゴリズム「ｇｚｉｐ」などの圧縮手段を使用して応答を圧縮する。次いでステップ９５７で、その応答をそのキャッシュに保存する。次いでステップ９５８で、Ｓ-ノードは例えばＴ／ＴＣＰなどのノード間プロトコルを使用して応答をＣ-ノードに送信する。

ノード間プロトコルおよび技術
ノード間プロトコル、すなわちＣ-ノードとＳ-ノードの間で使用される高性能プロトコルには多くの候補が存在する。ウェブ通信を高速化することが可能ないくつかの技術がすでに知られているが、広くは導入されていない。ただし本発明はそのようなプロトコルの特定のものには限定されず、この分野で継続中の開発を包含する。以下に挙げるのは、そのような１１種類のプロトコルのリストである。

本発明のいくつかの実施形態では、Ｃ-ノードおよびＳ-ノードは、要求に直接応答すること以外の目的で相互に通信するためのソフトウェアを含む。具体的には、Ｓ-ノードは、いつＣ-ノードが特定の応答を必要とするかを事前に予測することを試みるソフトウェアを含むことができ、そのような場合Ｓ-ノードはＣ-ノードからの明示的な要求を受けなくともＣ-ノードに応答を送信することができる。その応答はＣ-ノードのキャッシュ内で利用することが可能になり、これによりＣ-ノードは該当する要求を受信した場合により迅速に応答することができる。下記で述べる高性能ノード間プロトコルの１つ、予測型コンテンツ・プッシュ（Ｐｒｅｄｉｃｔｉｖｅ Ｃｏｎｔｅｎｔ Ｐｕｓｈｉｎｇ）はこの概念を例証するものである。

接続プーリング
通例、ＨＴＴＰ通信を行うことが可能になる前にはＴＣＰ接続を確立する。この接続を確率する際にはオーバーヘッド遅延があり、これは少なくとも１回のラウンドトリップタイム（ＲＴＴ）、すなわちパケットが発信元から宛先まで伝播し、戻ってくるのにかかる時間である。ＴＣＰ接続を確立する際に伴う第２のコストは、輻輳の回避手段として、通例「スロー・スタート」モードと呼ばれる特別なモードで、接続がデータの送信を開始することである。重要な点は、スロー・スタート・モード中は、送信側はさらに多くのデータ（すなわち、さらに多くのパケット）の送信が可能になるまでに、受信者からの「確認」メッセージを待たなければならない場合が多いことである。追加の確認を待つことで生じる遅延は通例ＲＴＴに比例する。「スロー・スタート」という名が示すように、このモード中の性能は低下する場合がある。しばらくすると、具体的には十分なトラフィックが送信されると、接続は通常の動作に達する。

本発明では、Ｃ-ノードとＳ-ノードのペアは、一般的なクライアント／サーバ間のＨＴＴＰ対話の長さよりも長い時間にわたってそれらの間に１つまたは複数のオープンＴＣＰ接続を維持することができる。この接続はそれぞれ、まずあるクライアントのために、次いで別のクライアントのために、以下同様にして再使用することができる。この方式では、ノード間に新たな接続を開かなければならない回数が大幅に節減され、したがって接続確立のオーバーヘッドも節減される。１つまたは複数のオープン接続をより長い時間にわたって維持し、いくつかの短い通信セッションを１つの長継続時間の接続上に多重化する技術は接続プーリングと呼ばれ、他の状況に応用されてきた。

ノード間プロトコルの一部として接続プーリングを使用する場合でも、Ｃ-ノードと通信するクライアントはやはり、Ｃ-ノードへの接続を頻繁に開く必要がある可能性がある。しかし、１つのＣ-ノードが多数のサーバに代わってクライアントにコンテンツを配信することができるので、クライアントが任意の単一サーバへのオープン接続を維持する場合よりも長く、Ｃ-ノードへのその接続をオープンの状態にすることも可能であることが考えられる。

同様に、Ｓ-ノードと通信するサーバはやはりＳ-ノードへの接続を頻繁に開く必要がある可能性がある。しかし、１つのＳ-ノードで多数の異なるクライアントに代わってサーバに対する要求を扱うことができるので、サーバが任意のクライアントへのオープン接続を維持する場合よりも長く、Ｓ-ノードへの接続をオープンにしておくことも可能であると思われる。

Ｃ-ノードとクライアントの間、またはＳ-ノードとサーバの間に頻繁な接続の確立がある場合でも、それらの接続が確立される際のネットワーク距離はどちらの場合も短い距離である可能性が高いことが本発明の重要な特性である。上記で指摘したように、ＴＣＰ接続確立のオーバーヘッドはＲＴＴに依存し、したがってネットワーク距離に依存する。ノード間プロトコルとしての接続プーリングは、Ｃ-ノードとＳ-ノード間の比較的長いネットワーク距離にわたって過度の接続確立を回避し、このような場合に節減が最大になる。接続プーリングは、ＴＣＰ以外の他の接続指向プロトコルと併せても使用できることは理解されよう。

ＴＣＰの修正
ＴＣＰはＨＴＴＰトラフィックの搬送に適さないプロトコルであると本質的に広く考えられているので、全く異なるプロトコルか、またはＴＣＰを修正したバージョンでＨＴＴＰを搬送することに利点があると思われる。本発明のＣ-ノードおよびＳ-ノードは、そうした独自のプロトコルまたは改良型のプロトコルを使用するように設計することができるので、ノード間プロトコルとして、ＴＣＰの代替プロトコル、またはＴＣＰを改良したプロトコルを使用することができる。

例えば、Ｔ／ＴＣＰ（トランザクションＴＣＰ）はＴＣＰに基づく標準プロトコルであるが、このプロトコルでは各ホストで十分な情報を保持して、開始コスト、具体的には３ウェイ・ハンドシェークおよびスロー・スタートを回避または低減する。実際に広くは使用されていないが、Ｔ／ＴＣＰ用のソフトウェアは容易に入手することができ、修正を加えずに本発明でノード間プロトコルとして使用することができる。

当業者には、この他にも多くの知られる改良例および修正例があることが理解されよう。一般に知られる改良例のさらなる例は以下である。選択的な確認を用いるＴＣＰ（ＴＣＰ-ＳＡＣＫ）、ＴＣＰラージ・ウィンドウ（ＴＣＰ-ＬＷ）、輻輳の予測（例えばＴＣＰ Ｖｅｇａｓプロトコルに見られる）、およびＴＣＰスプーフィング。

ＴＣＰまたは他のトランスポート・レベルまたはネットワーク・レベルのプロトコルに対する改良の広い分類には、パケット・サイズの操作が含まれる。ＩＰ（および、したがってＴＣＰやＩＰで搬送される他のプロトコル）などパケットに基づくプロトコルの性能は、送信されるパケットのサイズ、およびそれらを送信するタイミングに依存する。重要な１要因は、性能上の理由から、パケット・サイズを「パス最大転送ユニット（ＰＭＴＵ）」よりも小さく維持することが重要であることである。ＰＭＴＵは、細分化を必要とせずにリンク（すなわちパス）を介して搬送することのできる最大のパケット・サイズとして定義される。

細分化を回避するために、大きめのパケット（それがＰＭＴＵよりも小さくとも）を使用した方がよい場合でも、パケットは小さめのサイズ（すなわちＰＭＴＵ以下）にすることが多い。Ｃ-ノードとＳ-ノード間で、ＰＭＴＵを動的に監視し、パケットを最適なサイズにしようとすることができる。さらに、パケット・サイズの決定には、アプリケーション・レベルのオブジェクト境界を考慮に入れないことが多い。それでも、よりインテリジェントなパケット・サイジングより性能を高めることが可能である。方策の１つは、アプリケーション・レベルのオブジェクト（ウェブ・ページ、ウェブ画像など）が分割される際に横切るパケット境界が可能な限り少なくなるようにパケット・サイズを選択し、複数の小さなオブジェクトを組み合わせて単一のパケットにしようとするものである。

ＴＣＰおよびＩＰに対する改良のさらに別の分類は、パケットのタイミングに関するものである。「バースト性」（狭すぎる間隔でパケットを送信する）を防止し、また送信側がサブリンクの帯域幅を超えてパケットを送信した際に生じるパケット損失も防止することが望ましい。これは、送信側を修正して、経路の伝送プロパティを学習させ、いずれかのサブリンクの容量を（瞬時的であっても）超える可能性のあるパケット・バーストの送信を控えさせることにより実現することができる。あるいは、送信側は、パケット間で計算された時間待機することにより、より均等にパケット間の間隔を空けなければならない。代替法は、受信側がネットワーク状態を監視している場合である。ＴＣＰでは、受信側が送信側に確認メッセージ（ＡＣＫメッセージ）を戻すタイミングが、送信側がそれ以降のパケットを送信するタイミングに影響する。この方式で、受信側は送信側に影響を与えて、より効果的にパケット間の間隔を空けさせることができる。これはＴＣＰ速度制御と呼ぶことがある。当業者には理解されるように、パケット・サイジングおよびパケット・タイミングに関連する他の技術が可能であり、リンクの一端または両端が非標準的なソフトウェアを使用できる場合に特に実用的である。

ＨＴＴＰヘッダの圧縮
ＨＴＴＰプロトコルは、その中に含まれる内容に加えて、要求と応答両方のすべてのメッセージの一部としてヘッダを含む。このヘッダは可読のテキスト形態であり、通例は数百バイトの長さである。ヘッダの態様の多くは非常に予測が容易、または過度に冗長であり、より簡潔な圧縮形態で搬送することが可能である。

例えばヘッダはしばしばコンテンツの長さを記述するフィールドを含み、例えばコンテンツが１２３４５バイト長である場合には「Ｃｏｎｔｅｎｔ-Ｌｅｎｇｔｈ：１２３４５」というテキスト・ラインを含む。これは、単語「Ｃｏｎｔｅｎｔ-Ｌｅｎｇｔｈ」を表すことが知られた短いコードを含め、数１２３４５を５つの個別の文字ではなく２バイトの２進表現で符号化することによって圧縮することができる。

別の例として、ヘッダはしばしば、そこで実行されているソフトウェアのバージョンなど、クライアントまたはサーバの各種の特性を伝えることがある。この情報は、繰り返し送信する必要はない。例えば、Ｃ-ノードが各サーバのソフトウェア・バージョンを記憶している場合、Ｓ-ノードは、それがＣ-ノードに搬送するすべての応答にその情報項目を含める必要はない。代わりに、Ｃ-ノードは、送信側にＨＴＴＰで応答を搬送する直前にＨＴＴＰヘッダの必要なラインを再構成することができる。当業者には理解されるように、これらはＨＴＴＰヘッダを圧縮することが可能な多くの方式の例に過ぎない。ＨＴＴＰヘッダに固有の圧縮技術に加えて、標準的なテキスト圧縮技術も使用することができる。

ノード間プロトコルは、すべてのヘッダ情報が圧縮される修正バージョンのＨＴＴＰを使用することができる。送信されるバイトが少ないので、それに比例して性能が向上する。

ＨＴＴＰコンテンツの圧縮
クライアントに搬送される、Ｓ-ノードからＣ-ノードに送信される応答メッセージは通例ウェブ・コンテンツを含んでいる。このようなコンテンツの大半は、そのコンテンツに適した標準的アルゴリズムを使用して圧縮することができる。
例えばテキストは「ｇｚｉｐ」と呼ばれる標準アルゴリズムを使用して圧縮することが多い。

現在、クライアントとサーバ間の直接の通信では圧縮を使用することがある。
しかし、圧縮を行うことができるのは、クライアントとサーバが各自がそのためのソフトウェアを有する圧縮法をネゴシエートすることができ、またクライアントとサーバの両方が圧縮解除（あるいは個々に圧縮）を行う計算的コストを負担する余裕がある場合だけである。

Ｃ-ノードとＳ-ノードは、改良型の圧縮ソフトウェアを実行するように構成することができ、また等しい圧縮能力を持つように構成することができ、そして圧縮および圧縮解除の速度を上げるためのハードウェアの加速またはその他の技術を使用することができるので、これらのノードは圧縮可能なすべてのウェブ・コンテンツに対してあらゆる場合に圧縮を使用することができる。本発明では、ノード間プロトコルとして改良型のウェブ・コンテンツ圧縮技術を使用することができ、それによりノード間で通信されるトラフィック量を低減し、それに比例して性能を高める。

予測型のプリフェッチ
Ｃ-ノードは、それがすでに受信している要求に基づいて、クライアントが行う可能性の高い将来の要求の予測を試みることができる。この最も重要な事例は、クライアントが埋め込みオブジェクトへの参照を含むＨＴＭＬページを受信する場合に起こる。埋め込みオブジェクトは、小さな画像、ＪａｖａＳｃｒｉｐｔ（登録商標）などのスクリプト言語中の小さなコード部分、ＨＴＭＬスタイル・シート、ＨＴＭＬフレーム中に入れるコンテンツ、その他などである。今日使用されるクライアント・ソフトウェアのほぼ大半は、デフォルトで、ユーザからの承認フィードバックを待たずに直ちに埋め込み画像を要求するように構成されている。元のページを配信するＣ-ノードは、まもなくその埋め込みオブジェクトに対する要求を同じクライアントから受信することを非常に高い確信度で予測することができる。

本発明では、クライアントから受信した要求またはクライアントに戻した応答に基づいて、クライアントが近い将来に要求すると思われる他のウェブ・オブジェクトを予測するソフトウェア・コンポーネントを用いることができる。Ｃ-ノードのキャッシュに記憶されたそのようなオブジェクトについて、Ｃ-ノードは任意選択で対応するＳ-ノードに要求を送信するか、または、そのオブジェクトのサーバに直接要求を送信してキャッシュ内のオブジェクトがまだ新しいかどうかを確認することができる。Ｃ-ノードのキャッシュに記憶されたそのようなオブジェクトの一部またはすべてについて、Ｃ-ノードは対応するＳ-ノードに要求を送信してオブジェクトを取り出すことができる。Ｃ-ノードは、Ｓ-ノードからオブジェクトを受信すると、それまでに要求をクライアントから受信している場合にはそのオブジェクトをクライアントに転送することができ、あるいはそのような要求を予期してオブジェクトをキャッシュに記憶することができる。

予測型のコンテンツ・プッシュ
Ｓ-ノードも、すでにそれが見た要求に基づいて、クライアントが行う可能性の高い将来の要求の予測を試みることができる。本発明ではノード間プロトコルを使用することができ、これによりＳ-ノードは予測した将来の要求に対する応答を入手すると、予測した要求をその応答と併せて元の要求の送信元であるＣ-ノードに送信する。ＨＴＴＰなど標準的なウェブ・プロトコルとの重要な相違点は、このノード間プロトコルでは、Ｃ-ノードがそれに対する明示的な要求を行っていない場合でも、上記のような応答がＳ-ノードからＣ-ノードに「プッシュ」される点である。

Ｃ-ノードは、プッシュされるウェブ・コンテンツのプロトコルを理解し、Ｓ-ノードから送られる要求と応答を受信し、それをそのキャッシュに記憶する。後にクライアントが予測される要求の１つを行うと、Ｃ-ノードはキャッシュ内の応答を使用して直ちに応答することができる。

このノード間プロトコルは、Ｃ-ノードが、要求および応答を数秒またはそれ以下の長さの間、記憶することが可能な非常に小さなキャッシュを有する場合でも有用である。したがって、このプロトコルが必要とするディスク空間やメモリなどのリソースは、従来のキャッシュまたはコンテンツ分配ノードよりも少なくて済む。従来型のキャッシュおよびコンテンツ分配ノードは、そのコンテンツを直接ウェブ・サーバから入手し、ＨＴＴＰのような標準プロトコルにより通信し、明示的な要求がない限りコンテンツをプッシュすることはできない。Ｓ-ノードが近い将来行われる可能性が高い要求を予測し、応答をＣ-ノードにプッシュするとＣ-ノードのキャッシュがポピュレートされるような、ここで述べるプッシュ型のノード間プロトコルの使用は、Ｃ-ノードとＳ-ノードの両方を含む本発明のアーキテクチャを使用して可能になる。

このプロトコルの変形形態をキャッシュの維持に使用することができる。例えばそれ自体のキャッシュ内の１要素が古くなったことに気付くことにより、サーバが何らかのコンテンツを更新したことをＳ-ノードが知ると、Ｓ-ノードは、その変化の通知（およびそのコンテンツの新バージョン）を古くなったバージョンを有するすべてのＣ-ノードにプッシュすることができる。

パイプライン
ウェブ・コンテンツの要求元は、次の要求を送信する前に１つの要求に対する応答が戻ってくるのを待たずに、単一のＴＣＰ接続で複数の要求を次々にサーバに送信することができる。クライアントが応答と要求を一致することができるように、サーバは、要求を受信した際と同じ順序で応答を戻さなければならない。
このプロセスはパイプラインと呼ばれ、著しい性能の利得を提供できることが知られている。現在使用されるウェブ・クライアントでパイプラインをサポートするものはほとんどない。一方、すべてではないがウェブ・サーバの多くはパイプラインをサポートしている。

本発明では、クライアント、サーバ、あるいはその両方がそれ自体ではパイプラインを使用することができない場合でも、Ｃ-ノードとＳ-ノード間の要求および応答をパイプラインするノード間プロトコルを使用することができる。例えば、パイプラインを行わないブラウザでも通例は所与の宛先（サーバやＣ-ノードなど）に対して複数の接続を開き、いくつかの要求を同時に送信している。Ｃ-ノードは、これらの同時の要求を受信し、単一の接続でそれをＳ-ノードにパイプラインすることができる。サーバがパイプライン化された要求を処理することができる場合、Ｓ-ノードはクライアントからの要求を（恐らくは他のクライアントからの要求とともに）そのサーバに対してパイプラインすることができる。
同様に、あるサーバがパイプラインを行うことができない場合は、Ｓ-ノードは代わりにパイプライン化された一連の要求を取り出し、それをそのサーバへの複数のＴＣＰ接続に多重化し、これらの複数の接続から並行して応答を取り出し、それをパイプライン方式でＣ-ノードに送り返すことができる。

デルタ符号化およびテンプレートのインスタンス化
多くのウェブ・ページ、特に動的に生成されるウェブ・ページは、小さな変更を除いてはその大部分が相互に似ている。一般的な事例は、ウェブ・ページを、ユーザ固有のデータ（例えば個人名）を用いて何らかの方式でカスタマイズした、変化しないテンプレートと見なすことができる場合である。

ノード間プロトコルの１つはデルタ符号化であり、この場合はＣ-ノードがそのキャッシュ内に、要求されたオブジェクトである第２のウェブ・オブジェクトに似ているが同じではない第１のウェブ・オブジェクトを有する。Ｓ-ノードは、そのキャッシュまたはサーバから第２のオブジェクトを取り出し、２つのオブジェクトの差（デルタ）の何らかの表現のうち、一方よりも簡潔なものを抽出することができる。Ｓ-ノードはそのデルタ表現をＣ-ノードに通信し、Ｃ-ノード
はその表現とそれがキャッシュした第１のオブジェクトを組み合わせて要求される第２のオブジェクトを再構成し、それをクライアントに通信する。この方式では、Ｓ-ノードとＣ-ノード間で通信されるバイト数が減る。

このノード間プロトコルの変形形態はテンプレートのインスタンス化であり、この場合は、元のオブジェクトを２つの部分から構成できるように、Ｓ-ノードがウェブ・オブジェクトを分析し、オブジェクトをテンプレートとカスタマイズ・データと呼ばれる２つの部分に分離する。（あるいはサーバ自体がこの分離を定義してもよい。）Ｓ-ノードは、テンプレートとカスタマイズ・データをＣ-ノードに通信し、前者をキャッシュに保持するようにＣ-ノードに命令する。Ｓ-ノードが、テンプレートは同じであるがカスタマイズ・データが異なる別のオブジェクトをＣ-ノードに送信する必要があるとき、Ｓ-ノードは代わりにカスタマイズ・データと共に、テンプレートを指定する短いコードを送信することができる。するとＣ-ノードは元のページを構成して、そのページをクライアントに伝達する。

Ｓ-ノードのキャッシングを使用したデルタ符号化
このノード間プロトコルでは、Ｓ-ノードがそこから伝搬した特定の要求および応答を記憶するキャッシュを有することが必要となる。その特有の機能が働くのは、Ｓ-ノードが、すでにＳ-ノードのキャッシュにある例えばｏｂｊ１とする第１のオブジェクトと同じである可能性のある、またはキャッシュ内のｏｂｊ１に非常に似ているが同じではない可能性のある例えばｏｂｊ２とする第２のオブジェクトに対する要求を受信するが、差があるとしてもｏｂｊ１とｏｂｊ２の差が確実には分からない場合である。例えば、このような事例の１つは、キャッシュに記憶されたオブジェクトと同じＵＲＬを使用して、要求されるオブジェクトを識別するものの、それに対応するオブジェクトがサーバで更新されており、したがってキャッシュ内のオブジェクトが古くなっている恐れがある場合である。
別の一般的な事例は、キャッシュ内のオブジェクトのＵＲＬとＵＲＬが異なるものの、疑問符「？」の存在の後にしか差がない場合である。これは、慣習的に、２つのオブジェクトは、異なるパラメータを用いて使用された同じｃｇｉ-ｂｉｎプログラムの出力である可能性が高く、したがって実質的に似ている可能性があるためである。

Ｓ-ノードは要求を受け取ると、直ちに、Ｃ-ノードがｏｂｊ１をクライアントに配信せずにそれを一時的記憶装置に保持しておく方がよいという指示と併せてキャッシュのｏｂｊ１をＣ-ノードに伝達する。Ｓ-ノードは、同時に必要なオブジェクトｏｂｊ２をサーバに要求する。Ｓ-ノードは、ｏｂｊ２を受信すると、それをｏｂｊ１と比較してそれらが異なるかどうかを判断する。オブジェクトが異ならない場合、Ｓ-ノードはＣ-ノードに短いメッセージを送信して、Ｃ-ノードが一時的記憶装置に保持しているオブジェクト（すなわちｏｂｊ１）をクライアントに送信するようにＣ-ノードに通知する。２つのオブジェクトが異なる場合、Ｓ-ノードはｏｂｊ２全体をＣ-ノードに送信することができ、Ｃ-ノードはそれを受信すると、ｏｂｊ２をクライアントに送信して、一時的記憶装置に保持している第１のオブジェクトを破棄する。あるいは、２つのオブジェクトが異なる場合、Ｓ-ノードはＣ-ノードにｏｂｊ１とｏｂｊ２の差の何らかの表現を送信することができ、Ｃ-ノードはこの表現と一時的記憶装置に保持している第１オブジェクトを組み合わせて、第２オブジェクトを復元してそれをクライアントに送信することができる。

このノード間プロトコルは、インターネット上で通信されるトラフィックの正味量は減らさず、またクライアントの近くで要求されたオブジェクトに似たオブジェクトを、要求を予期してキャッシングすることもしない。しかしこのプロトコルは、サーバがまだ要求を評価する作業を行っている間であり、またサーバが応答をＳ-ノードに送信するプロセスにある間であっても第１オブジェクトをＣ-ノードに伝達するので、クライアントが要求オブジェクトを受信するまでの待ち時間を短縮することができる。第１オブジェクトが第２オブジェクトと同じである、または第２オブジェクトとわずかにしか異ならないことが判明した場合、Ｓ-ノードは、Ｃ-ノードからクライアントに応答を送信することが可能になる前に、短くしたがって高速の通信だけをＣ-ノードに送信すればよい。

誤り訂正コード
インターネットを介した伝送では頻繁にエラーが生じるが、特に重要なのは、損失し受信者まで伝達されないパケットである。この場合、通例は、指定の時間内に企図される受信者から確認を受信しないことによるか、またはパケットが到着していない旨の通知を受信者が送信した際に、パケットが受信されていないことに送信側が最終的に気付かなければならない。すると送信側はパケットを再送信することができる。エラーが生じたことに気付き、そしてパケットを再送信するプロセスにはかなりの時間がかかる場合があり、この時間中、受信者はメッセージ全体を構成するパケットをまだすべて持っていないので待機しなければならない。

性能を向上するために、送信側は、要求と応答を含んだパケットと重複する追加の情報パケットを送信することができ、受信者は、１つまたは複数のパケットが損失した場合でも、これらの追加パケットによりメッセージ全体を直ちに復元することができる。この追加パケットは、メッセージ自体を構成するパケットの送信と同時に、またはその直後に送信することができる。この追加パケットは、誤り訂正コードおよび「消去」コードの標準的手段を用いることができる。

インテリジェント・ルーティング
インターネットを介してＩＰメッセージ（ＩＰで送信されるＴＣＰ通信を含む）を送信する際には、通例、ルータと呼ばれるデバイスが、メッセージ中のパケットがその宛先に正確かつ（望ましくは）効率的に到着することを保証する役割を負う。メッセージの送信側と受信者は、通例はこのルーティング・プロセスを明示的に要求する、あるいは管理する必要はない。しかし、明示的にルーティングを管理する、またはルーティングに影響を与えることにより、より高い性能と信頼性を得ることが可能になることもある。本発明は、例えば所与のＳ-ノードと所与のＣ-ノード間に２つのＴＣＰ接続を維持することができ、これにより接
続の最終的な発信元と宛先（すなわちＳ-ノードとＣ-ノード）が同じであっても、この２つの接続はインターネット中で異なる経路をたどる。１つの接続を介した通信が非効率的になった場合（例えばその接続経路にあるルータが一時的に輻輳するなど）、本発明は直ちに第２の接続を介してトラフィックを再送信することができる。

これを実現する具体的な一方式は、標準ＩＰプロトコルの一部である「ソース・ルーティング」のオプションを使用するものである。これにより、パケットを発信元から宛先まで特定のルートをたどらせることができ、あるいはパケットを１つまたは複数の指定した中間ノード（ルータなど）を通過させることが可能になる。同じ発信元から同じ宛先までの２つの接続は、このように異なる経路をとるように作用を加えることができる。別個の経路を形成する別の方式は、１つのノード（例えばＣ-ノードまたはＳ-ノード）が、異なるネットワークに接続された複数のネットワーク・インタフェース・カード（ＮＩＣ）を有する場合に行われる。このようなノードがメッセージを送信する際、ノードはどのＮＩＣを使用するかを指定することができ、したがって少なくともその通信で使用する最初のサブリンクを決定することができる。当業者には理解されるように、これらは、通信がたどる特定経路に影響を与え、コントロールすることが可能である手段の例証に過ぎない。この例は、性能を向上させるためにルーティング・プロセスを管理する、またはそれに影響を与えることが可能な多数の方式を例証するものに過ぎない。

本発明の好ましい実施形態をさらに図１１に示す。Ｃ-ノード２５および２６と、Ｓ-ノード２７および２８は、先に述べたようにインターネット中の異なる位置に配置されている。この実施形態では、ネットワーク・マッピングと併せてＤＮＳベースのリダイレクト法を使用し、少なくともＣ-ノードから代表的マシンに対して行われる測定を用いる。セレクタおよびマッピング・デバイス２４は、専用ＤＮＳサーバ・ソフトウェア２３と同じマシン２２で実行されるソフトウェアである。クライアント２０は、図でｗｗｗ．ｓｉｔｅ．ｃｏｍと名づけたサーバ２９にコンテンツを要求することを希望する。

クライアント２０は、ｗｗｗ．ｓｉｔｅ．ｃｏｍの名に対応するＩＰアドレスを見つけるためにそのローカルＤＮＳサーバ２１を調べる。ローカルＤＮＳサーバ２１は、要求を専用のＤＮＳサーバ２３に中継する。ＤＮＳサーバ２３は、問い合わせの一部として、ローカルＤＮＳサーバ２１のＩＰアドレスを知る。ＤＮＳサーバ２３はマッピング・デバイス２４を調べ、マッピング・デバイス２４は要求元のアドレスとそのネットワーク・マップを使用して、提供されたＩＰアドレスと選択されたＣ-ノード間のネットワーク距離が最短になるＣ-ノードを選択する（したがって選択されるＣ-ノードはクライアント２０に近いことが予測される）。上記のように、また図４および図６に示すように、Ｃ-ノードを選択する際にはこの他の要因も考慮に入れることができる。図１１では、Ｃ-ノード２５がセレクタによって選択されている。

この実施形態ではＩＰアドレス分類法を使用する。したがって、各Ｃ-ノード、具体的にはＣ-ノード２５には複数のＩＰアドレスを与え、その１つ１つが可能な各サーバ名に対応している。ＤＮＳシステム２３は、サーバ名ｗｗｗ．ｓｉｔｅ．ｃｏｍに対応するＣ-ノード２５のＩＰアドレスを戻す。ＤＮＳサーバ２３は、このＩＰアドレスをローカルのＤＮＳサーバ２１に戻し、ＤＮＳサーバ２１はこの応答をクライアント２０に中継する。クライアント２０は提供されたアドレスを使用してＣ-ノード２５へのＴＣＰ接続を開き、ＨＴＴＰ ｏｖｅｒ ｔｈｅ ＴＣＰ接続を使用してその要求を伝達する。Ｃ-ノード２５は、その接続が開かれたＩＰアドレスを記録し、ＩＰアドレス分類を使用して、クライアント２０の要求が対象とするサーバ２９の名前、すなわちｗｗｗ．ｓｉｔｅ．ｃｏｍを再構成する。Ｃ-ノード２５は要求されるオブジェクトをそのキャッシュ内で見つけ、オブジェクトを直ちにクライアント２０に戻すことを試みることができる。さもなければ、Ｃ-ノード２５はサーバとＳ-ノードの関連のデータベースを使用して、サーバ２９へのトラフィックを搬送することのできるＳ-ノードの名前を見つける。ここで、Ｓ-ノード２８は以前にサーバ２９の名前、すなわち
ｗｗｗ．ｓｉｔｅ．ｃｏｍと関連付けられており、このノードが選択される。Ｃ-ノード２５は、ノード間プロトコルを使用してＳ-ノード２８に要求を送信する。

Ｃ-ノード２５とＳ-ノード２８間で使用するノード間プロトコルは、ＴＣＰを、より高速のプロトコル、この好ましい実施形態ではＴ／ＴＣＰに置き換える。
この他に、ＨＴＴＰヘッダ圧縮、ＨＴＴＰコンテンツ圧縮、予測型コンテンツ・プッシュ、およびデルタ符号化をノード間プロトコルとして同時に使用することができる。Ｓ-ノード２８はノード間プロトコルを使用して要求を受信し、Ｓ-ノード２８がサーバ２９に対して開いたＨＴＴＰ ｏｖｅｒ ｔｈｅ ＴＣＰ接続を使用してその要求をサーバ２９に転送する。次いでＳ-ノード２８は、この場合もＨＴＴＰ ｏｖｅｒ ＴＣＰを使用して要求に対する応答をサーバ２９から受信する。Ｓ-ノード２８は、ノード間プロトコルを使用してＣ-ノード２５に応答を送信する。Ｃ-ノード２５は、ＨＴＴＰを使用してこの応答をクライアントに転送する。図２〜１０と、これらの図面に関連する先の説明を使用してこの実施形態についてさらに説明することができる。

本発明について、クライアントからサーバに要求が送信され、応答が送り返されるという観点から説明したが、本発明は要求または応答の一方のみについての性能を高めるように適合できることは理解されよう。さらに、Ｓ-ノードからＣ-ノードへの通信に使用されるノード間プロトコルが、逆方向で使用されるプロトコルと同じものである必要はない。１方向のみにおける本発明の使用の一例は以下の通りである。クライアントはその要求をサーバに送信することができ、サーバは、そのような要求がすべてそのサーバに近いＳ-ノードでインターセプトされるように構成することができる。この役割において、Ｓ-ノードはよく知られる「逆プロキシ」として機能する。ただし、Ｓ-ノードがクライアントの要求に対する応答を取り出すと（Ｓ-ノードのキャッシュまたはサーバから）、Ｓ-ノードは、そのクライアントに近いと思われるＣ-ノードを選択することができる（例えば上記のネットワーク・マッピング手段を使用して）。そしてＳ-ノードは
、効率的なノード間プロトコルを使用して、選択したＣ-ノードに応答を伝達することができる。選択されたＣ-ノードは、標準プロトコルを使用してその応答をクライアントに送信することができる。Ｃ-ノードとクライアント間で使用される標準プロトコルがＴＣＰを使用する場合、Ｃ-ノードは、クライアントにとって通信が直接Ｓ-ノードから来たものに見えるように、その通信を「偽装」しなければならないことがある。しかし、この方式でＴＣＰ通信を偽装するための技術はよく知られている。したがってこの例では、主に通信の半分にしか本発明を使用していないことになる。すなわち、サーバからクライアントに応答を戻す際には本発明を使用するが、クライアントの最初の要求をサーバに送信するためには必ずしも使用されない。この例のように本発明を用いることの利点は、クライアントの要求が近くのＣ-ノードに送信されるのを確実にするためのリダイレクト手段の必要性を排除する点である。

代替実施形態
本発明の特定実施形態についての前述の説明は、例証および説明の目的で提示している。これは完全を期したものではなく、あるいは本発明を開示した形態のみに限定するものではない。上記の教示に照らして多くの修正形態および変形形態が明らかになろう。実施形態は、本発明の原理とその実際的な応用例を最も正確に説明するために選択し、説明したものであり、したがって企図する特定の使用例に適した各種の修正を施した各種の実施形態を可能にする。例えばＳ-ノードおよびＣ-ノードの機能は、それらが要求および応答を処理する際に果たす役割によって区別している。しかし、コンピュータなどの１台のデバイスまたはコンピュータ・クラスタが両機能を実施できることが理解されよう。

別の例として、説明した実施形態は、両伝送方向、すなわち発信元から宛先までとその逆において向上した通信性能を提供する。代替実施形態では、本発明は、１方向のみ、または特定のパケットやメッセージのみについてより優れた性能を提供することができる。例えば、ウェブ・コンテンツに対する要求は、Ｃ-ノードとＳ-ノードの選択を行い、そのノードを通信に使用してクライアントから
サーバに送信することができるが、Ｃ-ノードとＳ-ノード間のサブリンクには標準プロトコルを使用する。ウェブ・サーバからの応答は同じ経路を使用することができる

Claims (14)

1. インターネットを介して通信を送信する方法であって、
   複数の第１のタイプのノードから１つを選択するステップと、
   複数の第２のタイプのノードから１つを選択するステップと、
   発信元から第１のプロトコルによって送信される通信を前記選択された第１のタイプのノードにおいて受信するステップと、
   前記通信を前記選択された第１のタイプのノードから前記選択された第２のタイプのノードへ前記第１のプロトコルより高速の第２のプロトコルにしたがって送信するステップと、
   前記通信を前記選択された第２のタイプのノードから宛先に送信するステップとを含み、
   前記発信元から前記宛先への前記通信の送信は終端間の送信であり、
   前記発信元から前記選択された第１のタイプのノードを経て前記宛先へ前記通信を送信することは、前記発信元と前記選択された第１のタイプのノードとの間のサブリンクに関して通信性能の尺度を最適化することによって、かつ、前記選択された第１のタイプのノードと前記選択された第２のタイプのノードとの間のサブリンクに関して前記第２のプロトコルを使用することによって、前記終端間の送信の性能を最大にし、
   前記第１のタイプのノードの選択は、（ｉ）前記選択された第１のタイプのノードがキャッシュ内に位置する前記通信に関連するオブジェクトを有する可能性と、（ｉｉ）前記終端間の送信に沿った少なくとも１つのサブリンクに関する通信性能尺度とを含む要因の組み合わせに基づくことを特徴とする方法。
2. 前記第２のプロトコルは接続プーリングを含むことを特徴とする請求項１に記載の方法。
3. 前記第２のプロトコルはＴＣＰを改良したバージョンを含むことを特徴とする請求項１に記載の方法。
4. 前記第２のプロトコルはＨＴＴＰヘッダの圧縮を含むことを特徴とする請求項１に記載の方法。
5. 前記第２のプロトコルはＨＴＴＰコンテンツの圧縮を含むことを特徴とする請求項１に記載の方法。
6. 前記第２のプロトコルは予測型のプリフェッチを含むことを特徴とする請求項１に記載の方法。
7. 前記第２のプロトコルは予測型のコンテンツ・プッシュを含むことを特徴とする請求項１に記載の方法。
8. 前記第２のプロトコルはパイプライン化を含むことを特徴とする請求項１に記載の方法。
9. 前記第２のプロトコルはデルタ符号化およびテンプレートのインスタンス化を含むことを特徴とする請求項１に記載の方法。
10. 前記第２のプロトコルは第２の形式のノードにおけるキャッシングを使用するデルタ符号化を含むことを特徴とする請求項１に記載の方法。
11. 前記第２のプロトコルは誤り訂正コードの使用を含むことを特徴とする請求項１に記載の方法。
12. 前記第２のプロトコルはインテリジェント・ルーティングの使用を含むことを特徴とする請求項１に記載の方法。
13. 前記選択された第１のタイプのノードを前記発信元と同じ場所に配置することを特徴とする請求項１に記載の方法。
14. 前記第２のタイプのノードを前記宛先と同じ場所に配置することを特徴とする請求項１に記載の方法。

Images