JP2003527669A - 両指向性周辺キャッシュ装置と方法 - Google Patents

Abstract

(57)【要約】 少なくとも1個のネットワークの一部であるエンドユーザから発せられたコンテンツリクエストに対して約50%乃至約80%のヒット率を得る装置と方法である。コンテンツリクエストは、エンドユーザのネットワークに作動可能に直接に通信するキャッシュファームとの通信により行われる。エンドユーザのネットワークはキャッシュファームに作動可能に直接に接続された少なくとも2個のネットワークの1つである。本出願のキャッシング装置と方法はISPネットワーク周辺ルータと接続された一連の小さい（デイスク容量に換算して）キャッシュファーム、透過キャッシュ或いは“インジェクタ”を使用する。インジェクタはネットワークアクセスポイント(NAP)にクラスタにされてもよい。これらのNAPにおけるネットワークはこれらのネットワークのルータ上でWCCPプロトコル或いはレイヤ4スイッチを使用してこれらのネットワークのトラッヒクをこれらのインジェクタクラスタ即ちキャッシュファームに再向させる。この再向はネットワーク周辺ルータからインジェクタ即ちキャッシュファームへの専用に高速の“クロス接続”上で行われる。ネットワーク周辺ルータは、そのネットワークのエンドユーザのために外に出るコンテンツリクエストを扱い、そのネットワークのコンテンツプロバイダ顧客のために内部のコンテンツリクエストを扱うようにプログラムされる。インジェクタキャッシュファームに位置していないコンテンツに対して、インジェクタキャッシュファームはセントラルキャッシュを通信してセントラルキャッシュがリクエストされたコンテンツを有しているかどおうかを決定する。本出願の装置ろ発明によれば、リクエストされたコンテンツがセントラルキャッシュ上にキャッシュされる即ち格納される可能性は少なくとも約75%であり、従って、エンドユーザはNAPあるいはバックボーンインターネット上の電子トラッヒクを使わずにリクエストしたコンテンツを受け取る。

Description

【発明の詳細な説明】

【０００１】 発明の背景 本発明は、例えば小さい透過キャッシュ、代理キャッシュ、或いは実質的に同
じ機能を果たす同等物といった、クエリーあるいはコンテンツリクエストをセン
トラルキャッシュに入れる装置を用いるキャッシュ装置と方法に係り、更に詳し
くは、両指向性周辺キャッシュ装置関し、更に詳しくは、エンドユ‐ザ（インタ
ーネットサービスプロバイダ(ISP)の外部帯域幅を増加することなしに、キャッ
シュファームとシブリング、あるいはセントラルキャッシュの使用によるインタ
ーネットサイトのコンテンツ或いはコンテンツサイトの問い合わせのヒット率を
増加させる装置と方法に関する。更に詳しくは、最もアクセスされるコンテンツ
の約8%から約50%までもがキャッシュファームに保存され、残りの最もアクセス
されるコンテンツの約60%がセントラルキャッシュに保存される装置と方法に関
する。

【０００２】 本出願に規定されているように、HTTPリクエストは“ハイパーテキスト転送プ
ロトコルの略であり、WWWに使われる基本的プロトコルである。HTTPはメッセ‐
ジがどのようにフォーマット化され伝送されるか、（例えば、ネットスケープあ
るいはインターネットエクスプロ‐ラウエブブラウザのような）ＷＷＷサーバー
とＷＷＷブラウザが様々なコマンドに応答してどのような行動をとるべきかを規
定する。例えば、あなたがURL(Uniform Resources Locator)にあなたのブラウザ
で入ると、本明細書に引例として開示されている HYPERLINK http://www.pswebo
paedia.com/ni http://www.pswebopaedia.com/に規定されているように、URLは
実際にWWWサーバへHTTPコマンドを送り、WWWサーバがリクエストされたWWWペー
ジをフェッチして伝送するようにWWWサーバに指示する。

