JP6236435B2 - 非同期データ・ディクショナリを使用した、マルチテナント共有インフラストラクチャにおけるストリームベースのデータ重複排除 - Google Patents

Description

本願は、２０１２年５月１７日付け出願の第６１／６４８，２０９号に基づき、これに対する優先権を主張するものである。

本願は一般に、ネットワークを介したデータ通信に関する。

分散型コンピュータ・システムは従来技術で良く知られている。こうした分散型コンピュータ・システムの１つが「コンテンツ配信ネットワーク」又は「ＣＤＮ」であり、典型的にはサービス・プロバイダによって運営及び管理される。サービス・プロバイダは、典型的には、サービス・プロバイダの共有インフラストラクチャを使用する第三者（カスタマ）のためにコンテンツ配信サービスを提供する。この種の分散型システムは、時には「オーバーレイ・ネットワーク」と呼ばれ、典型的には、コンテンツ配信、適用促進、又は外部委託されたオリジン・サイト・インフラストラクチャの他のサポートなどの、様々なサービスを容易にするように設計された、ソフトウェア、システム、プロトコル、及び技法と共に、ネットワークによって結び付けられた自律型コンピュータの集合を言い表す。ＣＤＮサービス・プロバイダは、典型的には、カスタマのポータルに提供された後、ネットワークに展開される、デジタル・プロパティ（ウェブサイトなど）を介してサービスを配信する。

データ差分は、リソースの共有先行インスタンスを活用するための既知の技術及び方法であり、サーバとクライアントとの間での、圧縮用語の共有ディクショナリ内のデータのバージョンとしても知られており、プロセスは、それらの先行インスタンス以降に発生した差異又は変化を送信するだけで作用する。データ差分は圧縮に関係するが、わずかに異なる概念である。特に、直感的に言って、差異はある種の圧縮である。受信者が送信者と同じオリジナル・ファイルを有する限り、その送信者は受信者に新しいファイル全体ではなく差異を与えればよい。差異は事実上、古いファイルから新しいファイルをどのように作成するかを説明するものである。これは通常、新しいファイル全体よりもかなり小さいため、一種の圧縮である。ある文書の第１のバージョンとその同じ文書の第２のバージョンとの間の差異がデータ差異であり、データ差異は、文書の第１のバージョンをプリセット・ディクショナリとして使用した文書の第２のバージョンの圧縮結果である。

ストリームベースのデータ重複排除（deduplication）システムも、従来技術で知られている。一般に、ストリームベースのデータ重複排除システムは、接続の送信側ピアを通じて流れるデータを検査すること、及び、そのデータのブロックを、各ピアが所与のブロック周辺で同期した共有ディクショナリ内を指示するリファレンスに置き換えることによって、作用する。リファレンス自体はデータよりもかなり小さく、しばしばそのハッシュ又はフィンガープリントである。受信側ピアは、修正されたストリームを受信すると、リファレンスをオリジナル・データに置き換えてストリーム全体を再度作成する。例えば、フィンガープリントが、単一の文字変数で表される固有のハッシュであるシステムについて考えてみる。送信側ピアのディクショナリは、図３に示されるような様式となり得る。受信側ピアのディクショナリは、図４に示されるような様式となり得る。そこで、例えば送信側ピアが「Ｈｅｌｌｏ， ｈｏｗ ａｒｅ ｙｏｕ？ Ａｋａｍａｉ ｉｓ Ａｗｅｓｏｍｅ！」などの文字列を送信すると想定すると、重複排除システムが代わりにこのデータを処理し、「Ｈｅ［Ｘ］ｒｅ ｙｏｕ？［Ｔ］［Ｍ］ｏｍｅ！」というメッセージを送信する。受信側ピアは、そのディクショナリを使用してメッセージを復号する。この例では、送信側ピアが「ｏｍｅ！」をリファレンス［Ｏ］に置き換えていないことに留意されたい。これは、送信側ピアはそのキャッシュ内にフィンガープリント及びブロックを記憶しているが、受信側ピアは記憶していないことが（メカニズムを介して）わかるためである。したがって送信側ピアは、メッセージ内にリファレンスを挿入せずにメッセージを送信する。この種のシステムは、典型的には、いくつかの既知の様式では対称型のディクショナリを実装（populate）している。１つの手法では、データ・ストリームが、データ・プロセッサを介して流れる際に、ディクショナリ・データが固定長ブロック（例えば、あらゆるブロックが１５字長さである）内に実装される。データが送信側ピア及び受信側ピアの両方を初めて通過するとき、それらがどちらも同じ方法でディクショナリを構築していると仮定すると、どちらのピアも同じエントリを含むディクショナリを有する結果になる。しかしながらこの手法は、生成されるフィンガープリントに悪影響を及ぼし、方式全体を損なう可能性のある、「シフト」問題として知られる問題を被るため、最適ではない。

代替の手法は、ローリング方式で算出されたハッシュを用いる可変長ブロックを使用する。ラビン・フィンガープリンティングとして知られる技法に基づく良く知られたソリューションでは、システムは、フィンガープリンティング・プロセス中にデータのストリーム全体にわたってあるサイズ（例えば４８バイト）のウィンドウをスライドさせる。この技法の実装は、Muthitacharoen等による「A Low-Bandwidth Network File System」（ＬＢＦＳ）という名称の論文で説明されており、その結果は可変サイズ・シフト防止ブロックを達成する。

ストリームベースのデータ重複排除製品及びサービスを供給する現行のベンダは、デバイスをペアにすることによって、ディクショナリ発見（何の情報がピアのディクショナリに入っているかを知ること）の問題に対処している。したがって、例えば機器／ボックス・ベンダは各エンドでペアのデバイス又はプロセスに依拠して各一方のエンドがもう一方と通信することにより、ペアにされたピアでいずれのリファレンスが存在するかを各サイドに知らせるテーブルを維持する。しかしながら、この種のソリューションは、「パス内（in path）」ペアを表す個別のボックス及びユニットに対処する場合にのみ作用する。

しかしながらパス内ペア・ソリューションは、ノードの分布が木に酷似しているＣＤＮなどのオーバーレイ・ネットワークとの関連では実用的でない。例えば代表的なインプリメンテーションでは、特定のオリジン・サーバ（又は、より一般的には、「ルート」に位置する「テナント」）に関連して、オーバーレイは、ルート近くの親ティア・サーバ（parent tier server）及びリーフ・ノード近くのクライアント・エッジ・サーバを有する場合がある。言い換えれば、ボックスが１つ又は複数のピア・ボックスの小セットを認識する必要があるのではなく、親ティア・サーバが（既知のボックス・ベンダ・ソリューションの場合などのように）それぞれが潜在的に多くのサーバを含む何十、何百、或いは何千のエッジ領域と接触することが必要となる可能性がある。このコンテキストでは、マシーンごとのテーブル（per machine table）はスケーリング不可能である。

