CDNの仕組み（JANOG36）

CDNの仕組み
JANOG 36
2015年7月15日
鍋島公章
株式会社Jストリーム
1© 2015 J-Stream Inc. All Rights Reserved.
REV:20150715

目次
▶CDN概論
▶キャッシュ制御
▶負荷分散
▶キャッシュ出来ない通信への適用
▶プロトコル変換（アクセラレーション）
▶CDNの未来
© 2015 J-Stream Inc. All Rights Reserved. 2

CDN概論
▶CDNとは
▶CDNのメリット
▶CDNの仕組み

CDN：Content Delivery Network
▶Content (デジタルデータ/不可算名詞）
▶Not Contents(入れ物/可算名詞）
▶Delivery (配達)：コンテンツをクライアントに届けること
▶Not Distribution(流通)：コンテンツを配信網内に分散させること
▶Network (実際には仮想ネットワーク)
▶Not 配信専用の物理Tire1ネットワーク(昔はあった）
4
© 2015 J-Stream Inc. All Rights Reserved.

CDNとは
▶配信のアウトソース
▶地理分散
5
オリジンサーバ
CDNサーバ
クライアント

CDNとは
▶メリット
6
種別用途
国際配信アクセスの高速化
国内配信ピーク対策、コスト削減
プロトコル変換 SSL化、HTTP/2化、WebSocket化等

CDNのメリット：高速化
▶TCPの速度制限
▶前提：ショートセッション
▶ロングセッションはTCPウィンドウの自動拡張により速度改善
▶後進国
▶不十分な国際リンク
距離 RTT 最高速度
東京・沖縄間 0.04秒 12.5Mbps
日米間 0.10秒 5.0Mbps
日欧間 0.20秒 2.5Mbps

CDNのメリット：ピーク対策
▶ピーク例
▶CDNの効果
8
ピーク同時接続ピーク帯域
キャンペーン通常の数～数十倍
メディア露出同時接続：数千数百Mbps
TV連動同時接続：数十万～数十Gbps～
仮定：1ページあたり10オブジェクト、1オブジェクトたり20KB
CDNなし
CDNあり
オリジン
トラフィック

CDNのメリット：設備費用の圧縮
▶配信設備の壁
▶CDNの効果
▶設備費用の平準化
9
項目上限値
クラウド
ホスティング
同時接続 200～
帯域 100Mbps
専用サーバ
同時接続 1,000～10,000
帯域 100Mbps、1Gbps
ピーク性能
設備費用
CDNなし CDNあり
共用の壁 100Mbpsの壁 1Gbpsの壁

CDNのメリット：プロトコル変換
▶プロトコル変換
▶オリジンサーバ
▶HTTP/1.1
▶CDNサーバ（変換後の主要プロトコル）
▶TLS
▶HTTP/2
▶WebSocket
10
オリジンサーバクライアント
TLS
HTTP
CDNサーバ

もっとも単純なCDN
▶コンポーネント
▶DNS複数IPアドレス返し
▶ミラーサーバ
▶ブラウザ処理
▶複数のIPアドレス
▶ラウンドロビン動作
▶フェイルオーバー処理
▶HTTPデーモンダウン
▶瞬時切り替え
▶サーバダウン
▶数十秒以上(TCPフェイル）待ち
▶課題
▶最適なサーバ選択
▶フェイルオーバー処理
▶ミラーサーバ同期待ち
198.51.100.10
203.0.113.10
192.0.2.10
DNS:www.example.jp
192.0.2.10
203.0.13.10
198.51.100.10
フルミラーラウンドロビン
CDNサーバ

CDNの仕組み
▶コンポーネント
▶配信サーバ
▶コンテンツの複製
▶リクエストルーティング
▶（広域負荷分散）
▶最適な配信サーバの選択
▶最適な配信経路の選択
▶管理システム
▶顧客コンソール
▶顧客管理、ログ管理
▶複製制御、配信経路制御
192.0.2.10
203.0.13.10
最適な複製配置最適なサーバ選択
198.51.100.10
CDNサーバ

CDN配信サーバ：複製の方式
▶キャッシュ型
▶一般オブジェクト、共用CDN
▶オブジェクト配置：削除アルゴリズム
▶LRU (Least Recently Used)：アクセス時刻が古いもの
▶LFU (Least Frequently Used)：アクセス頻度が低いもの
▶ミラー型
▶巨大オブジェクト(XGB～）、OTT専用CDN
▶コンテンツの人気度にあわせた（意図的な）オブジェクト配置
▶無駄なディスク書き込みの排除
▶同期さえれた後に外部公開（CMS必須）
1回目
2回目以降
オリジンサーバCDNサーバ

CDN配信サーバ：パフォーマンス
▶一般構成
▶目安（構成により異なる：RAID、CPU等）
▶瞬間ピークの前提
▶特定コンテンツへの集中アクセス(オンメモリのオブジェクトヒット)
▶The state of Arts構成（Netflix等）
▶SSD＋メインメモリ100GB～＋各種チューニング
▶通常ピーク：30Gbps～
通常ピーク瞬間ピーク
HDD構成～0.5Gbps 5Gbps程度
SSD構成数Gbps 5Gbps程度

キャッシュ制御
▶HTTPヘッダ
▶部分ファイル対応
▶Cookie対応

キャッシュ制御
▶生存時間（TTL）、キャッシュ禁止指定
▶基本的な考え方（現実は別）
▶大まかな制御
▶設定コンソール＋API
▶細かな制御＋クライアントのキャッシュ制御
▶HTTPヘッダ
HTTPヘッダ
正規表現
API
方法概要
設定コンソールによる指定正規表現等によるオブジェクト指定
CDN API コンテンツの削除、プリロード
オリジンサーバからの制御レスポンスのHTTPヘッダによるオブジェクト単位の詳細設定
設定コンソール

キャッシュ：HTTPヘッダ
▶HTTPの基本
HTTPリクエスト
HTTPレスポンス
GET /index.html HTTP/1.1
Accept: image/gif, image/jpeg, */*
…
HTTP/1.1 200 OK
Date: Thu, 26 Oct 2012 16:51:49 GMT
Server: Apache/1.3.14 (Unix)
….
HTML本体
HTTPヘッダ

リクエストレスポンス
Accept: image/gif, image/x-xbitmap, image/jpeg,…
Accept-Language: ja
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (compatible; MSIE 5.5;…
Host: example.jp
Connection: Keep-Alive
HTTP/1.1 200 OK
Date: Thu, 26 Oct 2000 16:51:49 GMT
Server: Apache/1.3.14 (Unix)
Last-Modified: Thu, 18 Mar 1999 05:31:05 GMT
ETag: "f012-491-36f08f99"
Accept-Ranges: bytes
Content-Length: 1169
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html> <head>
<title>サンプルサーバ</title>
…
HTTPヘッダ

▶CDNにおける分類
③レスポンス
HTTPヘッダ
②リクエスト
HTTPヘッダ
④レスポンス
HTTPヘッダ
①リクエスト
HTTPヘッダ
ブラウザ CDNサーバオリジンサーバ
リクエスト
①CDNサーバ、オリジンサー
バに対するキャッシュ指示
②オリジンサーバに対する
キャッシュ指示
ー
レスポンスー
④ブラウザに対するキャッ
シュ指示
③CDNサーバ、ブラウザに
対するキャッシュ指示

HTTPヘッダ：③オリジン生成（レスポンス）
▶オリジンサーバが生成するCDN関連ヘッダ
HTTPヘッダ概要サンプル
キャッシュ
コントロール
Cache-Control キャッシュ設定一般各種パラメータ指定
Expires 有効期限 Thu, 01 Dec 2015 16:00:00 JST
Vary URLに対し複数のオブジェクト User-Agent
設定が必須（無いと
キャッシュされない）
Content-Length オブジェクト長 4427
Last-Modified 最終更新時間 Thu, 01 Dec 2014 16:00:00 JST
設定しない方が良い（あ
るとキャッシュされない
場合がある）
ETag オブジェクトのユニークiD 686897696a7c876b7e
httpのサーバ圧縮 Content-Encoding エンコーディング gzip, deflate, sdch※
※sdch: Shared Dictionary Compression over HTTP (Chrome)

▶Cache-Controlパラメータ
用途パラメータ概要
キャッシュ許可
public キャッシュ許可
private ブラウザ等に対し許可（キャッシュサーバでは禁止）
no-cache キャッシュ不許可
no-store 一時的な（内部処理としての）コピーも禁止
改変許可 no-transform 改変不可
最新性のチェック
max-age 無チェック時間の最大値
s-maxage 無チェック時間の最大値（キャッシュサーバ上）
must-revalidate 毎回、チェック
proxy-revalidate プロキシー、CDNサーバでは毎回チェック

▶サンプル
Cache-Control 用途
no-cache, no-transform
・キャッシュ不可
・改変不可
private
・ブラウザではキャッシュ可
・CDNではキャッシュ不可
public, max-age=3600
・キャッシュ可
・ブラウザおよびキャッシュサーバは1時間以上保持したオブジェクトの最新性を
チェック
public, s-maxage=3600
・キャッシュ可
・キャッシュサーバは1時間以上保持したオブジェクトの最新性をチェック
・ブラウザは、最新性チェック設定（毎回、起動時等）に従う

HTTPヘッダ：③オリジン生成(Vary)
▶Vary
▶同一URLに対し複数のVariationが存在する
▶例
▶User-Agent（オリジンはUser-Agent毎にページ生成）
▶Accept-Encoding(オリジンはhttpをgizp圧縮）
▶指定
▶User-Agent、Accept-Charset、Accept-Encoding、Accept-Language
▶注意:キャッシュ効率が低下(User-Agent：IE 9だけで数十種類）
Vary: User-Agent
https://example.jp

HTTPヘッダ：③オリジン生成(ETag)
▶ETag
▶例
▶ETag: "686897696a7c876b7e"
▶オブジェクト毎・サーバ毎にユニークな値
▶オリジンサーバが複数台の場合
▶CDNに悪影響（キャッシュされない）
▶オリジンサーバで生成しない設定が必要
ETag: “12345"
ETag: “98765"
ミラー

HTTPヘッダ：③オリジン生成(その他)
▶オリジンで意図的に生成すべきヘッダ
▶有効期間の指定（expire、max-age）
▶指定が一切無いとCDNサーバでキャッシュされない場合がある
▶ブラウザにおける最新性チェックを防ぐ(FEO)
▶指定時間の間は、再起動してもチェックしない

HTTPヘッダ：②④CDNサーバ生成
▶CDNサーバが生成
HTTPヘッダ概要サンプル
②リクエスト
（対オリジン）
X-Forwarded-for ブラウザIPアドレス 192.168.0.100
Forwarded 同上 192.168.0.100
④レスポンス
（対ブラウザ）
AGE オブジェクトの無チェック時間 3623
Via 中継サーバの名前※ our-proxy
※中継サーバ名前：中継サーバで設定された名前（偽造容易）
③レスポンス
HTTPヘッダ
②リクエスト
HTTPヘッダ
④レスポンス
HTTPヘッダ
①リクエスト
HTTPヘッダ

HTTPヘッダ：①ブラウザ生成
▶ブラウザが生成（キャッシュサーバへの指示関連）
HTTPヘッダ概要
キャッシュ関連 Cache-Control 各種設定
最新性チェック
If-Modified-Since 指定時間から変更があった場合
If-Unmodified-Since 指定時間から変更が無かった場合
Etag関連
If-Match Etagがマッチした場合
If-None-Match Etagがマッチしない場合
If-Range Etagがマッチした場合Rangeを実行
Vary関連
User-Agent ブラウザ名
Accept-Charset 受け付けるCharset
Accept-Encoding 受け付けるEncoding(HTTP圧縮：gzip、deflate、sdch)
Accept-Language 受け付けるLanguage
Pragma (HTTP/1.0) Pragma:no-cache キャッシュ不可

HTTPヘッダ：①ブラウザ生成
▶Cache-Control
用途パラメータ概要
キャッシュされたコンテンツの
送信許可(対キャッシュサーバ)
no-cache
キャッシュされたコンテンツの配信を不許可
得られたコンテンツをキャッシュ不可
no-store 同上（一時的なストアも不許可）
改変不可(対キャッシュサーバ) no-transform 改変不可、改変されたコンテンツの配信を不許可
キャッシュ存否 only-if-cached キャッシュされていた場合のみ
最新性のチェック
（条件を満たさない場合、受け
取りを拒否）
max-age 無チェック時間の最大値
max-stale 無効となってからの最大時間
min-fresh 有効である時間の最小時間※
※例 min-fresh=3600：1時間以内に無効となるコンテンツを受け付けない

キャッシュ：応答コード抜粋
系列 Code 概要
100系 100 通知
200系 200 処理成功
206
Range成功
部分コンテンツ配信
300系
301
リダイレクト（恒久）
サイト移設、常時SSL
302
リダイレクト（臨時）
Apacheデフォルト
304 オブジェクト無変更
307
リダイレクト（臨時）
メソッド変更禁止※
系列 Code 概要
400系 400 リクエスト不正
401 パスワードエラー
403 権限エラー
404 オブジェクトNot Found
407 プロキシ認証必要
412 マッチング条件失敗※※
500系 500 サーバ内エラー
502 CDN：オリジンエラー
503 サービスダウン（高負荷）
504 CDN：オリジンタイムアウト
※PostなのにGetで処理するブラウザ対策 ※※If-Unmodified-Since

MPEG-DASH概要
▶ライブ
▶オンデマンド
HTTPサーバ
メディアソース
mp4、mp4aファイル
MPDファイル
クライアント
変換
HTTPサーバ
メディアファイル
mp4、mp4aファイル
MPDファイル
クライアント
変換ファイルの部分取得

キャッシュ：部分ファイル対応
▶URLパラーメタ方式
▶例：http://example.jp/test.mp4?range=1025,2048
▶test.mp4の1025バイト目から2048バイト目までを指定
▶オリジンの対応が必要
▶一般的な方法
▶使用サービス：Youtube
▶キャッシュの対応
▶CDN
▶「URLパラメータを含む」キャッシュができることが必須
▶企業FW
▶「URLパラメータを含む」キャッシュは出来ないが、HTTPの中継は出来るた
め（多くの場合）影響なし（元々、多くのMPEG-DASHはno-cache）

▶CMS等へのキャッシュ適用
▶URLパラーメタを含むキャッシュ
▶例：http://example.jp/index.php?page=12
▶ページ番号：12
▶全体をキーとしてキャッシュ
▶例：http://example.jp/index.php?page=12&uid=100
▶ページ番号：12
▶ユーザID：100
▶ページ番号までをキー（uid部分を無視）してキャッシュ
▶メリット
▶バックエンドDB負荷の低減
▶ページの更新
▶CDN APIで対象ページを更新

▶HTTP Rangeヘッダ方式
▶Range例
▶応答コード
GET /test.mp4
Host: example.jp
Range:bytes=1025-2048
HTTP/1.1 206 Partial Content
…
Accept-Ranges:Bytes
Content-Length: 1024
Content-Range:bytes 1025-2048/40960
Code 概要コンテンツの扱い
200 Range失敗全体が返される
206 Range成功指定部分が返される
リクエストレスポンス

▶Rangeヘッダに対するキャッシュの実装レベル
▶補足：クライアントの実装レベル
▶Rangeを出して200が返るとパニックするアプリに注意
レベル概要レスポンス
ファイルの最後のみを指定
キャッシュの可否返答待ち
レベル1 Rangeリクエストの仕様を守る(処理
できないことをレスポンスする）
200
不可なし（先頭か
ら返す）レベル2 可（全体）
レベル3 部分ファイルをクライアントに返す 206 可（全体）※ あり
レベル4 部分的なキャッシュが出来る 206 可（指定部分のみ）なし
※全体をキャッシュするまでファイルを返さない（待ちが発生）

キャッシュ：Cookieの基本
1回目リクエスト 2回目以降リクエスト
HTTPリクエスト
HTTPレスポンス
HTTP/1.1 200 OK
…
Set-Cookie:id=kosho;path=/;expires=…
はじめまして。
HTTPリクエスト
…
Cookie:id=kosho
HTTPレスポンス
HTTP/1.1 200 OK
…
koshoさん、こんにちは

キャッシュ：クッキー(Set-Cookie)
▶「レスポンスにSet-Cookieを含む」オブジェクト
▶キャッシュすると複数の端末に同じクッキーを設定
▶一般的には無意味
⇒キャッシュさせない
HTTPリクエスト
HTTPレスポンス
HTTP/1.1 200 OK
…
Set-Cookie:id=kosho;path=/;expires=…
はじめまして。

キャッシュ：クッキー(Cookie)
▶「Cookieを含むリクエストに対する」オブジェクト配信
▶Cookieベースでページ生成
▶情報の漏洩⇒キャッシュさせない
▶Cookieベースでユーザトラッキングのみ
▶キャッシュ可能
▶CDNへの設定
▶基本ルール
▶無視してキャッシュ
▶例外ルール
▶キャッシュしないＵＲＬを指定
▶補足
▶クッキーベースの制御は困難
▶使用例：グルーピング(国別クッキー）
HTTPリクエスト
…
Cookie:uid=kosho
HTTPレスポンス
HTTP/1.1 200 OK
…
koshoさん、こんにちは
HTTP/1.1 200 OK
…
みなさん、こんにちは

負荷分散
▶リクエストナビゲーション（広域負荷分散）
▶DNS
▶メタファイル
▶エニキャスト
▶SDN
▶制御
▶粒度
▶テーブル作成
▶ローカル負荷分散

広域負荷分散
▶リクエストナビゲーション
▶手法
単位（粒度）補足
DNS ローカルDNSサーバ一般的な方法
メタファイルクライアントIPアドレスストリーミング用
エニキャスト AS 一部CDN事業者が使用を開始
? ー一部Tire1 OTT
39

40
広域負荷分散：DNS
▶DNSによる制御
▶ホスト名をResolveする時に、異なるIPアドレスを返す
▶ISP DNS(ISPのDNSキャッシュサーバ）単位のクライアント認識
usa.example.jp
(203.0.113.10)
japan.example.jp
(198.51.100.10)
example.jp
ISP DNSサーバ
example.jp DNSサーバ
ISP DNSサーバ
example.jp
198.51.100.10 203.0.113.10
198.51.100.10 203.0.113.10
example.jp example.jp
課題
DNSの有効期間（30秒等）を無視するDNSサーバ
DNSの有効期間（30秒等）内の障害

41
広域負荷分散：メタファイル
▶メタファイルによる制御
▶メタファイル生成時に、異なるメディアファイル（サーバ）を返す
▶IPアドレス単位のクライアント認識
usa.example.jp
japan.example.jp
https://usa.example.jp/test.mp4
https://japan.example.jp/test.mp4
課題
メタファイルサーバの地理分散
クライアント単位のルーティングテーブル作成は大変
video.mpd

42
広域負荷分散：エニキャスト
▶エニキャストによる制御
▶同じIPアドレスを複数の拠点に配置
▶ルーティング（主にBGP）で経路を制御
198.51.100.10 198.51.100.10
経路の広報
経路の広報
課題
サーバダウン時の経路制御
経路制御が乱れた時のTCP（ステイトフル）通信

43
広域負荷分散：Tire1 OTT
▶Tire1 OTTネットワーク内処理
▶AS内部の経路制御を高速化
198.51.100.10 198.51.100.10
?
Tire 1 Network
課題
詳細不明

44
広域負荷分散:制御粒度
▶地理的距離≠ネットワーク距離
▶トンネリング
▶携帯網 (GTP-u)
▶フレッツ網 (PPPoE)
▶DNSベース
▶ISP DNS単位の制御

広域負荷分散:テーブル作成
▶基本アプローチ
①距離の計測
②計測結果の収集
③ナビゲーションテーブル作成
ISP DNS-abc ISP DNS-xyz
②計測結果の収集
GSLB
①距離の計測
DNS-abc: Edge1
DNS-xyz:Edge2
….
③ナビゲーションテーブル作成
Edge1 Edge2

広域負荷分散:テーブル作成
▶実際
▶自動距離測定は難しい
▶メトリック
▶RTT (ICMP)：ICMP通らない、ISPからのクレーム
▶ルータホップ数：同上
▶BGP ホップ：GSLBへの読み込ませが大変
▶プローブ数
▶配信拠点が増えると、全拠点からの計測は不可能
▶現実には、事前設定した各種テーブルとの合わせ技＋職人技
▶国別・IPテーブル
▶AS・IPテーブル

ローカル負荷分散：クラスタ化
▶キャッシュサーバのローカルクラスタ化
▶メリット
▶ヒット率の向上
▶パフォーマンス向上（DiskIOの軽減）
▶ローカル・リクエスト制御
▶手法
▶複数IP返し
▶L4SW（Direct Server Return）
▶メリット
▶フェイルオバー
example.jp
(DNS複数IPアドレス返し)
198.51.100.10
198.51.100.11
198.51.100.11198.51.100.10
キャッシュのハッシュ化

キャッシュ出来ない通信のCDN
▶アプリケーション通信
▶ライブストリーミング

キャッシュできない通信のCDN
▶配信サーバの中継による経路制御
▶L3な経路を取らない（アプリケーション層ルーティング）
▶対象
▶ライブ・ストリーミング
49
輻輳

50
アプリケーションCDN
▶高速プロトコルの使用（配信サーバ間）
▶アグレッシブ（わがまま）なプロトコルを使用
▶極端な例：全速力で送信、輻輳無視、全速力で再送信
▶対比：TCPの特性
▶Fairness（公平性）：ひとつのセッションがリソースを占領しない
▶輻輳検知→送信レートを下げる
▶注意
▶「高速化の効果＜プロトコル変更のコスト」がありうる（主に国内配信）
TCP 特殊（わがままな）プロトコル

51
ライブCDN
▶経路の冗長化
▶プッシュ型：スプリッタで結合（昔の実装、最近はあまり聞かない）
▶パケットを一定時間バッファ、シーケンス番号で判別
▶プル型：最近の実装
▶2経路を用意（視聴アプリで切り替え）
エンコーダ
エンコーダ
ライブフィード
（ライブのオリジン）
ライブフィード

52
ライブCDN
▶エンコーダおよび会場回線の冗長化
▶代表例
▶エンコーダ→会場→ライブフィードサーバ：2系統プッシュ
▶スプリッタ→ライブフィード：2系統プル
▶例：アクティブ・スタンバイ構成
▶実際の運用ではアクティブ・アクティブが多い
エンコーダライブフィード
会場（足回り）回線

プロトコル変換
▶SSL
▶HTTP/2
▶WebSocket

SSL CDN：SSL化の動向
▶動向
大項目
マーケターニーズ
Google検索のランクダウン
SSLサイトからのリファラ取得
HTTP/2 基本的にTLSが使用される(非暗号版が実装されるか未定)
ブラウザ実装
FireFox：非SSLサイトへの機能制約（予定）
Chrome：非SSLサイトへのワーニング表示（ベータ機能）
動画のHTTPS化
Youtube:対応済み
Netflix：2015年9月より開始、2016年中に完了
米国連邦政府連邦機関の全サイトをSSL化(期限：2016年12月31日)
iOS9アプリ ATS(TLS1.2+ forward secrecy必須）がデフォルトで有効化

SSL CDN：SNI
▶SSL SNI (Server Name Indicator)
▶SSLにおけるバーチャルホスト機能
▶非対応
▶Android 2.x、Windows XP、Java6、古めのテレビ
▶SSL ハンドシェイク
▶SNIを使わない場合、ホスト名は使わない
・Client Hello (サポートしている暗号方式）
接続したいホスト名 (SNI)
・Server Hello (使用する暗号方式）
・Server Certificate (サーバのSSL証明書)
www.example.jp
198.51.100.10
198.51.100.10
名前引き

SSL CDN：証明書の種類
ドメイン認証（CNのみ）企業認証（CN＋Ｏ）
EV 証明書：企業認証＋綿密なチェック＋専用上位証明書
CN: Common Name
O: Organization

SSL CDN：証明の対象（サブジェクト）の格納
ワイルドカード・一般証明書マルチドメイン証明書

SSL CDN：IPアドレス割り振り
▶1台のCDNサーバに4種類のIPアドレス
▶補足
▶SNIのマルチドメイン・ワイルドカード証明書は実装依存
▶配信サーバが証明書の中身（マルチドメイン・ワイルドカード）を認識する
必要がある
IPアドレス証明書例 EV対応 SNI使用
① 顧客証明書 www.example.jp ○ ×
② マルチドメイン証明書/CDN事業者 www.example.jp/www.stream.ne.jp △ ×
③ ワイルドカード証明書/CDN事業者 *.stream.ne.jp × ×
④ 顧客証明書 www.example.jp ○ ○
マルチドメイン証明書/顧客 www.example.jp/example.jp ○ ○
ワイルドカード証明書/顧客 *.example.jp × ○

HTTP/2概要
▶HTTP/2 メリット
▶プロトコルのバイナリ化（フレーム化）
▶HTTP/2フレーム：HTTPメソッドの新フォーマット
▶HTTPヘッダの圧縮
▶使用するTCPは1セッション
▶輻輳制御の効率化→帯域利用の最大化
▶多重化通信(多重ストリーム）
▶HTTP/2ストリーム：サーバ・クライアント間の（多重化）通信単位
▶新規TCP、新規SSLセッションの開始コストを削減
▶同時転送数の上限なし（サーバ側の制限あり）
▶ストリーム間の優先付け
▶サーバープッシュ（コンテンツのプリセンド）

HTTP/2 CDN
▶HTTP/2アクセラレータ
クライアント
HTTP/2
HTTP/1.1
複数のリクエスト
を1本のTCP化
サーバプッシュ
レスポンスHTTPヘッダ
プッシュ指定
link:<screen.css>; rel=preload; as=stylesheet
CDN設定
プッシュ指定(ファイル)
プライオリティ指定

WebSocket概要
▶WebSocket概要
▶HTTPベースの両方向通信
▶軽量
▶他の軽量プロトコルのラップ
▶RESP (Redis Serialization Protocol)
▶MQTT (MQ Telemetry Transport)
▶CoAP (Constrained Application Protocol)
▶アプリケーション
▶ゲーム・チャットルーム
▶リアルタイム一斉配信
▶アンケート
▶データ集計(IoT：Internet of Things)

WebSocket CDN
▶RESP等のWebSocket化（さらにはSSL化）
▶FWの通過
▶RESP:ほぼ通らない
▶WebSocket:たまに通らない(Protocol Upgradeできない）
▶SSL：通る
（Redis等）CDNサーバ
クライアント
RESP等/WebSocket/SSL
RESP等
終端＋各
種処理
PC等からの操作

WebSocket CDN：課題
▶ポート番号
▶ポート番号：0～65,535
▶最近のサーバは、1台あたり6万セッション以上を処理可能
▶1台のサーバに複数IPアドレス
▶SSL化
▶SSL化の負荷：10倍程度
▶SSLオフロード（アクセラレータ）ボード
▶IPアドレスの増加
▶「WebSocket対応＝最近の端末」⇒SNIでOK
▶WebSocketの終端
▶汎用（API）化

CDNの未来
▶複数CDNの統合
▶ICN/CCN

複数CDNの結合
▶マルチCDN
▶メタGSLBによるCDN振り分け
▶CDNフェデレーション(CDNI)
▶CDNの結合
▶CDNIインターフェイス
▶IETFでの議論
▶CDI WG: 2001～2003
▶CDNI WG: 2011～
▶配信サーバの共有モデル
▶プロプライエタリなシステム
CDN1
CDN2
契約
CDN1
CDN2
プロプライエタリ
CDN1
CDN2
CDNI
契約
契約
GSLB
GSLB
GSLB
GSLB
GSLB
マルチCDN
CDNI
配信サーバの共有
メタGSLB

ICN/CCN
▶Internetの仕組みをコンテンツを中心に再構築
▶Information Centric Networking (ICN)
▶Content Centric Network (CCN)
▶CCN概要
▶コンテンツのPublish＆Interest
▶名前によるルーティング（コンテンツへの経路テーブル）
▶経路上へのコンテンツ・プロパゲーション（複製）
▶課題
▶スケーラビリティ（キャッシュ領域、経路テーブル）
違いはルーティング
PublishInterest
複製複製複製

おわりに
▶参考文献等のリンク
▶J-Stream CDN情報サイト
▶https://tech.jstream.jp/blog/meeting/janog36/

CDNの仕組み（JANOG36）

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a CDNの仕組み（JANOG36）

Similar a CDNの仕組み（JANOG36） (20)

Más de J-Stream Inc.

Más de J-Stream Inc. (11)

Último

Último (8)

CDNの仕組み（JANOG36）