HTTPキャッシュの仕組みの詳細な説明

ネットワークアプリケーションの開発において、ウェブサイトのアクセス速度と効率を向上させることは非常に重要です。さまざまな種類のキャッシュを設計することで、不必要なデータ伝送やリクエストを効果的に回避し、ウェブサイトの応答速度を大幅に向上させることができます。HTTPプロトコル自体には、HTTPキャッシュの仕組みが組み込まれています。この記事では、HTTPキャッシュの仕組みとその応用について詳しく説明します。

HTTPにおけるキャッシュの種類

キャッシュの原則は、リクエストされたリソースのコピーをローカルに保存することです。これにより、リクエストが再度行われたときに、サーバーから再度ダウンロードする代わりに、コピーを直接返すことができ、リソースの伝送を削減し、効率を向上させます。リソースに直接アクセスして返すことに加えて、HTTPキャッシュは主に2つのカテゴリに分けられます。

共有キャッシュ: 異なるクライアントが共有キャッシュからリソースを取得できます。これは、複数のクライアントが同じリソースにアクセスするシナリオに適しています。Webプロキシサーバーで一般的に使用されます。多くのユーザーがサーバー上のリソースコピーを共有できるため、各ユーザーが繰り返し保存することを避け、リソースの無効なコピーを削減できます。
プライベートキャッシュ: 特定のユーザーまたはクライアントのみがアクセスでき、他のユーザーはアクセス権を持っていません。ブラウザキャッシュは通常、プライベートキャッシュに属し、現在のブラウザのみにサービスを提供し、他のブラウザとは共有されません。

HTTPにおけるキャッシュされた応答のステータス

HTTPキャッシュは通常、GETリクエストに適用されます。これは、GETリクエストには通常、URI以外のパラメータがなく、主にサーバーからリソースを取得するために使用されるためです。異なるGETリクエストは、異なるステータスコードを返します。

200 OK: リソースが正常に返されました。
301: リダイレクト。
404: リクエストされたリソースが存在せず、例外が発生しました。
206: 不完全な結果が返されました。

HTTPにおけるキャッシュ制御

HTTPキャッシュ制御は、HTTPヘッダーを介して実装されます。HTTP 1.1では、Cache-Controlが導入され、これを利用して、リクエストとレスポンスのキャッシュ動作を細かく制御できます。

キャッシュなし: Cache-Control: no-storeを使用すると、リソースがキャッシュされないことが保証されます。
キャッシュ検証: Cache-Control: no-cacheは、クライアントキャッシュの検証を要求します。
必須検証: Cache-Control: must-revalidateを使用すると、期限切れのリソースの使用が許可されません。
キャッシュスコープ制御: サーバーは、Cache-Control: privateまたはCache-Control: publicを介して、キャッシュがプライベートかパブリックかを制御できます。
有効期限の設定: Cache-Control: max-age=31536000は、リソースの有効時間を設定し、Expiresヘッダーをオーバーライドします。この時間内では、リソースは最新であると見なされ、サーバーから再取得する必要はありません。

HTTP 1.0では、Pragmaフィールドで同様の機能を実現できます。たとえば、Pragma: no-cacheはCache-Control: no-cacheと同様の効果があり、クライアントにキャッシュをサーバーに送信して検証させます。ただし、サーバーの応答には通常Pragmaが含まれていないため、PragmaはCache-Controlを完全に置き換えることはできません。

キャッシュの更新

クライアントがリソースをキャッシュした後、セキュリティ上の理由から、有効期限を設定する必要があります。有効期限内でのみ、キャッシュは有効です。有効期限を超えた場合は、サーバーからリソースを再取得する必要があります。このメカニズムにより、クライアントが取得するリソースが常に最新の状態に保たれ、サーバー側の更新がクライアントにタイムリーに同期されることが保証されます。