米国特許第７，１１１，０５７号 米国特許第７，４７２，１７８号 米国特許第７，３７６，７１６号 米国特許公開第２００４００９３４１９号 米国特許第６，８２０，１３３号 米国特許第７，６６０，２９６号 米国特許第７，２４０，１００号

したがって、オーバーレイ・ネットワークとの関連においてデータ重複排除のための改良技法を提供することが、依然として求められている。

インターネット・インフラストラクチャ配信プラットフォーム（例えばサービス・プロバイダによって運営される）は、オーバーレイ・ネットワーク（「マルチテナント共有インフラストラクチャ」）を提供する。特定のテナントにはたオリジンが関連付けられている。本開示によれば、テナントのオリジンに近い１つ又は複数のオーバーレイ・ネットワーク・サーバには、データ重複排除を提供する重複排除エンジンが備え付けられている。これらのサーバは、典型的にはエンド・ユーザ・アクセス・ネットワークの近くに配置されたエッジ・サーバであるオーバーレイ・ネットワーク・キャッシュ子からの要求を受信するという点で、そのオリジンに対する重複排除キャッシュ親である。エッジ・サーバも、重複排除エンジンを含む。オリジンのコンテンツに対する要求がオーバーレイ・ネットワーク・エッジ・サーバから着信すると、要求は、オリジンについての重複排除キャッシュ親を介してルーティングされる。キャッシュ親はコンテンツを（おそらくオリジンから）引き出した後、従来の重複排除動作を実行する。特に、キャッシュ親はまずオリジンについてその「ライブラリ」（又は「ディクショナリ」）を調べ、すでにわかっているバイトのチャンクを、それらのチャンクにすでに割り当てられている名前に置き換えることによって、オブジェクトを圧縮できるかどうかを確かめる。この動作では、既知の方法でオブジェクトを「圧縮する」。次いで、キャッシュ親は、圧縮されたオブジェクトをオーバーレイ・ネットワーク・エッジ・サーバに送信し、当該オブジェことはそこでエッジ・サーバ重複排除エンジンによって処理される。しかしながら、この配信ループの外側で、重複排除キャッシュ親は、新しくわかったバイトのチャンクを記憶するためにオブジェクトを処理し、それを維持しているライブラリ（又はディクショナリ）に新しいチャンクを入れることも行う。圧縮されたストリームがオーバーレイ・ネットワーク・エッジ・サーバで受信された場合、エッジ・サーバは、名前（又は「フィンガープリント」）によって置き換えられたチャンクを探索した後、自身のディクショナリ内でフィンガープリントをキーとして使用して元のチャンクを引き出すことによって、圧縮されたストリームを処理する。

エッジ・サーバが必要とするチャンクがキャッシュ内にない場合、従来のＣＤＮ手法に従って（例えばキャッシュ階層などを介して）それらを引き出し、必要であれば最終的にそれらを重複排除キャッシュ親から引き出す。かくして、送信側ピアと受信側ピアとのペア間のディクショナリが同期していなくても、適切なセクションがオンデマンドで再同期化される。この手法は、送信側ピアと受信側ピアの特定のペアで維持されるライブラリが同じである（すなわち同期化されている）ことを必要としない（又はその旨を保証する必要がない）。むしろこの技法は、ピアが事実上そのディクショナリを、実際のトランザクションに関連してオンザフライで「埋め戻す（backfill）」ことを可能にする。この手法は非常にスケーラブルであり、いずれのタイプのコンテンツに対しても、またいずれのタイプのネットワークを介しても作用する。

上記では、主題のより適切な特徴のうちのいくつかを概説した。これらの特徴は、単なる例示であるものと解釈すべきである。開示された主題を異なる態様で適用すること、又は、この主題を後述するように修正することによって、他の多くの有益な結果を得ることができる。

次に、主題及びその利点をより完全に理解するために、添付の図面に関連して以下で説明する。

コンテンツ配信ネットワーク（ＣＤＮ）として構成される、既知の分散型コンピュータ・システムを示すブロック図である。 代表的なＣＤＮエッジ・マシーン構成を示す図である。 データ差分プロセスにおける送信側ピア・ディクショナリを示す図である。 データ差分プロセスにおける受信側ピア・ディクショナリを示す図である。 本開示の非同期データ・ディクショナリをインプリメントするための、例示のワイド・エリア・ネットワーク（ＷＡＮ）アーキテクチャを示す図である。 オーバーレイ・ネットワーク及びカスタマ・プライベート・ネットワーク内でインプリメントされる特定の実施形態を示す図である。

図１は、本明細書の技法によって（以下で説明するように）拡張される、既知の分散型コンピュータ・システムを示す。

図１に示されるような既知のシステムでは、分散型コンピュータ・システム１００がＣＤＮとして構成され、インターネットの周囲に分散されたマシーン１０２ａ〜ｎのセットを有するものと想定される。典型的には、ほとんどのマシーンはインターネットのエッジ近くに、すなわちエンド・ユーザ・アクセス・ネットワークに、又はその近傍に配置されたサーバである。ネットワーク・オペレーション・コマンド・センタ（ＮＯＣＣ）１０４が、システム内の様々なマシーンの動作を管理する。ウェブ・サイト１０６などの第三者サイトは、分散型コンピュータ・システム１００、及び特に「エッジ」サーバに対する、コンテンツ（例えばＨＴＭＬ、埋め込みページ・オブジェクト、ストリーミング・メディア、ソフトウェア・ダウンロードなど）の配信を肩代わりさせる。典型的には、コンテンツ・プロバイダは、サービス・プロバイダの権威あるドメイン名サービスによって管理されているドメインに対して、所与のコンテンツ・プロバイダのドメイン又はサブ・ドメインを（例えばＤＮＳ ＣＮＡＭＥによって）エイリアス化することによって、自身のコンテンツ配信を肩代わりさせる。コンテンツを所望するエンド・ユーザは、そのコンテンツをより確実かつ効率的に取得するために、分散型コンピュータ・システムに向けて送られる。詳細には示されていないが、分散型コンピュータ・システムは、利用データ及び他のデータをエッジ・サーバから収集し、そのデータを領域又は領域のセット全体にわたって集約し、そのデータを、モニタリング、ログ記録、警告、課金、管理、又は他の運営及び管理機能を容易にするために、他のバックエンド・システム１１０、１１２、１１４、及び１１６に渡す、分散型データ収集システム１０８などの、他のインフラストラクチャも含み得る。分散型ネットワーク・エージェント１１８は、ネットワーク並びにサーバのロードをモニタリングし、ネットワーク、トラフィック、及びロードのデータを、ＣＤＮによって管理されているコンテンツ・ドメインに関して権限のあるＤＮＳ照会処理機構１１５に提供する。分散型データ移送機構１２０を使用して、エッジ・サーバに制御情報（例えばコンテンツを管理し、ロード・バランシングを容易にするためのメタデータなど）を配信することができる。

