P2P技术如何拯救一家直播网站

  • 时间:
  • 浏览:0
  • 来源:神彩大发快3_彩神大发快3官方

分派 / LiveVideoStack

P2P连接

存活的希望

整个网络分为三偏离 :四个多是推流偏离 ,或者我有人要保证流是要推到边缘节点上;第二是边缘节点与边缘节点要做四个多可靠、快速的分派,让所有数据尽量快到达Edge server,从前保证延迟比较小;第三偏离 是P2P,当数据到达Edge server上,有人要快速通过P2P网络分派到各个观看端进行播放。在其他系统带有个锚点,或者我所有Edge sever都应该尽快拿到所有的视频数据和音频数据。

四个多直播网站的窘境

我的四个多有人是做直播平台的,每天至少有20万人观看,在经历了2016年的千播大战以前,有人升级了观看体验——主或者我提高了分辨率和清晰度,但成本也或者我提高到了从前的5倍,也或者我或者我我从前是20G,现在每天要付出5000G的效率流量,这对于四个多普通的平台来说成本是致命的。

节点评估

推流

第四个多是推区间,也或者我负责推流区域的缓冲,至少四个多Push的JitterBuffer,这里设置的500ms缓冲主或者我为了避免过度拉取,机会推送的流是不规则的,UDP会跳出抖动、丢包、延迟,同時 P2P多路径传输之间并算不算的大间题会引来抖动,其他buffer或者我为了避免好快进行拉取用的 。第五个是拉区间,在其他区间有人一般会向邻居拉取三次,这之间的缓冲也或者我与邻居之间的五个RTT来回。机会三次没拉到,就会进入补偿区,补偿区就会向服务器拉取4次,机会这样拉取到数据则会返回拉区间。

单路径RUDP

经过算法的升级,有人最终实现了从前的效果:边缘节点效率大致降到24G;BGP机会采用了多链路保障和直链的最好的办法,至少降到从前的1/3-1/4的比例;机会效率的降低,对物理服务器的依赖也就自然减少,目前服务器降到41台左右。这里值得一提的是,通过测试有人所有的端延迟至少在1秒左右,最大延迟在2秒左右,连麦延迟在500~5000毫秒之间 ,与从前的情况汇报相比,在保留固有功能和连麦系统等服务没受到影响的情况汇报下,有人节省了至少1/3的效率,基本达到了有人最初的要求,同時 有人也还在不断优化其他网络模型,也欢迎感兴趣的小伙伴与我探讨。

三阶段——推

前面提到平台观看人数能达到20万以上,它每天在边缘节点上就前要用83G来扛住边缘节点的分派,机会系统是分布式的,或者我在边缘节点与边缘节点之间也前要做分派,这偏离 又会前要2G的BGP效率流量,其他效率很大。或者我它需至少5000台物理机来抗,对于私有云搭建的成本我不言而喻是很了解,机会按照公有云来计算语句,每个月至少要支付百万以上的成本,这对于四个多三线城市的小公司来说压力是巨大的,况且还有比较沉重的业务和寥寥无几的融资渠道。

有人前面提到整个协议是建立在UDP之上的,而在推送过程中UDP有机会会跳出丢包,这时有人就前要向邻居拉取,这样要怎样拉取?首先有人通过gossip协议选者拉取的目标:也或者我在单位时间内定时发送本地缓冲区有其他包,把其他包通过gossip协议交换出去,邻居节点之间就会知道其他节点包的信息,或者我我跳出丢包的情况汇报,就可不可否通过gossip信息找到前要去拉取的节点,而拉取节点的选者是通过前面提到的亲和度分值尽量选者近的、通讯友好的节点,而其他拉取过程有机会会是多次的,机会跳出拉取失败,则会在四个多RTT周期 以前向其他节点拉取,它是四个多循环的随机过程。

接下来有人重点讲解其他分派系统的具体细节,首先上图是系统的架构图,大致分为四层:最上层是BGP——用来协调边缘节点与边缘节点之间的分派;第二层是边缘节点,它主或者我用来分派媒体数据到观看端;第三层有人在客户端层面上做了一层超级节点,用来分摊大偏离 边缘节点的分派压力,其他层的主要目的或者我为了节省效率;第四层是普通节点,这主或者我机会其他端机会是4G机会其他比较差的WiFi,它们机会这样上传的能力。这样在旁边还四个多多小红圈,它表示推流的过程,机会业务中对上麦、连麦有需求,有人这样用连麦系统,或者我采用了并算不算推流加连麦的最好的办法来做,使用的是可靠UDP,也或者我RUDP技术。

成本

