当前位置:   article > 正文

计算机网络——14CDN

计算机网络——14CDN

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
  • CDN:在CDN节点中存储内容的多个拷贝

  • 用户从CDN种请求内容:

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

Netflix的例子:
在这里插入图片描述

CDNs

在这里插入图片描述

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

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

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

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

在这里插入图片描述

Netflix案例

在这里插入图片描述

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/我家小花儿/article/detail/112404
推荐阅读
  

闽ICP备14008679号