【０００３】 RFC1983( HYPERLINK http://www.cis.ohio-state.edu/htbin/rfc/rfc1983.htm
l http://www.cis.ohio-state.edu/htbin/rfc/rfc1983.html, 本明細書に引例と
して開示されているところに規定されているように、帯域幅は、技術上、伝送チ
ャネルの最高周波数と最低周波数とのへルツ(Hz)で表される差である。しかし、
更に典型的に使われているように、“帯域幅は所定の通信回路で送られることの
できるデータあるいはコンテンツの量である。” 私達の目的のため、また本出
願に使われているように、私達は後者の規定、帯域幅は所定の通信回路で送られ
ることのできるデータあるいはコンテンツの量を言う。

【０００４】 ほとんどのインターネット使用者は、1情報がインターネットで送られた時に
、その情報が意図された目的地に必ず届くのは当然のこととしている。しかし、
その情報を送り、受ける工程はかなり複雑である。

【０００５】 情報がインターネットで送られる際には、伝送制御プロトコル(TCP)はまずそ
の情報をパケットに分解する。それらのパケットを伝送コンピュ‐タはローカル
ネットワーク、インターネットサービスプロバイダ(ISP)、あるいはオンライン
サービスへ送る。そこからパケットは、最終目的地に着く前に、多くの段階のネ
ットワーク、コンピュ‐タ、通信線を通して進み、たぶん町を越え、世界をめぐ
るであろう。多様のハードウエアがそれらのパケットを処理し、それらのパケッ
トを正しい目的地に経路させる。このハードウエアは、ネットワーク間でデータ
を伝送し、インターネットを結びつける糊の多くを構成するように設計されてい
る。ハードウエアの最も重要な部材のうち５個は、スイッチ、ハブ、ブリッジ、
ゲートウエイ、リピータとルータである。

【０００６】 スイッチは、コンピュ‐タとネットワークとを接続してトラヒックの経路を変
更することを可能にする。ブリッジはローカルエーリアネットワーク(LAN)どう
しを接続する。ブリッジは別のLAN宛てのデータがそのLANに送られることができ
るようにしながら、ローカルデータを自分のネットワーク内に保持しておく。ゲ
ートウエイはブリッジに似ているが、１種類のネットワークから別の種類のネッ
トワークへデータを移すこともする。

【０００７】 データがインターネットで伝送される際に、データは時として長い距離を越え
る。このことは、そのデータを送っている信号がその距離を行く間に弱まるとい
う問題となりうる。この問題を解決するために、リピータが、その信号が弱まら
ないように間隔をおいてそのデータを増幅する。

【０００８】 ルータは、インターネットトラヒックを管理するのに重要な役割をする。ルー
タの仕事は、パケットが正しい目的地に送られることを確実にすることである。
データが同じLANにあるコンピュータ間に転送されている場合は、そのネットワ
ーク自身がその内部のトラヒックを取り扱うことができるのでルータはめったに
必要とされない。データが２個の異なるネットワーク間で送られる際にルータは
役割を果たす。ルータはパケットを調べてパケットの目的地を決定する。ルータ
はインターネット上の活動の量を考慮し、パケットを別のルータ−パケットの最
終目的地により近いルータへ送る。

【０００９】 中間レベルのネットワークは、高速データ通信線、イーサネット（登録商標）
とマイクロ波線を用いてLANどうしを接続する。地域ネットワークは地理上の区
域における中間レベルネットワークである。広域ネットワーク(WAN)は中間レベ
ルネットワークの別の種類のものである。WANは多くのネットワークサイトが結
合し合った組織からなる。

【００１０】 パケットが中間レベルネットワーク内のLAN上のコンピュ‐タからその中間レ
ベルネットワーク上のどこかのコンピュータに伝送される際に、ルータ（或いは
一連のルータ）がパケットをパケットの正しい目的地へ送る。しかし、目的地が
中間レベルネットワークの外にある場合は、パケットはネットアクセスポイント
(NAP)へ送られ、そこでパケットはバックボーンネットワークで国内或いは世界
に送られる。超高速バックボーンネットワークサービス(vBNS)のような高速バッ
クボーンネットワークは膨大の量−155メガビット（何百万ビット）/秒(Mbps)を
伝送することができる。驚異的な96億ビット/秒で伝送することができるより速
いバックボーンネットワークさえ作られつつある。

【００１１】 WWW("ウェブ")を含むインターネットは近年膨大な情報源に発達した。テキス
ト、画像、音声画像を含むがこれらに限定されない多くの型の情報が世界のどこ
においてもエンドユ‐ザによる検索に利用できるようにされている。どのような
情報或いはコンテンツ −テキスト、画像、音声画像−を世界のどこのエンドユ
‐ザも容易に検索できるウェブ上に誰でも提示できる。これは、インターネット
と、インターネットの最近もっとも使われている形態であるWWW（wwwとして公知
）の信じがたい成功に役立っている。

【００１２】 インターネットが直面している主要な問題は、あらゆる場所のエンドユ‐ザが
世界のどこからでも情報にアクセスするので通信容量の需要が増加していること
である。インターネットトラヒックはほとんどの国際通信線による全ての従来の
電話とファクシミリトラヒックを既に追いぬいていると推定される。バックボー
ンネットワーク、即ち、膨大の量のインターネットトラヒックを運ぶ超高容量線
を増やすといった、容量の増加が絶えず行われている、非常に遅く、高価な方法
であり、需要が供給を追い越し続けている。インターネットトラヒックが増加す
るにつれてサービス品質(QoS)が低下する。更に、使用者は、彼らがリクエスト
するコンテンツからかなりの距離にある傾向がるため、この距離はインターネッ
トのQoSの有為な要素となり得る。

【００１３】 インターネットコンテンツは測定不可能になりつつあり、たぶん何千テラバイ
トになりつつある。すべてのこれらの情報或いはコンテンツの相対的に小さい部
分集合が、エンドユ‐ザにより、見るために実際にリクエストなされるものの割
合が膨大に大きいことを説明している。

【００１４】 インターネットによる情報の転送を高速化するために、情報が伝送される距離
を制限するために、またインターネットにより実際に伝送される電子トラヒック
の量を制限するために様々のキャッシング方式が提供されてきた。一般に、ほと
んどのキャッシング方式は、例えば単一のインターネットサービスプロバイダ(I
SP)のようなエンドユ‐ザ地域の１エンドユ‐ザによりダウンロードされたファ
イルあるいはコンテンツのコピーを保持して、そのエンドユ‐ザと同じ地域の他
のエンドユ‐ザが、同じキャッシングサーバ/コンピュータへのアクセスを有し
ていればそのコンテンツを見ることができるようにする。キャッシングは、エン
ドユ‐ザ地域の１エンドユ‐ザがファイルあるいはコンテンツを得る際に、ファ
イルあるいはコンテンツのコピーが（例えば代理サーバのようなローカルサーバ
上に）保持されて、同じエンドユーザ地域の他のエンドユ‐ザが同じキャッシン
グサーバ/コンピュータへのアクセスを有していればそのファイル或いはコンテ
ンツを見ることができることを意味する。

【００１５】 従って、キャッシングがほぼ1993年、WWWが創られてから約３年後から使用さ
れてきた。従って、キャッシングは、数人のエンドユーザに同じデータあるいは
コンテンツをリクエストさせる確率が良好なすべてのインターネットデータある
いはコンテンツの部分集合を選択する目的に役立つ。このように、キャッシング
は、エンドユーザにサーブするのに必要なデータ通信容量を減らすのに使うこと
ができる。これは、例えばバックボーンインターネットワークを増やすような上
述のデータ通信容量が限られている場合或いは高価な場合に特に重要である。

【００１６】 典型的なエンドユ‐ザ地域の大きさと均質性に依り、約30乃至60ギガバイトの
キャッシュがエンドユ‐ザ地域外の電子トラヒックを減らし、従って、インター
ネット上では約30乃至約50%減らすであろう（参照：“The Measured Access Cha
racteristics of World-Wide-Web," Bradley M. Duska, David Marwood, & Mich
ael J. Feeley, Department of Computer Science, University of British Col
umbia, in USENIX Symposium on Internet Technologies and Systems, pp. 23-
35, Monterey, California, 12月8-11日、1997、本明細書に引例として開示する
）。WWW上で利用できるコンテンツが増えるにつれて、必要とされるキャッシュ
の大きさは時と共に増加して約30乃至約50%のヒット率（キャッシュからサーブ
される、リクエストされたファイル或いはコンテンツの割合）を保持しなければ
ならない可能性が高い。これらの数字はかなり大きいが、ヒット率が約75%或い
はそれ以上に上げられることができれば有意義な利点を加えることになるであろ
う。典型的なエンドユ‐ザの行動により、1)さらに大きなキャッシュ、最近では
約200乃至約400ギガバイトのオーダのキャッシュが必要になるばかりか、2)特定
のエンドユ‐ザ地域の相対的に多くのエンドユ‐ザ、最近では約数100,000万の
エンドユ‐ザを必要とするであろう。このような大きなエンドユ‐ザ地域が必要
な理由は、エンドユ‐ザ地域が大きいほど、エンドユ‐ザがなにかの利益共同体
を共有している場合は特に、他の誰かがいずれかの所定のファイルあるいは特定
のコンテンツをリクエストした確率が高い。

【００１７】 上述の状態はかなりの興味を引く技術挑戦を生じさせ、このことが異なる解決
策を見出してきた。Mirror Image Internetにより提案され、スエーデン特許出
願第9603753-6号、名称“Internet Communication System",1994年10月4日出願
（本明細書に引例として開示）に記載されている１先行技術の装置によれば、イ
ンターネット情報コンテンツプロバイダによって例えばWWWホームページ或いは
サイトとして提供され、インターネット上のどこかの1次公表サイトに位置する
情報にアクセスしたい使用者USR1は一般には、情報リクエスト、具体的にはHTTP
リクエストをWWWポートへ送り、多重装置を介してインターネットの最初の切り
替え点へ送られ、ここで、リクエストはインターネット上を経路されて最終的に
コンテンツプロバイダに届く。次に、コンテンツプロバイダはリクエストに答え
て、リクエストされた情報をインターネットを介して使用者USR1へ送り返される
。

【００１８】 しかし、上記スエーデン特許出願の第1図に示された、発明の第1実施例によれ
ば、使用者USR1からUSRNへの情報リクエストは、情報リクエストが第1切り替え
点に届く前にインターセプタにより捕捉される。そこで、情報リクエストはイン
ターセプタにより調べられ、インタ‐セプタは、例えば、リクエストされた情報
がコンテンツプロバイダにより提供された情報であるか、インターセプタと直接
接続され、“ミラーサーバ”と呼ばれることのあるローカルサーバ上にコピーと
してあるいは類似して存在するかを決定する。コンテンツプロバイダにより提供
されたリクエストされた情報のコピー或いは類似がローカルサーバに保存されて
いる場合は、使用者からのリクエストはサーバへ再経路され、サーバはリクエス
トされた情報をサーバへ返す。しかし、係わる情報のコピー或いは類似がローカ
ルサーバ上に無いと決定する場合、使用者USR1からUSRNへの情報はインターネッ
ト通信の従来の形態にあるようにインターネットの最初の切り替え点に送られる
。

【００１９】 別の解決策がMirror Image Internetにより提案され、スエーデン特許出願第9
803246-9号、名称"An Internet Caching System and A method and an Arrangem
ent in Such a System," 1998年9月24日出願（本明細書に引例として開示）に記
載されている。この出願に記載されている１解決策は、上記スエーデン出願の第
1図に示されているように多数の“フィーダ”或いは下流エンドコンピュ‐タが
接続された“セントラルキャッシュ”を使う。フィーダはセントラルキャッシュ
のためのセントラルファイルサーバと平行に時間のかかる仕事や時間に厳しい多
くの仕事を行う。結果として、セントラルファイルサーバへの処理ロードが減り
、セントラルファイルサーバがより多くの時間をキャッシュされた情報ファイル
の実際の検索にかけることができるためセントラルファイルサーバは相対的にさ
らに多くのコンテンツリクエストを能率よく処理することができる。上記スエー
デン出願の1方法によれば、“セントラルキャッシュ”は何百万人のエンドユウ
ザまでの規模にすることとコスト効率とを結びつける手段として使われる。

