ネット・トラフィックの最適化についてのCDN、OTTな議論

1. 通信と放送の融合を考えるBoF 5
～竹やりを超えよう～
Janog 47
Masaaki NABESHIMA
Jan 28, 2021
Copyright (c) kosho.org 1
V1.2

2. • コロナの影響でトラフィックが増えたこともあり、ネット・トフィッ
クの最適化(トラフィックエンジニアリング)についての議論が盛ん
• ただし、国内ではインターネットトラフィックを支配しているCDNや
QoE計測を行っているOTTについてまともな議論が行われていない
• 国内でのトラフィック議論は、CDNやOTTという「爆撃機」に対し、
ネットワークオペレーションという「竹やり」で戦おうとしている
Copyright (c) kosho.org 2
BoFの背景

3. ◼ 目的
• ネット・トラフィックの最適化についてCDN、OTTな議論をする
◼ アジェンダ
• 国内CDNの状況(前回の復習)
• CDNとISPの協調(Open Caching)
• OTT QoE計測
• 国内最適化(シミュレーション)
• NGN網内配信
• 政府調達のCDN要件厳密化
Copyright (c) kosho.org 3
はじめに

4. ◼ CDN配信拠点数
Copyright (c) kosho.org 4
国内CDNの状況(鍋島調査)
GSLB方式 自社 (拠点数) ISP内 (AS数)
Cloudfront DNS 1 0
Clodflare エニキャスト 2 0
Akamai (edgesuite) DNS 2 42
Akamai (edgekey) DNS 2 8
Akamai (akamaized) DNS 2 38
Fastly 国別：DNS
国内：エニキャスト
3 0
Youtube URL生成 2 11
Netflix URL生成 2 ?

5. ◼ 素朴な疑問
• 国内トラフィックの最適化
• 一般的には「細かくCDN配信サーバを配置すればよい」と言われて
いる
• じゃあ、一番配信拠点の多いAkamaiを使えば良い？
• すでに42 ISP以上でサーバを運用
• ポリティカルな意味(主権問題)以外にも、いろいろ課題がありそう
Copyright (c) kosho.org 5
Akamai考察

6. ◼ 系列比較
• SSL化により、分散度合いが減っているように見える
• 可能性：プラットフォームのライセンス販売もしている？ので、技術
だけ買って国内運用すれば良い？
Copyright (c) kosho.org 6
Akamai考察
Edgesuite系列 Edgekey系列
概要 配信拠点が多く、配信性能も良い 配信拠点が少なく、配信性能も悪いと言われ
ている(Cedexis anonymous SSL)
ISP 42以上 8以上
コンテンツ Web系非SSL配信、ビデオ系(SSL含む、
Abema?)
Web系SSL配信、ビデオ系(SSL含む、
Paravi?←QoE悪い(VideoMark logより))
補足 ISP内部にサーバがあってもリクエストが割り
振られないケースが多い(Akamai ASからの配
信が多い)

7. ◼ 上位ISP(シェア1%以上)
Copyright (c) kosho.org 7
国内ISPの状況(鍋島調査)
Akamai, edgesuite Akamai edgekey Youtube Netflix
KDDI (2516) 〇 〇 〇 ？
Softbank BB (17676) 〇 × × ？
NTT Communications (4713) 〇 × × ？
NTT Docomo (9605) 〇 〇 〇 ？
So-net Entertainment (2527) 〇 × 〇 ×
Jupiter Telecommunication (9824) 〇 〇 〇 ？
Ucom (17506) 〇 × × ？
Biglobe (2518) × × 〇 ？
K-Opticom (17511) × 〇 〇 〇
IIJ (2497) 〇 × × ×
Vectant (2519) 〇 〇 × ？
Chubu Telecommunications (18126) 〇 × × ？
NTT-PC (2514) 〇 〇 〇 ？
Asahi Net (4685) 〇 × 〇 ？
Tokai (10010) × 〇 × ？
Fujitsu (2150) × × × ？

8. ◼ 配置の傾向
• Akamai Edgesutie系列
• 結構な数のISPが持っている(ただし前述の議論あり)
• Akamai(2系列)、Youtubeを持っている⇒お勧めISP
• モバイル大手2社(KDDI、Docomo)、NTT-PC
• Youtubeを持たない
• SBB、OCN、UCM、IIJ、Vectant、Chubu-tele、Tokai、Fujitsu
◼ サーバの分散配置
• 色々な人がトラヒックの最適化には分散配置と言い、ISPもそれに対
して(表立って)反対している雰囲気はない。しかし、ISPはCDNサーバ
を内部にあまり持っていない
Copyright (c) kosho.org 8
ISP内部CDNサーバ

