hysryt
commented
2 years ago 3章
- HTTPヘッダーでローカルキャッシュを活用する
- cache-control ヘッダ
max-age=<seconds>- キャッシュの有効期間。s-maxage=<seconds>- 共有キャッシュ用のキャッシュの有効期間。max-ageより優先される。no-cache- 名前が紛らわしいがキャッシュはされる。ただしキャッシュされたデータを使用する前にデータが有効かどうかをサーバーに問い合わせる必要がある。キャッシュをさせない場合はno-storeを使用する。no-store- キャッシュしてはならないことを表す。must-revalidate- キャッシュが古くなったらキャッシュが有効かどうかをサーバーに問い合わせる必要があることを表す。- age ヘッダ
- プロキシのキャッシュに入ってからの経過時間。
-
コンテンツを改善して転送量を減らす
- Apacheでヘッダーを操作する場合は
mod_headersを使用する。header set- ヘッダーを設定する。同名のヘッダーがある場合は上書き。header append- 同名のヘッダーにヘッダー値をコンマ区切りで追加する。同名のヘッダーがない場合は新規追加。header add- ヘッダーを追加する。同名のヘッダーがあっても新規追加。-
header unset- ヘッダーを削除する。
- HTTP
- RFCには存在しないが、プロキシやCDNの中にはHTTPメソッドとしてPURGEを使用できるものがある
-
HTTP2ではリクエストの開始行は擬似ヘッダーに置き換わっている。バージョン指定は無くなった。
- HTTPレスポンス
206 Partial Content- Range付きのリクエストが成功して部分的なレスポンスボディを返すときのステータスコード。動画配信など。502 Bad Gateway- CDNやProxyとオリジンの間に問題があることを表すステータスコード。名前に反して、オリジンの方に問題があることが多いらしい。-
504 Gateway Timeout- CDNからオリジンの間のレスポンスが遅い場合などに返されるステータスコード。
- HTTPキャッシュ
- RFC7234
- HTTPのレスポンスはデフォルトでキャッシュされる仕組みになっている（cache-controlの設定が無かったともしても）
- キャッシュされる条件は78ページの図がわかりやすい
- キャッシュを使用する条件は80ページの図がわかりやすい
- キャッシュ可能なメソッドはGET、HEAD、POST
- POSTもRFC的にはキャッシュ可能だが基本的にはキャッシュされない。（前にお問い合わせフォームの確認画面がキャッシュでおかしいことになったけどこれのせい？.htaccessとかで
no-storeを指定すれば回避できたかも） - キャッシュ可能なステータスコードは 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 421, 451, 501
- 404 もキャッシュ可能なことに注意
-
実装によってはこれら以外の場合でもキャッシュされることがある。
- リクエストの
cache-controlヘッダでmax-age=0を送信すると、「指定された秒数を超えるキャッシュを受け付けない」という指定になるらしい（意味がよくわからない）- 指定した秒数（つまりこの場合は0）以上経過しているキャッシュは受け付けない、ということっぽい？
- ブラウザは通常のリロードの場合に
max-age=0を送信する- ページに埋め込まれたcssやjsの読み込みには使わないっぽい？
-
ただし解釈しないCDNが多いらしい
- キャッシュの分類
- shared - 複数のクライアントで共有するキャッシュ（経路上のキャッシュ）
- private - 共有しない（してはいけない）キャッシュ（ローカルキャッシュ）
- publicまたはprivateを指定するとキャッシュできない場合（キャッシュできないステータスコードなど）でも強制的にキャッシュを行う
- 403はキャッシュできないステータスコードだが、publicやprivateの指定があればキャッシュできる
- public を指定すると shared にキャッシュ、private を指定すると private にキャッシュ
- 未指定、public、private のそれぞれの動作の違いは84ページの図がわかりやすい
- 前述のとおり、HTTPは基本的にキャッシュを行うので未指定であってもキャッシュできない場合を除いてキャッシュは行われる
- sharedキャッシュとするためだけにpublicを指定するのは間違い
- privateキャッシュに格納する場合はprivateの指定が必要（ただし通常キャッシュできない場合もキャッシュされることに注意）
-
Google Cloud CDN は明示的にpublicを指定しないとキャッシュされないらしい
- キャッシュの使われ方の分類
- no-store - キャッシュを格納してはならないという指定
-
no-cache - キャッシュを使用する際はオリジンへ問い合わせを行い、そのキャッシュが有効な場合のみ使用できる
- キャッシュの更新の方法の分類
- must-revalidate - 期限切れキャッシュの場合は再検証を強制し、検証できなければキャッシュは使用できない。
- proxy-revalidate - 期限切れキャッシュの場合は再検証を強制し、検証できなければキャッシュは使用できない。ただしprivateキャッシュには適用されない。
- immutable - キャッシュは更新できない。キャッシュを使わないようにしたい場合はURLを変更するしかない。
-
no-cacheは毎回検証が必要だが、must-revalidateとproxy-revalidateは期限が切れた時に再検証が必要。
- no-transform - 経路の中間でオブジェクトに対しての操作を許可しない
-
httpsを使うことでも回避できる（というよりhttpsの方が確実？）
-
- キャッシュの期限指定
- キャッシュの有効期限のことをTTL（Time to live）と呼ぶ
- キャッシュには2種類の状態がある
- Fresh - TTLの期限内のキャッシュ（検証が成功してキャッシュが有効な状態）
- Stale - 期限切れだが条件付きで使えるキャッシュ（検証が無効な状態）
- 英単語としては、Freshは「新鮮」、Staleは「新鮮でない」という意味
- Stale から Fresh にするには再検証に成功して有効な状態にする必要がある
- 有効期限はその間は「必ず保存されていること」を保証するものではない
- 有効期限が切れても即座に削除されるわけではない
- 期限切れのキャッシュとして保持され、場合によってはそれが使用される
- ディレクティブ
max-age- レスポンスを生成した時点からの残りの有効期間の秒数。実際の実装ではクライアントがリクエストを開始してからの秒数として使用されることが多いらしい。s-maxage- 経路上のキャッシュのみに有効なmax-agestale-while-revalidate- 再検証を行なっている間に古いキャッシュを使うことを許容する期限-
stale-if-error- 再検証でエラー（オリジンがダウンしている時など）が起きた際に古いキャッシュを使うことを許容する期限。現時点では対応しているブラウザは少ないらしい。
- Expires
- 期限切れの時刻を指定する
- GMT以外は使用できない
Cache-Control: max-ageの方が優先される。- そもそもExpiresは
Cache-Control: max-ageを理解しないクライアントようらしい -
現在はほとんどのブラウザやProxy/CDNで
Cache-Control: max-ageを理解する
- TTLを指定しなかった場合
-
TTL = (Date - Last-Modified) / ブラウザ実装による定数（一般的には10）
-
- キャッシュさせたくない場合の指定
- キャッシュでの事故でありがちなのが、個人データがCDNでキャッシュされてしまうこと
- そのため、キャッシュを使用しない
no-storeに加え、経路上にキャッシュさせないためのprivate、もしキャッシュがあっても再検証を必要とさせるno-cacheを指定すると良い。この本の中ではmust-revalidateも推奨している。 - MDNなどでは
no-store以外を指定するのは悪い例と書かれているが、現状のCDNの実装などを見るとno-storeだけでは心許ないらしい。 -
Last-Modifiedヘッダを消すとTTL未指定の時の動きを排除できるらしい。
- 条件付きリクエスト
- 再検証を効率化するための仕組み
If-Modified-Sinceヘッダ - キャッシュのLast-Modifiedヘッダを値として使用する。更新がある場合はコンテンツを送るよう指示するヘッダIf-None-Match- キャッシュのETagヘッダを値として使用する。一致しなかったらコンテンツを送るよう指示する。If-Modified-SinceとIf-None-Matchを両方指定した場合はIf-None-Matchが優先される。- コンテンツを送る必要がない場合は
304 Not Modifiedとなる。 -
304 として返す場合にもキャッシュの指定が必要。
- Varyヘッダ
- リクエストの特定のヘッダをキャッシュのセカンダリキーとして使用する。
- プライマリキーはURL
- たとえば Accept-Encoding や User-Agent などが指定されることが多い
-
ただしUser-Agentはブラウザによってかなり異なるため無数のパターンが生まれてしまう
- ETag
- ETagの生成方法にinodeが含まれる場合は注意が必要
- ロードバランサは以下に複数のWebサーバーがある場合、Webサーバーによってinodeが変わってしまう
- 結果、ファイルが変わっていないのにETagが変わってしまう
-
過去のApacheではデフォルトでinodeが含まれていたらしい
- 既存の設定の改善
- ゲートウェイに設定を集約する
- ProxyやWebサーバーなど、構成によって異なる
- 3つに分類して深掘りする
- キャッシュさせたくない
- ローカルのみにキャッシュさせたい
-
ローカル+経路上にキャッシュさせたい
- コンテンツサイズの削減
- 圧縮
-
gzip、brotli
- ありがちな問題
- JSONが圧縮されてない
- 複数サーバーを使っている時にデプロイの時間によってLast-Modifiedが変わってしまっている
- デプロイ時にタイムスタンプを保持する設定を行う
2章