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是权威服务器
文章来源:https://www.toymoban.com/news/detail-826800.html
Netflix案例
文章来源地址https://www.toymoban.com/news/detail-826800.html
到了这里,关于计算机网络——14CDN的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!