4.3 キャッシュと HTTP の仕様
4.3 キャッシュと HTTP の仕様
キャッシュのメリットは以下の通り
- ネットワークが切れた場合でもある程度サービスを継続できる
- サーバへの通信回数・転送量が減る
(ユーザーの体感速度向上やユーザー/サーバ側のコスト低減につながる)
プロキシサーバーがある場合はデータ鮮度に気を付ける必要あり。
4.3.1 Expiration Model (期限切れモデル)
レスポンスデータにキャッシュの保存期間を設定しておき、期限が切れたら再度アクセスをしてデータ取得を行う。
保存期間の指定方法は以下の 2 つ。
Cache-Control レスポンスヘッダを利用
現在時刻からの秒数を指定を行う。
max-age の計算には Date ヘッダ (レスポンスが生成されたサーバ側の日時) が利用される。
Expires レスポンスヘッダを利用
期限切れを絶対時間で RFC1123 で定義された形式で指定する。
両方を併用した場合はCache-Control が優先される。
4.3.2 Validation Model (検証モデル)
保持しているキャッシュが有効かどうかをサーバに問い合わせる方法 (条件付きリクエスト)。
問い合わせの結果として、有効の場合は「有効である」という情報のみ、有効でない場合は最新のデータを返す。
通信によるオーバーヘッドは変わらないが、転送データが軽減できる。
条件付きリクエストでは「保持してるデータの状態」として最終更新日時やエンティティタグ（MD ハッシュ等） をサーバに伝える。
これらはサーバ側で生成され、クライアント側でキャッシュとして保存される。
最終更新日時とエンティティタグのやり取りは以下のヘッダが利用される。
レスポンスヘッダ
それぞれLast-Modified とETag が利用される。
リクエストヘッダ
それぞれIf-Modified-SinceとIf-None-Matchヘッダを利用する。
サーバー側からのレスポンスではステータスコードはキャッシュが有効な場合は304で空ボディ、変更があった場合は200とともに最新データを返す。
4.3.3 Heuristic Expiration（発見的期限切れ）
サーバの更新頻度や状況を参考に、クライアント側でキャッシュの有効期限を決める方法を Heuristic Expiration（発見的期限切れ）とよぶ。
4.3.4 キャッシュさせたくない場合
Cache-Control ヘッダを以下のように利用してキャッシュをさせたくないことをクライアント側に伝えることができる。
4.3.5 Vary でキャッシュの単位を指定する
キャッシュを行う際に、URI 以外にどのリクエストヘッダ項目をデータを一意に特定するのに利用するかを指定する場合はVary ヘッダを利用する。
(Accept-Language ヘッダに指定の言語によってレスポンスの利用言語を変える場合等に利用される[サーバ駆動型コンテンツネゴシエーション\の一例])
4.3.6 Cache-Control ヘッダ
stale-while-revalidate
stale-while-revalidate=600 のように秒数を指定する。レスポンスヘッダに指定する。
プロキシサーバーが max-age で指定された秒数を超えた後に、キャッシュを返しつつ非同期でキャッシュの検証を行う時間を指定できる。
stale-if-error
オリジンサーバへのアクセスが何らかの理由で失敗した時に、保持している新鮮でないキャッシュをクライアントに返してもよい秒数を指定する。
サーバの停止等があっても少しの間サービスを継続することができる。