WebRTC绿帘石不具备服务端能力,要怎样实现高性能、稳定的服务端能力成为绕不过语句题。有人太多怎样开设了“WebRTC服务端开发”专题,并邀请本文分享者袁荣喜担任出品人,同時 与网易云、苏宁文创、触宝电话等技术大咖分享接入网关服务、协议适配、服务稳定性和行业应用。

以上是本次的分享,感谢有人。

流媒体P2P分派系统

这样平台你会 继续存活,就前要将效率成本降到现在的1/3,也或者我只用500G就能避免大间题。将产品迁移到CDN上是四个多避免最好的办法,毕竟各大云厂商目前的优惠力度还是比较大的,但有人在前期采用CDN做测试时发现会四个多多大间题:首先是延迟大间题,在什么都分享中算不算提到CDN的延迟至少是3-5秒,有以前更大,尤其是在大规模直播下;而第五个大间题则是每个观看端完会有上麦的需求,但连麦服务是前要额外付费的,综合计算使用CDN也无法降低成本,甚至还有增加。

演讲 / 袁荣喜

当所有数据详细到了本地,本地会四个多多播放缓冲区,包 括WebRTC完会有JitterBuffer从前的播放缓冲,有人也设计了四个多Buffer,它与前面讲到的三阶段一一对应。

由此有人在RUDP之上设计了四个多多链路的传输(如上图):首先Edge server之间是直连的,同時 有多个BGP server来做relay ,上面是无情况汇报的,也或者我即使某十根链路跳出大间题,其他有好多个链路还在并行传数据,从前就能保证尽量的可靠和可用。其次为了节省成本这里还四个多多设计原则,Edge server之间尽量保证直连,不走BGP机会一定量走BGP,从前就可不可否节省一大偏离 BGP流量,根据统计可不可否节省500%的成本。

要在P2P网络上做数据分派,就要构建四个多鲁棒性的P2P网络——也或者我动态可靠的P2P网络,构建从前四个多网络前要分为三步:首先是连接——客户端之间要相互建立连接;第二是节点之间的评估;第三是节点分层。

最终效果

有人假定机会选举好四个多超级节点,这样边缘节点就会按照上图向下推送媒体数据到超级节点,超级节点再向下推给其他节点或超级节点,其他推送并算不算不算树型形态,而P2P是图形形态,或者我有人引入了预先订阅的机制。举例说明,假设某个节点播倒入媒体包的第十秒,它就要开使英文订阅第二十秒到三十秒的包。这样订阅是要怎样完成的呢?超级节点在选者买车人身份完会选者四个多区域值,这样普通节点就会向所在区域的超级节点订阅(有机会会向多个超级节点订阅),对前面的例子而言,节点有机会会向超级节点A订阅一三五七九秒的包,向B订阅二四六八十秒的包。而超级节点也会做预先订阅,比如对于超级节点A而言,机会它自身负责一三五七九秒的包,这样直接向Edge server订阅;相反则前要向负责对应分片 的超级节点做订阅。

对于连接,穿越是四个多非常头疼的大间题,而有人在最初的版本也是基于NAT的最好的办法来做的,但同時 引来四个多大间题——穿越里都可不可否500%,也或者我说有机会在某个防火墙机会NAT上面的节点拥有很好的上传资源,却这样得到利用。或者我有人通过STUN协议做了四个多多端口的猜测机制,通过其他机制可不可否将整个穿越率优化到500%。但依旧有一偏离 无法穿透,这是机会其他厂商会设置黑名单机制是因为 无法穿越,或者我有人设计了云端协调穿越时机的机制,从而将穿越率优化到至少90%,也基本达到有人的预期。

WebRTCon 2018 8折报名

完成节点之间穿越,就可不可否做P2P通讯了。首先要建立心跳关系和益跳的情况汇报交换,不过实在从原则上来讲,四个多节点跟所有的节点机会跟大偏离 节点能通讯是好的,但从实际效果来看不言而喻这样,机会直播时有机会是一千个节点甚至更多节点,而四个多节点不机会于这样多节点 频繁的做心跳机会信息交换,或者我并算不算的效率就会被其他探测包消耗掉,或者我有人一般最多会选者40个节点,而这40个节点什么都言而喻是固定不变的,它会有优胜劣汰的机制,当有节点被淘汰时有人就会从这样穿越的节点中继续穿越,或者我达到四个多平衡,这样就会形成并算不算群居效应——好的节点会尽量聚集在同時 。

节点分层

三阶段播放buffer

