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^{st}$ISP POP较近）
    • 采用租用线路将服务器蔟连接起来
    • Limelight

• CDN：在CDN节点中存储内容的多个拷贝

• 用户从CDN种请求内容：

  • 重定向到最近的拷贝，请求内容

Netflix的例子:

CDNs

OTT挑战：在拥塞的互联网上复制内容

• 从哪个CDN节点中获取内容
• 用户在网络拥塞时的行为
• 在哪些CDN节点中存储什么内容

CDN：“简单”内容访问场景

• Bob(客户端)请求视频http://netcinema.com/6Y7B23V-
• 视频存储在CDN，位于http://KingCDN.com/NetC6y&B23V
• 下图中的authorative是权威服务器

Netflix案例