図２に示すように、所与のマシーン２００は、１つ又は複数のアプリケーション２０６ａ〜２０６ｎをサポートするオペレーティング・システム・カーネル（Linux又は変種等）２０４を動作させるコモディティ・ハードウェア（例えばIntel Pentiumプロセッサ）２０２を含む。コンテンツ配信サービスを容易にするため、例えば所与のマシーンは典型的に、ＨＴＴＰ（ウェブ）プロキシ２０７、ネームサーバ２０８、ローカル・モニタリング・プロセス２１０、分散型データ収集プロセス２１２等の一連のアプリケーションを実行する。ストリーミング・メディアでは、マシーンは通常、サポートされるメディア・フォーマットの要件に応じて、Windows Media Server（ＷＭＳ）又はフラッシュ・サーバ等の１つ又は複数のメディア・サーバを含む。

ＣＤＮエッジ・サーバは、好ましくは構成システムを利用するエッジ・サーバに配分されている構成ファイルを利用して、好ましくはドメイン特化型、カスタマ特化型の１つ又は複数の広範なコンテンツ配信特性を提供するように構成されている。所与の構成ファイルは、ＸＭＬをベースとし、１つ又は複数の高度のコンテンツ処理特性を容易にする一連のコンテンツ処理規則及び命令を含むことが好ましい。構成ファイルは、データ伝送機構を介してＣＤＮエッジ・サーバに配信することができる。米国特許第７，１１１，０５７号は、エッジ・サーバ・コンテンツ制御情報を配信及び管理するための有用なインフラストラクチャを説明しており、これ等のエッジ・サーバ制御情報は、ＣＤＮサービス・プロバイダ自体、又は（エクストラネット等を介して）オリジン・サーバを運用するコンテンツ・プロバイダ・カスタマによってプロビジョニングすることができる。

ＣＤＮインフラストラクチャは複数の第三者によって共有されるため、本明細書ではマルチテナント共有インフラストラクチャと呼ぶことがある。ＣＤＮプロセスはインターネット上の公開でルーティング可能なノードに、モバイル・ネットワーク内に配置されたノード内又はその近傍に、企業ベースのプライベート・ネットワーク内又はその近傍に、或いはそれらの任意の組み合わせで、配置可能である。

メタデータ構成可能なオーバーレイ・ネットワーク・ウェブ・プロキシ（図２のプロキシ２０７など）は、本明細書ではグローバル・ホスト又はＧＨｏｓｔプロセスと呼ぶことがある。

ＣＤＮは、米国特許第７，４７２，１７８号に記載されたもののような記憶サブシステムを含むことができる。この開示内容は引用により本願に含まれるものとする。

ＣＤＮは、カスタマ・コンテンツの中間キャッシングを提供するためにサーバ・キャッシュ階層を運用することができる。このようなキャッシュ階層サブシステムの一例が米国特許第７，３７６，７１６号に記載されている。この開示内容は引用により本願に含まれるものとする。

ＣＤＮは、米国特許出願公開第２００４００９３４１９号に記載されたように、クライアント・ブラウザ、エッジ・サーバ、及びカスタマ・オリジン・サーバ間でセキュアなコンテンツ配信を提供することができる。これに記載されたセキュアなコンテンツ配信は、一方ではクライアントとエッジ・サーバ・プロセスとの間で、他方ではエッジ・サーバ・プロセスとオリジン・サーバ・プロセスとの間でＳＳＬベースのリンクを実施する。これによって、ＳＳＬによって保護されたウェブ・ページ及び／又はそのコンポーネントを、エッジ・サーバを介して配信することができる。

オーバーレイとしてＣＤＮリソースを用いることにより、（プライベートに管理可能な）エンタープライズ・データ・センタと第三者へのサービスとしてのソフトウェア（ＳａａＳ）プロバイダとの間の広域ネットワーク（ＷＡＮ：wide area network）高速化サービスを容易にしてもよい。

典型的な運営においては、コンテンツ・プロバイダは、ＣＤＮによりサービスされることを望むコンテンツ・プロバイダ・ドメイン又はサブ・ドメインを特定する。ＣＤＮサービス・プロバイダは、（例えば正規名又はＣＮＡＭＥを介して）コンテンツ・プロバイダ・ドメインをエッジ・ネットワーク（ＣＤＮ）・ホスト名と関連付け、するとＣＤＮプロバイダがそのエッジ・ネットワーク・ホスト名をコンテンツ・プロバイダに提供する。コンテンツ・プロバイダのドメイン・ネームサーバは、コンテンツ・プロバイダ・ドメイン又はサブ・ドメインへのＤＮＳクエリを受信すると、エッジ・ネットワーク・ホスト名を返すことによって応答する。エッジ・ネットワーク・ホスト名はＣＤＮを指すので、ＣＤＮネーム・サービスにより解決される。そのために、ＣＤＮネーム・サービスは１つ又は複数のＩＰアドレスを返す。すると、リクエストを行っているクライアント・ブラウザは、そのＩＰアドレスと関連付けられているエッジ・サーバに対して（例えばＨＴＴＰ又はＨＴＴＰＳを介して）コンテンツ・リクエストを行う。このリクエストは、オリジナル・コンテンツ・プロバイダ・ドメイン又はサブ・ドメインを含むホスト・ヘッダを含んでいる。ホスト・ヘッダを有するリクエストを受信すると、エッジ・サーバはその構成ファイルをチェックして、リクエストされたコンテンツ・ドメイン又はサブ・ドメインが実際にＣＤＮによって処理されているのか否かを判断する。処理されているのであれば、エッジ・サーバは、構成に規定されているように、そのドメイン又はサブ・ドメインに対するコンテンツ処理規則及び命令を適用する。これらのコンテンツ処理規則及び命令はＸＭＬベースの「メタデータ」構成ファイル内にあってもよい。