9. ◼ アプローチ
• CDNのサーバをISPが無料コロケ
• 大手のみ(Youtube、Netflix、Akamai)
• AkamaiもSSLは怪しい(自社ASからの配信が多い)
• その他CDNではエニキャストが増加⇒自社AS+強い配信拠点
• CDNとISPのレベニューシェア
• すべて破綻（直近、Ericsson UDN)
• CDN フェデレーション(CDN間のトラフィック交換)
• OnAppモデル(OnApp社がCDNスイートをISP・キャリアに販売、販
売したCDN間でのトラフィック交換)はオペレーション中
• Open Caching
• 構想は6年ぐらい前、最近、実サービスが動き出した
Copyright (c) kosho.org 9
CDNとISPの協調

10. ◼ CDNフェデレーション(OnAppモデル)
• キャリア・ISP・ASPがOnApp社のCDNスイートを購入、CDN運営
• それぞれのCDNは独立運用だがアーキテクチャは同じ
• 各社のCDNは他ISPのCDNノードを使い配信
• メインターゲットは中小規模Web(配信単価が高い)
Copyright (c) kosho.org 10
CDNとISPの協調

11. ◼ Open Cachingとは
• ISPが所有・運用するOCN (Open Caching Node) サーバを、CDNの共用
配信サーバとして利用すること
• 推進団体：Streaming Video Alliance
• 状況：運用中
Copyright (c) kosho.org 11
Open Caching
ISP
CDN-A CDN-B
OCN
サーバ

12. ◼ CDNマーケット状況
• ISPとCDNの協調：マイナーISPは無視
• マイナーなISPにはCDNの配信サーバを配置できない
• CDNサーバのパフォーマンス＞＞ISPが必要とするキャパシティ
• 透過型キャッシュ：下火
• SSLの普及
• 基本的にSSLコンテンツはキャッシュできない
• コンテンツの整合性問題
• 「透過型キャッシュ＝勝手キャッシュ」でありオリジンのアッ
プデートを検知できない（しない）場合がほとんど
Copyright (c) kosho.org 12
Open Caching:背景

13. ◼ Open Caching背景
• 透過型キャッシュのメーカーが、CDNのコンテンツをきちんとキャッ
シュできるフレームワークをアライアンス(SVA)のもと開発
• 機能
• SSL証明書挿入、キャッシュ整合性操作(パージ等)
• 2段階リクエストルーティング
• 実装
• CDNの共用配信サーバ
• マイナーISPにも配置可能
Copyright (c) kosho.org 13
Open Caching:背景

14. ◼ Streaming Video Alliance (SVA)
• https://www.streamingvideoalliance.org/
• 設立：2014年11月、米国主導
• ワーキンググループ
• Open Caching、Quality of Experience (QoE)、Home Storage Open
Caching Node、5G and Edge Cloud for Streaming Video、
Measuring Latency in ABR Streaming、End-to-End Ad Monitoring、
…
• メンバー
• 91社
• https://www.streamingvideoalliance.org/current-members/
Copyright (c) kosho.org 14
Open Caching:推進団体

15. ◼ メンバー
Copyright (c) kosho.org 15
Open Caching:推進団体(SVA)

16. ◼ コンテンツ
• グローバル：Disney +、Steam、Dailymotion
• 米国：CBS、Warner Media
• ブラジル：Globo
• パキスタン：Tune.PK
• 準備中：Amazon Video
◼ ISP (公表分のみ)
• ブリティッシュテレコム (英国)
• VCサポート：有
• https://www.lightreading.com/cablevideo/cisco-qwilt-digital-alpha-take-on-cdns-with-open-caching/d/d-id/764494
• TIM Brazil (ブラジル)
• VCサポート：有
• https://www.lightreading.com/the-edge/tim-to-light-up-open-caching-in-brazil/d/d-id/766199
Copyright (c) kosho.org 16
Open Caching:運用情報 (2021年1月現在)

