 |
||
|
|
|
| 注意： 本製品は既に生産⁄販売を終了しております。 |
|
ネットワーク キャッシング
| インターネット及びイントラネットの成長に伴うネットワークに関する問題 |
インターネットやイントラネットのトラフィックは驚異的なスピードで成長しています。ネットワーク トラフィックは 100 日ごとに倍増していると言われています。このような急激なネットワーク トラフィックの増加により、ISP （internet service provider） や企業は、ネットワークに関する様々な問題に直面しています。
- WAN 回線の混雑と高い送信費用
- ネットワーク サービス品質の向上
- ユーザの体感するインターネットやイントラネット コンテンツへのアクセス品質、速度のコントロールと向上
- 経済的なネットワーク拡張性
| ソリューション - トラフィック パターンのローカル化 |
これらのネットワークに関する問題を最も効果的に解決する方法は、既存のネットワーク設備を使って、トラフィック パターンをローカル化することです。これによってコンテンツ リクエストにローカル ネットワーク内で応答できるようになります。このソリューションによって先ほどのネットワークに関する問題を次のように解決することができます。
- コンテンツ配信の高速化、高品質化 - コンテンツ リクエストに対してインターネット及びイントラネット経由で遠くのサーバが応答する代わりに、近くのネットワーク内で応答することによって、コンテンツ配信を高速化することができます。またこれにより、自分のネットワークが他のネットワークの影響を受けて不安定になることを防げるため、安定したネットワーク サービス品質とコンテンツへのアクセス品質を保証することができます。
- WAN 回線の効率的な利用 - 同じコンテンツにアクセスするために WAN 回線を何度も利用することがなくなるため、 WAN 回線の使用量は減少するか、または増加するとしてもその速度が緩やかになります。これにより利用可能な回線容量が増えるため、新規ユーザやトラフィック、音声などの新しいサービスに回線を効率的に利用できます。
トラフィック パターンのローカル化はトラフィックの操作に関する問題です。いくつかのパラメータに基づいてトラフィック パターンを最適化するためにはネットワークにトラフィックを操作する能力が必要になります。従ってトラフィック パターンのローカル化ソリューションを実現するには、まず、既存のネットワークがこの能力を備えているか確認が必要です。ネットワークのいくつかの重要なポイントでWCCP （Web Cache Communication Protocol） のような、Webページへのリクエストを透過的に転送する機能が設定可能であればこの能力を備えていると言えます。
ネットワーク側の準備が整ったら、ネットワークの重要なポイントにネットワーク キャッシュを追加すればソリューションは完成します。ネットワーク キャッシュは、アクセス頻度の高いコンテンツを透過的にキャッシュまたは保存し、その後の同じコンテンツへのリクエストに対してはローカルに応答します。これにより、同じコンテンツの転送の為にWAN回線を繰り返し無駄に消費するのを防ぐことができます。
次に、２つの構成機器がどのように連動して動作するか説明します。
1. ユーザがブラウザを使い Web ページをリクエストします。
2. ネットワークがそのリクエストを分析し、特定のパラメータに基づいて、近くのネットワーク キャッシュに透過的にリクエストを転送します。
3. キャッシュに該当する Web ページがない場合、キャッシュがオリジナル Web サーバにWebページを リクエストします。
4. オリジナル Web サーバはキャッシュにコンテンツを送り、キャッシュはストレージにコンテンツを保存しつつ、同時にユーザにコンテンツを配信します。この時点で、コンテンツがキャッシュされました。
5. その後、別のユーザが同じ Web ページをリクエストすると、ネットワークがそのリクエストを分析し、特定のパラメータに基づいて、近くのネットワーク キャッシュに透過的にリクエストを転送します。
6. インターネットやイントラネットを経由してリクエストを送る代わりに、ネットワーク キャッシュがローカルにそのリクエストに応答します。この処理により、コンテンツ配信は高速化され、WAN 回線の使用量も減少します。
| Cisco Content Engine のキャッシング サービス |
シスコのネットワーク キャッシング ソリューションは、既存のネットワーク設備と連携して動作する Cisco Content Engine のキャッシング機能によって実現します。Cisco Content Engine は、コンテンツ配信を高速化し、システムの拡張性とコンテンツの品質を保証するコンテンツ サービス プラットフォームです。次節以降で、シスコのネットワーク キャッシング ソリューションについて詳細な技術情報を提供します。
トランスペアレント ネットワーク キャッシングCisco Content Engine はトランスペアレント ネットワーク キャッシングを次のように実行します（図 1 を参照）。
1. ユーザがブラウザを使って Web ページをリクエストします。
2. WCCP 対応ルータはリクエストをTCP ポート番号に基づいて分析し、リクエストをCisco Content Engineに透過的に転送するかどうかを判断します。どのリクエストを転送するかについては、アクセス リストを使って制御することもできます。
3. Cisco Content Engineにリクエストされたコンテンツがない場合、Cisco Content Engineとエンド サーバとの間で新たにTCP 接続が確立され、コンテンツのリクエストが送られます。エンド サーバからCisco Content Engineにコンテンツが送られ、保存されます。
4. Cisco Content Engineはクライアントにコンテンツを送信します。以後、同じのコンテンツがリクエストされると、Cisco Content Engineはストレージに保存されているコンテンツを使用して透過的にリクエストに応答します。
図 1：トランスペアレント ネットワーク キャッシング
WCCP ルータが Web サーバ宛てのパケットをCisco Content Engineに転送するため、クライアントにとってCisco Content Engineは透過的に動作します。クライアントは、各自のブラウザに特定のプロキシ キャッシュを使用するように設定する必要はありません。これは、ISP や大企業にとって非常に重要な機能です。ブラウザの設定を統一するには、コストがかかり、管理が困難だからです。さらに、Cisco Content Engineの動作はネットワークに対しても透過的です。Cisco Content Engineに転送されないトラフィックはルータで通常通り処理されます。
階層的な配置Cisco Content Engine はクライアントやネットワークの動作に対して透過的なので、ユーザはネットワーク上の複数の場所にCisco Content Engineを階層的な形で容易に追加していくことができます。たとえば、ISP がCisco Content Engineをインターネットとの接続ポイントに設置した場合、全てのPOP（Points Of Presence）でその効果を得ることができます。（図 2 を参照）。クライアントからインターネット上のサーバへのリクエストはCisco Content Engine に転送され、キャッシュにヒットした場合、Cisco Content Engineがクライアントに応答します。クライアントに対するサービス品質をさらに向上させたい場合、ISP は各々の POP にCisco Content Engineを配置することができます。その場合、クライアントがインターネットにアクセスすると、そのリクエストはまず POPの Cisco Content Engineに転送されます。POPの Cisco Content Engineがクライアントからリクエストのあったコンテンツを持っていなかった場合、Cisco Content Engineはエンド サーバに通常のWebリクエストを送信します。上流ではこのWebリクエストがインターネットとの接続ポイントに設置された Cisco Content Engine に転送されます。Cisco Content Engine がリクエストに応答した場合、インターネットとの接続回線のトラフィックを削減することができ、Web サーバへのリクエスト負荷は減り、クライアントに対するネットワークの応答時間も短縮されます。企業ネットワークでも、この階層的なトランスペアレント ネットワーク キャッシュの配置を適用することによって、同様な効果を得ることができます（図 3 を参照）。
図 2：Cisco Content Engineの階層的配置（ISP）
図 3：Cisco Content Engineの階層的配置（企業）
クラスタ化による拡張性
Cisco ネットワーク キャッシング ソリューションは、ネットワーク トラフィックの増加に伴う負荷をCisco Content Engineを追加してクラスタ化するだけで簡単に処理できるよう設計されています。この仕組みにより、ユーザは、Cisco Content Engineを追加すれば、その台数に比例した処理能力とストレージ容量を得ることができます。たとえば、1 台の Cisco Content Engine 7320 では、155Mbps 以上のトラフィック処理能力と、396GBのストレージ容量をサポートしますが、そこにもう1台Cisco Content Engine 7320 を追加することにより、310Mbps 以上のトラフィック処理能力と 792GBのストレージ容量をサポートするようになります。WCCPは最大 32 台のCisco Content Engineをクラスタ化できます。
この台数に比例した処理能力とストレージ容量の拡張性は、WCCP 対応ルータがCisco Content Engineにトラフィックを転送する際の動作によって実現されています。WCCP 対応ルータは、着信リクエストの宛先 IP アドレスに対してハッシュ機能を実行し、そのリクエストを 256 個の独立した「バケット」の 1 つにマッピングします。統計的に、このハッシュ機能によって、着信リクエストはすべてのバケットに均等に分散されます。さらに、これらのバケットは、Cisco Content Engineクラスタ内のすべてのCisco Content Engineに均等に割り当てられます。WCCP 対応ルータは、インターネット上の特定の宛先 IP アドレスへのリクエストが、毎回同じCisco Content Engineに転送されることを保証します。経験的に、この分配アルゴリズムによって、Cisco Content Engineクラスタ内で常に負荷が均等に分散されることが証明されています。人気の高い Web サイトのほとんどは、複数の IP アドレスを使ってサービスを行っていますので、この方法によって負荷が一部のCisco Content Engineに集中することを防止することができます。
Cisco Content Engineクラスタに新しいCisco Content Engineを追加した場合、WCCP 対応ルータは新しいCisco Content Engineを検出し、そのCisco Content Engineを含めたCisco Content Engineクラスタに対して256個のバケットをもう1度分配し直します。例えば、ルータとCisco Content Engineが 1 台ずつという最も単純なケースでは、256 個のバケットはすべて 1 台のCisco Content Engineに割り当てられます。そこにもう 1 台のCisco Content Engineを追加すると、WCCP 対応ルータは 2 台のCisco Content Engineにパケットを均等に転送するようになります。つまり、それぞれのCisco Content Engineに 128 個ずつバケットを割り当てます。さらに 3 台目のCisco Content Engineを追加すると、WCCP 対応ルータは、3 台のCisco Content Engineそれぞれに 85 個または 86 個のバケットを割り当てます。
既存のCisco Content Engineクラスタを稼動させたまま、新たなCisco Content Engineを追加接続することができます。この場合、WCCP 対応ルータは、新しく追加されたCisco Content Engineを含むCisco Content Engineクラスタのメンバに、自動的に均等にバケットを割り当て直します。新しく追加されたCisco Content Engineはコンテンツを持っていないため、ストレージにコンテンツが十分に蓄積されるまではキャッシュ ミスが頻繁に発生することになります。このコールド スタートに伴う問題を軽減するために、新しく追加されたCisco Content Engineは、最初のしばらくの間だけ、Cisco Content Engineクラスタの他のメンバに対してリクエストされたコンテンツを持っているかどうか確認するメッセージを送ります。他のメンバがコンテンツを持っていた場合、新しく追加されたCisco Content Engineに対してそのコンテンツを送ります。新しく追加されたCisco Content Engineが十分なコンテンツを他のメンバから受け取ったと判断すると（判断基準値は設定可能です）、以後キャッシュ ミスの際、他のメンバにコンテンツを問い合わせるのをやめ、直接エンド サーバにリクエストを送るようになります。
フォールト トレランスとフェール セーフ機能Cisco Content Engineクラスタ内のいずれかのCisco Content Engineにフェール（障害）が発生した場合、Cisco Content Engineクラスタはその障害によってCisco Content Engineクラスタ全体の機能が影響を受けないように「治療」します。WCCP 対応ルータは、故障したCisco Content Engineの担当していた負荷を、残りのCisco Content Engineに均等に再分配します。Cisco Content EngineクラスタはCisco Content Engineが1台少ない状態で動作することになりますが、Cisco Content Engineクラスタ全体としての動作には影響ありません。
Ciscoネットワーク キャッシング ソリューションは、2台のWCCP対応ルータでMHSRP （Multigroup Hot-Standby Router Protocol） を動作させてCisco Content Engineクラスタを共有させることによって、完全な冗長性を備えたキャッシング システムを構築できます。これを、「WCCP マルチホーミング」と呼びます。WCCP 対応ルータに故障が発生すると、Cicso IOS のフォールト トレランスおよびフェール セーフ機能が適用されます。たとえば、ホットスタンバイ ルータは動的に処理を引き継ぎ、Cisco Content EngineクラスタにWeb リクエストを転送しつづけます。
Cisco Content Engineクラスタ内の全てのCisco Content Engineが故障した場合、WCCP 対応ルータは自動的にCisco Content Engineクラスタへのトラフィック転送を中止し、クライアントからのWebリクエストを通常どおりに実際の宛先 Web サイトへ送ります。Cisco Content Engineクラスタ全体が使用できなくなったことによる影響は、ユーザにとっては Web コンテンツのダウンロード時間が長くなったという形で現れますが、それ以外には大きな影響はありません。このフェール セーフ機能は、クライアントからの全てのトラフィックがCisco Content Engineクラスタを経由して流れることがないようにネットワークをデザインすることによって実現されています。
WCCP マルチホーム ルータのサポート先ほど述べたように、Cisco ネットワーク キャッシング ソリューションは、複数の WCCP 対応ルータをCisco Content Engineクラスタの「ホーム」ルータとすることによって、冗長性を高めることができます。これにより、全てのWCCPホーム ルータを通過するWebトラフィックを、Cisco Content Engineクラスタに転送することができます。例えば、MHSRP ルータ ペアの両方をホーム ルータとするCisco Content Engineクラスタの場合、完全な冗長性を備えたキャッシング システムとなり、全てのシングル ポイント オブ フェイラー（1ヶ所の障害によってシステム全体が使用不能になること）を除去することができます（図 4 を参照）。
図 4：完全な冗長性を備えたCisco Content Engineクラスタの構成
オーバーロード バイパス
Web トラフィックが突発的に急増すると、Cisco Content Engineクラスタがオーバーロード（過負荷）状態になる場合があります。この過負荷状態を適切に処理するため、各Cisco Content Engineは自身が過負荷状態になったことを検出し、以後のリクエストを拒否し、拒否したリクエストをオリジナルWeb サーバに転送する機能を持っています。オリジナルWeb サーバは直接クライアントに応答します。バイパスされたリクエストはCisco Content Engineによって処理されていないためです（図 5 を参照）。
過負荷になったCisco Content Engineは、近い将来にまたオーバーロード バイパス機能を実行しなくても処理できるだけのリソースがあると判断した時点で、リクエストの受け付けを再開します。オーバーロード バイパス機能のオン⁄オフは、CPU およびファイル システムの負荷によって自動的に決定されます。Cisco Content Engineの負荷が大きすぎて、ホーム ルータから出された基本的な WCCP ステータス チェック メッセージにも応答できないほどの状況では、WCCP ホーム ルータはそのCisco Content EngineをCisco Content Engineクラスタから取り除き、バケットを割り当てなおします。
このオーバーロード バイパス機能によって、トラフィックが非常に大きい場合でも、Cisco Content Engineクラスタは異常に長い待ち時間を発生させることはなく、ネットワークのアベイラビリティ（可用性）を維持することができます。
図 5：オーバーロード バイパス
ダイナミック クライアント バイパス
Web サイトによっては、クライアントの IP アドレスを使用してクライアントを認証する必要があります。ただし、クライアントと Web サーバの間にネットワーク キャッシュが配置されている場合、Web サーバからはキャッシュの IP アドレスしか参照できず、クライアントの IP アドレスは参照できません。
この問題やその他の同様の状況を解決するために、Cisco Content Engine には、ダイナミック クライアント バイパス機能が用意されています。この機能は、一定の条件下でクライアントにCisco Content Engineをバイパスさせ、オリジナル Web サーバに直接接続させる機能です。この機能により、Cisco Content Engineの導入によって既存の送信元 IP 認証モデルを変更する必要はなくなり、サーバのエラー メッセージもCisco Content Engineを介さず直接クライアントに返されるようになります。Cisco Content Engineはこのような状況をダイナミックに判断して動作するため、Cisco Content Engineを透過的に動作させるために必要な管理の手間はほとんどありません。
図 6 では、クライアントが Web リクエストを出し、それがCisco Content Engineに転送されています。Cisco Content Engineに該当するコンテンツがない場合、Cisco Content EngineはオリジナルWeb サーバからそのコンテンツを取得しようとします。
図 7 では、サーバが特定の HTTP のエラー リターン コード（401 - 不正なリクエスト、403 - 禁止、503 - サービスが利用不可など）でCisco Content Engineに応答した場合、Cisco Content Engineによりダイナミック クライアント バイパス機能が実行されます。Cisco Content Engineは、クライアントの IP アドレスと宛先 IP アドレスのバイパス ペアをダイナミックに保存するため、この IP アドレスのペアを持つ以降のパケットはCisco Content Engineをバイパスします。Cisco Content Engineは、自動 HTTP リトライ メッセージをクライアントのブラウザに送信します。
図 8 では、クライアントのブラウザが自動的にリロードを実行し、リクエストを送ると、そのリクエストがCisco Content Engineに転送されます。しかし、バイパス テーブルがチェックされてリクエストがテーブルのエントリのいずれかと一致した場合、Cisco Content Engineはそのリクエストを拒否し、オリジナル Web サーバにリクエストを直接送信します。その結果、オリジナル Web サーバがクライアントの IP アドレスを参照してクライアントを認証し、クライアントに直接応答します。
図 6：ダイナミック クライアント バイパス
図 7：ダイナミック クライアント バイパス
図 8：ダイナミック クライアント バイパス
リバース プロキシ キャッシング
ネットワークの応答時間をより短縮して、WAN 回線の使用量を最小限に抑えるために、Cisco Content Engineをクライアントの近くに配置することがよくあります。その結果、Cisco Content Engineにはクライアントが最も頻繁にアクセスするコンテンツが保存されます。さらに、Cisco Content Engineを Web サーバ ファームの前に配置することにより Web サーバ ファームの処理能力を拡張し、Web サイトの応答性能を向上させることができます。この構成では、Cisco Content Engineは特定のサーバのコンテンツだけを保存し、そのサーバのフロントエンドとしてクライアントからのリクエストに代理応答するため、リバース プロキシ キャッシングと呼ばれます。
サーバ上の他のコンテンツに比べて、特定のコンテンツだけが頻繁にリクエストされるようなサーバ ファームのフロントエンドとしてCisco Content Engineが動作する場合、この機能は特に重要となります。リバース プロキシ キャッシングを使用することにより、管理者は、少数の需要の高い URL がサーバ全体の性能に影響を与えないようにすることができます。さらなる利点として、需要の高い URL を識別したり、手動でコピーしたり、あるいはサーバ上の大量の URL と区別して管理する必要がありません。
リバース プロキシ キャッシングの機能
図 9 では、各Cisco Content Engineは、サーバ ファームをサポートしている WCCP 対応ルータやスイッチを「ホーム」としています。着信 Web リクエストが WCCP 対応ルータまたはスイッチに届くと、そのルータおよびスイッチは、着信リクエストの送信元 IP アドレスとポート番号に対してハッシュ機能を実行し、そのリクエストを 256 個の独立した「バケット」の 1 つにマッピングします。統計的に、このハッシュ機能によって、着信リクエストはすべてのバケットに均等に分散されます。さらに、これらのバケットは、Cisco Content Engineクラスタ内のすべてのCisco Content Engineに均等に割り当てられます。
図 9：リバース プロキシ キャッシング
ハッシュ機能は、宛先 IP アドレスではなく送信元 IP アドレスとポート番号に基づいて実行されるため、特定の Web オブジェクトがCisco Content Engineクラスタ内の複数のCisco Content Engineに保存される場合があります。リバース プロキシ キャッシングは人気のあるコンテンツがCisco Content Engineクラスタ全体に行き渡ることにより、複数のCisco Content Engineが人気の高いコンテンツへのリクエストに応答することを可能にします。さらに、Cisco Content EngineクラスタにCisco Content Engineを追加することにより、人気サイトのパフォーマンスは段階的に向上し、コンテンツのダウンロードに伴う時間は短縮されます。
宛先 IP アドレスに対してハッシュを実行することにより、リバース プロキシ キャッシングを行うこともできます。ただし、この場合、すべてのリクエストは同じ宛先 IP アドレスを持ち、1 台のCisco Content Engineに転送されます。サーバ ファームのフロント エンドとしてCisco Content Engineが 1 台あるだけで、それ以上に拡張する必要がない場合は、この方法で十分です。
| 最新コンテンツの保証 |
ネットワーク キャッシング システムに不可欠な要素は、Web から取得た場合と同じコンテンツを、ネットワーク キャッシュからユーザに確実に提供できる能力です。すべての Web ページは複数の Web オブジェクトで構成され、Web オブジェクトごとに、コンテンツの作成者と HTTP の規格（「HTTP キャッシング規格」節を参照）によって決められた独自のキャッシング パラメータがあります。したがって、リアルタイム オブジェクトを持つ Web ページでも、通常はキャッシュに保存できる他のオブジェクトが多数あります。キャッシュに保存できないオブジェクトの代表的な例として、回転する広告バナーや CGI（Common Gateway Interface）によって生成される応答があります。キャッシュに保存できる例として、ツールバー、ナビゲーション バー、GIF、および JPEG などがあります。このように、1 つの Web ページでエンド サーバから取り出す必要があるダイナミック オブジェクトはごくわずかで、残りのスタティック オブジェクトはローカルで提供できます。
Cisco Content Engine製品は、HTTP のキャッシング規格に準拠しており、また、管理者がオリジナルWeb サーバからコンテンツを取得して最新に更新する時期を制御できるようにしているため、最新のコンテンツを提供することができます。
HTTP のキャッシング規格
Cisco Content Engine 製品は、Web ページ上の各オブジェクトに対するキャッシング パラメータを規定した HTTP 1.0 および 1.1 規格に対応しています。
HTTP 1.0 では、コンテンツの作成者はキャッシュに保存できない各オブジェクトに対して「Pragma: no cache」ヘッダ フィールドを指定できます。また作成者はコンテンツを無限にキャッシュに保存させつづけることもできます。
HTTP 1.1 では、コンテンツの作成者はコンテンツをキャッシュに保存させる期間を指定できます。Web ページ上の各オブジェクトに対し、コンテンツ作成者は次のキャッシング属性を選択できます。
- キャッシング不可
- キャッシング可能（デフォルト設定）
- 明示的有効期限
HTTP 1.1 には、キャッシュ内のデータが最新のデータか確認するための再検証メカニズムIMS（If-Modified-Since）があります。Cisco Content Engineは、キャッシュ内の有効期限切れコンテンツに対するリクエストを受信した場合、またはクライアントから IMS リクエストを受け取り、そのコンテンツが設定された割合以上昔にキャッシュされたコンテンツだった場合、軽量の IMS リクエストをエンド サーバに送ります。オブジェクトをキャッシュに保存して以降、エンド サーバ上のオブジェクトが変更されていない場合、エンド サーバはキャッシュ内のオブジェクトのコピーをクライアントに配信してもよいことを伝える軽量のメッセージを返します。オブジェクトをキャッシュに保存して以降、エンド サーバ上のオブジェクトが変更されている場合、Cisco Content Engineは最新のコンテンツを取得します。クライアントから IMS リクエストを受け取っても、そのコンテンツが設定された割合以内の期間にキャッシュされたコンテンツだった場合、Cisco Content Engineは最新のコンテンツかどうか再確認することなくコンテンツを配信します。
Cisco Content Engineのコンテンツ フレッシュネス制御機能
Cisco Content Engine 製品は、HTTP キャッシング規格に準拠するだけでなく、管理者がCisco Content Engine内の Web オブジェクトの有効期限を制御できるようにしています。Cisco Content Engineには、「フレッシュネス係数」というパラメータがあり、コンテンツをどれだけ早く、遅くに期限切れにするかを設定できます。オブジェクトがキャッシュに保存されると、コンテンツの有効期限TTL（time-to-live）値が計算されます。
TTL 値 = (コンテンツがキャッシュされた日時 - コンテンツの最終更新日時) * フレッシュネス係数。
TTL 値に基づいてオブジェクトが「期限切れ」になると、そのオブジェクトが次に要求されたときに、コンテンツ・エンジンから IMS 要求が発行されます（IMS がフレッシュネスを再評価するプロセスの説明については、上記の「HTTP のキャッシング規格」節を参照してください）。
管理者が、保守的なフレッシュネス ポリシを使用したい場合、フレッシュネス係数を小さな値（0.05 など）に設定することにより、オブジェクトは短時間で期限切れになります。ただし、この方法を採用すると、IMS リクエストがより頻繁に発行され、回線使用量が増えるという不利点が伴います。進歩的なフレッシュネス ポリシを設定したい場合は、フレッシュネス係数を大きな値に設定することにより、オブジェクトの有効期限が長くなり、IMS による回線への負荷が小さくなります。
ブラウザのフレッシュネス制御機能
最後に、クライアントはブラウザの「リロード」または「更新」ボタンを使用することにより、コンテンツをいつでも明示的に更新できます。
この「リロード」コマンドまたは「更新」コマンドは、データを更新するためにブラウザから出されるコマンドです。「リロード」コマンドまたは「更新」コマンドにより、変更されたデータだけを確認する一連の IMS リクエストが発行されます。
Shift キーを押した状態で「リロード」または「更新」を押すコマンドは、「リロード」または「更新」コマンドの拡張です。正しく実装されているブラウザでは、このコマンドにより IMS リクエストではなく、「pragma: no cache」が常に起動されます。その結果、Cisco Content Engineはバイパスされ、エンド サーバによりすべてのコンテンツが直接提供されます。
| 要約 |
トラフィック パターンのローカル化ソリューションによって、管理者はコンテンツ配信の高速化と、WAN回線容量の最適な利用が実現できます。トラフィック パターンのローカル化はトラフィックの操作に関する問題です。いくつかのパラメータに基づいてトラフィック パターンを最適化するためにはネットワークにトラフィックを操作する能力が必要になります。従ってトラフィック パターンのローカル化ソリューションを実現するには、まず、既存のネットワークがこの能力を備えているか確認が必要です。ネットワークのいくつかの重要なポイントでウェブ キャッシュ コミュニケーション プロトコル（WCCP）のような、Webページへのリクエストを透過的に転送する機能が設定可能であればこの能力を備えていると言えます。
既存のネットワーク設備にCisco Content Engineを追加することにより、低コストでネットワーク キャッシング ソリューションを導入できます。これにより、様々な規模のネットワークに低コストでキャッシュを導入することができ、ネットワーク全体でキャッシング サービスの効果を得ることができます。
| 更新日：2002 年 7 月 3 日 |
