服务器直连分发的缺点:性能问题,服务器可能离用户很远,内容分发效率低,大量用户同时访问的时候系统也可能瘫痪
zipf定律:80%的访问集中在20%的内容上
启示:两种策略
web cache:在靠近用户网络的地方缓存流行内容,后续请求不用再发到服务器,运营商采用,是被动模式,缺点是存在版权和内容更新的问题,类似于劫持,并且很多类型的内容不能缓存,比如动态数据、依赖参数和cookie的数据、加密数据
cdn:把内容拷贝到不同地域的多台服务器,减轻服务器负载,提升用户QoE,内容提供商采用,是主动模式,cdn分发中没有路由器的参与
负载轻、性能高(处理能力&带宽等)、距离客户端近(物理位置近或RTT小)、成本低(带宽&能耗等)的服务器
两种实现方法:静态&DNS
静态:通过HTTP重定向,来自北京的请求都重定向回北京
DNS:通过DNS来指示相应的cdn服务器
通过DNS迭代/递归查询,返回所选择的cdn服务器
阿斯蒂芬
网络层面:cdn所在网络与其他网络的互联问题、内容传输效率问题
应用层面:内容放置问题(地域)、内容复制到哪些服务器上、存储空间问题
跨网访问:最好避免跨运营商,在各运营商都缓存
放在哪:依赖于内容在地域上的流行度
放什么:zipf定律,怎样预测视频的流行度(可以用早期流行度预测整个生命周期流行度,不需要对每个视频都完整缓存)
存储空间:减小不必要存储,在内容级别,不流行内容不需要存储多份;在内容块级别,只存部分内容块(只存储视频开头的一部分)
分块传输,一个chunk对应几秒的内容,便于切换码率:DASH(基于HTTP的动态自适应流dynamic adaptive stream based on http)
降低码率,还是不行那就要换CDN
点播QoE:高码率、少卡顿、少切换
直播QoE:高码率、少卡顿、少切换、低时延
内容流行度分布不均,大量上行资源浪费,存在大量流行度低的内容,没有必要高码率上传
主播也分为轻度、中度、重度使用
无人观看的直播浪费了很多流量
在观看位置方面,绝大多数情况是跨网传输,对QoE有明显影响,且一次直播的主要观众群体来自少数几个网络位置
自适应上传:优化上传系统,保证QoE同时减少资源浪费,基本原则是通过合理的码率分配实现资源消耗和QoE之间的平衡,解决思路是无人观看期间降低上传码率,未来被观看概率越低的直播码率越低
边缘服务器预取:预取直播最新GoP到相同网络内的边缘服务器,降低启动时延,包括三种预取策略:1 网络中最热门的k个边缘服务器、2 主播历史上最热门的k个边缘服务器、2+未预取则缓存
高光重传:观看人数特别多的片段被毁看的概率也大,解决方法是在实时上传的同时保存高码率版本录像在本地,在低带宽利用率期间上传高码率高光时刻录像
这ppt上实在是一个有用的中国字都没有
是一个覆盖网络
使用泛洪搜索,请求资源的主机向邻居节点发送search请求,邻居节点收到后如果有资源就发给他,如果没有就再进行转发,直到找到有资源的主机。有资源的主机就会把资源发给请求的主机
文件分块传输,一个节点可以从多个节点下载文件快,节点之间直接交换块的信息,块选择策略是邻居中最缺哪块就优先哪块
涉及到的概念有:
neighbors:一个peer连接的所有peers
interest neighbors:有我需要的pieces的neighbors
upload slots:一个peer多个peers同时发送pieces的最大peers数
rarest first:下载neighbors最缺的piece
tit-for-tat策略来保证公平性
一个peer周期性选择四个最高传输速率的interest neighbors,第五个upload slot进行随机发送,有助于新节点的启动和优质邻居节点的发现
包括一个web server(存.torrent文件),一个tracker和若干个peer
请求peer问tracker,tracker告诉请求Peer应该去哪些peers找,请求peer向这些peers发送handshake,peers向请求peer发送数据块
是一种非结构化网络,形成的拓扑没有逻辑结构
给定文件ID,定位保存该ID对应文件的服务器
其他内容同网络路由
拓扑结构方面,节点动态性;overlay(网络上叠加的虚拟化技术)和IP网络的不匹配。解决方法是找临近节点,用界标簇算法产生界标向量,IP网络上相邻的节点拥有相近的界标向量
应用方面,文件定位:哪些节点有我想要的东西;文件的availability:多少个节点有所请求的文件块;激励机制:我为什么要做贡献
直播用P2P效果比较好