追加の背景として、米国特許第６，８２０，１３３号及び第７，６６０，２９６号で説明されている技法は、図１に示されたようなオーバーレイ・ネットワーク内のエッジ・プロキシとフォワード・プロキシとの間のパケット配信を容易にするために使用可能である。

非同期データ・ディクショナリを使用するストリームベースのデータ重複排除
次に、上記の事柄を背景として、本開示の手法を説明する。ペアリングによるディクショナリ発見（ピアのディクショナリ内に何の情報があるかを知ること）の問題に対処する、既知のストリームベースのデータ重複排除製品及びサービスとは対照的に、本明細書の技法は、異なるパラダイムに従って動作する。

特に、またある特定のサイズのオブジェクトについて、ピア・ノードは、実際にそうであるか否かに関わらず、フィンガープリントに関連付けられたブロックを有するものと「想定」する。この手法では、（送信側及び受信側ピアの任意の特定ペアの）両側で同一のライブラリを維持すること（または同一のライブラリを維持していることの保証）を必要としない。むしろこの手法では、ライブラリが作成され、そのライブラリに（例えばウェブを介して）アクセスすることができる。ライブラリはいずれの場所にでも配置可能である。理解されるように、この手法は、標準のＣＤＮ機能及び特徴を活用することが可能であるため、エンド・ユーザに（固定回線及び非固定回線の両方のネットワーク上のエンド・ユーザを含み、アプリケーション・タイプに関係なく）、重複排除の利点並びにオーバーレイ・ネットワーキング技術によって提供される利点の両方を提供することができる。この代替手法では、ピアが所与のフィンガープリントに関連付けられたブロックを有さない場合、ピアは送信側エージェントにこのブロックを要求するよう、要求を戻す。一実施形態において、各ブロックは、マグネット・スタイル（magnet-style）ＵＲＩなどの当該ブロックに関連付けられた特定のＵＲＩを有する。マグネットＵＲＩは、縮小形でそのコンテンツを記述すること（例えばコンテンツの暗号ハッシュ値）によって、ダウンロード可能なリソースを言い表す。マグネットＵＲＩを使用することに代わる方法は、復号（受信側又は子）ピアをして符号化（送信側又は親）ピア（又はピア領域）に要求を戻させ、何らかの合意済プロトコルを使用して、復号ピアによる復号に使用不可能であるいかなるチャンクに関してもロー・データを要求することである。復号器側でのデータの処理は非常に高速であり、したがって何らかのわずかな処理オーバヘッド時間内にミッシング・チャンクを検出し、符号器に要求を返送することが好ましい。

好ましくは、ミッシング・ブロックに関して送信側ピアへの無関係なラウンド・トリップの返送を避けるために、特別な注意が払われる。したがって一実施形態では、非常に小さな、例えば１つの初期輻輳ウィンドウ（ＣＷＮＤ）内で送信されるファイルは、ブロックが受信側ピアに存在する場合、ブロック・キャッシュ・ミスのリスクがペイアウト（payout）よりも大きいため、重複排除されない。これは、ネットワークＩ／Ｏカードへのシリアル化遅延が、キャッシュ・ミス時に発生し得る待ち時間よりも大幅に小さいためである。したがって好ましくは、（ミッシング・ブロックによって起こり得る余分な待ち時間に直面した場合であっても）重複排除を使用するいずれかの利点があることの統計的確率が存在する応答のみを考慮すべきである。

したがって、本開示に従い、重複排除システムは、互いに明示的に通信するピアを含むことが可能であり、そのようなピアが、別のピアが何を有しているか又はその反対であるかに関して、ある想定を立てることに関わる、オンデマンド・キャッシュ同期化プロトコルを使用する。このプロトコルに従い、ローカル符号化ピアが所与のデータ・ブロックをすでに有する場合、復号ピアはそのブロックを有すること、及び、ローカル符号化ピアが所与のデータ・ブロックを有さない場合、復号ピア・エンティティはそのブロックを有さないことを、想定してよい。さらにシステムは、ピア間のキャッシュ同士の不一致の原因となる。これが生じた場合、不一致を解決する。このために、何らかのデータ（ストリーム内に見られたオブジェクト、チャンク、チャンクのセットなど）が復号に使用できない場合は必ず、復号ピアは符号化ピア（又はピアの領域）に要求を戻し、必要なロー・データを要求する。前述のように、復号器側でのデータの処理は非常に高速であるため、わずかな処理オーバヘッド時間内にミッシング・データが検出され、符号器に要求が返送される。この手法は、いずれのキャッシュ同期化プロトコルが利用されているかに関わらず、トランザクションが完了可能であることを保証するフォールバック機構が存在することを保証する。かくして、ミッシング・データ・サポートは、完全なキャッシュ・ミスの可能性に対処し、前述のキャッシュ同期化手法と共に使用することができる。

このタイプの重複排除手法を実装するための代表的なアーキテクチャが、図５に示されている。簡略化するために、クライアント５００がエッジＧＨｏｓｔプロセス５０２と対話しており、エッジＧＨｏｓｔプロセス５０２は（典型的にはＷＡＮを介して）、テナントオリジン５０６付近に配置されたフォワードＧＨｏｓｔプロセス５０４と通信するように示されている。各ＧＨｏｓｔプロセス５０２及び５０４には、重複排除エンジン５０８、ディクショナリのための付随データ・ストア、及び他の関連プロセスが関連付けられている。これらの要素は、集合的に重複排除モジュールと呼ぶことがある。キャッシュ親は、フロント・エンド最適化（ＦＥＯ）などの他の技術も実装可能である。ＧＨｏｓｔは、何らかのインターフェースを介して重複排除モジュールと通信する。代替実施形態では、重複排除機能はＧＨｏｓｔ内にネイティブに実装されている。オリジンのコンテンツに関する要求がプロセス５０２から着信すると、要求はオリジンに対するキャッシュ親５０４を介してルーティングされる。キャッシュ親５０４は、（おそらくはオリジンから）コンテンツを引き出した後、その重複排除エンジン５０８を使用して、従来の重複排除動作を実行する。特に、キャッシュ親はまずそのライブラリ内を調べ、すでに分かっているバイトのチャンクをそれらのチャンクに対してすでに割り当てられている名前に置き換えることによって、オブジェクトを圧縮できるかどうかを調べる。ライブラリが複数のＣＤＮカスタマ間で共有されるのが好ましいが、代替の実施形態では、ライブラリは特定のオリジンに固有のものである。次いで、キャッシュ親５０４は、圧縮されたオブジェクトをエッジ・サーバ・プロセス５０２に送信し、そこでエッジ・サーバ重複排除エンジン５０８によって処理される。しかしながら、この配信ループの外側では、重複排除親５０４は新しく分かったバイトのチャンクを記憶するためにオブジェクトを処理し、新しいチャンクをそのライブラリに入れる。圧縮されたストリームがエッジ・サーバ・プロセス５０２で受信された場合、エッジ・サーバは、名前（又は「フィンガープリント」）によって置き換えられたチャンクを探索した後、その名前を使用してオリジナルのチャンクを引き出すことによって、圧縮されたオブジェクトを処理する。

