Web キャッシュ テクノロジーの概要

導入

WWW はインターネット上で最も人気のあるアプリケーションの 1 つであり、その急速な成長によりネットワークの混雑とサーバーの過負荷が発生し、その結果、顧客のアクセス遅延が増加し、WWW サービス品質の問題が発生しています。キャッシュ テクノロジーは、サーバーの負荷を軽減し、ネットワークの混雑を軽減し、WWW のスケーラビリティを向上させる効果的な方法の 1 つであると考えられています。その基本的な考え方は、顧客のアクセスの時間的局所性の原理を利用して、顧客がアクセスしたコンテンツをキャッシュに保存することです。キャッシュ: 次回コンテンツにアクセスするときは、ホスティング Web サイトに接続する必要はありませんが、キャッシュに保存されたコピーによって提供されます。
Web コンテンツは、クライアント、プロキシ サーバー、およびサーバー側でキャッシュできます。研究によると、キャッシュ テクノロジによって WWW のパフォーマンスが大幅に向上し [1][2]、次のような利点がもたらされることが示されています。
(1) ネットワーク トラフィックを削減し、ネットワークの混雑を緩和します。
(2) 顧客のアクセス遅延の削減。主な理由は次のとおりです。① プロキシ サーバーにキャッシュされたコンテンツの場合、顧客はリモート サーバーからではなくプロキシから直接取得できるため、転送遅延が削減されます。ネットワークへの混雑とサーバー負荷が軽減され、顧客がより早くネットワークを取得できるようになります。
（３）クライアントのリクエスト内容の一部をプロキシから取得できるため、リモートサーバの負荷が軽減される。
(4) リモート サーバーの障害やネットワーク障害により、リモート サーバーがクライアントの要求に応答できない場合、クライアントはプロキシからコンテンツのキャッシュされたコピーを取得できるため、WWW サービスの堅牢性が向上します。
Web キャッシュ システムには次の問題もあります。
(1) お客様が代理店を通じて入手したコンテンツが古い場合があります。
(2) キャッシュの無効化が発生すると、プロキシ処理のオーバーヘッドが追加されるため、クライアントのアクセス遅延が増加します。したがって、Web キャッシュ システムを設計するときは、キャッシュ ヒット率を最大化し、失敗コストを最小限に抑えるように努める必要があります。
(3) エージェントがボトルネックになる可能性があります。したがって、エージェント システムの効率がリモート サーバーに直接接続されているクライアントの効率と少なくとも同じになるように、サービス顧客の数の上限とサービス効率の下限をエージェントに設定する必要があります。
現在、Web キャッシュ システムとその最適化の問題に関して広範かつ詳細な研究が行われており、これらの研究作業は主にプロキシの役割に焦点を当てています。
2 Web キャッシュ システムの理想的な特性 理想的な Web キャッシュ システムには、次の特性が必要です。
(1) 速度: キャッシュ システムは、顧客のアクセス遅延を効果的に削減できなければなりません。
(2) 堅牢性: 堅牢性とは可用性を意味し、顧客は Web サービスがいつでも利用できることを望んでいます。
(3) 透明性: キャッシュ システムは顧客に対して透明である必要があり、顧客が得られる結果は、迅速な応答と良好な可用性のみです。
(4) スケーラビリティ: Web キャッシュ システムは、ネットワークのサイズと密度が増大し続けるのに合わせて適切に拡張できる必要があります。
(5) 効率: Web キャッシュ システムがネットワークにもたらすオーバーヘッドは小さいほど良いです。
(6) 適応性: キャッシュ システムは、顧客のリクエストやネットワーク環境の動的な変化に適応できます。これには、キャッシュ管理、キャッシュ ルーティング、プロキシ構成などが含まれ、理想的なキャッシュ パフォーマンスを得るために重要です。
(7) 安定性: Web キャッシュ システムが採用するソリューションは、ネットワークに不安定性をもたらすべきではありません。
(8) 負荷分散: 理想的なキャッシュ ソリューションは、特定のエージェントやサーバーがボトルネックやホット スポットになり、システムの一部またはシステム全体のパフォーマンス低下を引き起こすことを避けるために、負荷をネットワーク全体に均等に分散できる必要があります。
(9) 異種処理能力: ネットワークの規模とカバレージ エリアが拡大し続けるにつれて、ネットワークは一連の異なるハードウェアおよびソフトウェア アーキテクチャにまたがるようになります。 Web キャッシュ システムは、さまざまなネットワーク アーキテクチャに適応できる必要があります。
(10) シンプルさ: シンプルなソリューションは実装が簡単で、一般に受け入れられています。理想的な Web キャッシュ ソリューションは、シンプルで構成が簡単である必要があります。
上記の特性に着目すると、Web キャッシュ システムは次の問題を解決する必要があります。
(1) キャッシュ アーキテクチャ: ネットワーク内でキャッシング プロキシがどのように編成および設定されるか。
(2) エージェントの連携: エージェント間でどのように連携するか。エージェントが互いに連携することで、ヒット率が向上し、キャッシュ システムのパフォーマンスが向上します。
(3) キャッシュ ルーティング: 1 つのキャッシュ プロキシに障害が発生した場合、リクエストを他のキャッシュ プロキシに転送する方法。
(4) キャッシュ置換アルゴリズム: キャッシュ領域が十分でない場合、キャッシュの内容を置換する方法。
(5) キャッシュの一貫性: つまり、キャッシュされたコンテンツの適時性と、キャッシュされたコンテンツが古くならないようにする方法。
(6) コンテンツのプリフェッチ: クライアントのアクセス遅延を軽減するために、エージェントがサーバーまたは他のエージェントからコンテンツをプリフェッチする方法。
(7) 負荷分散: ネットワーク内の「ホットスポット」現象を解決する方法。
(8) キャッシュコンテンツ: キャッシュできるコンテンツの種類。
Web キャッシュ システムを設計するときは、上記の問題に対処する必要があります。
3 Web キャッシュ ソリューションの概要
3.1 Web キャッシュ アーキテクチャ Web キャッシュ システムのパフォーマンスは、顧客ベースの規模に依存します。顧客ベースが大きくなるほど、キャッシュされたコンテンツが再度要求される可能性が高くなります。キャッシュ グループが相互に連携すると、ヒット率が向上し、キャッシュ システムのパフォーマンスが向上する可能性があるため、キャッシュ システムのアーキテクチャでは、エージェントが効果的に連携できるようにする必要があります。一般的なキャッシュ アーキテクチャには、階層型、分散型、ハイブリッド型があります。

