Web配信の技術を読んでいく
2021/05/11(火) 20:50-23:00
- 表紙
- 第1章 はじめに
- 第2章 配信の基礎
- 2.3 配信の経路まで
気づき・感想
-
配信とは、サーバにあるコンテンツをクライアントに届けること
- とてもわかりやすい原則。Webサイトだろうが、ゲームアセット配信だろうが、同時配信ライブだろうが、根本的にはみんなこれ
-
配信には種類がある
- スポーツなどのライブ配信、ゲームアセット配信など
- これらはリアルタイム性が求められる。バッファを小さくしたり、パケットロスで欠落してもスキップできるように(視聴体験向上)、WebRTCなどより適したプロトコル、フォーマット採用
- 動画配信(VOD)
- 事前にエッジへ配信して、オリジンへの急激なトラフィック増を避ける
- スポーツなどのライブ配信、ゲームアセット配信など
-
2.3 配信の経路にあった、「ファーストマイル、ミドルマイル、ラストマイル」の視点はとても為になった。
- その後のコラムにあった5Gの話があった。ラストマイル側が低遅延だったとしても、ファーストマイル、ミドルマイルが遅かった場合には、全面的に解決するわけでは無さそう。
- MEC(マルチエッジコンピューティング)で5Gを利用している端末に近いところに配置するという考え方も。
- 第1章で、ProxyとCDNどちらもキャッシュできそうだけど、これらの違いは何なのか? という疑問はあった。〜マイルの概念で考えると、Proxyはファーストマイル側。CDNはラストマイル、ミドルマイル側となるんだろうか。と、仮説が立った
- その後のコラムにあった5Gの話があった。ラストマイル側が低遅延だったとしても、ファーストマイル、ミドルマイルが遅かった場合には、全面的に解決するわけでは無さそう。
2021/05/18(火) 20:00-21:30
- 2.4 配信をより高速なものにするために
- 2.5 キャッシュの格納場所による分類
- 2.6 private/sharedキャッシュ
- 2.7 どこでキャッシュすべきか
感想等
- 参加者のうち多数が、10秒ごとにコンテンツが更新されるようなものは作らない
- そう考えたときに、配信の最適化も重要ではあるけど、どのキャッシュがprivateなのかsharedなのかという区別をちゃんと付けられるようにしておくことの方が結構大事なんじゃないか
- ちゃんと設定が把握できてないと、いつの間にかprivateな対象を経路上のキャッシュとしてキャッシュしてしまう恐れがありそう
- 図2.18の格納場所としてのキャッシュを「ローカル・経路上・ゲートウェイ」キャッシュと名付けているのが今日イチ良かった!
- 経路上のキャッシュの中にゲートウェイキャッシュが内包されており、経路上のキャッシュで使えるノウハウは、ゲートウェイキャッシュにも活用できる、というのが端的にわかる良い図
配信最適化で実現したいこと
- コンテンツを高速にダウンロードできること
- 突発的なリクエスト増に耐えられること
- 低コストで実現する
配信経路を最適化する
- CDNを経路上に置いて、出来る限りクライアントとコンテンツを配信できるものを近くに置くこと
キャッシュの格納場所による分類
大まかに分けると3箇所ある
- クライアント側のキャッシュ(ローカルキャッシュ) → ブラウザキャッシュ
- 配信経路上のキャッシュ
- オリジンのキャッシュ(ゲートウェイキャッシュ)
ローカルキャッシュ
- 外に問い合わせがいかないので高速
- 主にCSS/JavaScript/画像をキャッシュする
昔はブラウザのキャッシュは、ある時間までキャッシュする程度の制御しかできなかった(TTL?)
最近だと、Service Workerを使うことで、より細かく柔軟に制御が可能
経路上のキャッシュ
主にCDNを用いる。
オリジンの負荷軽減、配信経路最適化、大きな配信帯域を確保するなどで導入することが多い。
CDN割り振りの仕組み
- DNSにより割り振る方式
- IP AnyCast方式
経路制御プロトコル(BGP) → Anycastに関連する技術
ゲートウェイキャッシュ
Proxyを用いてキャッシュする。
オリジン側に近い。大体オリジンの傍(同一リージョンなど)に配置する
経路上のキャッシュの一部だが、キャッシュの内容に一貫性をもたせやすいのがメリット。
ストリーミングデータのように時系列で変化するものをCDNでキャッシュすると、エッジごとにキャッシュする内容が変わる恐れがあるので、それを防ぐ目的がある。
digコマンド
EDNS Client Subnet (ECS) の挙動を確認するために、digコマンドを初めて使った。
ほんとに違った
% dig www.akamai.com +short
www.akamai.com.edgekey.net.
www.akamai.com.edgekey.net.globalredir.akadns.net.
e1699.dscx.akamaiedge.net.
104.102.151.130
% dig www.akamai.com @8.8.8.8 +short
www.akamai.com.edgekey.net.
www.akamai.com.edgekey.net.globalredir.akadns.net.
e1699.dscx.akamaiedge.net.
104.102.151.130
% dig www.akamai.com @9.9.9.9 +short
www.akamai.com.edgekey.net.
www.akamai.com.edgekey.net.globalredir.akadns.net.
e1699.dscx.akamaiedge.net.
184.27.20.136
privateとshared、ローカルキャッシュと経路上のキャッシュ
キャッシュの対象としてprivateかsharedにするかという考え方。
キャッシュの格納先として、ローカルキャッシュか、経路上のキャッシュ(&ゲートウェイキャッシュ)という考え方。
ローカルキャッシュ、経路上のキャッシュは本書での特別な言い方。他だと、格納先もprivate、sharedって言ったりするので、気をつける。
キャッシュファイルの末尾
レスポンスヘッダが含まれているらしい
cache-control:
など
2021/05/25(火) 20:00-22:00
- 3章 HTTPヘッダ・設定とコンテンツの見直し
- 3.3 ステータスコード まで
参考記事
感想等
- HTTP2 疑似ヘッダばかり
- GET HTTP2っていうのは、curlがよしなに表示してくれるの知らなかった。
- x-で始まるヘッダは独自ヘッダってのは分かってたけど、現在非推奨であることは知らなかった
- Apacheでのヘッダ操作のコラムを見ていて、そもそもHTTPヘッダってそんなカジュアルに変えていいものなのかと不安に思ってしまった
- CDNとかProxyとかでもヘッダを操作できるっぽいから、良いのか?
- と思ったけど、禁止ヘッダー名があるから、こいつらは操作ができない仕様になっている?
- ステータスコードは、外部向けに作るAPIならある程度標準仕様に則った作りにする必要はありそう
- マイクロサービスでの通信で使うやつは、極論プロジェクト内で整合が取れていればステータスコードに厳密にならなくてもいいのではないかもしれない
- でもログにはステータスコードが出て、bodyの中身まではいちいち出さないだろうから、出来ることなら標準仕様に則ったステータスコードをちゃんと使うことは大事だと思われる
- マイクロサービスでの通信で使うやつは、極論プロジェクト内で整合が取れていればステータスコードに厳密にならなくてもいいのではないかもしれない
HTTP2
試しに、curlでHTTP2で投げる
% curl --head --http2 https://twitter.com/
HTTP/2 200
date: Tue, 25 May 2021 13:29:47 GMT
expiry: Tue, 31 Mar 1981 05:00:00 GMT
pragma: no-cache
server: tsa_m
...
curlだと、HTTP2 200
って表記になるが、
これはcurlがよしなに表示してくれている。
本当は疑似ヘッダ :method: GET
や:scheme: https
などが返ってくる。
(この疑似ヘッダって生で見たいけど、どうやれば見えるんだ)
キャッシュされる/されない例
される
Cache-Control: max-age = 3600
Age: 0
クライアントにキャッシュされるけど、期限切れ扱い(なので、毎回クライアントからリクエストする)
Cache-Control: max-age = 3600
Age: 3600
AgeはオリジンからのレスポンスをProxyがキャッシュしてからの時間なので、
max-ageを上回ると期限切れ扱いになるらしい。
【疑問】キャッシュするのが複数あった場合(Proxy、CDN)、どこからAge数えるんだろ?
HTTPヘッダ
Set-Cookieなど、一部のヘッダ名は重複しても良いらしい
カンマ区切りで定義できるものはOKということ?
ステータスコード
1xx番台のステータスコードはあまり見たことなかった。
レスポンスは完結しているわけではないから、クライアントが判断してもう一度投げるもの?
301と302は恒久的か一時的かの違い。
昔のドメインをまず使わないよね。→でもそれって恒久的かわからないよね。→結果的にそうなるかもしれないが、もう恒久的に使わないという意思表示なんじゃないかと言える
403の種類が多くあって面白い
2021/06/01(火) 20:00-22:00
- 3.3 ステータスコード 4xx番台から
2021/06/08(火) 20:00-22:00
- 3.5 Cache-Controlによるキャッシュ管理
- 3.6 Cache-Controlにおける期限指定
感想等
- Cache-Controlのディレクティブが色々多い
- public, private, 未指定の挙動が、名前から想像できるものが違った
- Fresh, Staleキャッシュという概念を知れたのは大きかった
- 最後、実際のWebページをChromeの開発者ツールで、どうキャッシュされているのかを確認してやると、もっとイメージが付けやすかった
Cache-Controlは出来ること
- キャッシュする・しないの設定(no-store)
- キャッシュの範囲や強制的にキャッシュさせるの指定(public, private, 未指定)
- キャッシュを使う際の設定(no-cache, must-revalidate)
Cache-Controlの期限指定
-
Time-To-Live(TTL)
-
キャッシュの有効期限
-
キャッシュの有効期限内をそのまま返せる
- Freshなキャッシュ
-
キャッシュの有効期限が切れても、そのまま使う
- Staileなキャッシュ
no-storeとmax-age=0, must-revalidateって何が違うの?
no-storeってキャッシュ保持しない。
max-age=0, must-revalidateだと、何が違うんだ? って思ったけど、
キャッシュ自体はしたうえで、常にキャッシュが最新かどうかを検証しにいくということ、らしい。