JP2003522358A

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

Info

Publication number: JP2003522358A
Application number: JP2001557212A
Authority: JP
Inventors: グローヴ，アダム，ジェイ．; カーリトノフ，マイケル; トゥマーキン，アレクセイ
Original assignee: ネトリ，インコーポレーテッド
Priority date: 2000-02-07
Filing date: 2001-02-07
Publication date: 2003-07-22
Also published as: US6820133B1; WO2001058069A1; US7359985B2; AU778459B2; BR0108170A; JP2009217836A; HK1055361A1; US20070050522A1; EP1264432A1; JP5044607B2; US7392325B2; CN1263263C; US20070050521A1; AU3974801A; CN1422468A; US7418518B2; CA2399526A1; EP1264432B1; WO2001058069A8; EP1264432A4

Abstract

(57)【要約】標準の通信プロトコル、クライアントおよびサーバを維持しながら、２つのタイプの分散型専用ノードを用いてインターネットを介したワールドワイドウェブのトラフィックを増大させるための方法および装置が開示される。したがって、ウェブ・クライアント（１０）の要求は、標準のプロトコル（１１）を使用して、ウェブ・クライアント（１０）に適切に近くに選択された第１のタイプの専用の第１のノード（１２-１）に向けられる。第１のノード（１２-１）は、改善された性能のための、特にトラフィック量と待ち時間を低減するための、専用のプロトコル（１３）を使用してウェブ・クライアント（１０）の要求を第２のタイプの第２のノード（１４-２）に伝達する。要求の最終的な宛先（１６）に適切に近くに選択された第２のノード（１４-２）は、標準のプロトコル（１１）を使用して要求を宛先（１６）に転送する。宛先（１６）からクライアント（１０）への応答は、通常、対応する逆経路を取る。さらに、専用ノードは、いくつかの通信ステップを回避または改善するために、ウェブ・キャッシュを含めて他の技術を使用することができる。

Description

【発明の詳細な説明】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【図面の簡単な説明】

【図１】本発明の一実施形態による、ネットワークの改善された通信性能を提供するシ
ステムのブロック図である。

【図２】本発明の一実施形態によるリダイレクション・システムによって使用されるプ
ロセスの流れ図である。

【図３】本発明の一実施形態によるリダイレクション・システムによって使用されるデ
ータ構造を示す図面である。

【図４】本発明の一実施形態によるセレクタによって使用されるプロセスの流れ図であ
る。

【図５】本発明の一実施形態によるセレクタによって使用されるデータ構造を示す図面
である。

【図６】本発明の一実施形態によるマッピング・デバイスによって使用される別のプロ
セスの流れ図である。

【図７】本発明の一実施形態によるＣ-ノードによって使用されるデータ構造を示す図
面である。

【図８】本発明の一実施形態によるＣ-ノードによって使用されるプロセスの流れ図で
ある。

【図９】本発明の一実施形態によるＣ-ノードによって使用されるデータ構造を示す図
面である。

【図１０】本発明の一実施形態によるＳ-ノードによって使用されるプロセスの流れ図で
ある。

【図１１】本発明の好ましい実施形態による、ネットワークの改善された通信性能を提供
するシステムのブロック図である

