キャッシュ制御は、ユーザーがインターネットを閲覧するときにリソースをキャッシュする方法を開発者が指示できる重要な方法です。キャッシュ制御がないと、ブラウザーのキャッシュとその結果としてのユーザー エクスペリエンスが最適ではなくなります。
キャッシュ制御とは何ですか?
ユーザーがインターネットを閲覧するとき、通信はいわゆる ハイパーテキスト転送プロトコル (HTTP) 形式。これは、インターネット上の通信の標準を決定するプロトコルです。 1997 年の HTTP/1.1 のリリース以来、2015 年に HTTP/2 がリリースされるまで、プロトコルにはほとんど変更がありませんでした。
HTTP/1.1 と HTTP/2 の両方には、キャッシュを可能な限り適切に機能させることを目的とした多数の要素が含まれています。ユーザーはクライアントであり、Web サーバーにリクエストを (たとえば URL の形式で) 送信し、Web サーバーは (Web ページで) 応答します。 HTTP ヘッダーは、HTTP トランザクションをスムーズに進めるための追加情報を含む、この形式の要素またはパラメーターです。
Cache-Control は、クライアント要求とサーバー応答におけるブラウザーのキャッシュ動作を定義する一連のパラメーターを含む HTTP キャッシュ ヘッダーです。クライアントがサーバーにリクエストを行うと、ブラウザーはリソースのコピーをキャッシュまたは保存して、アクセスを高速化し、待機時間を短縮します。これは、ブラウザが最後に変更されたファイルを再度取得する必要がある場合に、Web サーバーに再度リクエストを行う必要がないことを意味します。 Cache-Control は、応答をいつ、どのように、どのくらいの期間キャッシュするかを指定します。
ブラウザキャッシングとは？
ブラウザー キャッシュは、次のクライアント要求時にすぐに読み込むために、Web ブラウザーが Web サイトのリソースを保存するプロセスです。たとえば、背景画像を含む Web ページを読み込むと、実際の動作を確認できます。初めてページをロードすると、画像がブラウザのキャッシュに保存されます。次回そのページにアクセスすると、ページの読み込みが速くなり、待ち時間が短縮されていることがわかります。これは、ブラウザが Web サーバーに画像を再度要求していないためです。代わりに、ローカル ファイルから画像を読み込みます。
ただし、ブラウザのキャッシュは無期限にファイルを保存しません。 Time to Live (TTL) と呼ばれる一定の時間枠があり、それを超えると、キャッシュされたリソースがローカル ファイルから期限切れになります。 TTL の期限が切れた後にページを読み込むと、ブラウザは Web サーバーに別のリクエストを送信し、リソースの新しいコピーを受信する必要があります。各ブラウザーとサーバーの TTL は、HTTP ヘッダーで指定されます。
HTTP ヘッダー
HTTP ヘッダーは、クライアントとサーバー間の通信に関する追加情報を含む一連の条件付きリクエスト パラメーターです。 World Wide Web は、クライアントとサーバー間のすべての通信の構文を概説するハイパーテキスト転送プロトコルに基づいて動作します。
クライアントとサーバー間の通信では、さまざまな種類の情報を指定するためのヘッダーがいくつかあります。
リクエストの場合、ヘッダーには通常、リクエストされているリソース、クライアントのブラウザ、およびクライアントが受け入れるデータ形式に関する情報が含まれています。応答の場合、情報は通常、要求が正常に実行されたかどうか、および本文内のリソースの言語と形式に関する情報です。
大まかに言えば、HTTP キャッシュ ヘッダーは次のように分類できます。
一般ヘッダー
これらは HTTP キャッシュ ヘッダーであり、要求メッセージと応答メッセージの両方に使用できますが、メッセージのコンテンツには適用されません。 Cache-Control はそのようなヘッダーの 1 つです。その他には、メッセージの日付と時刻を指定する Date や、トランザクション後にネットワーク接続が開いたままかどうかを指定する Connection が含まれます。
リクエストヘッダー
これらは、HTTP 要求で使用されるヘッダーです。これらには、フェッチされているリソース、またはリクエストを行っているクライアントに関する詳細情報が含まれています。
例としては、取得するコンテンツまたはメディアの種類をアドバタイズする Accept や、サーバーによって以前に送信された保存済みの HTTP Cookie を含む Cookie などがあります。
応答ヘッダー
応答ヘッダーには、HTTP 応答に関する追加情報が含まれています。例としては、オブジェクトがプロキシ キャッシュにあった時間を指定する Age や、ページのリダイレクト先の URL を示す Location などがあります。
エンティティ ヘッダー
他のヘッダーとは異なり、エンティティ ヘッダーには、メッセージの内容と本文に関する情報が含まれています。これらは、HTTP 要求または HTTP 応答メッセージで使用できます。例としては、エンティティ本体のサイズをバイト単位で指定する Content-Length や、視聴者向けの言語を記述する Content-Language などがあります。
キャッシュ制御ヘッダー/ステータス コードの説明
キャッシュ制御ヘッダーには、キャッシュ方法、キャッシュする時期、キャッシュしない時期など、キャッシュに関するすべての情報が含まれています。これらは本質的に、コロンで区切られたキーと値のペアで構成されるディレクティブです。 「キー」はコロンの左側に表示されるもので、この場合は常に「キャッシュ制御」になります。ヘッダーの値はコロンの右側に表示されます。たとえば、「cache-control: max-age」はそのようなディレクティブの 1 つです。
キャッシュ制御ディレクティブは、クライアントが HTTP 要求で使用する場合は要求ディレクティブと見なされ、サーバーが HTTP 応答で使用する場合は応答ディレクティブと見なされます。
最も一般的なキャッシュ制御ディレクティブの一部を次に示します。
キャッシュ制御: max-age
max-age ディレクティブは、リクエストが行われた時点からキャッシュされたコピーとして保存されているフェッチされた HTTP レスポンスをブラウザが使用できる期間を指定します。これは秒数で指定された最大時間です。たとえば、max-age=90 は、HTTP 応答が再利用できるようになるまで、次の 90 秒間キャッシュされたコピーとしてブラウザーに残ることを意味します。画像、CSS、JavaScript ファイルなどの静的ファイルの場合は、積極的なキャッシュを使用できます。 max-age より古いキャッシュされた応答は、古い応答と呼ばれます。
キャッシュ制御: S-Maxage
s-maxage は max-age ディレクティブに似ていますが、「s」は共有キャッシュと同様にsharedを表します。これは、コンテンツ配信ネットワーク (CDN) およびその他の中間キャッシュに関連します。 max-age ディレクティブと、expires ヘッダー フィールドが存在する場合は、これをオーバーライドします。
S-maxage と max-age の比較
s-maxage と max-age はどちらも、プロキシやブラウザなどの中間キャッシュにリソースをキャッシュできる期間を指定する Cache-Control ヘッダー ディレクティブです。ただし、2 つのディレクティブ間の重要な違いはセキュリティに影響します。
max-age ディレクティブは、中間キャッシュを含むキャッシュがリソースをキャッシュできる最大時間を秒単位で指定します。一方、 s-maxage ディレクティブは、プロキシ サーバーなどの共有キャッシュにのみ適用され、これらの共有キャッシュがリソースをキャッシュできる最大時間を秒単位で指定するために使用されます。
s-maxage 値を短く設定すると、機密情報が長期間キャッシュされ、権限のないユーザーに公開されるリスクが軽減されます。
対照的に、max-age ディレクティブは、クライアント側のキャッシュによってリソースをキャッシュできる期間を制御することにより、Web パフォーマンスを最適化することに重点を置いています。 max-age は依然としてセキュリティに影響を与える可能性がありますが、Web ページの読み込み時間を短縮し、サーバーの負荷を軽減するためによく使用されます。
キャッシュ制御: キャッシュなし
このディレクティブは、同じ URL への後続のリクエストでリソースを再利用できないことをキャッシュに伝えます。 オリジンサーバー リソースが変更されたためです。つまり、キャッシュされたバージョンの URL を使用する前に毎回サーバーで再検証する必要があるというブラウザへの指示です。これは、他の利点の中でも特に認証が尊重されるようにするのに役立ちます。 no-cache ディレクティブは、応答が変更されていないことを確認するためにサーバーとの間でラウンドトリップを行うことにより、キャッシュされた応答の検証に ETag ヘッダー フィールドを使用します。変更がない場合、ダウンロードは不要です。
キャッシュ制御: no-store
no-store は no-cache に似ていますが、より単純です。このディレクティブでは、HTTP 応答をキャッシュして再利用することはできません。代わりに、リソースを要求する必要があり、毎回元のサーバーから完全な応答がダウンロードされます。これは、個人情報や銀行データを扱う場合に特に重要です。
キャッシュ制御: 変換なし
リソースがキャッシュ サーバーに格納されている場合、中間プロキシがこれらのアセットを変更することがあります。たとえば、スペースを節約してパフォーマンスを向上させるために、画像やファイルの形式を変更できます。アセットが元のエンティティ本体と同一のままである場合、これは問題を引き起こす可能性があります。 no-transform ディレクティブは、中間キャッシュまたはプロキシにそのような変更を行わないように指示します。たとえば、応答本文、Content-Encoding、Content-Range、または Content-Type を編集することはできません。
プライベート vs.パブリックキャッシュ制御
パブリック キャッシュ制御とは、プロキシ サーバーなど、サーバーとクライアントの間の任意の仲介者によってリソースをキャッシュできることを意味します。プライベート キャッシュ制御とは、リソースをユーザーのブラウザーのみがキャッシュでき、他の仲介者はキャッシュできないことを意味します。
セキュリティの観点から見ると、機密情報が意図しない者によってキャッシュされるリスクが軽減されるため、プライベート キャッシュ コントロールの方が一般的に優れています。たとえば、Web ページに顧客アカウント情報が含まれている場合、Cache-Control ヘッダーを Private に設定すると、この情報が他のユーザーが使用するプロキシ サーバーによってキャッシュされなくなります。
ただし、パブリック キャッシュ制御は、公開されている画像や CSS ファイルなど、仲介者がセキュリティ上の懸念を持たずに安全にキャッシュできる特定のリソースに必要な場合があります。この場合、リソースが機密でないことを確認し、適切なキャッシュ ディレクティブを使用して機密データへの不正アクセスを防ぐことが重要です。
要約すると、プライベート キャッシュ制御とパブリック キャッシュ制御の選択は、要求されるリソースの性質とアプリケーションのセキュリティ要件によって異なります。セキュリティの専門家として、これらの違いを理解し、セキュリティ リスクを最小限に抑えるために適切なキャッシュ ディレクティブが使用されていることを確認することが重要です。
ステータスコードの構成
ステータス コードの設定により、サーバーはどのステータス コードをどれくらいの期間キャッシュするかを指定できます。
たとえば、Web アプリケーションは、サーバーがリクエストの成功を示す 200 OK ステータス コードで応答した場合、特定のリソースをより長期間キャッシュしたい場合がありますが、サーバーが 4xx または 5xx ステータスで応答した場合はリソースをキャッシュしたくない場合があります。コード。エラーまたはサーバー側の問題を示します。
セキュリティの観点から、ステータス コード構成パラメータを使用すると、リクエストでエラーが発生したり失敗したりした場合に、機密情報のキャッシュを防ぐことができます。たとえば、ユーザーが制限されたリソースにアクセスしようとして、403 Forbidden ステータス コードを受け取ったとします。その場合、サーバーはその特定のリソースに対して短いキャッシュ TTL (Time To Live) を指定して、リソースがキャッシュされて許可されていない者に公開される可能性を防ぐことができます。
さらに、ステータス コード構成を使用して、CSRF (クロスサイト リクエスト フォージェリ) や XSS (クロスサイト スクリプティング) などの特定の種類の攻撃を軽減することもできます。これらの攻撃に関与するリソースに適切なキャッシュ TTL 値を設定することで、サーバーはこれらのリソースの古いバージョンが悪意を持って使用されるのを防ぐことができます。
結論として、ステータス コード構成パラメータは、応答ステータス コードに基づいてキャッシュ動作を制御し、特定の種類の攻撃を軽減することでセキュリティを強化するために使用できる Cache-Control ヘッダーの重要な側面です。
キャッシュ制御に CDN を使用する利点
キャッシングは、リソースをサーバーからローカル ドライブの近くに移動して、アクセスを高速化し、待ち時間を短縮することと考えることができます。これと同じ考え方が当てはまる コンテンツ配信ネットワーク (CDN) は、Web サイトのコンテンツをプロキシに移動して、コンテンツの配信と帯域幅の最適化を高速化します。プロキシ サーバーは、リソースをすべてエンド ユーザーまたは Web サイト訪問者のローカル ドライブに保存するのではなく、キャッシュする中間サーバーです。
CDN はキャッシュ制御に多くの利点をもたらします。
1. キャッシュポリシー管理を簡素化します
Web 開発者が手動でファイル タイプにタグを付け、すべての異なるキャッシュ ヘッダーを微調整して管理するのは大変なことです。 CDN は、使いやすいダッシュボードを使用して、キャッシュ ポリシーの管理を簡素化するのに役立ちます。管理者は、必要に応じてキャッシュ ヘッダー ディレクティブを上書きし、詳細なレベルで特定のファイルやファイル タイプを制御できます。
2. プロキシを使用してブラウザのキャッシュを強化します
ブラウザー キャッシュ自体は、最初の訪問後に Web サイトのリソースをローカル ドライブにダウンロードする役割を果たします。 CDN は、プロキシを使用して、ローカルに保存されたリソースの配信を高速化できます。
これにより、コンテンツをサイトの訪問者に近づけることができ、キャッシュされた単一のコピーが複数の訪問者に確実に提供されます。また、ブラウザがまだサイトのコンテンツをキャッシュしていない可能性のある初めての訪問者にも、リソースを迅速に配信できます。
3. 機械学習を使用してキャッシュを自動化できます。
より高度な CDN の中には、機械学習 (ML) を使用してキャッシュ制御を自動化できるものがあります。 ML アルゴリズムは、コンテンツの使用パターンを追跡し、動的にコンテンツとリソースをキャッシュに生成できます。
たとえば、時間の経過とともにあまり変更されていない HTML ファイルは、静的というラベルを付けて、キャッシュ可能として分類できます。ページの読み込みと応答を高速化するために、CDN サーバーから直接提供できます。アルゴリズムは、ページのステータスを追跡し続け、変更があるとすぐに動的として分類できます。これにより、ストレージとキャッシュのポリシーが最適化され、コンテンツの配信速度が向上します。