【００２０】 キャッシングはもう1つのインタ‐ネット通信の問題、コンテンツサーバにお
ける混雑を解決するのにも使われてきた。"逆代理“としても知られているこの
コンテンツ側のキャッシングはコンテンツサーバの前に1個或いは数個のキャッ
シングサーバを置くことにより構成される。このことは、良いキャッシュはコン
テンツサーバよりも速くオブジェクトをサーブする（コンテンツ側キャッシュは
さらにもっと限定された一連の仕事するのであり、従って、通常は注文製作のOS
を有する）という事実から主に得られる幾つかの利点を与える。逆代理はサーバ
サイトにおける混雑をこのように減らすが、インターネットの混雑にはなにもし
ない。

【００２１】 従って、この着想はこの業界で発展して、“バックボーンキャッシュ”を展開
させ、これらのバックボーンキャッシュの最良の位置は異なるネットワーク間で
トラヒックが切り替えられる所であると確立された。当初(1998年初頭)、幾つか
のバックボーンキャッシュが配置され、これが多くの用途にとって問題に至った
。このようなことで、ローカルキャッシュがユーザのIPアドレスを使ったコンテ
ンツリクエストを再出できない場合（そして、次のコンテンツリクエストが正し
く戻されるためには）認証方式をやめることができる。公知のように、認証はネ
ットワークトラヒックのインターセプトが始められる前かインターセプトがない
ポート上で行われる。コンテンツリクエストは捕捉されずローカルキャッシュに
より再発行されるので、オリジンサーバはユーザの機械のIPアドレスを見る。認
証は通常に行われ、オリジンサーバは特定のIPアドレスからユーザにセッション
を確立する。

【００２２】 “正常”なコンテンツリクエストがなされると、コンテンツリクエストはルー
タにより捕捉されてローカルキャッシュへ戻される。次に、ローカルキャッシュ
はコンテンツリクエストをオリジンサーバへ再出する。そこで、オリジンサーバ
はローカルキャッシュのIPアドレスを見るが、エンドユーザのIPアドレスを見る
のではないので、認証は行われない。種々のキャッシュ販売者は今これらの問題
のほとんどを解決した。

【００２３】 しかし、バックボーンキャッシュは、バックボーンキャッシュが非常に多くの
位置になければならないという事実に苦しんでいる。というのは、各個々のISP
はバックボーンキャッシングで自分のバックボーンキャッシングを提供しなけれ
ばならないためである。従って、複数個のISPが1個のバックボーンキャッシュを
共有するというよりもむしろ各個々のISPにバックボーンキャッシングの複製が
ある。従って、各バックボーンキャッシュにかなりの量のトラヒックがあるが、
大きいキャッシュの余地があり、各ISPが自分のバックボーンキャッシュを持つ
ことは、エンドユーザとコンテンツサーバとの間のネットワークに相対的に多数
の相対的に大きなキャッシュがあり、各キャッシュが高いコストを有するが相対
的にほとんど価値を加えないであろうということを意味する。このことは、バッ
クボーンキャッシングの概念を無くすと特に真実となるであろう。この場合には
エンドユーザからオリジンサーバまでの経路が多くのバックボーンキャッシュを
通る。多数のバックボーンキャッシュのたった1個がリクエストされたコンテン
ツをコンテンツをリクエストしているエンドユーザへ送るが、多数のバックボー
ンキャッシュのすべてがキャッシュを扱わなければならないであろうということ
は、リクエストされたコンテンツが多数のバックボーンキャッシングの1個上に
位置するまでリクエストの伝送経路がバックボーンキャッシュ間でインターネッ
ト上を行ったり来たりするであろうということにおける帯域幅の問題を創り出す
ことがない。

【００２４】 最近のバックボーンキャッシュはHTTPヒット率を約30乃至約50%の範囲で発生
することができる。しかし、ヒット率を約70乃至約80%の範囲で発生させ、よっ
てインターネットサービスプロバイダ(ISP)用の帯域幅コストを減らし、各ISPの
エンドユーザに更に高質のサービスを提供すのが望ましいであろう。

【００２５】 インターネットは成長しつずける（1995年には6,642,000ホスト、1996年には1
5,000,000ホスト、例えば、 HYPERLINK http://www.davesite.com/webstation/n
et-history.shtml http://www.davesite.com/webstation/net-history.shtmlを
参照）ので、長距離データ通信回路あるいはバックボーンネット‐ワークにより
扱われなければならないデータあるいはコンテンツの量は同様に成長しつずける
。より多くトラヒックを扱う更に多くの回路/バックボーンネットワークを増や
すことは、増えつずけるリクエストされるコンテンツ/データを扱う、回路、ハ
ブ、ブリッジ、ゲートウエイ、リピータ、ルータ等のハードウエアを設置する終
わることのない戦いである。この問題を緩和するのを助けるために、ISPはロー
カルキャッシュを設置した。

【００２６】 第1図に示されているように、NETWORK ISP A"26としたネットワーク上のエン
ドユーザ20,22,24は“ローカルキャッシュ”28を通過してインターネット30に入
り、従って、コンテンツサイト32に入る。エンドユーザを強制的にローカルキャ
ッシュ28を経由させることにより、ローカルキャッシュは種々のコンテンツサイ
トのコンテンツを‘キャッシュ’する、あるいは格納することができる。例とし
て、エンドユーザ24がHTTPリクエストをエンターしコンテンツサイト32に例えば
HTTP:www.example.com/のようにアクセスすると、閲覧ソフト（図示せず）はロ
ーカルキャッシュ２８へ行き、ローカルキャッシュ28はコンテンツのコピーをWW
Wサイト HYPERLINK http://www.example.com www.example.comで検索する。次に
、ローカルキャッシュ28はWWWサイト HYPERLINK http://www.example.com.32 ww
w.example.com.32から検索されたコンテンツのコピーをエンドユーザ24へ送り、
ローカルキャッシュ28の HYPERLINK http://www.example.com www.example.com
から検索されたコンテンツのコピーを格納する。エンドユーザ22がエンドユーザ
24により使用されたのと同じローカルキャッシュ28を通ることによりインターネ
ットと通信し、WWWサイト HYPERLINK http://www.example.com.サイト32 www.ex
ample.com.サイト32へのアクセスをリクエストすると、ローカルキャッシュ28は
、ＷＷＷサイトwww.example.com.に格納されたコンテンツを得るにはインターネ
ット30を経由して HYPERLINK http://WWW.EXAMPLE.COM.サイト32 WWW.example.c
om.サイト32へ行く必要がないであろう、むしろ、ローカルキャッシュ28は、エ
ンドユーザ24による前のリクエストから‘キャッシュ’（格納）したコンテンツ
を送るであろう。ローカルキャッシュ28は、第2（と次のいずれかの）エンドユ
ーザ（達）にコンテンツのもう1つのコピーを得るのにウェブサイト32にアクセ
スする。即ちインターネット30でコンテンツリクエストをウェブサイト32に送り
ウェブサイト32からの応答を待つ必要がなっかたので、通信回路34上の帯域幅が
節約されることはあきらかである。エンドユーザコンテンツリクエストが通信回
路34を通らないので通信回路34はより多くのトラヒックを従ってより広い帯域幅
を扱うことができる。

【００２７】 上記例において、ネットワークISP B 36のエンドユーザは恩恵を得ていない。
ネットワークISP B 36はネットワーク中にローカルキャッシュを使用していない
ので、 HYPERLINK http://WWW.www.example.com.32 WWW.www.example.com.32の
コンテンツのコピーを得てそのコンテンツをリクエストしているエンドユーザ、
例えばエンドユーザ38に返すのに、WWWwww.example.com.32に格納されているコ
ンテンツに対するあらゆるリクエストはインターネット30中を行ったり来たりし
て HYPERLINK http://www.example.com.32 www.example.com.32へ行かなければ
ならない。インターネットを介してのWWWでのこのコンテンツリクエストの伝送
は、ローカルキャッシュ28へのコンテンツリクエストにより応答されるコンテン
ツリクエストよりも相対的に広い帯域幅を使うばかりか、より多くの時間をとる
のは明らかである。というのは、コンテンツリクエストはインターネット30上を
リクエストされたコンテンツをWWWサイト HYPERLINK http://www.example.com.3
2 www.example.com.32に有するサーバへ伝送されてエンドユーザ38に戻されなけ
ればならないからである。

【００２８】 公知のように、節約される帯域幅の量は“バイトキャッシュヒット率”の関数
である。バイトキャッシュヒット率は次のように計算される。

