HTTP キャッシュ の 良い点 と 問題点 および 対策

0 件のコメント

キャッシュ無効化 はすぐにやってしまいがちですが…キャッシュも正しく使いこなせばとても便利な機能だと思います。 正しく使いこなせていないから問題になるのであって、その原因をつきとめ改善できればより良いサービスが構築できる ハズ と個人的には思っています。

良い点

  • 通信回数が減るので、サーバーへの負荷が減る
  • 通信量が減るので、ネットワーク帯域を効率的に利用できる
  • 通信効率が良くなるので、クライアントの応答が早くなる

悪い点(正しく使わないと発生する問題)

問題点を改めて述べるほどでもないとは思いましたが…一応、列挙してみました。 これらの問題が解決できれば、ユーザーは幸せになれる ハズ です。 以下では、それぞれ問題点について少し考察してみます。

新しい情報に書き換わらない 問題

[原因]

レスポンス ヘッダーに Cache-ControlPragma が正しく設定されていないことが原因。

[対策1]

サーバー側で キャッシュ 無効化 を行います。 具体的にはサーバーからの レスポンス ヘッダー に以下の設定をします。 HTML なら METAタグ で、C# ASP.NET や Java, PHP 等 であればコードで キャッシュ しないことを明示的に指定します。 リクエスト ヘッダー ではないことに注意します。

  • Cache-Control: no-cache, no-store
  • Pragma: no-cache

[対策2]

クライアント側で キャッシュ 無効化 を行います。 クライアントからサーバーへリクエストする際の URL クエリパラメター に無意味な文字列を付加します。

見られてはいけない情報が見えてしまう 問題

Proxy サーバー、キャッシュサーバー などを利用していると発生する問題。 個人用ページ等が キャッシュサーバー に残ってしまい、他の人がアクセスしたとき別の人の キャッシュ が配信されてしまう問題。

[原因]

レスポンス ヘッダーに Cache-Control が正しく設定されていないことが原因。

[対策]

サーバー側で キャッシュ 無効化 を行います。 サーバーからの レスポンス ヘッダーに以下の設定をします。

  • Cache-Control: private, no-store, no-cache, must-revalidate

思うようにキャッシュの良さを享受できない 問題

ロードバランサ、DNSラウンドロビン等を利用しているときに発生する問題。 キャッシュ が効かず、毎回ダウンロードが発生している問題。

[原因]

サーバーが異なると、同じファイルでも異なる ETag が設定されてしまうことが原因。

[対策1]

サーバー側の設定を変更します。 すべてのHTTPサーバーで ETag を明示的に同じにしてしまいます。

[対策2]

サーバー側の実装を変更します。 具体的には、 ETag を削除し、 Last-Modified および If-Modified-Since を利用するよう実装を変更します。

今回、参考にしたサイトは以下の通りです。