Closed11
書籍「Web配信の技術」ノート
第2章 配信の基礎
- RFCのSHOULDは「する必要がある」くらいの強い意味
- private/sharedには'キャッシュする対象としての分類’と'キャッシュの格納先による分類'がある。書籍内では前者として扱う
第3章 HTTPヘッダ・設定とコンテンツの見直し
- HTTP2はリクエストの開始行・レスポンスの説明行を持たない。代わりに
:
で始まる擬似ヘッダを持つ。 - リダイレクト系301/302はリダイレクト時にメソッドをリダイレクト前のリクエストから変更できるが、クライアントにより挙動がことなるため、307/308は変更できないように。
- 使用上キャッシュはオプショナルであるがデフォルトで実行される動作。適切に設定することが重要。
- キャッシュ
-
no-cache
はリクエスト時に必ずキャッシュの再検証を強制する -
must-revalidate
はStale状態のキャッシュの場合、リクエスト時に再検証を強制する
-
- コンテンツの圧縮
- JPEGのqualityは大きい時に画像サイズの差が大きくなる(1 -> 0.9で半分程度にもなる)
- JPEGのqualityによる画像への影響を測れるSSIM(Structural Similarity)という手法がある。ImageMagickでも使われている。
- qualityの値はエンコーダに依存する
- https://pwiki.awm.jp/~yoya/?ImageSizeReduce
第4章 キャッシュによる負荷対策
-
vary
ヘッダはどのリクエストヘッダをセカンダリキーとして利用するかを指定する- キャッシュキー(プライマリキー)はURL、セカンダリキーはプライマリキーの絞り込みにさらに別の条件を追加するもの
- キャッシュキーはクライアントのリクエストだけで決まるが、クライアントからのリクエストとオリジンからのレスポンスの組み合わせとなる情報(リクエストのvaryヘッダとレスポンス内でvaryヘッダで指定されたヘッダの値)
- キャッシュのTTL
-
max-age
: 相対的なTTLを指定。リクエスト開始時間をオリジンでコンテンツが生成された時間として扱い、その時間を基準とする。 -
Expires
: 絶対的なTTLを指定。 -
stale-while-revalidte
,stale-if-error
: キャッシュがTTL期限過ぎてStaleした状態の時の制御を行う。それぞれ再検証(revalidate)中はStaleしたキャッシュを返す期間、エラーがあった時にStaleしたキャッシュを返す期間設定。 -
Age
: キャッシュされてからの経過時間を表す。経路上のキャッシュがクライアントに向けたレスポンスに含む。リクエスト時間
-Age
が残りのTTLとなる - Staleしたキャッシュはキャッシュされていないとは異なる(
max-age=0
とno-store
は異なる)。Staleしたキャッシュは再利用されるケースがある。 -
max-age=0
とno-cache
も異なる。no-cache
は再検証に成功しないとキャッシュを再利用できないというもので、no-cache
~=max-age=0, must-revalidate
。
-
-
キャッシュの消去
- キャッシュの消去は異常時に行うものとして、運用上は適切なTTLを設定することを基本とするのがよい。
- キャッシュの消去は負荷の高い処理で、CDNでも回数制限などが設けられている。
第5章 より効果的・大規模な配信とキャッシュ
-
キャッシュの目的
- サービス全体の負荷軽減
- キャッシュヒット率の向上が目的ではない
- 負荷の高いリソースへのキャッシュ率が高いほうがよい
- サービス全体の負荷軽減
-
経路上の処理フロー
- 開発者から操作できるのは主に以下の4つ
- RxReq: クライアントからリクエストを受信した直後 (キャッシュルックアップ前)
- TxReq: オリジンへのリクエスト(キャッシュルックアップ後)
- RxResp: オリジンからのレスポンス(キャッシュストア前)
- TxResp: クライアントへのレスポンス
- 開発者から操作できるのは主に以下の4つ
--> RxReq -- Cache lookup +-> TxReq ------------------->
Client CDN/Proxy | Origin
v
<-- TxResp <--------------+ Cache store <--- RxRes <----
第6章 CDNを活用する
- CDN
- キャッシュ機能に目が行きがちだがそれだけではない。
- DSA(Dynamic Site Accelaration)
- エッジ-オリジン間はコネクションをkeep-aliveしているため、コネクションが使いまわせる
- 帯域を確認するのに通信量をだんだんと増やしていく、TCP slow startが発生しない
CloudfrontにPOP(edge location)とregional cache edgeがあることを知った。
Lambda@Edgeはregional cache edge上で動く。Cloudfont FunctionsはPOP上で動く。
このスクラップは2021/05/15にクローズされました