【００２９】 ヒットの大きさ/ すべてのリクエストされたコンテンツの大きさ)*100 従って、もしインターネットキャッシュを使う多くのエンドユーザが500メガ
バイトをリクエストし、100メガバイトはローカルキャッシュからサーブされ、4
00メガバイトがローカルキャッシュにないために源のWWWサイトサーバから検索
されなければならないとすると、バイトヒット率は (100/500)*100 or 20% である。

【００３０】 当業者には容易なはずであるが、資源の利用と復帰速度に関して、エンドユー
ザがコンテンツリクエストがインターネットで源のコンテンツサーバに伝送され
てエンドユーザに戻るのを待つ必要がない点においてバイトキャッシュヒット率
が高いほど良い。更に、エンドユーザISPと源のISPの両者の帯域幅の利用が良く
なる。エンドユーザISPは、コンテンツリクエストと、順次戻ってくるコンテン
ツはコンピュータネットワークアクセスポイント(NAP)に戻る必要がないから恩
恵を受ける。コンテンツプロバイダウェブサイトのISPは、コンテンツサーバが
リクエストされたコンテンツを伝送して源のISPネットワークに戻す必要がなっ
かため、、コンテンツプロバイダウェブサイトのISPはコンテンツプロバイダウ
ェブサイトコンテンツリクエストをその内部ネットワーク上のトラッヒクの型で
コンテンツリクエストを受け取ることがないように決してコンテンツリクエスト
を見ないので、コンテンツプロバイダコンテンツサイトISPのネットワーク上の
需要或いは帯域幅を減らす点で恩恵を受ける。

【００３１】 キャッシュヒット率はユーザコンテンツリクエストとデイスク容量との関数で
あるので、エンドユーザコンテンツリクエスト多いほど、デイスク容量が大きい
ほど、ヒット率は高い。ユーザコンテンツリクエストが多いほど、別のユーザが
特定のコンテンツサーバにある同じオブジェクトをリクエストした可能性が高い
という事実によりヒット率を高める。ユーザがリクエストするコンテンツあるい
はオブジェクトを保持するデイスク容量がない場合にはヒット率は下がるであろ
う。従って、十分はデイスク容量を持つことはヒット率を高める。

【００３２】 より高いヒット率は、源のコンテンツサーバ上にあるより多くのオブジェクト
あるいはコンテンツがキャッシュからサーブされたことを当然に意味する。キャ
ッシュは源のコンテンツサーバサイトよりエンドユーザに近いため、キャッシュ
はオブジェクト或いはコンテンツをエンドユーザへ速く送るように固有に構成さ
れているため、また、キャッシュは源のコンテンツサーバほど典型的にはオーバ
ロードされていないため、ローカルキャッシュが置かれている位置よりも、エン
ドユーザから相対的に更に離れた位置に格納された、源のコンテンツサイトから
コンテンツが戻されるのを待たなければならないのに比べて、典型的にはずつと
速いキャッシュヒットで、リクエストされたコンテンツをエンドユーザは得る。

【００３３】 この低いヒット率問題の1つの可能性のある解決策は、単一位置にひとかたま
りの“キャッシュファーム”を位置させることである。このようなキャッシュフ
ァームは、約300個或いはそれ以上の機械で各機械が4個まで或いはそれ以上のCP
Uと、7ギガバイト或いはそれ以上のデイスク容量を有するいかなる数の個々のフ
ァームからなってもよく、合計で1200個或いはそれ以上のCPUと、21テラバイト
或いはそれ以上のキャッシュ容量を有する。このハードウエアを使うと、約75+%
範囲でヒット率を達成できるであろう。この可能性ある解決策は、全世界のトラ
ッヒクがインタ−ネット上を通信されて単一のキャッシュファームに戻されなけ
ればならないことである。この方法を使うと、エンドユーザはより高度のサービ
スを受けない可能性がもっとも高い。事実、それらのサービス水準はバックボー
ンインターネット上の相対に高い密度の通信により低下するするかもしれない。

【００３４】 例として、ロサンジェルスのエンドユーザがサンフランシスコの源のコンテン
ツサーバからコンテンツをリクエストすると、そのコンテンツリクエストは例え
ばニューヨーク州ニューヨークにあるキャッシュファームを経由して行かなけれ
ばならない、従って、ほんの数百マイル離れて格納されているコンテンツを得る
のに、キャッシュファーム内で数千マイル離れているのに匹敵する少なくとも2
度大陸を横断する。これはどのヨーロッパのエンドユーザにたいしても当てはま
る。ヨーロッパのエンドユーザは、パリ或いはロンドンにあるかもしれない源の
コンテンツサイトからコンテンツを得るのにわざわざニューヨーク州ニューヨー
クへ行かなければならないからである。また、このような方法は、エンドユーザ
のISP装置は実際の帯域幅節約を受けることがないであろうということと、多く
の場合、エンドユーザのISPは余分の内部帯域幅を使い外部帯域幅を節約するか
もしれないことを意味する。従って、エンドユーザがニューヨークのキャッシュ
ファームからコンテンツを得る際には、ISPは自分のネットワークから外へ出る
必要がなく、従って、ISPは外部帯域幅を節約するが、ISPは自分のネットワーク
を通して余分に2度あるいは3度コンテンツを伝送しなければならず、従って、IS
Pがバックボーンインターネットを使用した際の内部帯域幅よりも更に内部帯域
幅を使用する。

【００３５】 バックボーンキャッシングの最近の実例は、IPアドレス、ハードウエアアドレ
ス、コンテンツアドレス、コンテンツ組を含むがこれらに限定されない複数の基
準に基ずいて、通常のリクエスト経路から代替目的地へパケットを再経路するこ
とができるネットワーク装置を使用することにより行われる。1つの当該方法は
、すべてのネットワークトラッヒクの経路に“レイヤ4スイッチ”40を置くもの
である（第2図参照）。レイヤ4スイッチはすべてのコンテンツリクエストあるい
はトラッヒクをキャッシュファーム42ヘ再送する。この方法の問題は、レイヤ4
スイッチがネットワーク技術者がレイヤ4スイッチのトラッヒクの流れに入れな
ければならない更にもう1つの装置であり、従って、故障の可能性のあるもう1つ
の点を導入する。

【００３６】 別の実例は、CISCOシステムズ(Systems)により発明された、WCCP（第3図を参
照）のプロトコルを使用することである。このプロトコルはISPの周辺ルータで
作動し、すべてのコンテンツリクエストをキャッシュファーム46へ再伝送する。
この方法に対する利点は、ISPが（キャッシュファーム自体以外の）新しいハー
ドウエアはなにも設置する必要がないことである。

【００３７】 これらの先行技術の方法は次の欠点を有している：各個々のキャッシュは、約
50％以上のヒット率を達成するのに必要なコンテンツを収容する膨大（数百ギガ
バイト）なデイスク容量を持たなければならないであろう。ヒット率はデイスク容 量とユーザコンテンツリクエストとの関数であるので、これらの方法は約50%以
上のヒット率を得るのに十分なユーザコンテンツリクエストを有していない。こ
れは、これらのキャッシュが1個のインターネットサービスプロバイダのためだ
けにエンドユーザコンテンツリクエストを扱っているからであるが、より高いヒ
ット率を達成するためにはいくつかのインターネットサービスプロバイダを通し
てユーザコンテンツリクエストを集めることが望ましい。

【００３８】 従って、役70 - 80%の範囲のヒット率を発生し、インターネットサービスプロ
バイダのための帯域幅コストを減らし、インターネットサービスプロバイダユー
ザにより質の高いサービスを提供するために少なくとも2個、好ましくは2個以上
のいくつかのインターネットサービスプロバイダを通してユーザコンテンツリク
エストを集める装置と方法が必要である。

【００３９】 本発明の開示 最近のバックボーンキャッシュは30 - 50%の範囲のコンテンツヒット率を発生
することができると信じられている。本出願に含まれる概念を用いるこのにより
、装置と方法はバックボーンキャッシュが約70 - 80%の範囲のヒット率を発生す
るようにし、それによりインタネットサービスプロバイダの帯域幅を減らし、イ
ンタネットサービスプロバイダのユーザにより質の高いサービスを与えるように
する。

【００４０】 従って、本発明の第1の目的は、ユーザコンテンツリクエストを少なくとも2個
、好ましくは2個以上のインタネットサービスプロバイダを通して集める装置と
方法を提供することである。