17. ◼ Open Cachingの機器導入費用をVenture Capitalがサポート
• 基本プログラム
• CISCO (Edge computing platform)＋Digital Alpha (Venture Capital)
• Digital Alpha (VC)
• 機器代を負担
• CDN事業者等から利用料を徴収、機器代を穴埋め？
• レベニューシェアではなく、デジタルシネマのVPF的な施策？
• CDNレベニューシェア：すべて破綻
• Open Cachingモデル：？
Copyright (c) kosho.org 17
Open Caching:投資会社によるサポート
VPF (Virtual Printing Fee)制度：デジタルシネマ機器の導入費用をスタジオが補助する
プログラム。映画を1本興行するたびに、(デジタル化により不要となる)物理フィルム1本相
当の代金(約6万円)を劇場に支払うというもの。このプログラムにより映画館のデジタル化(1
台2000万程度)が一気に進んだ。基本的に機器代金の補てんが終了すると補助は切れる。

18. ◼ ビジネスモデル考察
• Qwiltキャッシュ性能：20Gbps
• 平均配信5Gbps⇒配信量年間20PB(20,000,000GB)
• GB単価(仮定と考察)
• 所感
• GB単価0.1～0.2円ぐらいでビジネスが回りそう
Copyright (c) kosho.org 18
Open Caching :投資会社によるサポート
GB単価 年間 CDN側の値ごろ感 VC回収 実現可能性
1.00円 2,000万円 高すぎ Xか月 ×
0.10円 200万円 悪くない X年 〇
0.01円 20万円 格安 X十年 ×

19. ◼ ビジネスモデル考察
• VCのリスク
• 導入したが配信量が少ない（投資回収できない）
• 配信側との握りが望ましい
• 国内展開(案)
• 国内大手OTTがファンドを作り、OCNをばら撒けば成立
• 補足
• この手のファイナンシャルスキームでは、タイトな収支コント
ロールとコンテンツ側との握りが求められる、単純な中抜き商社
の出る幕は無い
• メーカとの直契約(一般的)
• コンテンツとの窓口＋運用サポート会社(今回の場合だと国内
CDN事業者?) Copyright (c) kosho.org 19
Open Caching :投資会社によるサポート

20. ◼ 構成
• Open Caching Node (OCN)、各ISP
• Open Caching Controller (OCC)、クラウド上
Copyright (c) kosho.org 20
Open Caching:システム構成
ISP ISP ISP
OCN
Open Caching
Controller (OCC)
現状Qwilt社製品のみ
OCN OCN Open Cache Node (OCN)

21. ◼ OCNのユーザリクエスト処理
• 通常のCDNエッジサーバ(Reverse Proxy)として受け取る
• 透過型ではない
• 間接的にCDNのGSLBからエッジサーバとして指定を受ける
• 2段階ルーティング
Copyright (c) kosho.org 21
Open Caching:システム構成
OCN
CDN GSLB
OCC GSLB
example.jp
OCNのIPアドレス

22. ◼ 2段階ルーティング
• ユーザがOCNを持たないISPの場合
• CDNは適切なCDNサーバのIPアドレスを返す
• ユーザがOCNを持つISPの場合
①ユーザリクエスト1(⇒CDN GSBL)
CDNはOpen Caching用のCNAMEを返す(example.jp.opencaching)
②ユーザDNSリクエスト2(⇒OCC GSLB)
OCCはCNAMEから適切なOCNサーバのIPアドレスを返す
Copyright (c) kosho.org 22
Open Caching:システム構成
CDN GSLB
OCC GSLB
example.jp
example.jp.opencaching
example.jp.opencaching
OCNのIPアドレス

23. ◼ API
• リクエストルーティング
• フットプリント(Open CachingをサポートしているISPのリスト)
• OCNの健全性(OCNが落ちている場合、そのISPに対しては2段階
ルーティングしない)
• コンテンツ操作
• 設定(SSL証明書等)
• キャッシュ操作(パージ等)
• ログ回収
• 課金ログ等
Copyright (c) kosho.org 23
Open Caching:OCC API
ISP ISP ISP
OCN
Open Caching
Controller (OCC)
OCN OCN
CDN-B
CDN-A CDN-C