完成节点评估后,有人前要根据评估结果做节点区分,也或者我要避免超级节点和普通节点的大间题。超级节点最重要的作用或者我分摊Edge server的分派压力,同時 还机会承担一偏离 网络节点管理工作。超级节点的产生最好的办法有并算不算:并算不算不算自我推荐,其他最好的办法它前要得到Edge server的许可;第二种是Edge server自身的分派压力过于繁重,就会从质量比较好的普通节点中选者其他比较稳定的成为超级节点。机会网络是动态的,有机会会跳出衰减、分割、断开的情况汇报,或者我超级节点不言而喻是永久的,当超级节点的网络跳出衰减,评估函数f(x) 会作出反应降级为普通节点,这实在是四个多层厚动态的循环过程 。

成功构建网络以前或者我要怎样做数据分派,有人将它分为三步:先推、后拉、再补偿,有人下面逐一做详细介绍。

P2P网络构建

三阶段——拉

经过从前的循环过程最终包被播放,对于机会播放的包算不算要删除呢?有人知道P2P是对等系统,机会别人缺少你机会播放的包,向你拉取,但你播放开使英文后就直接删除了,这就是因为 这样命中,其他大间题肯定与算不算人希望都看的,或者我有人将机会播放的分片倒入缓冲区中保留3秒,尽量使得拉取请求命中。以上或者我整个分派过程。 

网络架构

基本情况汇报

在具体介绍这三偏离 网络实现最好的办法以前,有人先来看下流媒体中最重要的一偏离 ——分派切片,也或者我数据要怎样打包都可不可否符合有人的要求和场景。最早有人采用HLS的最好的办法,也或者我一秒打四个多分片,不过它会引来延迟的大间题,从实际的测试中有人发现会有大于一秒的延迟,但机会分片太小了就又会引入其他大间题。经过测试,有人最终采用一帧为四个多分片,从前可不可否带来四个多好处:首先是粒度小,每一帧至少在几十毫秒,从前有人可不可否尽量去优化其他延迟;第二点或者我实现简单,机会每四个多编解码算不算基于帧的编解码,从前绿帘石的或者我四个多分片模式;第三点是组织比较灵活,可不可否与播放buffer无缝接合。

这样有人先来看下这家平台的情况汇报汇报:它是南方三线城市的直播平台,PC占有率至少有70%,移动端占有率在500%左右,码流也从320x240,20K升级到640x4500,至少每秒的单路码流在5000kbps左右,也或者我5000KB/S的样子 。机会它和YY例如,都属于聊天室形式的,也或者我每四个多观看端完会有上麦的需求,也或者我前要要避免延迟的大间题,机会延迟太多,在上麦的过程中和下麦的过程带有机会会产生信息不对等,由此丢失一偏离 信息,或者我对于观看端延迟要求在两秒以内,而麦与麦之间的延迟要控制在5000毫秒,这就对延迟有非常高的要求。

UDP可不可否很好的避免延迟和连接的大间题,但机会它的不可靠,会产生丢包大间题,或者我有人借助了WebRTC的GCC 原理,在UDP之上设计了一层可靠,保证数据可不可否尽快、尽好的传到Edge server上。上图是它的原理,它通过一系列并发的发包,最后再通过确认机制来回馈要重传的包机会说其他以前重传包。

下图是Edge server的对比数据,有人在Edge server上做了四个多开关——将它等分为开启P2P分派和不开启P2P分派,对同四个多Edge sever以一天为单位分派数据:每5分钟分派一次当时每秒出去的效率,图中红色的线表示这样开启P2P,也或者我详细使用Edge server来中转,浅紫色的线表示开启P2P。图中有人可不可否都看在高峰期,开启P2P从Edge server输出的流量至少都可不可否5000mb/s ,而未开启P2P的则是达到了将近4500mb/s ,也或者我在 Edge server上可不可否节省到从前的1/4。

这样既然是传输产生的高成本,算不算可不可否对传输最好的办法做优化——P2P技术,它早期源于音频分享和文件分享,或者我是下一代CDN的主流技术。在做从前四个多系统以前首先前要调研目前用户端上传的最大效率,有人发现有500%以上用户的上传效率在1.6mbs以上,平均来看至少可不可否做到640KB/S 码率的上传程度。前期调查后,有人确立了系统设计的四个多目标:降成本、控延迟和保质量,也或者我在保证用户体验下将成本降低1/3,在后期的小规模测试和大规模替换中的效果还是比较满意的。