───────────────────────────────────────────────────── フロントページの続き (31)優先権主張番号０９／５３４，３２１ (32)優先日平成12年３月24日(2000．3．24) (33)優先権主張国米国（ＵＳ） (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ，ＴＲ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，ＬＳ，ＭＷ，ＭＺ，ＳＤ，ＳＬ，ＳＺ，ＴＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＥ，ＡＧ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＢＺ，ＣＡ，ＣＨ，ＣＮ，ＣＲ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＤＭ，ＤＺ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＡ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＭＺ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＴＺ，ＵＡ，ＵＧ，ＵＺ，ＶＮ，ＹＵ，ＺＡ，ＺＷ (72)発明者カーリトノフ，マイケルアメリカ合衆国 10023 ニューヨーク州，ニューヨーク，アパートメント４エフ，ウエスト 71エスティーストリート 145 (72)発明者トゥマーキン，アレクセイアメリカ合衆国 93117 カリフォルニア州，ゴレタ，ロスモアロード 630 Ｆターム(参考） 5K030 HB19 HC01 LB05 【要約の続き】することができる。

Claims

【特許請求の範囲】

【請求項１】インターネットを介して発信元と宛先の間でインターネット
・メッセージを伝達する方法であって、（ａ）第１のタイプのノードを選択するステップと、（ｂ）第２のタイプのノードを選択するステップと、（ｃ）第１のプロトコルを使用して発信元から第１のタイプのノードにインタ
ーネット・メッセージを伝達するステップと、（ｄ）第２のプロトコルを使用して第１のタイプのノードから第２のタイプの
ノードにインターネット・メッセージを伝達するステップと、（ｅ）第３のプロトコルを使用して第２のタイプのノードから宛先にインター
ネット・メッセージを伝達するステップとを含む方法。
【請求項２】インターネットを介して発信元と宛先の間でインターネット
・メッセージを伝達する方法であって、（ａ）第１のタイプのノードを選択するステップと、（ｂ）第１のプロトコルを使用して発信元から第１のタイプのノードにインタ
ーネット・メッセージを伝達するステップと、（ｃ）第２のプロトコルを使用して第１のタイプのノードから第２のタイプの
ノードにインターネット・メッセージを伝達するステップと、（ｄ）第３のプロトコルを使用して第２のタイプのノードから宛先にインター
ネット・メッセージを伝達するステップとを含む方法。
【請求項３】選択するステップ（ａ）が、（ａ１）第１のタイプの複数の候補ノードの各々に対して、発信元と第１のタ
イプの候補ノードの間のサブリンクに対する通信性能の尺度を決定するステップ
と、（ａ２）通信性能の尺度を最適化するために、第１のタイプの複数の候補ノー
ドの中から第１のタイプのノードを選択するステップとを含む請求項１に記載の方法。
【請求項４】選択するステップ（ａ）が、（ａ１）第１のタイプの複数の候補ノードの各々に対して、発信元と第１のタ
イプの候補ノードの間のサブリンクに対する通信性能の尺度を決定するステップ
と、（ａ２）通信性能の尺度を最適化するために、第１のタイプの複数の候補ノー
ドの中から第１のタイプのノードを選択するステップとを含む請求項２に記載の方法。
【請求項５】選択するステップ（ｂ）が、（ｂ１）第２のタイプの複数の候補ノードの各々に対して、宛先と第２のタイ
プの候補ノードの間のサブリンクに対する通信性能の尺度を決定するステップと
、（ｂ２）通信性能の尺度を最適化するために、第２のタイプの複数の候補ノー
ドの中から第２のタイプのノードを選択するステップとを含む請求項１に記載の方法。
【請求項６】選択するステップ（ｂ）が、（ｂ１）第２のタイプの複数の候補ノードの各々に対して、第１のタイプの候
補ノードと第２のタイプの候補ノードの間のサブリンクに対する通信性能の尺度
を決定するステップと、（ｂ２）通信性能の尺度を最適化するために、第２のタイプの複数の候補ノー
ドの中から第２のタイプのノードを選択するステップとを含む請求項１に記載の方法。
【請求項７】ステップ（ａ）が、第１のタイプのノードおよび第２のタイ
プのノードを介する、発信元から宛先へのリンク内の少なくとも１つのサブリン
クに対する通信性能の尺度を最適化するために、第１のタイプのノードを選択す
るステップを含み、ステップ（ｂ）が、第１のタイプのノードおよび第２のタイプのノードを介す
る、発信元から宛先へのリンク内の少なくとも１つのサブリンクに対する通信性
能の尺度を最適化するために、第２のタイプのノードを選択するステップを含む
請求項１に記載の方法。
【請求項８】選択するステップ（ａ）が、（ａ１）第１のタイプの複数の候補ノードの各々に対して、発信元と第１のタ
イプの候補ノードの間のサブリンクに対する通信性能の第１の尺度を決定するス
テップと、（ａ２）通信性能の第１の尺度を最適化するために、第１のタイプの複数の候
補ノードの中から第１のタイプのノードを選択するステップとを含み、選択するステップ（ｂ）が、（ｂ１）第２のタイプの複数の候補ノードの各々に対して、第１のタイプのノ
ードと第２のタイプの各候補ノードの間のサブリンクに対する通信性能の第２の
尺度と、第２のタイプの候補ノードと宛先の間のサブリンクに対する性能の第３
の尺度とを決定するステップと、（ｂ２）通信性能の第２および第３の尺度の組合せを最適化するために、第２
のタイプの複数の候補ノードの中から第２のタイプのノードを選択するステップ
とを含む請求項１に記載の方法。
【請求項９】インターネットを介して発信元と宛先との間でインターネッ
ト・メッセージを伝達する方法であって、（ａ）第１のタイプのノードと第２のタイプのノードを選択するステップと、（ｂ）第１のプロトコルを使用して発信元から第１のタイプのノードにインタ
ーネット・メッセージを伝達するステップと、（ｃ）第２のプロトコルを使用して第１のタイプのノードから第２のタイプの
ノードにインターネット・メッセージを伝達するステップと、（ｄ）第３のプロトコルを使用して第２のタイプのノードから宛先にインター
ネット・メッセージを伝達するステップとを含む方法。
【請求項１０】選択するステップ（ａ）が、（ａ１）第１のタイプの複数の候補ノードの各々に対して、発信元から第１の
タイプの候補ノードまでのサブリンクに対する通信性能の第１の尺度を決定する
ステップと、（ａ２）第２のタイプの複数のノードの各々に対して、第１のタイプの各候補
ノードと第２のタイプの各候補ノードとの間のサブリンクに対する通信性能の第
２の尺度と、第２のタイプの各候補ノードと宛先の間のサブリンクに対する通信
性能の第３の尺度とを決定するステップと、（ａ３）通信性能の第１、第２、第３の尺度の組合せを最適化するために、第
１のタイプの複数の候補ノードの中から第１のタイプのノードを選択し、第２の
タイプの複数の候補ノードの中から第２のタイプのノードを選択するステップとを含む請求項９に記載の方法。
【請求項１１】選択するステップ（ａ）が、（ａ１）複数の第１のタイプの候補ノードと第２のタイプの候補ノードの各々
に対して、第１のタイプの候補ノードと第２のタイプの候補ノードを介する発信
元から宛先までのリンク内の少なくとも１つのサブリンクに対する通信性能の尺
度を決定するステップと、（ａ２）通信性能の尺度を最適化するために、第１のタイプの複数の候補ノー
ドからの第１のタイプのノードと、第２のタイプの複数の候補ノードからの第２
のタイプのノードとの組合せを選択するステップとを含む請求項９に記載の方法。
【請求項１２】選択するステップ（ａ）が、（ａ１）複数の第１のタイプの候補ノードと第２のタイプの候補ノードの各々
に対して、第１のタイプの候補ノードと第２のタイプの候補ノードの間のサブリ
ンクに対する通信性能の尺度を決定するステップと、（ａ２）通信性能の尺度を最適化するために、第１のタイプの複数の候補ノー
ドからの第１のタイプのノードと、第２のタイプの複数の候補ノードからの第２
のタイプのノードとを選択するステップとを含む請求項９に記載の方法。
【請求項１３】（ｆ）第４のプロトコルを使用して宛先から第２のタイプ
のノードに第２のインターネット・メッセージを伝達するステップと、（ｇ）第５のプロトコルを使用して第２のタイプのノードから第１のタイプの
ノードに第２のインターネット・メッセージを伝達するステップと、（ｈ）第６のプロトコルを使用して第１のタイプのノードから発信元に第２の
インターネット・メッセージを伝達するステップとをさらに含む請求項１に記載の方法。
【請求項１４】（ｅ）第４のプロトコルを使用して宛先から第２のタイプ
のノードに第２のインターネット・メッセージを伝達するステップと、（ｆ）第５のプロトコルを使用して第２のタイプのノードから第１のタイプの
ノードに第２のインターネット・メッセージを伝達するステップと、（ｇ）第６のプロトコルを使用して第１のタイプのノードから発信元に第２の
インターネット・メッセージを伝達するステップとを含む請求項９に記載の方法。
【請求項１５】インターネットを介して発信元と宛先との間でインターネ
ット・メッセージを伝達する方法において、（ａ）第１のタイプのノードを選択するステップと、（ｂ）第１のプロトコルを使用して発信元から第１のタイプのノードにインタ
ーネット・メッセージを伝達するステップと、（ｃ）第２のタイプのノードが第１のタイプのノードからのインターネット・
メッセージをインターセプトするステップであって、第１のタイプのノードから
のインターネット・メッセージが第２のプロトコルを使用して伝達されるステッ
プと、（ｄ）第３のプロトコルを使用して第２のタイプのノードから宛先にインター
ネット・メッセージを伝達するステップとを含む方法。
【請求項１６】インターネットを介して発信元と宛先の間でインターネッ
ト・メッセージを伝達する方法において、（ａ）第２のタイプのノードを選択するステップと、（ｂ）第１のタイプのノードが発信元からのインターネット・メッセージをイ
ンターセプトするステップであって、発信元からのインターネット・メッセージ
が第１のプロトコルを使用して伝達されるステップと、（ｃ）第２のプロトコルを使用して第１のタイプのノードから第２のタイプの
ノードにインターネット・メッセージを伝達するステップと、（ｄ）第３のプロトコルを使用して第２のタイプのノードから宛先にインター
ネット・メッセージを伝達するステップとを含む方法。
【請求項１７】伝達するステップ（ｃ）が、発信元から第１のタイプのノードにインターネット・メッセージをリダイレクト
するステップを含む請求項１に記載の方法。
【請求項１８】伝達するステップ（ｂ）が、発信元から第１のタイプのノードにインターネット・メッセージをリダイレク
トするステップを含む請求項２に記載の方法。
【請求項１９】伝達するステップ（ｂ）が、第１のタイプのノードから第２のタイプのノードにインターネット・メッセー
ジをリダイレクトするステップを含む請求項９に記載の方法。
【請求項２０】第１のプロトコルが標準プロトコルであり、第２のプロト
コルが高性能プロトコルであり、第３のプロトコルが標準プロトコルである請求
項１に記載の方法。
【請求項２１】第１のプロトコルが標準プロトコルであり、第２のプロト
コルが高性能プロトコルであり、第３のプロトコルが標準プロトコルである請求
項２に記載の方法。
【請求項２２】第１のプロトコルが標準プロトコルであり、第２のプロト
コルが高性能プロトコルであり、第３のプロトコルが標準プロトコルである請求
項９に記載の方法。
【請求項２３】第４のプロトコルが標準プロトコルであり、第５のプロト
コルが高性能プロトコルであり、第６のプロトコルが標準プロトコルである請求
項１３に記載の方法。
【請求項２４】第４のプロトコルが標準プロトコルであり、第５のプロト
コルが高性能プロトコルであり、第６のプロトコルが標準プロトコルである請求
項１４に記載の方法。
【請求項２５】第１のプロトコルが標準プロトコルであり、第２のプロト
コルが高性能プロトコルであり、第３のプロトコルが標準プロトコルである請求
項１５に記載の方法。
【請求項２６】第１のプロトコルが標準プロトコルであり、第２のプロト
コルが高性能プロトコルであり、第３のプロトコルが標準プロトコルである請求
項１６に記載の方法。
【請求項２７】インターネット・メッセージがワールドワイドウェブのメ
ッセージである請求項２０に記載の方法。
【請求項２８】インターネット・メッセージがワールドワイドウェブのメ
ッセージである請求項２１に記載の方法。
【請求項２９】インターネット・メッセージがワールドワイドウェブのメ
ッセージである請求項２２に記載の方法。
【請求項３０】インターネット・メッセージがワールドワイドウェブのメ
ッセージである請求項２３に記載の方法。
【請求項３１】インターネット・メッセージがワールドワイドウェブのメ
ッセージである請求項２４に記載の方法。
【請求項３２】インターネット・メッセージがワールドワイドウェブのメ
ッセージである請求項２５に記載の方法。
【請求項３３】インターネット・メッセージがワールドワイドウェブのメ
ッセージである請求項２６に記載の方法。
【請求項３４】宛先から発信元にウェブ・コンテンツを提供する方法にお
いて、（ａ）ノードを選択するステップと、（ｂ）ウェブ・コンテンツを要求するインターネット・メッセージを発信元か
らノードに伝達するステップと、（ｃ）ノードがそのキャッシュ内に要求されたウェブ・コンテンツを含んでい
る場合、そのウェブ・コンテンツをノードから発信元に伝達するステップと、（ｄ）ノードがそのキャッシュ内に要求されたウェブ・コンテンツを含んでい
ない場合、ウェブ・コンテンツを要求するインターネット・メッセージを第１の
タイプのノードから宛先に伝達するステップとを含む方法であって、ノードが、通信性能の尺度を最適化するように選択され、通信性能の尺度が、
ノードと宛先の間のサブリンクに対する通信性能の少なくとも１つの尺度を含む
方法。
【請求項３５】通信性能の尺度が、発信元とノードの間のネットワーク距
離と、ノードとサーバの間のネットワーク距離と、要求されたウェブ・コンテン
ツがノードのキャッシュに存在する可能性との組合せである請求項３４に記載の
方法。
【請求項３６】インターネットを介して発信元から宛先にインターネット
・メッセージを伝達するシステムにおいて、１つまたは複数の第１のタイプのノードと、１つまたは複数の第２のタイプの
ノードを含む複数のノードと、１つまたは複数の第１のタイプのノードから第１のタイプのノードを識別し、
その選択を発信元に伝達する第１のセレクタと、１つまたは複数の第２のタイプのノードから第２のタイプのノードを識別し、
その選択を選択された第１のタイプのノードに伝達する第２のセレクタとを含むシステムであって、第１のタイプの各ノードが、第１のプロトコルを使用して発信元からインターネット・メッセージを受信す
るための受信機と、第２のプロトコルを使用して選択された第２のタイプのノードにそのメッセー
ジを伝達するための送信機とを含み、第２のタイプの各ノードが、選択された第１のタイプのノードからメッセージを受信するための受信機と、第３のプロトコルを使用してそのメッセージを宛先に送信するための送信機とを含むシステム。
【請求項３７】インターネットを介して発信元から宛先にインターネット
・メッセージを伝達するシステムにおいて、１つまたは複数の第１のタイプのノードと、１つまたは複数の第２のタイプの
ノードを含む複数のノードと、１つまたは複数の第１のタイプのノードから第１のタイプのノードを識別し、
その選択を発信元に伝達するセレクタと、を含むシステムであって、第１のタイプの各ノードが、第１のプロトコルを使用して発信元からインターネット・メッセージを受信す
るための受信機と、第２のプロトコルを使用して第２のタイプのノードにそのメッセージを伝達す
るための送信機とを含み、第２のタイプの各ノードが、選択された第１のタイプのノードからメッセージを受信するための受信機と、第３のプロトコルを使用してそのメッセージを宛先に送信するための送信機とを含むシステム。
【請求項３８】第１のセレクタが、発信元と、第１のタイプの複数の候補
ノードの各々の間のサブリンクに対する通信性能の第１の尺度を最適化する第１
のタイプのノードを識別する請求項３６に記載のシステム。
【請求項３９】第１のセレクタが、発信元と、第１のタイプの複数の候補
ノードの各々の間のサブリンクに対する通信性能の第１の尺度を最適化する第１
のタイプのノードを識別する請求項３７に記載のシステム。
【請求項４０】第２のセレクタが、第２のタイプの選択されたノードと宛
先の間のサブリンクに対する通信性能の尺度を最適化する第２のタイプのノード
を識別する請求項３６に記載のシステム。
【請求項４１】第１のセレクタが、第１のタイプのノードと第２のタイプ
のノードを介した、発信元から宛先へのリンク内の少なくとも１つのサブリンク
に対する通信性能の尺度を最適化する第１のタイプのノードを識別し、第２のセレクタが、第１のタイプのノードと第２のタイプのノードを介した、
発信元から宛先へのリンク内の少なくとも１つのサブリンクに対する通信性能の
尺度を最適化する第２のタイプのノードを識別する請求項３６に記載のシステム。
【請求項４２】インターネットを介して発信元から宛先までインターネッ
ト・メッセージを伝達するシステムにおいて、１つまたは複数の第１のタイプのノードと、１つまたは複数の第２のタイプの
ノードを含む複数のノードと、１つまたは複数の第１のタイプのノードから第１のタイプのノードを識別し、
その選択を発信元に伝達し、また、１つまたは複数の第２のタイプのノードから
第２のタイプのノードを識別し、その選択を選択された第１のタイプのノードに
提供するセレクタとを含むシステムであって、第１のタイプの各ノードが、第１のプロトコルを使用して発信元からインターネット・メッセージを受信す
るための受信機と、第２のプロトコルを使用して選択された第２のタイプのノードにそのメッセー
ジを伝達するための送信機とを含み、第２のタイプの各ノードが、選択された第１のタイプのノードからメッセージを受信するための受信機と、第３のプロトコルを使用してそのメッセージを宛先に送信するための送信機とを含むシステム。
【請求項４３】セレクタが、発信元と第１のタイプのノードの間のサブリ
ンクと、第１のタイプのノードと第２のタイプのノードの間のサブリンクと、第
２のタイプのノードと宛先の間のサブリンクとに対する通信性能の尺度を最適化
する第１のタイプのノードおよび第２のタイプのノードを識別する請求項４２に
記載のシステム。
【請求項４４】セレクタが、発信元と宛先の間のリンク内の少なくとも１
つのサブリンクに対する通信性能の尺度を最適化する第１のタイプのノードと第
２のタイプのノードを識別する請求項４２に記載のシステム。
【請求項４５】第２のタイプのノードが、第４のプロトコルを使用して宛
先から第２のインターネット・メッセージを受信するための受信機と、第５のプ
ロトコルを使用して第２のインターネット・メッセージを第１のタイプのノード
に伝達する送信機とをさらに含み、第１のタイプのノードが、第５のプロトコルを使用して第１のタイプのノード
から第２のインターネット・メッセージを受信するための受信機と、第６のプロ
トコルを使用して第２のインターネット・メッセージを発信元に伝達するための
送信機をさらに含む請求項３６に記載のシステム。
【請求項４６】第２のタイプのノードが、第４のプロトコルを使用して宛
先から第２のインターネット・メッセージを受信するための受信機と、第５のプ
ロトコルを使用して第２のインターネット・メッセージを第１のタイプのノード
に伝達する送信機とをさらに含み、第１のタイプのノードが、第５のプロトコルを使用して第１のタイプのノード
から第２のインターネット・メッセージを受信するための受信機と、第６のプロ
トコルを使用して第２のインターネット・メッセージを発信元に伝達するための
送信機とをさらに含む請求項４２に記載のシステム。
【請求項４７】インターネットを介して発信元と宛先の間でインターネッ
ト・メッセージを伝達するシステムにおいて、１つまたは複数の第１のタイプのノードと、１つまたは複数の第２のタイプの
ノードを含む複数のノードと、１つまたは複数の第２のタイプのノードから第２のタイプのノードを識別し、
その選択を第１のタイプのノードに提供するセレクタとを含むシステムであって、第１のタイプの各ノードが、第１のプロトコルを使用して発信元からインターネット・メッセージをインタ
ーセプトするためのインターセプタと、第２のプロトコルを使用して選択された第２のタイプのノードにそのメッセー
ジを伝達するための送信機とを含み、第２のタイプの各ノードが、選択された第１のタイプのノードからメッセージを受信するための受信機と、第３のプロトコルを使用してそのメッセージを宛先に伝達するための送信機とを含むシステム。
【請求項４８】インターネットを介して発信元から宛先にインターネット
・メッセージを伝達するシステムにおいて、１つまたは複数の第１のタイプのノードと、１つまたは複数の第２のタイプの
ノードを含む複数のノードと、１つまたは複数の第１のタイプのノードから第１のタイプのノードを識別し、
その選択をリダイレクタに伝達する第１のセレクタと、１つまたは複数の第２のタイプのノードから第２のタイプのノードを識別し、
その選択を選択された第１のタイプのノードに提供する第２のセレクタと、発信元から、選択された第１のタイプのノードにインターネット・メッセージ
をリダイレクトするためのリダイレクタとを含むシステムであって、第１のタイプの各ノードが、第１のプロトコルを使用してリダイレクタからインターネット・メッセージを
受信するための受信機と、第２のプロトコルを使用して選択された第２のタイプのノードにそのメッセー
ジを伝達するための送信機とを含み、第２のタイプの各ノードが、選択された第１のタイプのノードからメッセージを受信するための受信機と、第３のプロトコルを使用してそのメッセージを宛先に伝達するための送信機とを含むシステム。
【請求項４９】インターネットを介して発信元から宛先にインターネット
・メッセージを伝達するシステムにおいて、１つまたは複数の第１のタイプのノードと、１つまたは複数の第２のタイプの
ノードを含む複数のノードと、１つまたは複数の第１のタイプのノードから第１のタイプのノードを識別し、
その選択をリダイレクタに伝達するセレクタと、発信元から、選択された第１のタイプのノードにインターネット・メッセージ
をリダイレクトするためのリダイレクタとを含むシステムであって、第１のタイプの各ノードが、第１のプロトコルを使用してリダイレクタからインターネット・メッセージを
受信するための受信機と、第２のプロトコルを使用して第２のタイプのノードにそのメッセージを伝達す
るための送信機とを含み、第２のタイプの各ノードが、選択された第１のタイプのノードからメッセージを受信するための受信機と、第３のプロトコルを使用してそのメッセージを宛先に送信するための送信機とを含むシステム。
【請求項５０】第１のプロトコルが標準プロトコルであり、第２のプロト
コルが高性能プロトコルであり、第３のプロトコルが標準プロトコルである請求
項３６に記載のシステム。
【請求項５１】第１のプロトコルが標準プロトコルであり、第２のプロト
コルが高性能プロトコルであり、第３のプロトコルが標準プロトコルである請求
項３７に記載のシステム。
【請求項５２】第１のプロトコルが標準プロトコルであり、第２のプロト
コルが高性能プロトコルであり、第３のプロトコルが標準プロトコルである請求
項４２に記載のシステム。
【請求項５３】第４のプロトコルが標準プロトコルであり、第５のプロト
コルが高性能プロトコルであり、第６のプロトコルが標準プロトコルである請求
項４５に記載のシステム。
【請求項５４】第４のプロトコルが標準プロトコルであり、第５のプロト
コルが高性能プロトコルであり、第６のプロトコルが標準プロトコルである請求
項４６に記載のシステム。
【請求項５５】第１のプロトコルが標準プロトコルであり、第２のプロト
コルが高性能プロトコルであり、第３のプロトコルが標準プロトコルである請求
項４５に記載のシステム。
【請求項５６】第１のプロトコルが標準プロトコルであり、第２のプロト
コルが高性能プロトコルであり、第３のプロトコルが標準プロトコルである請求
項４６に記載のシステム。
【請求項５７】インターネット・メッセージがワールドワイドウェブのメ
ッセージである請求項５０に記載のシステム。
【請求項５８】インターネット・メッセージがワールドワイドウェブのメ
ッセージである請求項５１に記載のシステム。
【請求項５９】インターネット・メッセージがワールドワイドウェブのメ
ッセージである請求項５２に記載のシステム。
【請求項６０】インターネット・メッセージがワールドワイドウェブのメ
ッセージである請求項５３に記載のシステム。
【請求項６１】インターネット・メッセージがワールドワイドウェブのメ
ッセージである請求項５４に記載のシステム。
【請求項６２】インターネット・メッセージがワールドワイドウェブのメ
ッセージである請求項５５に記載のシステム。
【請求項６３】インターネット・メッセージがワールドワイドウェブのメ
ッセージである請求項５６に記載のシステム。
【請求項６４】宛先から発信元にウェブ・コンテンツを提供するシステム
において、複数のノードと、１つまたは複数のノードから１つのノードを識別し、その選択を発信元に伝達
するセレクタとを含むシステムであって、各ノードが、第１のプロトコルを使用して、ウェブ・コンテンツへの要求を含むインターネ
ット・メッセージを発信元から受信するための受信機と、キャッシュと、第２のプロトコルを使用して、選択された第２のタイプのノードにメッセージ
を伝達するための第１の送信機と、キャッシュから発信元にウェブ・コンテンツを伝達するための第２の送信機と
を含み、セレクタが、通信性能の尺度を最適化するようにノードを選択し、通信性能の
尺度が、ノードと宛先の間のサブリンクに対する少なくとも１つの尺度を含むシ
ステム。
【請求項６５】通信性能の尺度が、発信元とノードの間のネットワーク距
離と、ノードとサーバの間のネットワーク距離と、要求されたウェブ・コンテン
ツがノードのキャッシュに存在する可能性の組合せである請求項６４に記載のシ
ステム。
【請求項６６】発信元から宛先に２つのインターネット・メッセージを伝
達する方法であって、（ａ）第１のメッセージをテンプレートとカスタマイズ部分とに分離するステ
ップと、（ｂ）テンプレートを宛先に伝達するステップと、（ｃ）第２のメッセージをテンプレートとカスタマイズ部分とに分離するステ
ップと、（ｄ）第２のカスタマイズ部分を宛先に伝達するステップであって、テンプレ
ートが、第２のカスタマイズ部分から第２のメッセージを再構成するための情報
を含む方法。