24. ◼ SVA
• https://www.streamingvideoalliance.org/documents/
Copyright (c) kosho.org 24
Open Caching:Documents
概要
Open Cache Solution Functional Requirements Document
Optimizing Video Delivery With The Open Caching Network
仕様
リクエスト
ルーティング
Open Cache Request Routing Functional Specification
Open Cache Request Routing Service Provisioning Interface Specification
キャパシティ管理
Open Caching Capacity Interface
Open Caching Performance Measurement Specification
コンテンツ管理 Open Caching Content Management Operations Specification
ログ管理
Open Cache Logging Requirements Specification
Open Caching Logging Integration Functional Specification
その他 Open Caching Relayed Token Authentication

25. ◼ CDNユーザ (Webサイトオーナー等)
• 基本的に設定なし
• CDNがOCCを使うかどうか設定する
• CDNユーザがOpen Cachingを使うには、CDNがOpen Cachingを
サポートしていなければいけない
• CDN側が作りこめば、CDNユーザがOpen Cachingの利用可否を制御
することも可能
Copyright (c) kosho.org 25
Open Caching:設定

26. ◼ CDN
• 事前準備
• OCCに対し配信設定を行う(OCCコンソール)
• OCCに指定コンテンツをOpen Caching対象として認識させる
• ホスト名、SSL証明書等
• 自社のGSLBに2段階ルーティングの設定を行う
• OCNを持つISPの場合、Open Caching用CNAMEを返す
• コンテンツ操作(パージ等)
• OCC APIを操作
• アクセスログ
• OCC API経由で取得
Copyright (c) kosho.org 26
Open Caching:設定

27. ◼ ISP
• 事前準備
• QwiltのキャッシュBOXでOpen Cachingを有効にする
• キャッシュBOX
• Open Cachingモードで稼働
• OCCと通信
• OCCコンソール
• キャッシュさせるコンテンツの指定(可否)
• 各種統計？
Copyright (c) kosho.org 27
Open Caching:設定

28. ◼ Open Caching
• ISPとCDNの新しい協調モデル
• ISP所有のCache箱をCDNの共用エッジサーバとして利用
• 小規模なISPおよびCDNも導入可能
• Venture Capital仲介によるCAPEX(初期投資)不要の導入
• 導入手順
• CDNユザー：なし
• CDN：OCC APIによる各種操作
• ISP：基本設定(Open Cachingをオンにする)のみ
Copyright (c) kosho.org 28
Open Caching:まとめ

29. ◼ CDN側の準備
• Open Cachingをフルに使う
• CDNバックエンドの作りこみ(OCC API操作)が必要
◼ Open Cachingの安定性
• OCC (Open Caching Controller)の安定性
• 新しいシステムであり安定性が不明
• OCN (Open Caching Node)の健全性
• OCNがオーバーロードすると配信品質が落ちる
• 対策
• CDN内部にマルチCDN処理（フェイルオーバー処理が必須）
Copyright (c) kosho.org 29
Open Caching:課題となりそうなところ

30. ◼ マルチCDN
• サーバサイド・マルチCDN
• CDNは以下の二つをチェックした後に2段階ルーティングを行う
• OCCの健全性、OCNの健全性
• 補足
• リアルタイム性の確保が難しい
• プレイヤサイド・マルチCDN
• プレイヤーは配信品質が落ちた場合OCNを切り離す
• 補足
• 単純なアプローチだが有望
Copyright (c) kosho.org 30
Open Caching:フェイルオーバー処理

31. ◼ ストリーミング再生のQoE
• 基本QoE (Quality of Experiment)
• 遅れなく、奇麗に、スムーズに動画を視聴
• 見たいコンテンツに必要な帯域があれば良い
• 例えばフルHD動画(6Mbps)であれば、ダウンロード速度6Mbpsが確
保されればQoE的にはOK
• これ以上ダウンロードが早くてもQoE的なスコアは同じ
• 注意：基本帯域の数倍以上必要
• 初期バッファリング、トリックプレイ(早送り等)
• 現実的なQoE計測
• 問題があった再生の割合を算出する
• 計測はプレイヤー主導
• プレイヤーが各種指標を計測し、集計サーバにアップロード
Copyright (c) kosho.org 31
ストリーミングQoE計測