接下来有人具体讲解其他个多网络是要怎样实现的。首先是推流,推流一般来说会用到RTMP机会说TCP的最好的办法,但它会带来四个多大间题:在网络不好的情况汇报下,机会每个端都前要上传和上麦的操作,从完会引来延迟大间题,有人测试发现TCP最大的延迟有机会达到1.2秒,这是不可接受的;第五个或者我在弱网环境下一定量传输数据,它会产生TCP连接频繁的断开,这就会造成数据推不上去机会间断性的推上去,从而是因为 观看节点频繁卡顿。

向Edge sever发起补偿的条件一般有并算不算:第并算不算不算在整个P2P网络中稀缺的包;第二种是迫切前要播放的包。但这上面还处在四个多风险,也或者我频繁的发起补偿请求实在对Edge server是非常大的冲击,尤其是一定量处在稀缺块的以前 ,或者我有人前要限制Edge server单位时间内的补偿请求,但机会有了其他限制机会会是因为 其他节点补偿失败,这时它就会通过前面拉取的过程,通过gossip协议做查找拉取 ,而算不算所有的都向Edge server拉取,这也是为了避免Edge server瞬间被补偿请求打死掉。

有了从前的订阅关系,Edge server和超级节点就会根据订阅的记忆信息向下推送。而其他推送路径一般最多达到两层,机会三层的拓扑太长,会引来延迟,同時 路径过长,一旦某四个多节点退出,受影响的节点太多。

通过上述的手段有人就可不可否尽力把包拉取到本地,也可不可否减少对Edge server的依赖,但有人无法排除从前并算不算机会性,或者我我的附进邻居都这样其他包,这样此时有人就都可不可否向Edge server拉取,有人在前面有提到锚点的概念,Edge server应该具有大偏离 机会详细的流媒体信息。

P2P分派媒体数据

数据到了Edge server上以前就要把数据快速的传输到其他Edge server,有人最初的设计和CDN一样——通过BGP server单线的中转,也或者我Edge server将数据传到BGP server,再由BGP server传输到其他Edge server上,其他做法最大的好处在于实现简单,或者我链路查找大间题比较明确。但同時 它也处在四个多大间题:首先或者我成本比较高,机会BGP的成本是整个Edge server边缘节点效率成本 的10倍;第二点机会它是建立在私有云上,而私有云每个机房算不算防火墙,而当网站频繁受到攻击时算不算机会变换防火墙策略,从前算不算机会是因为 某条链路不通机会到BGP不通,由此就会影响Edge server无法接收数据包,从而是因为 观看节点卡顿。

三阶段——补偿

众所周知运维成本是直播网站最大的成本组成,运维成本则主要体现在效率,而伴随主播与用户对视频清晰度以及连麦的需求不断提升,直播效率也在与日俱增。本文分派协会渣逆袭逆袭君音视频技术负责人袁荣喜在LiveVideoStackCon 2017上的分享,通过实践案例讲解了要怎样使用P2P技术将效率和延迟降低到传统技术的1/3,并详细介绍了P2P分派算法的分派和技术实现细节。

这样有人考虑算不算可不可否通过调整编解码来实现,有人都知道H.265从编码效果上来说可不可否减掉一半的成本,有人也在小规模内尝试了替换,不过发现处在CPU消耗的大间题,机会观看端的设备比较多样,既有移动端、算不算PC端,或者我设备的性能参差不齐,在较差的机器上会频繁跳出卡顿,根据统计大致有500%的用户无法接受其他方案。

有人好,我是来协会渣逆袭逆袭君的袁荣喜,我演讲的主题是《P2P技术是要怎样拯救一家直播网站的》,众所周知直播网站最大的成本或者我运维成本,当然完会有一偏离 主播的成本,而运维成本的主要表现就在于效率,从目前统计来看,四个多直播网站的成本至少有500%来源于效率。

机会你拥有音视频领域独当一面的能力,欢迎申请成为讲师,分享你的实践和洞察,请联系 speaker@livevideostack.com。更多详情扫描下图二维码或点击阅读原文

三偏离 网络

在选者了邻居和通讯情况汇报以及探测机制后,有人就要对整个通讯做评估。评估分为两偏离 :四个多是评价邻居,主要通过丢包率、RTT、通信命中率以及流媒体传输的稳定性计算出四个多亲和度分值;第二或者我评估买车人,主要通过CPU、效率复用、网络类型等计算出四个多load(负载)值,通过它有人就能知道本地节点跟其他节点至少处在其他位置,有人就能进行网络策略调节、通讯的QOS、节点区分以及网络收敛。有人早期的网络收敛是通过对照表的最好的办法实现的——也或者我经验值,但在网络层厚动态时,会跳出网络波动以及与邻居之间的通讯失效,或者我有人采用四个多简单的神经网络和四个多收敛函数f(x) 来做参数的调整决策。

多路径RUDP