より具体的な実施形態が図６に示されている。このシナリオでは、エンド・ユーザ６００は、通常の様式でオーバーレイ・ネットワークＤＮＳを介してエッジ・サーバ・マシーン６０２に関連付けられている。「エンド・ユーザ」とは、クライアント・マシーン（例えばデスクトップ、ラップトップ、モバイル・デバイス、タブレット型コンピュータなど）上で実行されるウェブ・ブラウザ・ユーザ・エージェント、又はそうしたデバイス上で実行されるモバイル・アプリケーション（app）である。「エンド・ユーザ」は、ＨＴＴＰ又はＨＴＴＰＳを介してエッジ・サーバ・マシーンと通信し、こうした通信は、他のネットワーク、システム、及びデバイスを横切ることができる。エッジ・サーバ・マシーンは、オーバーレイ・ネットワーク・プロバイダによって管理されるメタデータ構成可能なウェブ・プロキシ・プロセス（ＧＨｏｓｔ）６０４、及び関連付けられたストリームベースのデータ重複排除プロセス６０６を実行する。以下説明するように、重複排除プロセスは、理論上は、すべてのＣＤＮカスタマからの、すべてのファイルのすべてのブロックでデータ圧縮を実行する。この手法では、重複排除を実行するために、異なるＵＲＩからの１つのファイルの複数ピースを使用するか、または複数のファイルからの複数ピースを同時に使用してもよい。エッジ・サーバ・マシーン６０２は、別のオーバーレイ・サーバ機器（図示せず）で実行中の親ＧＨｏｓｔプロセス６０８などの、１つ又は複数の「親」ノードに対する「子」とすることができる。この例では、ＧＨｏｓｔプロセス６０８は「パススルー（pass-through）」であって差分機能は提供せず、省略することができる。

さらに図６に示すように、クライアント側からの要求は「オリジン」サーバ６１２に差し向けられる。オリジン（又はターゲット）サーバ６１２は、典型的にはオーバーレイ・ネットワーク・カスタマ・インフラストラクチャ（又はおそらくは、第三者クラウドベース・インフラストラクチャなどの何らかの他のホスティングされた環境）内で実行されるサーバである。典型的には、オリジン・サーバ６１２は、ウェブベースのフロント・エンドを、オーバーレイ・ネットワーク・インフラストラクチャを使用して迅速化されることが望ましいウェブ・サイト又はウェブアクセス可能なカスタマ・アプリケーションに提供する。限定的であることを意図していないこの例示のシナリオでは、オリジン・サーバ６１２はカスタマ独自のプライベート・ネットワーク６１４内で実行される。カスタマ・プライベート・ネットワーク６１４は物理マシーン６１５を含む。そのマシーン（又はカスタマ・ネットワーク内の何らかの他のマシーン）は、別のウェブ・プロキシ・プロセス６１８及び関連付けられた重複排除プロセス６２０をサポートすることができる。ウェブ・プロキシ６１８はメタデータ構成可能である必要がなく、オーバーレイ・ネットワークによって積極的に管理される必要もない。前述のアーキテクチャは限定的であることを意図しておらず、むしろ単なる例として提供されている。

以下で、エンド・ツー・エンド・フローについて説明する。このシナリオでは前述のように、「ＧＨｏｓｔ」はオーバーレイ・ネットワーク内のエッジ機器で実行されるメタデータ構成可能なウェブ・プロキシ・プロセスを言い表し、「ＡＴＳ」は、オーバーレイ・ネットワークとは別個のカスタマ・ネットワーク又はインフラストラクチャ内の機器上で実行されるオーバーレイ・ネットワークのウェブ・プロキシ・プロセスを言い表し、また、重複排除プロセスは、（この例示の実施形態において）特定のカスタマのネットワークに対してローカルのすべてのファイルからのすべてのブロックに関して重複排除を実行することができる。前述のように、そして採用されるネットワーク・アーキテクチャに依存して、関連付けられた重複排除プロセスがすべての（又はいくつかの）オーバーレイ・ネットワーク・カスタマからのすべてのブロックに関して重複排除を実行することができるように、ライブラリを共有してもよい。例示の実施形態では、ＧＨｏｓｔ（又はＡＴＳ）プロセスは、場合によっては関連付けられた重複排除プロセスとインターフェース（例えばローカルホスト）を介して通信可能である。

図６に示されたような代表的な（但し非限定的な）実装において、オーバーレイ・ネットワーク・プロバイダは、カスタマのインフラストラクチャ（プライベート・ネットワーク）内で実行するソフトウェアを、例えば仮想マシーン（ＶＭ）又は「エッジ機器」として提供する。エッジ機器６１０は、好ましくは、ＤＭＺ内又は企業ファイアウォールの背後のいずれかに配置され、オーバーレイ・ネットワーク・カスタマによってサポート及び管理されるハイパーバイザ（例えばＶＭｗａｒｅ ＥＳＸｉ（ｖ．４．０＋））６１６上で実行可能である。好ましい一実施形態では、エッジ機器は、オーバーレイ・ネットワークカスタマポータル（エクストラネット）を介してダウンロードされる６４ビット仮想機器として配布される。各エッジ機器は、少なくとも１つのパブリックにルーティング可能なＩＰアドレスを必要とし、好ましくはセキュア接続を介して、オーバーレイ・ネットワークによって構成可能である。