32. ◼ 重要指標 (SVA Key Network Delivery Metrics)
◼ 補助指標
• チャンクのダウンロード速度
• ユーザ環境(Wi-Fi等)
Copyright (c) kosho.org 32
ビデオQoE計測
再生開始までの時間 ユーザから再生ボタンを押してから動画が始まるまでの時間
初期バッファリング成功 再生開始リミットまでに初期バッファリングが充足したか？
再バッファリング率 再生途中に再バッファリングで動画が止まった時間
再生したコンテンツの
平均ビットレート
再生したビットレート(アダプティブビットレートにおいて
選択されたビットレート)

33. ◼ オープンソース実装
• Web VideoMark
• https://vm.webdino.org/
• WebDINO (旧 Mozilla Japan)
• ブラウザ用プラグインで動画再生の統計を取得
• Youtube、Tver、Paravi等
• 横ぐし的比較が可能
• CDN比較、ISP比較
• 課題
• iOS系端末では速度が取れない
• Resource Timing APIのtransferSizeが取れない
• APIではなくプレイヤーの内部処理にフックをかける必要あり
Copyright (c) kosho.org 33
OTT QoE計測

34. ◼ APIs
• User Timing API
• 任意のタイミングの時間計測
• Navigation Timing API
• ブラウザ表示に関する時間取得
• Resource Timing API
• リソースのロードに関する時間取得
• Frame Timing API
• フレーム表示に関する時間取得
• Server Timing API
• サーバが送信するヒント情報の取得
• High Resolution Time API
• マイクロ秒単位のタイムスタンプ
Copyright (c) kosho.org 34
W3C Web Performance Working Group

35. ◼ ISP単位、時間単位でビデオ視聴品質の統計データを出す
• 例
• 平均ビットレート（アダプティブ）
• 1080P、720P、480P
• バッファリング無し率
• 4K: XX%
• 1080P: YY%
• 720P:ZZ%
◼ 課題
• ISPのMVNOセグメントは別集計したい
• 絶対速度の計測は行ってない
• ビデオチャンク：小さいのであまり速度がでない
Copyright (c) kosho.org 35
OTT QoE計測の共通化、指標化

