CDN
视频流化服务和CDN：上下文
- 视频流量：占据着互连网大部分的带宽
- Netflix，YouTube：占据37%，16%的下行流量
- 挑战：规模性-如何服务~1B用户？
- 单个超级服务器无法提供服务（为什么）
- 挑战：异构性
- 不同用户拥有不同的能力
- 解决方案：分布式的，应用层面的基础设施
多媒体：视频
- 视频：固定速度显示的图像序列
- 网络视频特点：
- 高码率：>10x于音频,高的网络带宽需求
- 可以被压缩
- 90%%以上的网络流量是视频
- 数字化图像：像素的阵列
- 每个像素被若干bits表示
- 编码：使用图像内和图像间的冗余来降低编码的比特数
- 空间冗余（图像内）
- 时间冗余（相邻的图像间）
编码方式：
- CBR：以固定速率编码
- VBR：视频编码速率随时间的变化而变化
多媒体流化服务：DASH
- 服务器：
- 将视频文件分割成多个块
- 每个块独立存储，编码于不同码率（8-10种）
- 告示文件：提供不同块的URL
- 客户端
- 先获取告示文件
- 周期性的测量服务器到客户端的带宽
- 查询告示文件，在一个时刻请求一个块，HTTP头部指定字节范围
- 如果带宽足够，选择最大的码率的视频块
- 会话中的不同时刻，可以切换请求不同的编码块（取决于当时的可用带宽）
- 智能客户端：客户端自适应决定
- 什么时候请求块（不至于缓存挨饿或者溢出）
- 请求什么编码速率的视频块（当带宽足够用时，请求高质量的视频块）
- 哪里去请求块（可以向离自己近的服务器发送URL，或者向高可用带宽的服务器请求）
CDN
- 挑战：服务器如何通过网络向上百万用户同时流化视频内容
- 选择1：单个的、大的超级服务中心"mega-server"
- 服务器到客户端路径上跳数越多，瓶颈链路的带宽小导致停顿
- “二八规律”决定了网络同时充斥着同一个视频的多个拷贝，效率低（付费高、贷款浪费、效果差）
- 单点故障点，性能瓶颈
- 周边网络的拥塞
评述：相当简单，但是这个方法不可拓展
-
选择2：通过CDN，全网部署缓存节点，存储服务内容，就近为用户提供服务，提高用户体验
- enter deep：将CDN服务器深入到许多接入网
- 更接近用户、数量多、离用户近、管理困难
- Akamai，1700个位置
- bring home：部署在少数（10个左右）关键位置，如将服务器蔟安装于POP附近（离若干 1 s t 1^{st} 1stISP POP较近）
- 采用租用线路将服务器蔟连接起来
- Limelight
- enter deep：将CDN服务器深入到许多接入网
-
CDN：在CDN节点中存储内容的多个拷贝
-
用户从CDN种请求内容：
- 重定向到最近的拷贝，请求内容
Netflix的例子:
CDNs
OTT挑战：在拥塞的互联网上复制内容
- 从哪个CDN节点中获取内容
- 用户在网络拥塞时的行为
- 在哪些CDN节点中存储什么内容
CDN：“简单”内容访问场景
- Bob(客户端)请求视频http://netcinema.com/6Y7B23V-
- 视频存储在CDN，位于http://KingCDN.com/NetC6y&B23V
- 下图中的authorative是权威服务器
Netflix案例