したがって、上記の手法に従い、テナントのオリジンに関連付けられた少なくとも１つのサーバは重複排除エンジンを備える（又はこれに関連付けられる）。コンテンツに対する要求がエッジ・サーバから来ると、要求はオリジンについての重複排除キャッシュ親を介してルーティングされる。キャッシュ親は（おそらくオリジンから）コンテンツを引き出した後、コンテンツ・サイズ及び適用可能な任意の構成パラメータに応じて、重複排除を実行する。重複排除が行われると、親キャッシュはそのディクショナリを検査し、（すでに分かっているバイトのチャンクを、それらのチャンクにすでに割り当てられた名前に置き換えることによって）オブジェクトを圧縮できる場合、そのように実行する。次いで、キャッシュ親は、圧縮されたオブジェクトをエッジ・サーバに送信する。それとは別に、重複排除キャッシュ親は、新しく分かったバイトのチャンクを記憶するためにオブジェクトを処理し、維持しているライブラリ内にそれらを入れる。圧縮されたオブジェクトがエッジ・サーバで受信されると、前述のように、エッジ・サーバは、名前によって置き換えられたチャンクを探索した後、前述のように名前を用いてオリジナルのチャンクを引き出すことによって、圧縮されたオブジェクトを処理する。

一般化すると、本開示に従って、ストリームが親ノードを通過する／横切ると、親ノードはストリームをチャンクに分割する。次に親は、あらゆるチャンクについて、ストリームの送信先である子ノードがそのチャンクを有するかどうかに関して、事実上の「推測」を行う。「推測」は、例えば統計的かつ確率的に、何らかの発見的解決法に基づいてよいし、アルゴリズムの実行に基づいて導出されてもよいし、子の相対的位置に基づいてもよいし、ロード、待ち時間、パケット損失、又は他のデータに基づいてもよいし、或いは、何らかの他の方法で決定してもよいが、いずれかの方法で知ることができる。子が未だにチャンクを有していないようだと親が判断した場合、親は実際のデータを送信する。しかしながら、子がチャンクを有しているようだと親が判断した場合、親は単に名前／フィンガープリントを送信する。子が符号化されたストリームを取得し、あらゆるチャンク参照／名前についてストリームの復号を開始すると、次に子は、独自のローカル・ライブラリ／ディクショナリ内で名前を検索する。チャンクが存在する場合、子はそれを再展開する。しかしながら、チャンクが存在しない場合、子はチャンクについて実際のデータを要求するオンデマンド要求を（例えば符号化ピア／領域に対して）実行する。

この手法を用いると、ＣＤＮのすべての既知の利点（例えばロード・バランシング、キャッシング、ＷＡＮ促進など）が活用される。重要なことに、エッジ・サーバは、オリジンについて対称型のライブラリを維持する必要がない。むろん、エッジ・サーバはキャッシュ内にチャンクを有するであろうが、有していない場合は、通常のＣＤＮ様の手順に従って（例えばキャッシュ階層などを介して）それらを引き出し、必要であれば最終的に重複排除キャッシュ親からそれらを引き出す。

ＧＨｏｓｔプロセスは、要求が重複排除プロセスによって処理されるべきかどうかを判断する機能を有する。この判断を行うための技法の１つはテナント固有のメタデータを使用するものであり、この技法は米国特許第７２４０１００号で説明されている。

重複排除モジュールは、ＧＨｏｓｔについてのバディ・プロセス又はイン・プロセス・ライブラリとして実行することができる。ＧＨｏｓｔとモジュールとの間の通信機構は、共有メモリ、ローカルホスト、ＴＣＰ、ＵＤＳなどを介することができる。代替実施形態では、クライアント側の重複排除モジュール自体を、エンド・ユーザ・クライアント（ＥＵＣ）ネットワーク・マシーン、モバイル・デバイス・ハンドセットなどの、クライアント・デバイス上に直接配置することができる。

重複排除が実行されるかどうかを好ましくはメタデータ構成によって、好ましくはテナントごとに制御するようにしてよい。

前述のように、小さすぎるファイルについては重複排除機構を起動しないことが好ましい。したがって、小オブジェクト回避（aversion）サポートは、他の方法ではキャッシュ・ミス時に余分なＲＴＴを発生させる可能性のあるリスキーな重複排除動作の実行を、インテリジェントに回避する方法を提供する。これは一手法では、ＰＯＳＴに対する重複排除動作及びあるしきい値未満である「コンテンツ長さ」のヘッダを含む応答を、ＧＨｏｓｔにバイパスさせることによって達成可能である。しかしながら、ほとんどの動的コンテンツはチャンク化された転送符号化を使用するものであり、これはオブジェクトのサイズが予めわかっていないことを意味する。したがって、他の基準に基づいて重複排除を回避するための何らかの決定がなされない場合、ＧＨｏｓｔは、説明した機構を介して要求を渡さなければならない。

加えて、他方の側がデータを有している可能性があることが十分に保証されている場合にのみ、フィンガープリントを送信することが好ましい。かくして、好ましくは、ブロックが同じストリーム内に見つかった場合にのみ、フィンガープリントを送信する。

何らかのファイル形式（ハフマン符号化など）では大幅に圧縮されるけれども、同時に乱雑化する（jumbled）。市販の重複排除システムはしばしば、フィンガープリント及びチャンク化を実行する前にそれらのファイル・タイプをより重複排除に適した形式に復号するシステムを、その重複排除エンジンに提供する。こうした手法は、本発明でも同様に実装可能である。特に、それぞれの側（ＧＨｏｓｔ又は重複排除モジュール自体のいずれであっても）が、キャッシュ・ブロック・ヒットをより確実にするべく、ファイル形式ごとの圧縮解除フィルタを実装しても差し支えない。

本明細書で説明するＧＨｏｓｔ／重複排除モジュール・ソリューションは、プロトコル・ターミネータ（terminator）と相互動作するようにしてよい。プロトコル・ターミネータは、プロトコル（ＣＩＦＳ又はＭＡＰＩなど）を終了させ、これを例えばｈｔｔｐに変換するソフトウェアである。

重複排除モジュールは、ＦＥＯ技法などの他のＣＤＮ機構と相互動作するようにしてもよい。

図６に示されるように、本明細書で説明する１つの重複排除モジュールを、企業ＤＭＺ内に配置されたオーバーレイ・ネットワークに関連付けられたマシーンなどの、企業ネットワーク内に配置することができる。

さらに図６に示されるように、本明細書で説明する重複排除モジュールを、オーバーレイ・ネットワークを使用するか、又はこれと相互動作する企業に関連付けられた仮想マシーン（ＶＭ）内に配置することができる。しかしながら、フォワード・プロキシを企業（又は他のカスタマ・プライベート・ネットワーク）内に配置する必要がないため、このアーキテクチャに限定される訳ではない。