【００４１】 本発明の別の目的は、約70 - 80%の範囲のヒット率を発生するバックボーンキ
ャッシングアーキテクチャを提供することである。

【００４２】 本発明の別の目的は、インタネットサービスプロバイダのために帯域幅コスト
を減らすことである。

【００４３】 本発明の別の目的は、インタネットサービスプロバイダユーザにより高い質の
サービスを提供することである。

【００４４】 本発明の別の目的は、集めたコンテンツリクエスト情報を使って何がキャッシ
ュできか、何が人気のあるコンテンツ（度々アクセスされるコンテンツ）かを知
的に決定することである。

【００４５】 本発明の別の目的は、バックボーンキャッシュが果たすと意図された性能目標
を不釣合いの履行コストの増加を招くことなしに達成するバックボーンキャッシ
ングアーキテクチャを提供することである。

【００４６】 本発明の別の目的は、周辺キャッシュを使用してセントラルキャッシュをさら
に効率よく作動させ、より多くのトラッヒクをセントラルキャッシュへ送る装置
と方法を提供することである。

【００４７】 本発明の別の目的は、複数のバックボーンプロバイダを通してユーザコンテン
ツリクエストを、即ち、コンテンツサーバへのユーザコンテンツリクエストと、
コンテンツサーバからのユーザコンテンツリクエストを伝送しやすくする装置と
方法を提供することである。

【００４８】 本発明の別の目的は、ユーザコンテンツリクエストを、すべてのユーザがより
良い性能を受けように、多くの場合ISPが帯域幅を節約するようにユーザコンテ
ンツリクエストを集める装置と方法を提供することである。

【００４９】 本発明の別の目的は、エンドユーザからのウェブコンテンツの問い合わせのヒ
ット率をインタネット上の通信をなくして高める装置と方法を提供することであ
る。

【００５０】 本発明の別の目的は、ISPが必要とする外部帯域幅を減らす装置と方法を提供
することである。

【００５１】 本発明の別の目的は、最もアクセスされたウェブサイトコンテンツ」の約8乃
至約50%をキャッシュファームに格納する装置と方法を提供することである。

【００５２】 本発明の目的は、最もアクセスされたウェブサイトコンテンツの約80%をセン
トラルキャッシュに格納し、最もアクセスされたウェブサイトコンテンツの一部
はキャッシュファームにコピーされる装置と方法を提供することである。

【００５３】 本発明の別の目的は、キャッシュファーム、セントラルキャッシュと少なくと
も2個の別個のISPとの間で通信する装置と方法を提供することである。

【００５４】 本発明の別の目的は、恩恵（ヒット率）を低いコストで最高にするバックボー
ンキャッシングアーキテクチャを創ることである。

【００５５】 上記目的に沿って、本発明の1態様は、複数個の作動可能に相互接続されたエ
ンドユーザサイトと、作動可能に前記エンドユーザサイトに相対的に位置され、
前記エンドユーザサイトに度々アクセスされるコンテンツを格納する少なくとも
1個のキャッシュファームと、前記キャッシュファームに作動可能に接続され、
前記エンドユーザサイトにより度々アクセスされる、前記キャッシュファームに
格納されない少なくともいくつかの追加情報を格納するセントラルキャッシュと
を備えた、ネットワークに使用されるキャッシング装置を含む。

【００５６】 本発明の別の可能性のある態様は、インターネットエンドユーザからコンテン
ツプロバイダアドレスに向けられたコンテンツリクエストを途中で捕らえ、前記
インターネットエンドユーザは、エンドユーザの少なくとも1個のネットワーク
を形成する複数のエンドユーザの一人である工程と、前記コンテンツリクエスト
がキャッシュファームに格納されたコンテンツに関するかどうかを決定し、前記
キャッシュファームは少なくとも2個のネットワークに作動可能に接続され、前
記キャッシュファームは前記コンテンツプロバイダアドレスに提供されている情
報の少なくとも一部を提供する工程と、前記コンテンツリクエストをキャッシュ
ファームに向ける工程とを備えた情報を転送する方法を含む。

【００５７】 1具体例は、（デイスク容量に換算して）相対的に小さい透過キャッシュを周辺
キャッシュとしてインストールことである。これらの装置の主な目的が非常に高
いヒット率を提供することではなく、単にセントラルキャッシュに問い合わせを
注入するコストの低い装置であるため、これらの装置はインジェクタと呼ばれる
。この方法は、（セントラルキャッシュが各周辺キャッシュよりも大きいオーダ
であり得るので）ヒット率を上げるだけでなく、キャッシング装置全体のコスト
を有為に下げる。この方法は、標準のセントラルキャッシュモデルよりもより多
くのトラッヒクをセントラルキャッシュに送り込むであろう。特に、この方法は
、十分な限界大容量を自身が持たないISPを含むすべてのキャッシング装置にと
って問題の“限界巨大容量”に到達するのをより速くより容易にするであろう。

【００５８】 インジェクタは、コンテンツリクエストの型に基ずいて知的選択をするように
プログラムされることもできるであろう。ヴィデオストリーミに対するコンテン
ツリクエストは、例えば、あるヴィデオサーバに再送されることができるであろ
う。この再送は、スエーデン特許出願第9603753-6号、1996年10月14日出願開示
されているように（本明細書に引例として開示されている）、どのコンテンツが
どこにあるか（そしてどのコンテンツリクエストが全く再送されるべきでないか
）を調べるためにルックアップテーブルからなされることができるであろう。

【００５９】 本発明の他の目的と利点は下記の記載と、添付の図面と添付の特許請求の範囲
から明らかであろう。

【００６０】 本発明の最良の実施形態 本特許出願のシステム及び方法は、インターネットサービスプロバイダ（ＩＳ
Ｐ）ネットワークを含む複数のネットワークのいずれかに複数存在するサイトコ
ンテンツまたはオブジェクトのうち、エンドユーザのいずれかのコンテンツの配
信要求を効率よく処理するように設計されている。キャッシュファーム(Cache F
arm)は、例えばネットワーク装置を経由するなどしてエンドユーザのコンテンツ
配信要求を受信し、既に受信済の複数のコンテンツを保存し、既に要求された更
に多量のコンテンツを保存するセントラルキャッシュ（Central Cache）に動作
できるよう接続している。要求されたコンテンツをキャッシュファームから入手
できれば、そのコンテンツはキャッシュファームからエンドユーザに配信される
。コンテンツがキャッシュファームから入手できなければ、コンテンツの配信要
求はセントラルキャッシュに送信される。要求されたコンテンツがセントラルキ
ャッシュで入手できれば、そのコンテンツはキャッシュファームとエンドユーザ
のインターネットサービスプロバイダ（ＩＳＰ）の内部帯域幅を通じてエンドユ
ーザに配信される。コンテンツがキャッシュファームでもセントラルキャッシュ
でも入手できなければ、そこでそのコンテンツ配信要求は、インターネットを通
じてコンテンツサーバからエンドユーザに配信されるように、インターネットを
通じて送信される。ここで「コンテンツ」という用語を使用するにあたり、ある特
定の「コンテンツ」に制限して説明するものではなく、インターネットを通じてア
クセスされ通信され得るいかなるタイプのコンテンツも含む意図であることは理
解されよう。

【００６１】 ヒット率とは、ディスク容量とエンドユーザコンテンツ配信要求数の作用なの
で、本出願の目的のひとつは、ディスク容量の増やすことと同時にいくつかのバ
ックボーンキャッシュユーザのエンドユーザコンテンツ配信要求を一つのキャッ
シュに統合することによって、ヒット率を高めることである。

【００６２】 現在、スイッチを基盤としたルーティング、通常のルーティング（特に有効で
はない）等を含む複数の選択肢のひとつとして、インターネットサービスプロバ
イダのルータにＷＣＣＰを実行することで、双方向周辺キャッシングはある程度
望ましく実現している。ＷＣＣＰとはシスコ（ＣＩＳＣＯ）によって開発された
「ウェブ・キャッシュ・コントロール・プロトコル」（Web Cache Control Protoc
ol）というプロトコルである。このプロトコルは、コンテンツ配信要求をデータ
またはコンテンツストリームから抽出し、ＷＣＣＰに対応したキャッシュファー
ムのルートに切り替える（図３参照）。コンテンツ配信要求は、エンドユーザま
たはキャッシュからの要求で、基点のサーバまたはキャッシュからコンテンツを
要求するものである。例として、エンドユーザが自分のブラウザのロケーション
ボックスに HYPERLINK "http://www.example.com/ と入力しエンターを押すと"
http://www.example.com/ と入力しエンターを押すと、ブラウザはそのウェブ
ページへのＨＴＴＰコンテンツ配信要求を発動する。