キャッシュステータス: クライアントリソースが有効期限内にある場合、ステータスはfreshです。それ以外の場合は、staleです。
有効期限の処理: リソースがstale状態の場合、クライアントからすぐにクリアされることはありません。代わりに、次のリクエストで、サーバーのリソースがまだ新しいかどうかを判断するために、If-None-Matchリクエストがサーバーに送信されます。リソースが変更されていない場合、サーバーは304（Not Modified）を返し、リソースがまだ有効であることを示します。
鮮度の計算: リソースの鮮度の期間は、Cache-Control: max-age=Nによって決定されます。このヘッダーフィールドがレスポンスに存在しない場合は、Expiresヘッダーが存在するかどうかを確認します。存在する場合、鮮度の時間はExpires - Dateです。どちらも存在しない場合は、Last-Modifiedヘッダーを探し、鮮度の時間は（Date - Last-modified ）/ 10です。

Revving

HTTPリクエストの効率を向上させるために、通常はキャッシュ時間を長くすることが望ましいです。ただし、キャッシュ時間が長すぎると、サーバーリソースの更新が困難になります。頻繁に更新されないファイルの場合は、ファイル名とバージョン番号をリクエストURLに追加できます。同じバージョン番号は、リソースコンテンツが変更されておらず、長期間キャッシュできることを示します。サーバーリソースのコンテンツが変更された場合は、リクエストURLのバージョン番号のみを更新する必要があります。最新のフロントエンドパッケージングツールを使用すると、この操作を実装することは難しくありません。

キャッシュの検証

キャッシュされたリソースが期限切れになった場合、リソースをサーバーから再度リクエストするか、キャッシュされたリソースを再検証するかの2つの方法があります。再検証にはサーバーのサポートが必要であり、Cache-Control: must-revalidateリクエストヘッダーを設定する必要があります。

検証方法: クライアントがリソースの有効性を検証する場合、リソースをサーバーに直接送信することはできません。そうしないと、リソースの浪費が発生します。HTTPは、リソースの一意の識別子としてETagsヘッダーを提供します。クライアントは、サーバーにリソースが一致するかどうかを判断させるために、If-None-Matchリクエストを送信します。これは強力な検証です。レスポンスにLast-Modifiedが含まれている場合、クライアントはIf-Modified-Sinceリクエストを送信して、ファイルが変更されたかどうかをサーバーに問い合わせることができます。これは弱い検証です。
サーバーの応答: サーバーは、ファイルの検証を実行するかどうかを選択できます。検証しない場合は、ステータスコード200 OKとリソースを直接返します。検証する場合は、304 Not Modifiedを返し、クライアントにキャッシュされたリソースを引き続き使用できることを通知します。同時に、キャッシュの有効期限の更新など、他のヘッダーフィールドを返すことができます。

Vary応答

サーバーは、レスポンスにVaryヘッダーを含めることができます。その値は、Content-Encodingなどのレスポンスヘッダーの特定のキーです。これは、リソースが特定のエンコーディングでキャッシュされることを示します。例：

最初のリクエスト: クライアントはGET /resource HTTP/1.1、Accept-Encoding: *を送信し、サーバーはHTTP/1.1 200 OK、Content-Encoding: gzip、Vary: Content-Encodingを返します。このとき、リソースとgzipエンコーディングのContent-Encodingが一緒にキャッシュされます。
その後のリクエスト: クライアントはGET /resource HTTP/1.1、Accept-Encoding: brを送信します。現在のキャッシュされたリソースのエンコーディングはgzipであり、クライアントが予期するbrとは異なるため、リソースをサーバーから再取得する必要があります。サーバーはHTTP/1.1 200 OK、Content-Encoding: br、Vary: Content-Encodingを返し、クライアントはリソースをbr形式で再度キャッシュします。次回クライアントがbrタイプのリソースをリクエストすると、キャッシュにヒットします。

Varyは、リソース（エンコーディングタイプなど）をさらに分類することによってキャッシュを実装しますが、リソースの繰り返しストレージにつながります。この問題を解決するには、リソースリクエストを標準化する必要があります。つまり、リクエストの前にエンコーディング方法を検証し、複数のキャッシュを回避するために1つのエンコーディングを選択します。

結論

この記事では、キャッシュの種類、応答ステータス、キャッシュ制御、キャッシュの更新、Revving、キャッシュの検証、およびVary応答を含む、HTTPキャッシュの仕組みを包括的に紹介します。実際のアプリケーションでは、HTTPキャッシュの仕組みを深く理解し、合理的に適用することで、ウェブサイトのパフォーマンスとユーザーエクスペリエンスを向上させることができます。