视频服务挑战
- 规模性
- 异构性:不同用户有不同的能力(比如有线接入和移动用户;贷款丰富和受限用户)
- 解决方法是:分布式的应用层面的基础设施CDN
多媒体:视频
- 视频是固定速度显示的一系列图像的序列,图像又是一系列像素点的序列
- 视频占的带宽太大所以不经过压缩就在网络上传输基本是不可能的
- 压缩的基础
- 空间的冗余度:一个帧当中一些范围的像素点颜色一样,空间描述的时候可以说某个像素点在那一范围出现
- 时间上的冗余度:一些相邻的帧的像素点颜色一样,传输的时候仅仅把动的对象传输即可
- CBR (constant bit rate): 以固定速率编码
- VBR (variable bit rate): 视频编码速率随时间的变化而变化
存储视频的流化服务
- Download and play太慢了
- streaming服务边下载边看(就相当于我现在看b站下面有一个进度条还有一个比进度条跑的更快的白条,这个白条就是下载条)
- 多媒体流化服务:DASH(Dynamic Adaptive Streaming over HTTP)
- 服务器:将视频文件分割为多个chunk,每个chunk独立存储,编码于(8-10种)不同码率,告示文件(manifest file)提供不同块的URL(b站视频有很多码率视频)
- 客户端:周期性测量服务器到客户端的带宽,查询告示文件,在一个时刻请求一个块,HTTP头部指定字节范围(如果带宽足够,选择最大码率的视频块;会话中的不同时刻,可以切换请求不同的编码块,这取决于当时的可用带宽);
Content Distrubution Networks(CDN)
- 挑战:承载量
- 如果选择单个的,,大的超级服务器“mega-server”——方法简单但是延展性很差
- 服务器到客户端上路径跳数较多,瓶颈链路的带宽小导致停顿
- “二八规律”决定了网络同时充斥着统一个视频的多个拷贝,效率低(付费高,贷款浪费,效果差)
- 单点故障,性能瓶颈
- 周边网络的拥塞
- 如果选择单个的,,大的超级服务器“mega-server”——方法简单但是延展性很差
- 选项二:通过CDN,全网部署缓存节点,存储服务内容,就近为用户提供服务,提高用户体验
- 也就是说在网络中,CDN的运营商部署了许多缓存节点,用户上线时候不一定从原服务器获取流化服务,通过DNS的重定向,找离他最近服务质量最好的节点提供流化服务。使得问阿金传输跳数少,服务质量更好。
- 种类
- Enter deep:将CDN服务器深入到许多接入网(在Local ISP内部)
- 更接近用户,数量多,离用户近,管理困难
- Akamai:1700个位置
- Bring home: 部署在少数(10个左右)关键位置(比如在ISP关键节点机房附近),如将服务器簇安装于POP附近(离若干大的ISP,POP比较近)
在计算机网络中,POP表示入网点(Point of Presence)。POP位于网络企业的边缘外侧,是访问企业网络内部的进入点。外界提供的服务通过POP进入,这些服务包括Internet接入,广域连接以及电话服务(PSTN) - 采用租用线路将服务器簇链接起来
- Limelight
- 问题:跳数比第一种多
- 互联网络主机到主机之间的通信作为一种服务向用户提供
- OTT挑战:在拥塞的互联网上复制内容
- 从哪个CDN节点中获取内容?
- 用户在网络拥塞时的行为?
- 在哪些CDN节点中存储什么内容?
- Enter deep:将CDN服务器深入到许多接入网(在Local ISP内部)