【００６３】 双方向周辺キャッシングは、システムの制約にもよるが、少なくとも二つ、で
きれば多くの、可能な限り多くのインターネットサービスプロバイダのルータに
ＷＣＣＰを実行しコンテンツ配信要求を一つのキャッシュファームに導くことで
、少なくともある程度は実現されている。少なくとも二つのインターネットサー
ビスプロバイダからのコンテンツ配信要求を一つのキャッシュファームに導くこ
とによって、必要なヒット率を生み出すのに充分な数のエンドユーザのコンテン
ツ配信要求が利用できるので、エンドユーザのコンテンツ配信要求数の問題は解
消される。一つのキャッシュファームにあるいくつかのインターネットサービス
プロバイダからデータトラフィックを受信することによって、そのキャッシュフ
ァームのエンドユーザの数は著しく増加する。現行では、ディスク容量の問題に
対処するために、それぞれの独立したキャッシュに数十ギガバイツのディスク領
域がある複数のＷＣＣＰ対応のキャッシュを有するキャッシュファームが望まし
い。（例えば、あるアプリケーションには、独立した３２までのキャッシュを有
する単一キャッシュファームで充分かもしれないが、他のアプリケーションでは
、３２の多重キャッシュファームを組み合わせた更に大きなキャッシュファーム
が必要かもしれない。）各々のキャッシュファームは、そのディスク容量内で一
番最近にアクセスされたコンテンツを保持すればよいのである。

【００６４】 バックボーンのキャッシュファームに保存されていないコンテンツについては
、参考のためこの明細書に添付したスウェーデン特許出願番号第９８０３２４６
−９号、出願日平成１０年９月２４日、名称「インターネットキャッシングシス
テム及びこのシステムにおける方法及び処理」(An Internet Caching System And
A Method And An Arrangement In Such A System)に開示されるように、約１テ
ラバイト（またはそれ以上）のディスクキャッシュ容量を有するロケーションに
ある、例えばミラーイメージセントラルキャッシュ等のようなシブリングまたは
セントラル・キャッシュが使用される。この出願で使用されているように、シブ
リングキャッシュとは、現行のキャッシュとアクセスされたコンテンツサイトの
間に網目状にキャッシュを作成するのに利用するキャッシュのことである。この
ようにして、必要なディスク容量は、より高いヒット率を達成するためにシブリ
ングキャッシュとして働くセントラルキャッシュによって供給される。

【００６５】 インターネットサービスプロバイダから発信される全コンテンツ配信要求がル
ータによってキャッシュファームに転送されることで、全コンテンツ配信要求の
少なくとも約７０〜約８０パーセント（％）はそのコンテンツ配信要求を行った
エンドユーザのインターネットサービスプロバイダネットワーク内で処理され、
それらのネットワーク外の帯域幅にあるインターネットサービスプロバイダを確
保し（つまり使用するデータまたはコンテンツ通信機能またはインターネットバ
ックボーンがより少ない）、それらのエンドユーザに要求されたコンテンツへの
より高速なアクセスを供給する。更に、特定のインターネットサービスプロバイ
ダネットワーク内のサーバに着信する全てのコンテンツ配信要求も同様にキャッ
シュファームで傍受され、全てのコンテンツ配信要求着信とその結果生じるイン
ターネットサービスプロバイダバックボーン及びインターネットサービスプロバ
イダの顧客のコンテンツサーバからの返信のうち約７０〜約８０パーセント（％
）は保持される。この場合もやはり、インターネットサービスプロバイダはその
ネットワーク内の帯域幅を確保し、その顧客（この場合はコンテンツ供給者のこ
とである）は彼らのサーバのリソースを確保し、要求されたコンテンツをエンド
ユーザにより早く配信するのである。

【００６６】 典型的処理の代表的な例 以下の例において、「エンドユーザ」は、例えば通常はダイヤルアップまたは消
費者用接続経由のウェブページの内容等のコンテンツを要求するコンピュータで
あるが、いかなる接続タイプ（ＬＡＮ、Ｔ１、パーシャルＴ１、ＩＳＤＮ、ｘＤ
ＳＬ等）でも同様の結果であろう。「コンテンツサーバ」は、コンテンツの要求に
応えるそのコンテンツを有するコンピュータである。コンテンツサーバは、ウェ
ブサーバ、ＦＴＰサーバ、ニュースサーバまたはマルチメディアまたは他のデー
タまたはコンテンツタイプサーバのいかなるタイプでもよい。

【００６７】 図４に示すように、エンドユーザがコンテンツサーバ８３からコンテンツを要
求しその要求されたコンテンツがキャッシュファームに保存されている場合、エ
ンドユーザ６０がそのコンテンツ配信要求に着手する。コンテンツ配信要求は、
インターネットサービスプロバイダネットワーク６２を通りボーダールータ６４
に至る。ボーダールータ６４は、キャッシュをインジェクタとして利用し、通信
ルート７０を経由して、コンテンツ配信要求をＭＩＩネットワークノード６６に
、具体的にはキャッシュファーム６８に導く。キャッシュファーム６８は、要求
されたコンテンツがそこに保存されているかどうか確認する。要求されたコンテ
ンツがキャッシュファーム６８に保存されていれば、キャッシュファーム６８は
通信ルート７０経由でボーダールータ６４に要求されたコンテンツを返信する。
ボーダールータ６４は、そこで、要求されたコンテンツを通信ルート６２経由で
エンドユーザ６０に送信する。この全処理の間、コンテンツの要求及び結果とし
て生じる返信が、インターネットサービスプロバイダネットワーク８０、通信ル
ート８１及び８２、ボーダールータ８４またはネットワークアクセスポイント（
ＮＡＰ）８２経由のインターネットの構成要素を利用しなかったということが極
めて意義深いことに注目していただきたい。コンテンツ自体は、別のインターネ
ットサービスプロバイダのネットワークを通る必要も、ネットワークアクセスポ
イント８２に進む必要さえもない。かくして、コンテンツ配信要求は、そのイン
ターネットサービスプロバイダがキャッシュファーム６８に接続している限り、
要求を行うエンドユーザのインターネットサービスプロバイダの外へ出ることな
く、着手され満たされる。

【００６８】 コンテンツを要求するエンドユーザが、キャッシュファーム６８には属さない
がシブリングセントラルキャッシュ７４には属するという場合は、エンドユーザ
６０が、インターネットサービスプロバイダネットワーク６２を通りコンテンツ
の要求をネットワークノード６６が対処するという判断をくだすインターネット
サービスプロバイダのボーダールータ６４に至り、そのコンテンツの要求をＷＣ
ＣＰを利用して通信ルート７０経由でキャッシュファーム６８に転送するように
、コンテンツ配信要求に着手する。キャッシュファーム６８は、要求されたコン
テンツを有するかどうか確認する。キャッシュファーム６８がそのコンテンツを
有してなければ、キャッシュファーム６８は通信ルート７６経由でセントラルキ
ャッシュ７４にコンテンツ配信要求を発動する。キャッシュファーム６８及びセ
ントラルキャッシュ７４がお互いに充分に接続されているため、通常は１０〜２
０ｍ、しかしながらこの距離は５０〜１００ｋｍでもよい、コンテンツは極めて
早く返信される。この場合、返信とは、セントラルキャッシュ７４が確かに要求
されたコンテンツを有しており要求されたコンテンツをキャッシュファーム６８
に配信するということである。キャッシュファーム６８は、そこで、通信ルート
７０経由でエンドユーザ６０に返信し要求されたコンテンツをエンドユーザ６０
に配信する。

