Please enable JavaScript.

Coggle requires JavaScript to display documents.

Web配信の技術 - Coggle Diagram

- - - - Cache-controllヘッダとか
        Ageヘッダとか
        
        cache-controllはageの影響を受ける
        
        cache-contrlollが1hで、ageも1hだとすぐにキャッシュが消える
        
        このように両方見る必要がある
      - CDNの事故
        
        CDNによっては、サーバ側の意図とはちがった、標準とも違う動きをする場合がある
        
        疑ってかかるのが重要
        
        例えばcache-controllのno-store
        キャッシュさせないという設定であるが、CDNによってはこれを正しく理解できず、キャッシュしてしまう場合があるらしい
    - - キャッシュされる条件
        
        キャッシュを許可しているか
        
        可能なステータスコードか
        
        cache-controllがprivateでないこと
        とか色々ある
        
        キャッシュの格納先がshared
      - キャッシュを使う条件
        
        有効期限ないであるか？
        キャッシュの検証が完了してるか？
        とか色々ある
    - - Varyヘッダとキャッシュ
        
        これがない場合、PCでみたのにスマホ用の画面が返さる可能性がある。スマホの人が先にキャッシュしたから
        
        Varyは例えばUAごとにキャッシュを作るようなもの
        UAごとにキャッシュを作るべきであれば、Vary: UAとかにすると、実現出来る
        
        よく使うのはEncodingらしい
        
        gzipとかbortiとかreflateなどのどの圧縮技術にクライアントが対応しているかを送る
        
        サーバはそれごとにキャッシュをして返す。
      - コンテンツが更新されたかどうかを判別するヘッダ
        
        Last-Modified
        
        コンテンツをキャッシュした日を持っている
        これがサーバに通信したとき、日付が更新されているようであれば、新しいコンテンツを取得しにいく
        
        Etag
        
        仕組み的にはLast-Modifedと一緒だが、
        コンテンツごとに一意なIDを生成するらしい
        
        Last-ModifedはURLごとに一つの更新日という感じで持つが、
        Etagは同じURLだとしても、コンテンツが違うならことなるIDをもつっぽい
        
        英語と日本語の言語で提供しているサイトとか
        
        優先順位はEtagが上
        
        これにより予期せぬ落とし穴があるらしい
        事故にもつながるかも
        
        https://blog.redbox.ne.jp/http-header-tuning.html
      - 間違えやすいno-storeとno-cacheについて
        
        no-storeはキャッシュするなという意味
        
        no-cacheというのは、キャッシュがなければオリジンにいけということ
        必ずキャッシュがあるかどうか、それが最新かどうかを判定して、クライアントに返す
      - no-cache, must-revalidate, proxy-revalidate, immutable
        
        違い
        
        no-cacheは全リクエストで、キャッシュが最新か確認する
        
        must/proxy-revalidateはmax-ageを持っており、それが切れたときのみ、キャッシュが最新か確認する
        
        immutableは一度キャッシュすると二度と更新されることはない
        使い所がわからない
    - - CDN等では中間経路でデータを圧縮する場合がある
      - データを軽くして、速度を出したいたため
      - しかし問題がある
        
        圧縮することにして、復元するときに整合性が取れず、正しくDLすることが出来ない場合がある
        
        そこでno-transformディレクティブを指定する
        これが聞かない場合もある
        
        第2の対策として中間の通信をhttps化する
        
        こうすることで、圧縮してサイドssl化して通信するには、
        RootCAから辿れる（チェーンして）、証明書が必要だが、そんなもの中間は持ってないので、通信不可
      - 最近はgzipじゃなくてBrotliという圧縮を使うらしい、5-7倍くらい圧縮率が変わるとか
        
        https化必須
    - - 各サーバを辿ってくると、どこでどんなヘッダを設定しているのかわからず、設定に困ってしまう
      - こんなときは最後の出口で、ヘッダの精査と設定を行ってやればきれいになるので、クライアントはその出口の設定だけを意識すれば良い
  - - - 特定のユーザのみが使うキャッシュ
        ブラウザとかが主
    - - 複数のユーザが使うキャッシュ
        
        ブラウザ（一人で使うことになるが、ここに置くことももちろん出来る）
        
        CDN
        
        Proxy
  - - - 期限切れでオリジン検証中にキャッシュを返す
        
        オリジンがエラーのときにキャッシュを返す
        
        期限切れでオリジンに問い合わせたが変更ないので、キャッシュを置き換えずにそのまま使う
        
        stage-while-revalidateがバックグラウンドで再検証を行う愛大にフルキャッシュを使うことを許可する設定
        
        stale-if-error　オリジンが死んでるときに、キャッシュを使うことを許可する設定
    - - fresh
        
        有効期限内のキャッシュ
      - stale
        
        期限切れのキャッシュ
        
        期限切れでもすぐに捨てるわけではない。必要になる場面がある