図 1 Web キャッシュ システムのアーキテクチャ図
3.1.1 階層型キャッシュアーキテクチャ
Harvest プロジェクト [3] は、階層型 Web キャッシュ アーキテクチャを最初に提案しました。階層型キャッシュ アーキテクチャでは、図 1(a) に示すように、キャッシュはネットワーク内の複数のレベルで構成されます。簡単にするために、最下層キャッシュ、ローカル層キャッシュ、地域層キャッシュ、広域層キャッシュの 4 つのレベルがあると仮定します。最下層はクライアント/ブラウザ キャッシュです。クライアント キャッシュがクライアントのリクエストを満たせない場合、リクエストはローカル エリア レイヤー キャッシュに転送され、それでも満たされない場合、リクエストはワイド キャッシュに達するまでリージョナル レイヤー キャッシュに転送されます。エリアレイヤーキャッシュ。 すべてのレベルのキャッシュでリクエストを満たすことができない場合、リクエストは最終的にサーバーに転送されます。リクエストに対するサーバーの応答はトップダウンでクライアントに送信され、途中で各中間層キャッシュにコピーが残ります。同じコンテンツに対する他のリクエストは、特定のレベルのキャッシュで満たされるまで、下から上に転送されます。
階層型キャッシュ アーキテクチャは帯域幅効率が高く、クリックスルー率の高い Web コンテンツを迅速かつ効率的にネットワークに配信できます。ただし、このアーキテクチャにはいくつかの欠点もあります[4]。
(1) 階層型キャッシュ アーキテクチャを確立する必要があります。キャッシュ サーバーはネットワーク内の主要なアクセス ポイントに構成され、キャッシュ サーバーは相互に連携する必要があります。
(2) キャッシュのレベルごとに追加の遅延が発生します。
(3) 高レベルのキャッシュがボトルネックとなり、長いキュー遅延を引き起こす可能性があります。
(4) 同じコンテンツの複数のコピーが異なるキャッシュに保存されており、システム全体のキャッシュ領域の使用率は高くありません。
3.1.2 分散キャッシュ アーキテクチャ 階層型キャッシュ構造の上記の欠点を考慮して、一部の研究者は、図 1(b) に示すように、この構造では低レベルのキャッシュのみが存在する分散キャッシュ アーキテクチャを提案しています。文献 [5] の分散 Web キャッシュ構造では、ローカル層以降の中間キャッシュ層は存在せず、キャッシュが相互に連携して障害に対処します。無効なコンテンツを取得するクライアント要求をどのローカル エリア レイヤ キャッシュに転送するかを決定するために、各ローカル エリア レイヤ キャッシュは、キャッシュされたコンテンツのディレクトリ情報のコピーを他のローカル エリア レイヤ キャッシュに保持します。無効化が発生したときに、対応するローカル層キャッシュに正確に転送されます。キャッシュ アレイ ルーティング プロトコル CARP [6] (キャッシュ アレイ ルーティング プロトコル) は、URL 空間をさまざまな部分に分割し、各部分を疎結合キャッシュ グループに割り当てる分散キャッシュ スキームです。各キャッシュは、URL が割り当てられた Web コンテンツのみをキャッシュできます。これにより、クライアントがコンテンツをリクエストした URL に基づいてリクエストを転送するキャッシュを決定できるようになります。
分散キャッシュ構造では、ほとんどのネットワーク トラフィックがネットワークの下部で発生するため、ネットワークの輻輳が発生する可能性が低く、負荷分散がより適切に実現され、耐障害性が向上します。ただし、大規模な分散キャッシュ システムの構成では、多数の接続、高帯域幅の要件、管理の困難など、いくつかの問題が発生する可能性があります [4]。
3.1.3 ハイブリッド キャッシュ アーキテクチャ ハイブリッド アーキテクチャは図 1(c) に示されており、同一レベルのキャッシュは分散キャッシュ構造を採用しており、相互に連携します。 Harvest Group によって設計されたインターネット キャッシュ プロトコル ICP (インターネット キャッシュ プロトコル) は、最小の RTT で親キャッシュまたは隣接キャッシュから対応するコンテンツを取得することをサポートします。
3.1.4 キャッシュ アーキテクチャの最適化研究では、分散キャッシュ構造と比較して、階層型キャッシュ アーキテクチャの方が接続時間が短いため、より小さいドキュメントが中間層キャッシュにキャッシュされ、アクセス遅延が短縮されることが示されています。伝送時間とより高い帯域幅使用率。理想的なソリューションは、この 2 つを組み合わせてそれぞれの長所を最大限に発揮しながら、接続時間と送信時間を短縮することです。
3.2 キャッシュ ルーティング Web キャッシュ システムのスケーラビリティを考慮すると、ほとんどのキャッシュ システムはインターネット上に大量のキャッシュを分散させます。これによってもたらされる最大の問題は、必要なコンテンツをキャッシュするキャッシュをどのように見つけ出すかということです。 。この問題はネットワーク ルーティングに似ていますが、同じ方法では解決できません。従来のネットワーク ルーティングは、アドレス クラスタリング (階層的なアドレス表現によりアドレス クラスタリングが可能) に基づいて行うことができますが、WWW では、同じ URL プレフィックスまたはサーバー アドレス プレフィックスを持つドキュメントが同じクライアントに送信されないため、アドレスのルーティングが困難になります。クラスタ化されているため、キャッシュ ルーティング テーブルが管理不能なほど大きくなります。さらに、キャッシュの内容は常に更新されるため、キャッシュのルーティング情報が古いとキャッシュが無効になります。キャッシュ障害のコストを削減するために、理想的なキャッシュ ルーティング アルゴリズムでは、クライアントのリクエストを次のプロキシにルーティングする必要があります。プロキシはヒットする可能性が高く、クライアントからサーバーへのネットワーク パス上またはその近くに位置します。
3.2.1 ルーティングテーブルのキャッシング方式
Malpani et al. [7] は、クライアントのリクエストが指定されたキャッシュに転送される場合、そのキャッシュにリクエストされたコンテンツがあれば、それがクライアントに送信されます。同じグループ内の他のキャッシュは、対応するコンテンツをキャッシュしているキャッシュからのクライアントのリクエストに応答します。リクエストされたコンテンツがどのキャッシュにもキャッシュされていない場合、リクエストはオリジン サーバーに転送されます。 Harvest[3] キャッシュ システムは、キャッシュを階層構造に編成し、キャッシュ解決プロトコル ICP (インターネット キャッシュ プロトコル) を使用します。キャッシュ障害が発生すると、下位レベルのキャッシュは、顧客のリクエストをサーバーに転送する前に、まず兄弟ノードのキャッシュにクエリを実行します。最上位キャッシュの過負荷を避けるために、対応するコンテンツをキャッシュするかどうか。適応型 Web キャッシング システム [8] は、サーバーごとにキャッシュ ツリーを確立し、ツリー内のキャッシュは重複するマルチキャスト グループに編成され、リクエストはこれらの送信グループを通じて対応するキャッシュされたコンテンツを取得します。この方法はサーバーごとに異なるキャッシュツリーを構築するため、ルートノードの過負荷の問題がなく、自己構成性と堅牢性が比較的良好です。ただし、クリックスルー率が低いコンテンツのリクエストはより多くのキャッシュを通過する可能性があるため、この問題を解決するためにリクエストが通過するキャッシュの数を制限することを推奨しています。
3.2.2 ハッシュ関数方式
キャッシュ アレイ ルーティング プロトコル CARP [6] は、アレイ メンバー リストと URL に基づくハッシュ関数を使用して、Web オブジェクトの正確なキャッシュ アドレス、または Web オブジェクトをキャッシュする場所を決定します。概要キャッシュ [9] では、各プロキシは、同じグループ内の他のプロキシによってキャッシュされたコンテンツの URL 概要情報を保存し、クライアント リクエストを転送するときにこれらの概要情報を確認して、リクエストを転送するプロキシを決定します。オーバーヘッドを削減するために、これらの概要情報は定期的に更新されます。実験の結果、このシステムは、ICP とほぼ同じキャッシュ ヒット率を維持しながら、キャッシュ間の情報量、帯域幅の消費量、プロトコルに起因する CPU オーバーヘッドを大幅に削減できることが示されています。
3.3 キャッシュ置換アルゴリズム
キャッシュ置換アルゴリズムは、プロキシ キャッシュ システムのパフォーマンスに影響を与える重要な要素です。優れたキャッシュ置換アルゴリズムにより、より高いヒット率が得られます。これまでに提案されているアルゴリズムは次の 3 つのカテゴリに分類できます。
(1) 従来の置換アルゴリズムとその直接の進化は次のとおりです。 ① LRU (Least Recently Used) アルゴリズム: キャッシュから最も最近使用されていないコンテンツを置換します。 ② LFU (Lease Frequently Used) アルゴリズム: キャッシュから最も頻繁に使用されていないコンテンツを置換します。 ③Pitkow/Recker[10] は置換アルゴリズムを提案しました。キャッシュ内のすべてのコンテンツが同日にキャッシュされた場合、最大のドキュメントがキャッシュから置き換えられ、それ以外の場合は LRU アルゴリズムに従って置き換えられます。
(2) キャッシュコンテンツの主要な特性に基づく置換アルゴリズムには、次のものがあります。 ① Size[10] 置換アルゴリズム: キャッシュ内の最大のコンテンツを置換するアルゴリズム。置き換えられたドキュメントの個別の最小数。キャッシュされるドキュメントのサイズが S であると仮定し、少なくとも S のサイズを持つキャッシュ内のキャッシュされたドキュメントは、少なくとも S のサイズを持つオブジェクトがない場合は LRU アルゴリズムに従って置き換えられます。アルゴリズムは、少なくとも S/2 のサイズのドキュメントから使用されます。 ③LRU—Threshold[11] 置換アルゴリズム: 特定のしきい値を超えるドキュメントはキャッシュできないことを除き、LRU アルゴリズムと同じです。 12] 置換アルゴリズム: アクセス遅延が最も小さいドキュメントをキャッシュから置換します。
(3) コストベースの置換アルゴリズム。このタイプのアルゴリズムは、コスト関数を使用してキャッシュ内のオブジェクトを評価し、最終的にコスト値に基づいて置換オブジェクトを決定します。代表的なアルゴリズムとしては、①Hybrid[12]アルゴリズム：キャッシュ内の各オブジェクトに効用関数を割り当て、そのオブジェクトをキャッシュ内の最小の効用値に置き換えるアルゴリズム、②Lowest Relative Value[13]アルゴリズム：オブジェクトを次の値に置き換えるアルゴリズムがあります。 ③ 最小正規化コスト置換 (LCNR) [14] アルゴリズム: このアルゴリズムは、ドキュメントのアクセス頻度、送信時間、およびサイズに関する推論関数を使用して置換ドキュメントを決定します。文書送信時間のコスト、サイズ、および最終アクセス時間の重み付き推論関数に基づいて文書置換を決定する方法を提案しました。 ⑤サイズ調整 LRU (SLRU) [16] アルゴリズム: コストの比率に従ってキャッシュされたオブジェクトを並べ替えます。サイズを調整し、最小の比率を持つオブジェクトを選択して置換します。
つまり、キャッシュのヒット率を最大化するために、キャッシュ置換アルゴリズムに関して多くの作業が行われてきましたが、置換アルゴリズムのパフォーマンスは WWW アクセスの特性に大きく依存します。すべての Web アクセス モードを処理できるため、他のアルゴリズムよりも優れています。
3.4 キャッシュの一貫性
Web キャッシュ システムはアクセス遅延を短縮できますが、副作用もあります。顧客に提供されるキャッシュされたコピーが古いコンテンツである可能性があるため、キャッシュされたコンテンツが適時に更新および検証されることを保証するためのキャッシュ一貫性メカニズムが導入されている必要があります。お客様に最新のコンテンツを提供するため。
現在、キャッシュ一貫性には主に 2 つのタイプがあります。それは、強力なキャッシュ一貫性と弱いキャッシュ一貫性です。
3.4.1 強力なキャッシュ一貫性 (1) クライアントの確認: アクセスごとに、プロキシはキャッシュされたコンテンツが古いものとみなし、リクエストとともに「IF-Modified-Since-date」ヘッダーをサーバーに送信します。指定された時間が経過した後にコンテンツが変更された場合、サーバーは更新されたコンテンツをエージェントに送信し、要求されたコンテンツが変更されていない場合は、ドキュメントが変更されていないことを示す「304」応答が返されます。キャッシュされたコンテンツは効率的に継続されます。
(2) サーバーの確認: サーバーは、コンテンツが変更されたことを検出すると、最近コンテンツを要求し、コンテンツをキャッシュしている可能性があるすべてのクライアントに無効化情報を送信します [17]。 この方法では、無効な情報を送信するために、サーバーがコンテンツにアクセスするクライアントのリンク リストを保存する必要がありますが、同時に、リンク リスト自体も古くなってしまう可能性があります。これにより、サーバーはキャッシュされなくなった多くのクライアントにメッセージを送信し、このコンテンツの顧客には無効な情報が送信されます。
3.4.2 弱いキャッシュ一貫性 (1) アダプティブ TTL [18] (Time To Live) メカニズム: ドキュメントの存続期間を観察してその生存時間を調整することで、キャッシュ一貫性の問題を解決します。ドキュメントがかなりの期間変更されていない場合、再度変更されない傾向があります。このようにして、ドキュメントの存続期間属性には、ドキュメントの現在の「経過時間」(現在の時刻から最終変更時刻を引いたものに等しい) のパーセンテージが割り当てられます。適応型 TTL 方式により、ドキュメントが陳腐化する可能性を 5% 未満に制御できます。ほとんどのプロキシ サーバーはこのメカニズムを使用しますが、ドキュメントの有効期間に基づくこのキャッシュ一貫性メカニズムでは、キャッシュされたコンテンツの有効性が保証されません。
(2) ピギーバック無効化機構
Krishnamurthy らは、キャッシュ コヒーレンスの効率を向上させるためにピギーバック無効化メカニズムを使用することを提案しました。彼らは 3 つのメカニズムを提案しました。 ① Piggyback Cache Validation (PCV) [19] メカニズム: プロキシによってサーバーに送信されたリクエストを使用して、キャッシュの一貫性を向上させます。たとえば、プロキシがサーバーにリクエストを送信すると、有効性を確認するために、キャッシュされているが古い可能性のある一連のコンテンツがサーバーから送信されます。 ② Piggyback Service Invalidation (PSI) [20] (Piggyback Service Invalidation) メカニズム: 基本的な考え方それは、サーバーがプロキシに応答するときに、最後のプロキシ アクセス以降に変更された一連のコンテンツをプロキシ サーバーに通知し、プロキシがこれらのコンテンツを無効にすることで、キャッシュ内の他のキャッシュされたコンテンツのキャッシュ時間を延長することです。 PCV ハイブリッド メカニズム [21]: このメカニズムは、最後のリクエストがエージェントによって無効になってからの現在の間隔のサイズに基づいて、最高の全体的なパフォーマンスを達成するためにどのメカニズムを使用するかを決定します。この時間間隔が短い場合は PSI メカニズムが使用され、それ以外の場合は PCV メカニズムがキャッシュの内容を確認するために使用されます。基本原則は、時間間隔が短いほど、PSI と一緒に送信されるボイドの数が少なくなりますが、時間が長くなると、ボイド送信のオーバーヘッドが確認要求のオーバーヘッドより大きくなります。
3.5 コンテンツのプリフェッチ
Web キャッシュ テクノロジは Web パフォーマンスを向上させることができますが、調査によると [22]、どのようなキャッシュ スキームを使用しても、最大キャッシュ ヒット率は通常 40 ～ 50% を超えないことが示されています。キャッシュヒット率をさらに向上させるために、プリフェッチ技術が導入されました。プリフェッチ テクノロジは本質的にアクティブ キャッシュ テクノロジであり、その基本的な考え方は、顧客の現在のリクエストを処理する際に、顧客のアクセス コンテンツまたはモードに関する事前の知識を使用して、顧客のリクエスト コンテンツをギャップ キャッシュに使用することです。キャッシュを使用して遅延をより適切に隠し、サービス品質を向上させます。
初期の研究はブラウザ/クライアントと Web サーバー間のコンテンツのプリフェッチに焦点を当てていました。プロキシが導入されると、人々の研究の関心はプロキシとサーバー間のプリフェッチ技術に移りました。調査によると、プリフェッチ テクノロジーは顧客のアクセス遅延を効果的に削減できることが示されていますが、プリフェッチ テクノロジーには次の 2 つの理由から依然として議論の余地があります。
(1) コンテンツのプリフェッチは、主に顧客のリクエストの間隔を使用するタスクであり、この間隔は通常 1 分未満です [23]。この期間内にプリフェッチ タスクを完了できない場合は、 , 先読みは無意味になってしまいます。したがって、プリフェッチ アルゴリズムの効率にはより高い要件が求められます。
(2) コンテンツのプリフェッチでは、サーバーの負荷とネットワーク トラフィックが増加する代わりにクライアントの応答時間が短縮されるため、プリフェッチの精度に対する要件が高くなります。同時に、プリフェッチ モデルでは、顧客のアクセス特性、サーバー負荷、およびネットワーク トラフィック状況を考慮して、これらの要素を考慮せずにプリフェッチするドキュメントの数を決定する必要があります。
つまり、優れたプリフェッチ モデルは、低コストで高い効率と精度を備えている必要があります。プリフェッチの効率と精度に関してはさらなる研究が必要です。
3.5 負荷分散 多くの顧客が同時にサーバーからデータやサービスを取得すると、ホットスポット現象が発生し、サーバーのパフォーマンスが低下したり、場合によっては障害が発生したりすることがあります。この問題に対処する現在の方法のほとんどは、何らかのレプリケーション戦略を使用して、要求されたコンテンツをインターネット上に保存し、それによって負荷を複数のサーバー (エージェント) [24] に分散して、単一のサーバーがボトルネックになるのを回避するというものです。
3.6 コンテンツのキャッシュ プロキシは、データ キャッシュに加えて、複数の役割を果たすことができ、接続キャッシュと計算キャッシュも実行できます。接続キャッシュとは、クライアントとエージェント、およびエージェントとサーバーの間の永続的な接続の使用を指し、TCP 接続確立のオーバーヘッドとサーバー送信時のスロー スタート オーバーヘッドを削減し、それによって顧客のアクセス遅延時間を短縮します [25] ]。計算キャッシュは、サーバーのボトルネックを軽減するためにサービスの一部をプロキシに移行できる Web サーバーと見なされます。そのアプリケーションの 1 つは、プロキシを介して動的データをキャッシュし、によって生成された計算の一部をプロキシに移行します。プロキシを使用してキャッシュされた動的データを維持することで、顧客が動的データを取得する際のパフォーマンスが向上します。
4 さらなる研究が必要な問題 Web キャッシュ技術に関しては多くの研究が行われ、有益な成果が得られていますが、さらなる研究が必要な問題もまだいくつかあります。これらの問題には次のようなものがあります。
(1) 顧客のアクセス パターンの調査: 顧客のアクセス パターンを調査することで、キャッシュ管理とコンテンツのプリフェッチをより適切に実行し、キャッシュ ヒット率を向上させることができます。
(2) 動的データ キャッシュ: 現在の Web キャッシュ ヒット率が高くない重要な理由は、コンテンツのかなりの部分 (プライベート データ、許可されたデータ、動的データなど) をキャッシュできないことです。より多くのデータをキャッシュ可能にする方法、および顧客がキャッシュされていないページにアクセスする際のアクセス遅延を短縮する方法は、Web パフォーマンスを向上させる上で重要な問題となっています。
(3) Web トラフィックの特性: キャッシュ システムの効率は、Web アクセス フローの時間局所性と適切なキャッシュ管理戦略に依存します。Web クライアントによって生成される負荷特性を理解することは、Web サービスをより適切に設計および提供するために非常に重要です。
(4) プロキシ構成: 良好な Web パフォーマンスを得るには、プロキシ構成戦略の理想的な標準は、自己組織化、効率的なルーティング、負荷分散、安定した動作などです。この問題についてはさらなる研究が必要です。
つまり、Web パフォーマンスを向上させるための最先端の研究は、拡張性、堅牢性、適応性、安定性、効率性を備え、現在および将来のネットワークでより適切に構成できるキャッシュ ソリューションを開発することにあります。
ワン・シケ・ウー・ジ・ジン・シヤオ

(国立国防技術大学コンピューターサイエンス学部並列処理および分散国家重点実験室、長沙 410073)

-