【００６９】 ＭＩＩノード６６にアクセスを持たないインターネットサービスプロバイダの
エンドユーザがＭＩＩノード６６にアクセスを持つサーバのコンテンツを要求す
る場合は、コンテンツ配信要求は、エンドユーザ６０からボーダールータ６４へ
進む。ボーダールータ６４は、コンテンツ配信要求がインターネットサービスプ
ロバイダ８０へ向かっていると判断し、コンテンツ配信要求はネットワークアク
セスポイント８２へ送られ、そしてインターネットサービスプロバイダ８０のボ
ーダールータ８４へ送られる。インターネットサービスプロバイダ８０のボーダ
ールータ８４では、要求されたコンテンツは、ＷＣＣＰを利用し通信ルート８６
経由でＷＣＣＰキャッシュファーム６８へ経路をとる。キャッシュファーム６８
は、そこで、既に説明したように、要求されたコンテンツを確認し、入手可能で
あれば、その要求されたコンテンツをエンドユーザ６０へ配信する。この処理の
間、インターネットサービスプロバイダ８０のネットワークは、コンテンツの要
求または実際のコンテンツをインターネットサービスプロバイダ８０内のネット
ワークに運ぶ必要がなく、かくしてインターネットサービスプロバイダ８０のネ
ットワーク内の帯域幅の需要を低減することに注目していただきたい。

【００７０】 キャッシュファームは、現実的にはセントラルキャッシュと異なるネットワー
クアクセスポイントに設置することもでき、それでもかなりよいヒット率及びサ
ービス増加の特性を実現できる。キャッシュファームは、物理的にもネットワー
クとしてもセントラルキャッシュに極めて接近した位置にあると憶測されるが、
異なるネットワークアクセスポイントにキャッシュファームを設けることもでき
るのである。それでもなお、エンドユーザに迅速にコンテンツを配信し（１０％
〜２０％）、残存分（５０％〜６０％）はセントラルキャッシュから送られ、そ
れでもかなりよいヒット率及びサービス増加の特性を実現できる。

【００７１】 容量がより大きいハードドライブをキャッシュファームに導入することもでき
、それによってキャッシュファームはより高いヒット率を提供できる。結果とし
て、より少ないコンテンツ配信要求がセントラルキャッシュに送信されることに
なり、セントラルキャッシュの負荷を低減する。

【００７２】 もう一度図４を参照すると、本出願によるキャッシングシステムの説明に役立
つひとつの実例は、セントラルキャッシュ７４へのエントリーポイントとして機
能する一連の小さい（ディスク容量の点で）キャッシュファーム、透過型キャッ
シュまたは「インジェクタ」６８を利用していることである。この実例のインジェ
クタ６８は、例えば標準型のＳＵＮのハードウェア等を備え、現在のところ、例
えば、各々のディスク容量が約２０から約５６ギガバイト（ＧＢ）、ＣＰＵが４
，４００Ｍｈｚ、ＲＡＭが物理的に２ギガバイト（ＧＢ）であることが望ましい
。ソフトウェアについては、この実例のインジェクタは、インターネットサービ
スプロバイダまたはルータからのコンテンツの要求を受け入れるために、いくつ
かのプロトコルに対応していなくてはならない。また、それらのインジェクタは
、セントラルキャッシュと通信するためのプロトコルも必要とする。ここで望ま
れるプロトコル及びセントラルキャッシュからのコンテンツの要求を得るために
使用されるプロトコルは、ＷＣＣＰである。ＷＣＣＰは、シスコのプロトコルで
あり、キャッシュファームやレイヤ４スイッチまたはＷＣＣＰに類似した能力が
ある類似装置の容量を削りまたは拡張するのは勿論のこと、特に一連のキャッシ
ュを結合して「キャッシュファーム」または単一のより大きいキャッシュとして一
組のキャッシュにするなど、便利な特性を多く有する。現在、ＩＣＰ（インター
キャッシュプロトコル）は、キャッシュ内に目的物があるかどうか照会すること
に利用される軽量のプロトコルである。現在このＩＣＰは、キャッシュファーム
とセントラルキャッシュ間の通信に利用されている。ＩＣＰは力の弱いプロトコ
ルであり、現在は充分に機能しているが、将来的にはシステムが発達しておそら
く取って代わられるであろう。現在のところ、これらのＷＣＣＰ及びＩＣＰの両
方のプロトコルに対応する唯一知られているソフトウェアは、シスコ、インクト
ゥミ（Ｉｎｋｔｏｍｉ）及びノベル（Ｎｏｖｅｌｌ）で製品化されている。三つ
のソフトウェア製品はすべて、標準のハードウェアで作動し、ＷＣＣＰとＩＣＰ
プロトコルの両方に対応する「透過型ローカルキャッシュ」なので、本出願による
システムと方法に適切に機能する。

【００７３】 上述のハードウェア及びソフトウェアで作動するインジェクタは、現在は、Ｍ
ＡＥイースト（ＭＡＥ−Ｅａｓｔ）、ＬＩＮＸ等のネットワークアクセスポイン
ト（ＮＡＰ）で結合している。そこで、これらのネットワークアクセスポイント
のネットワークは、データのトラフィックをこれらの結合したインジェクタに転
送するため、それらのルータにＷＣＣＰプロトコルまたはレイヤ４スイッチを使
用する。待ち時間の縮小と高可用性を保持する手段として、この転送は、顧客の
「ボーダールータ」からＭＩＩインジェクタファームまたはキャッシュファーム６
８に、「相互接続」をもって行われることになる。この相互接続は、例えばＯＣ−
３[１５５メガビット秒（ＭＢＰＳ）]等のようなスピードの速いＡＴＭ接続であ
り得る。

【００７４】 これらのインジェクタファーム６８の各々は、エンドユーザサイトから、及び
基点のサーバを含むエンドユーザサイトへの、両方向のコンテンツ配信要求を捕
らえるため、ＷＣＣＰまたはレイヤ４スイッチを使用する。インターネットサー
ビスプロバイダのボーダールータは、通過するエンドユーザのために、発信され
たコンテンツ配信要求を処理し、また、そのコンテンツを供給する顧客のために
、着信されたコンテンツ配信要求を処理するように設定されている。

【００７５】 これらインジェクタマシン６８のディスクの空き容量が小さいため（約１８〜
４５ギガバイト）、インジェクタマシン６８は出回っているほとんどのコンテン
ツを直接供給できる。インジェクタキャッシュファーム６８に存在しないコンテ
ンツについては、インジェクタキャッシュファーム６８は、要求されたコンテン
ツがセントラルキャッシュにあるかどうか判断するため、セントラルキャッシュ
と通信する。セントラルキャッシュは１テラバイトを越えるコンテンツを有する
ので、要求されたコンテンツは、恐らく約７５パーセント（％）の確率で、セン
トラルキャッシュに貯えられ保存されている。

【００７６】 インジェクタキャッシュファーム６８は、特定のコンテンツのアクセス頻度に
基づいて、そのローカルディスクにどのコンテンツを保存すべきかを判断する。
コンテンツがアクセスされると、そのアクセスされたコンテンツはローカルドラ
イブ、すなわちインジェクタキャッシュファーム６８に加えられる。先行技術で
周知のように、ローカルドライブがコンテンツで一杯になると、例えばＬＲＵ（
Least Recently Used）法アルゴリズムのようなキャッシュ置換アルゴリズムを
利用して新しいコンテンツの余地を作るために古いコンテンツを取り除く。キャ
ッシュ置換アルゴリズムは、例えばインクトゥミ、ノベルまたはシスコ等のよう
なこれらのキャッシュ技術をもつプロバイダによって供給されている。

【００７７】 インジェクタキャッシュファーム６８の主な目的は、セントラルキャッシュに
照会やコンテンツ配信要求を投入する低コストの装置として機能することである
。この機能は、ＷＣＣＰを使用してインジェクタファームへコンテンツ配信要求
を転送するために（インターネットサービスプロバイダの、または企業、会社の
ネットワークの）顧客ボーダールータを構成すること、またはレイヤ４スイッチ
を利用することで実現する。これらのコンテンツ配信要求は、最初はＨＴＴＰで
あるかも知れないが、最終的には何でもよい（ＦＴＰ、リアルオーディオ、リア
ルビデオ等）。ヒット率はエンドユーザのコンテンツ配信要求とディスク容量の
作用なので、このシナリオはキャッシュのヒット率を激増させる。セントラルキ
ャッシュは、約１テラバイトを越えるディスク容量を有することが望ましく、ヒ
ット率が約７５パーセント（％）を越える程度の範囲になるように少なくとも２
つ、好ましくはそれ以上のバックボーンを通してエンドユーザのコンテンツ配信
要求を統合することが望ましい。