本明細書で説明する重複排除技法は、ＣＤＮのノード対ノード通信（ネットワーク内重複排除）などを容易にするために、１つ又は複数の他のＣＤＮサービス・オファリングに関連して使用することができる。

ＧＨｏｓｔ及び重複排除モジュールはソフトウェアの形態でインプリメントされ、専用マシーンとして１つ又は複数のプロセッサ内で実行される。

説明した技法によって処理可能なデータのタイプに制限はない。実際、あるデータ・タイプ（ＰＩＩなど）について、本明細書で説明するようなデータ重複排除は、キャッシング単独に勝る大幅な利点を有している。

重複排除機能は、デーモン・プロセス、すなわちハードウェア・プロセッサによって実行されるコンピュータ・プログラム命令のセットの形態で、インプリメント可能である。デーモンは、前述のＨＴＴＰベース・プロトコルにおいて、クライアント及びサーバの両方として機能可能である。好ましくは、これは、オーバーレイ・ネットワーク内での通信の高待ち時間レグの終わりに、サーバ（例えばＧＨｏｓｔ）内又は上に分流（shunt）される。前述のように、好ましくは、メタデータ構成データによって、（接続の送信側での）特定の要求が、プロトコルを使用して促進されるべき要求とみなされるべきであるかどうかを判断する。

一般に、本明細書で説明する手法は、オーバーレイ・サーバが、ネットワークのピア間で冗長データを送信する代わりに、はるかに小さなフィンガープリントを送信できるようにするものである。これにより、重複データが大量にあるトランザクションについて、回線上の全データのサイズが劇的に低減され、エンド・ユーザへの配信時間が短縮される。加えて、データ減少の結果として、転送される情報量及び帯域幅が必然的に減少するため、ネットワークの運営コストが引き下げられる。

前述の手法はかなりスケーラブルであり、いずれのタイプのコンテンツに対しても、またいずれのタイプのネットワークを介しても作用する。クライアントは、ウェブ・ブラウザ又は他のレンダリング・エンジン（モバイル・アプリケーションなど）を実行する、従来のデスクトップ、ラップトップ、又は他のインターネット・アクセス可能マシーンである。クライアントは、モバイル・デバイスとすることもできる。本明細書で使用される場合、モバイル・デバイスは、例えば携帯電話、ページャ、携帯情報端末（例えばＧＰＲＳ ＮＩＣを備えるＰＤＡ）、スマートフォン・クライアントを備えるモバイル・コンピュータなどの、任意のワイヤレス・クライアント・デバイスである。手法を実施可能である他のモバイル・デバイスは、ワイヤレス・プロトコルを使用してデータをワイヤレスで送受信することが可能な、任意のアクセス・プロトコル対応デバイス（例えばｉＯＳ（商標）ベースのデバイス、Ａｎｄｒｏｉｄ（商標）ベースのデバイスなど）を含む。典型的なワイヤレス・プロトコルは、ＷｉＦｉ、ＧＳＭ／ＧＰＲＳ、ＤＣＭＡ、又はＷｉＭａｘである。これらのプロトコルは、従来のネットワーキング・スタックが構築されるＩＳＯ／ＯＳＩ物理及びデータ・リンク層（レイヤ１及び２）を実装し、ＩＰ、ＴＣＰ、ＳＳＬ／ＴＬＳ、及びＨＴＴＰで完了する。代表的な実施形態では、モバイル・デバイスは、ＧＳＭネットワークについてのデータ技術であるＧＰＲＳ（汎用パケット無線通信システム）を介して動作する、携帯電話である。本明細書で使用されるモバイル・デバイスは、加入者固有情報を担持するスマート・カードである加入者識別モジュール（ＳＩＭ）、モバイル機器（例えば無線及び関連付けられた信号の処理デバイス）、マンマシーン・インターフェース（ＭＭＩ）、及び、外部デバイス（例えばコンピュータ、ＰＤＡなど）への１つ又は複数のインターフェースを含む、３Ｇ（又は次世代）適合デバイスとすることができる。本明細書で開示される技法は、特定のアクセス・プロトコルを使用するモバイル・デバイスでの使用に限定されるものではない。モバイル・デバイスは、典型的には、Ｗｉ−Ｆｉなどのワイヤレス・ローカル・エリア・ネットワーク（ＷＬＡＮ）技術をサポートしている。ＷＬＡＮはＩＥＥＥ ８０２．１１規格に基づいている。

より一般的には、本明細書で記載された技術は、一緒になって上述の機能を容易にし又は提供する、一連の１つ以上のコンピュータ関連のエンティティ（システム、マシーン、プロセス、プログラム、ライブラリ、機能など）を用いて提供される。典型的な実施形態においては、ソフトウェアが実行される代表的なマシーンは、コモディティ・ハードウェア、オペレーティング・システム、アプリケーション・ランタイム環境、及び一連のアプリケーション又はプロセス、ならびに関連データであって、所与のシステム又はサブシステムを提供するものから成る。既述の通り、機能はスタンドアロン・マシーンの形態でインプリメントされてもよいし、あるいは一連の分散されたマシーンにわたってインプリメントされてもよい。機能はサービス、例えばＳａａＳソリューションとして提供されてもよい。

上記は本発明のいくつかの実施形態によって実行される動作の特定の順序を記載したが、代替的な実施形態では、異なる順序での動作の実行、いくつかの動作の組み合わせ、いくつかの動作の重複等があり得るから、このような順序は例示的なものであることは理解されよう。本明細書における所与の実施形態の参照は、記載する実施形態が特定の特性、構造、又は特徴を含む場合があるが、全ての実施形態がその特定の特性、構造、又は特徴を必ずしも含むものではないことを示している。

開示した主題は、方法又はプロセスに照らして記載したが、主題の開示は本明細書における動作を実行するための装置にも関する。この装置は、必要な目的のために特別に構築してもよく、又はコンピュータに記憶したコンピュータ・プログラムによって選択的に活性化又は再構成される汎用コンピュータを含んでもよい。そのようなコンピュータ・プログラムは、限定ではないが、光ディスク、ＣＤ−ＲＯＭ、及び光磁気ディスクを含むいずれかのタイプのディスク、読み出し専用メモリ（ＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）、磁気もしくは光カード、又は電子命令の記憶に適したいずれかのタイプの媒体等のコンピュータ読み取り可能記憶媒体に記憶することができ、その各々はコンピュータ・システム・バスに結合される。