36. ◼ トポロジーの考察
• 配信拠点数とバックボーンコスト
• 県庁間距離 (https://www.gsi.go.jp/KOKUJYOHO/kenchokan.html)
• 人口比率 (https://www.stat.go.jp/data/jinsui/2019np/index.html)
• 算出
• 総距離(km)
• 人口重み付け総距離(距離*人口比率)
• 各配信拠点の割り当て人口比率
Copyright (c) kosho.org 36
国内最適化

37. ◼ 配信拠点：東西の最適化
• 現状、東京・大阪のトラフィック
• 2:1ぐらい
• バックボーンコストを最小化するように最適化
• 東京と大阪のトラフィック(人口比率）はほぼ同じになりそう
Copyright (c) kosho.org 37
国内最適化：シミュレーション結果(1)
配信拠点 総距離(km)
人口重みづけ
総距離
拠点の割り振り比率(人口比率)
東京、大阪 12,084 187.3 東京 0.53
大阪 0.47

38. ◼ 配信拠点：2か所⇒5か所
• 2か所(東京、大阪)⇒5か所(仙台、東京、名古屋、大阪、福岡)
• バックボーンコストは1/2になりそう
Copyright (c) kosho.org 38
国内最適化：シミュレーション結果(2)
配信拠点 総距離(km)
人口重みづけ
総距離
拠点の割り振り比率(人口比率)
東京、大阪 12,084 187.3 東京 0.53
大阪 0.47
仙台、東京、
名古屋、大阪、
福岡
6,186 92.0 仙台 0.13
東京 0.37
名古屋 0.14
大阪 0.21
福岡 0.16

39. ◼ 2拠点割り振り
◼ 5拠点割り振り
Copyright (c) kosho.org 39
国内最適化:県別割り振り
割り振り比率
仙台 0.13 北海道、青森、岩手、宮城、秋田、福島、新潟
東京 0.37 茨城、栃木、群馬、埼玉、千葉、東京、神奈川
名古屋 0.14 富山、石川、福井、岐阜、静岡、愛知、三重
大阪 0.21 滋賀、京都、大阪、奈良、和歌山、鳥取、岡山、徳島、香川、高知
福岡 0.16 広島、山口、愛媛、福岡、佐賀、熊本、大分、宮崎、鹿児島、沖縄
割り振り比率
東京 0.53 北海道、青森、岩手、宮城、秋田、福島、新潟、茨城、栃木、群馬、埼玉、千葉、東京、神
奈川、富山、静岡
大阪 0.47 石川、福井、岐阜、愛知、三重、滋賀、京都、大阪、奈良、和歌山、鳥取、岡山、徳島、香
川、高知、広島、山口、愛媛、福岡、佐賀、熊本、大分、宮崎、鹿児島、沖縄

40. ◼ Internet接続料金
• ISP料金：500～1,100円
• 光ファイバ料金：4,400～4,700円(集合住宅：3,050円～)
◼ 矛盾点
• バックボーン：500～1,100円/月
• 混み始めている、地方ISPはコスト負担に困っている
• ISPが負担(ISP料金はネット接続料金の10%～36%)
• 足回りファイバ網(NGN)： 4,400～4,700円/月
• 混んでるとは聞かない(NGN折り返しという非効率も始まりそう）
• PPPoE終端は容量不足
Copyright (c) kosho.org 40
バックボーンコスト考察

41. ◼ 課題
• 高い料金を取っているのに頑張らないNTTが悪い？
• CATVもNGN料金と同水準の値付けにしていて同罪
◼ 可能性
• NGN網内からの最適配信
• 他事業者(CDN等)は無理(SNI料金が高すぎる)
• NTT負担でやらせる(Open Caching等)
Copyright (c) kosho.org 41
バックボーンコスト考察

42. ◼ SNIインターフェイス
• NGN application Server-Network Interface
• サーバ接続のためのインターフェイス
• 1Gbpsあたり280万円/月
• IX接続(100Gbpsあたり108万円/月)の100倍以上
• 高すぎて使えない
◼ 背景
• ネットのコスト負担問題（ただ乗り問題）
Copyright (c) kosho.org 42
NGN網内からの配信

43. ◼ 1:100 (配信：ユーザ)の費用負担
• 「配信：ユーザ」で「1:100程度」
• 配信：IXまでの費用負担
• ユーザ(ISP)：IX以降のすべての費用負担
• 単価比較
• CDN配信：GBあたり1円程度
• モバイル受信：GBあたり200～300円程度
• 産業規模比較
• CDN配信：国内400～500億円程度
• ネット接続：約8兆円(モバイル通信、家庭用ファイバ、ISP、CATV
ネット接続)
Copyright (c) kosho.org 43
NGN網内からの配信

44. ◼ 可能性
• 配信事業者のNGN利用
• 大規模事業者向け料金プランが必要
• IXと同程度の値付け(100Gbpsで100万円程度)
• NTTの費用でOpen Caching
• 運営にかかる費用はNTT持ち
Copyright (c) kosho.org 44
NGN網内からの配信

45. ◼ 政府・地方自治体調達におけるCDN要件の厳密化
• 成功事例
• IPv6
• IPv6率：.jp全体2.87%に対し、go.jpは18.12%
• 要件
• 災害対策系配信
• 国内2拠点以上で配信(2 AS以上が望ましい)
• メディア系配信
• 国内2拠点以上、地理的最適化配信
• 課題
• 国内系CDNの保護、育成
Copyright (c) kosho.org 45
最適配信の推進

46. ◼ CDN現状
• Netflix、Youtube、Akamaiはきちんと分散配信(Akamaiは怪しくなっている）
◼ ISPとCDNの協調
• Open Cachingいけるかも
◼ OTT QoE
• ストリーミングのQoE
• 立ち上がりが早く、再バッファリング無しに、見れた動画の解像度
• 指標化は可能
◼ 国内最適化
• きちんとやれば東京：大阪でトラヒック比率1:1にできそう
• 5拠点(仙台、東京、名古屋、大阪、福岡)にすればバックボーンコストは1/2
• バックボーン最適化より足まり系最適化が重要
◼ NGN網内配信
• 他事業者(CDN等)の配信はSNI料金が1/100以下にならないと無理
• NTT費用もちのOpen Caching
◼ 最適配信の推進
• 調達におけるCDN要件の厳密化
Copyright (c) kosho.org 46
まとめ

47. ◼ ISP-CDN-JP
• https://groups.google.com/g/isp-cdn-jp
◼ 国内トラフィックの最適化について
• https://www.kosho.org/blog/net/jp-te-outline/
◼ なぜNGNのSNIは使えないのか？
• https://www.kosho.org/blog/net/why-ngn-sni-is-not-good/
Copyright (c) kosho.org 47
参考資料