【００７８】 具体的には、本出願のシステム及び方法によって、キャッシングシステムがよ
り早くより簡単に「限界量（critical mass）」を達成でき、それは限界量に達す
るに充分なコンテンツ配信要求を自らは生み出さないインターネットサービスプ
ロバイダに使用される全てのキャッシングシステムの問題である。本出願で使用
される「限界量」は、セントラルキャッシュが作動を始めるレベルで、ローカルキ
ャッシュには達成できない効率レベルである。限界量は、コンテンツ配信要求の
純粋な数量によって、更に早く達成される。調査によると、全てのインターネッ
トトラフィックの約８０パーセント（％）はウェブトラフィックである。インジ
ェクタキャッシュファーム及びセントラルキャッシュがバックボーンプロバイダ
のバックボーンルータに設定されると、バックボーンプロバイダが発信または着
信する全てのトラフィックの約８０パーセント（％）はセントラルキャッシュへ
方向付けられ、これは数百単位メガバイト秒に匹敵する。この高トラフィック率
は、セントラルキャッシュに必要なコンテンツ配信要求を供給し、高ヒット率を
生み出すことになる。

【００７９】 この状況は、限界量は、キャッシングシステム（キャッシュファーム、及び／
またはキャッシュファーム及びセントラルキャッシュ）を使用するエンドユーザ
が充分な数に達するまでは、功績において純損失を被るかもしれないことを暗示
している。限界量が達成されると、更に多くの要求がローカルで遅くなるよりも
早くなるため、功績において純益がうまれる。

【００８０】 前述の発明を実施例を参照して説明してきたが、様々な変更や改善は当業者に
生じ得る。それら全ての変更や改善は、添付のクレームの適用範囲内に収まると
意図している。

【図面の簡単な説明】

【図１】 従来技術によるキャッシュシステムのブロック図で、ローカル透過型キャッシ
ュを使用している。

【図２】 従来技術によるキャッシュシステムのブロック図で、図１に類似するが、ロー
カルキャッシュにつないだレイヤ４スイッチを使用している。

【図３】 従来技術によるキャッシュシステムのブロック図で、図１に類似するが、ロー
カルキャッシュにつないだＷＣＣＰプロトコルを使用している。

【図４】 本発明の双方向型バックボーンセントラルキャッシングシステム及び方法のブ
ロック図を示す。

───────────────────────────────────────────────────── 【要約の続き】 る。ネットワーク周辺ルータは、そのネットワークのエ ンドユーザのために外に出るコンテンツリクエストを扱 い、そのネットワークのコンテンツプロバイダ顧客のた めに内部のコンテンツリクエストを扱うようにプログラ ムされる。インジェクタキャッシュファームに位置して いないコンテンツに対して、インジェクタキャッシュフ ァームはセントラルキャッシュを通信してセントラルキ ャッシュがリクエストされたコンテンツを有しているか どおうかを決定する。本出願の装置ろ発明によれば、リ クエストされたコンテンツがセントラルキャッシュ上に キャッシュされる即ち格納される可能性は少なくとも約 75%であり、従って、エンドユーザはNAPあるいはバック ボーンインターネット上の電子トラッヒクを使わずにリ クエストしたコンテンツを受け取る。

Claims (16)

【特許請求の範囲】
1. 【請求項１】 複数個の作動可能に相互接続されたエンドユーザサイトと、 作動可能に前記エンドユーザサイトに相対的に位置され、前記エンドユーザ
   サイトに度々アクセスされるコンテンツを格納する少なくとも１個のキャッシュ
   ファームと、 前記キャッシュファームに作動可能に接続され、前記エンドユーザサイ
   トにより度々アクセスされる、前記キャッシュファームに格納されない少なくと
   もいくつかの追加情報を格納するセントラルキャッシュと、を備えたネットワー
   クに使用される両指向性周辺キャッシング装置。
2. 【請求項２】 前記セントラルキャッシュは、前記キャッシュファームの格納容量より大
   きいマグニチュード単位の格納容量を有する請求項１記載の装置。
3. 【請求項３】 前記エンドユーザサイトは、エンドユーザがリクエストして
   いるコンテンツと、源のサーバが供給する情報を含む請求項１記載の装置。
4. 【請求項４】 前記キャッシュファームは、度々アクセスされる情報を格納
   する請求項１記載の装置。
5. 【請求項５】 前記キャッシュファームは、情報が前記セントラルキャッシ
   ュに検索されるまで情報を保持する請求項１記載の装置。
6. 【請求項６】 透過キャッシュファームは、コンテンツリクエストを捕らえ
   て前記コンテンツリクエストをセントラルキャッシュへ与える請求項１記載の装
   置。
7. 【請求項７】 インターネットエンドユーザからコンテンツプロバイダアド
   レスに向けられたコンテンツリクエストを途中で捕らえ、前記インターネットエ
   ンドユーザは、エンドユーザの少なくとも１個のネットワークを形成する複数の
   エンドユーザの一人である工程と、 前記コンテンツリクエストがキャッシュファームに格納されたコンテン
   ツに関するかどうかを決定し、前記キャッシュファームは少なくとも２個のネッ
   トワークに作動可能に接続され、前記キャッシュファームは前記コンテンツプロ
   バイダアドレスに提供されている情報の少なくとも一部を提供する工程と、 前記コンテンツリクエストをキャッシュファームに向ける工程とを備えた
   情報を転送する方法。
8. 【請求項８】 リクエストされたコンテンツが前記キャッシュファームに格
   納されている場合は、前記コンテンツを得て、前記コンテンツをリクエストして
   いるインターネットエンドユーザへ伝送する工程を更に備えた請求項７記載の方
   法。
9. 【請求項９】 リクエストされたコンテンツが前記キャッシュファームに格
   納されていない場合は、前記コンテンツリクエストがセントラルキャッシュに格
   納されたコンテンツに関するかどうかを決定し、前記セントラルキャッシュは前
   記キャッシュファームに作動可能に接続され、前記セントラルキャッシュは前記
   コンテンツプロバイダアドレスに提供されている情報の少なくとも一部を提供す
   る工程を更に備えた請求項８記載の方法。
10. 【請求項１０】 前記リクエストされたコンテンツが前記セントラルキャッ
    シュに格納されている場合には、前記コンテンツを得て、前記コンテンツを前記
    キャッシュファームに次にインターネットエンドユーザへ伝送する工程をさらに
    備えた９項記載の方法。
11. 【請求項１１】 リクエストされたコンテンツが前記キャッシュファームに
    格納されていない場合は、この旨を前記キャッシュファームに通信する工程を更
    に備えた請求項１０記載の方法。
12. 【請求項１２】 前記リクエストされたコンテンツが前記キャッシュファー
    ムでも前記セントラルキャッシュでも得られないことが一旦決定されると、前記
    キャッシュファームは前記コンテンツを前記コンテンツプロバイダアドレスから
    得て、前記コンテンツをインターネットエンドユーザに伝送し、そして前記コン
    テンツを前記キャッシュファームに格納する工程を更に備える請求項１１記載の
    方法。
13. 【請求項１３】 ネットワークを形成する複数個の作動可能に相互接続され
    たエンドユーザサイトと、 少なくとも２個のネットワークに作動可能に接続され、前記エンドユー
    ザサイトにより度々アクセスされるコンテンツを格納する少なくとも１個のキャ
    ッシュファームとを備えた少なくとも２個のネットワークとの使用のための両指
    向性周辺キャッシング装置。
14. 【請求項１４】 前記キャッシュファームに作動可能に接続され、前記エン
    ドユーザサイトにより度々アクセスされる、前記キャッシュファームに格納され
    ない少なくともいくつかの追加情報を格納するセントラルキャッシュを更に備え
    た請求項１３記載の装置。
15. 【請求項１５】 前記キャッシュファームに作動可能に接続されたネットワ
    ークの数は３個或いは３個以上である請求項１３記載の装置。
16. 【請求項１６】 前記キャッシュファームは前記ネットワークに直接に、作
    動可能に接続されている請求項１３記載の装置。