システムの所与のコンポーネントを別個に記載したが、それらの機能のいくつかは、所与の命令、プログラム・シーケンス、コード部分等において組み合わせるか共有することが可能であることは当業者には認められよう。

これは限定ではないが、特定の機能の一部はオペレーティング・システム等に内蔵できるから、機能はアプリケーション層ソリューションの形態でインプリメントされるのが好ましい。

機能はまた、ＳＳＬ ＶＰＮなどの、ＨＴＴＰＳ以外の他のアプリケーション層プロトコル、又は類似の動作特性を有する他のプロトコルによってインプリメントされてもよい。

接続のクライアント側又はサーバ側をインプリメントし得るコンピューティング・エンティティのタイプに限定はない。いかなるコンピューティング・エンティティ（システム、マシーン、デバイス、プログラム、プロセス、ユーティリティなど）であっても、クライアント又はサーバとしての機能を果たすことができる。

Claims (14)

1. 送信側ピア・エンティティ、受信側ピア・エンティティ、及びデータ重複排除機構を備えるシステムであって、
   前記送信側ピア・エンティティは、第１のディクショナリと、前記送信側ピア・エンティティを介して流れるデータを検査すること、及び、前記データのブロックを前記第１のディクショナリ内を指示するリファレンスに置き換えることによって、ストリームベースのデータ重複排除を提供するように動作可能なプロセッサで実行されるプログラム・コードとを備えており、前記送信側ピア・エンティティはさらに、前記データのチャンクごとに、前記受信側ピア・エンティティが前記データ・チャンクを既に有している可能性を判断し、前記判断に基づいて前記受信側ピア・エンティティに対して前記データ・チャンク又は当該データ・チャンクへのリファレンスの一方を送信し、前記送信側ピア・エンティティが前記受信側ピア・エンティティは前記データ・チャンクを有している可能性がないと判断したときは、前記受信側ピア・エンティティが前記データ・チャンクを実際に有しているかどうかに関係なく、前記データ・チャンクが送信され、
   前記受信側ピア・エンティティは、コンテンツを前記第１のディクショナリのコンテンツと同期させる必要がない第２のディクショナリと、前記受信側ピア・エンティティを介して流れるデータを検査すること、及び、前記データのブロックを前記第２のディクショナリ内を指示するリファレンスに置き換えることによって、ストリームベースのデータ重複排除を提供するように動作可能なプロセッサで実行されるプログラム・コードとを備えており、
   前記データ重複排除機構は、前記受信側ピア・エンティティがデータ重複排除動作を実行する必要のある１つ又は複数のデータ・チャンクを、前記受信側ピア・エンティティが識別及び取得できるようにするための機構である、
   データ重複排除のためのシステム。
2. 前記１つ又は複数のデータ・チャンクが前記送信側ピア・エンティティから取得される、請求項１に記載のシステム。
3. データ・チャンクが、マグネットＵＲＩと、送信側及び受信側のピアによる合意済みの要求・応答プロトコルとのうちの１つを使用して取得される、請求項１に記載のシステム。
4. データ・チャンクがキャッシュ可能なウェブ・オブジェクトである、請求項１に記載のシステム。
5. 前記送信側及び受信側ピア・エンティティが、マルチテナント共有インフラストラクチャに関連付けられる、請求項１に記載のシステム。
6. 前記送信側ピア・エンティティが、前記１つ又は複数のデータ・チャンクを処理するための機構を含む、請求項１に記載のシステム。
7. 前記第２のディクショナリのコンテンツが、オンデマンドで前記第１のディクショナリのコンテンツと再同期化される、請求項１に記載のシステム。
8. 送信側ピア及び受信側ピアを備えるオーバーレイ・ネットワーク内で動作する方法であって、前記送信側ピアはテナントのオリジンに関連付けられ、また、前記受信側ピアはオーバーレイ・ネットワーク・エッジに関連付けられており、
   前記方法は、
   前記送信側ピアに関連して第１のディクショナリを維持すること、及び、
   前記受信側ピアに関連して第２のディクショナリを維持すること、を含み、前記第１のディクショナリ及び前記第２のディクショナリは同期されておらず、
   前記方法はさらに、
   前記送信側ピア及び前記受信側ピアを介して流れるデータを検査すること、及び、前記データのブロックを前記第１及び第２のディクショナリ内を指示するリファレンスに置き換えることによって、ストリームベースのデータ重複排除を提供することを含み、前記ストリームベースのデータ重複排除は、前記送信側及び受信側のピア内のハードウェア要素で実行されるソフトウェアを使用して実行されるものであり、前記送信側ピアはさらに、前記データのチャンクごとに、前記受信側ピアが前記データ・チャンクを既に有している可能性を判断し、前記判断に基づいて前記受信側ピアに対して前記データ・チャンク又は当該データ・チャンクへのリファレンスの一方を送信し、前記送信側ピアが前記受信側ピアは前記データ・チャンクを有している可能性がないと判断したときは、前記受信側ピアが前記データ・チャンクを実際に有しているかどうかに関係なく、前記データ・チャンクが送信され、
   前記方法はさらに、
   前記送信側ピアは、前記送信側ピアが所与のデータのブロックを有する場合、前記受信側ピアが前記所与のデータのブロックを有するものと想定し、その逆もまた同様であるプロトコルを、前記第１及び第２のディクショナリ全体にわたって施行すること、及び、
   前記受信側ピア・エンティティがデータ重複排除動作を実行する必要のある１つ又は複数のデータ・チャンクを、前記受信側ピアによって選択的に識別及び取得すること、
   を含む、方法。
9. 前記１つ又は複数のデータ・チャンクが前記送信側ピアから取得される、請求項８に記載の方法。
10. データ・チャンクが、マグネットＵＲＩと、送信側及び受信側のピアによる合意済みの要求・応答プロトコルとのうちの１つを使用して取得される、請求項８に記載の方法。
11. データ・チャンクがキャッシュ可能なウェブ・オブジェクトである、請求項８に記載の方法。
12. 前記送信側ピアが前記１つ又は複数のデータ・チャンクを処理する、請求項８に記載の方法。
13. 前記第２のディクショナリのコンテンツが、オンデマンドで前記第１のディクショナリのコンテンツと再同期化される、請求項８に記載の方法。
14. 前記データ重複排除機構は、データ・オブジェクトのサイズを判断し、前記データ・オブジェクトのサイズが所与の閾値を下回ると判断したことに応答して、前記データ・オブジェクトの重複排除をバイパスする、請求項１に記載のシステム。