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

  • 时间:
  • 浏览:1

成功构建网络就让要是如可做数据下发,朋友将它分为三步:先推、后拉、再补偿,朋友下面逐一做删改介绍。

通过上述的手段朋友就还可否 尽力把包拉取到本地,也还可否 减少对Edge server的依赖,但朋友无法排除要是这个可能,要是的付近邻居都越来越 这个包,越来越 此时朋友就只能向Edge server拉取,朋友在前面有提到锚点的概念,Edge server应该具有大主次可能删改的流媒体信息。

接下来朋友重点讲解这个下发系统的具体细节,首先上图是系统的架构图,大致分为四层:最上层是BGP——用来协调边缘节点与边缘节点之间的下发;第二层是边缘节点,它主要是用来下发媒体数据到观看端;第三层朋友在客户端层面上做了一层超级节点,用来分摊大主次边缘节点的下发压力,这个层的主要目的要是为了节省强度;第四层是普通节点,这主要是可能因此 端可能是4G可能因此 比较差的WiFi,它们可能越来越 上传的能力。越来越 在旁边还有另一一好十几个 小红圈,它表示推流的过程,可能业务中对上麦、连麦有需求,朋友越来越 用连麦系统,要是采用了这个推流加连麦的办法来做,使用的是可靠UDP,也要是RUDP技术。

朋友前面提到整个协议是建立在UDP之上的,而在推送过程中UDP有可能会总出 丢包,这时朋友就须要向邻居拉取,越来越 如可拉取?首先朋友通过gossip协议选着拉取的目标:也要是在单位时间内定时发送本地缓冲区哪些地方地方包,把哪些地方地方包通过gossip协议交换出去,邻居节点之间就会知道因此 节点包的信息,假使 总出 丢包的请况,就还可否 通过gossip信息找到须要去拉取的节点,而拉取节点的选着是通过前面提到的亲和度分值尽量选着近的、通讯友好的节点,而这个拉取过程有可能会是多次的,可能总出 拉取失败,则会在另一一好十几个 RTT周期 就让向因此 节点拉取,它是另一一好十几个 循环的随机过程。

对于连接,穿越是另一一好十几个 非常头疼的现象,而朋友在最初的版本也是基于NAT的办法来做的,但并肩引来另一一好十几个 现象——穿越里只能100%,也要是说有可能在某个防火墙可能NAT底下的节点拥有很好的上传资源,却越来越 得到利用。因此 朋友通过STUN协议做了另一一好十几个 多端口的猜测机制,通过这个机制还可否 将整个穿越率优化到100%。但依旧有一主次无法穿透,这是可能因此 厂商会设置黑名单机制导致 无法穿越,因此 朋友设计了云端协调穿越时机的机制,从而将穿越率优化到要花费90%,也基本达到朋友的预期。

三主次网络

成本

当所有数据删改到了本地,本地会有另一一好十几个 播放缓冲区,包 括WebRTC就让 有JitterBuffer要是的播放缓冲,朋友也设计了另一一好十几个 Buffer,它与前面讲到的三阶段一一对应。

三阶段——拉

越来越 平台不想继续存活,就须要将强度成本降到现在的1/3,也要是只用100G就能防止现象。将产品迁移到CDN上是另一一好十几个 防止办法,毕竟各大云厂商目前的优惠力度还是比较大的,但朋友在前期采用CDN做测试时发现会有另一一好十几个 现象:首先是延迟现象,在因此 因此 分享中就让 提到CDN的延迟要花费是3-5秒,有就让更大,尤其是在大规模直播下;而第好十几个 现象则是每个观看端就让 有上麦的需求,但连麦服务是须要额外付费的,综合计算使用CDN也无法降低成本,甚至还有增加。

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

P2P网络构建

存活的希望

流媒体P2P下发系统

在具体介绍这三主次网络实现办法就让,朋友先来看下流媒体中最重要的一主次——下发切片,也要是数据如可打包可否 符合朋友的要求和场景。最早朋友采用HLS的办法,也要是一秒打另一一好十几个 分片,不过它会引来延迟的现象,从实际的测试中朋友发现会有大于一秒的延迟,但可能分片太小了就又会引入因此 现象。经过测试,朋友最终采用一帧为另一一好十几个 分片,要是还可否 带来另一一好十几个 好处:首先是粒度小,每一帧要花费在几十毫秒,要是朋友还可否 尽量去优化这个延迟;第二点要是实现简单,可能每另一一好十几个 编解码就让 基于帧的编解码,要是火山岩石石的要是另一一好十几个 分片模式;第三点是组织比较灵活,还可否 与播放buffer无缝接合。

接下来朋友具体讲解这个另一一好十几个 网络是如可实现的。首先是推流,推流一般来说会用到RTMP可能说TCP的办法,但它会带来另一一好十几个 现象:在网络不好的请况下,可能每个端都须要上传和上麦的操作,要是会引来延迟现象,朋友测试发现TCP最大的延迟有可能达到1.2秒,这是不可接受的;第好十几个 要是在弱网环境下几瓶传输数据,它会产生TCP连接频繁的断开,这就会造成数据推不上去可能间断性的推上去,从而导致 观看节点频繁卡顿。

完成节点评估后,朋友须要根据评估结果做节点区分,也要是要防止超级节点和普通节点的现象。超级节点最重要的作用要是分摊Edge server的下发压力,并肩还可能承担一主次网络节点管理工作。超级节点的产生办法有这个:这个是自我推荐,这个办法它须要得到Edge server的许可;第二种是Edge server自身的下发压力过于繁重,就会从质量比较好的普通节点中选着因此 比较稳定的成为超级节点。可能网络是动态的,有可能会总出 衰减、分割、断开的请况,因此 超级节点不用说是永久的,当超级节点的网络总出 衰减,评估函数f(x) 会作出反应降级为普通节点,这确实是另一一好十几个 高度动态的循环过程 。

演讲 / 袁荣喜

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

三阶段——补偿

另一一好十几个 直播网站的窘境

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

朋友好,我是来自学渣君的袁荣喜,我演讲的主题是《P2P技术是如可拯救一家直播网站的》,众所周知直播网站最大的成本要是运维成本,当然就让 有一主次主播的成本,而运维成本的主要表现就在于强度,从目前统计来看,另一一好十几个 直播网站的成本要花费有100%来源于强度。

前面提到平台观看人数能达到6万以上,它每天在边缘节点上就须要用83G来扛住边缘节点的下发,可能系统是分布式的,因此 在边缘节点与边缘节点之间也须要做下发,这主次又会须要2G的BGP强度流量,这个强度很大。因此 它须要花费100台物理机来抗,对于私有云搭建的成本我并就让 很了解,可能按照公有云来计算话语,每个月要花费要支付百万以上的成本,这对于另一一好十几个 三线城市的小公司来说压力是巨大的,况且还有比较沉重的业务和寥寥无几的融资渠道。

数据到了Edge server上就让就要把数据快速的传输到因此 Edge server,朋友最初的设计和CDN一样——通过BGP server单线的中转,也要是Edge server将数据传到BGP server,再由BGP server传输到因此 Edge server上,这个做法最大的好指在于实现简单,因此 链路查找现象比较明确。但并肩它也指在另一一好十几个 现象:首先要是成本比较高,可能BGP的成本是整个Edge server边缘节点强度成本 的10倍;第二点可能它是建立在私有云上,而私有云每个机房就让 防火墙,而当网站频繁受到攻击时就让 可能变换防火墙策略,要是就让 可能导致 某条链路不通可能到BGP不通,由此就会影响Edge server无法接收数据包,从而导致 观看节点卡顿。

WebRTCon 2018 8折报名

完成节点之间穿越,就还可否 做P2P通讯了。首真难建立心跳关系和联 跳的请况交换,不过确实从原则上来讲,另一一好十几个 节点跟所有的节点可能跟大主次节点能通讯是好的,但从实际效果来看不用说越来越 ,可能直播时有可能是一千个节点甚至更多节点,而另一一好十几个 节点可能于越来越 多节点 频繁的做心跳可能信息交换,因此 这个的强度就会被这个探测包消耗掉,因此 朋友一般最多会选着40个节点,而这40个节点因此 因此 用说是固定不变的,它会有优胜劣汰的机制,当有节点被淘汰时朋友就会从越来越 穿越的节点中继续穿越,因此 达到另一一好十几个 平衡,越来越 就会形成这个群居效应——好的节点会尽量聚集在并肩。

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

多路径RUDP

节点评估

三阶段——推

第另一一好十几个 是推区间,也要是负责推流区域的缓冲,要花费另一一好十几个 Push的JitterBuffer,这里设置的100ms缓冲主要是为了防止过度拉取,可能推送的流是不规则的,UDP会总出 抖动、丢包、延迟,并肩P2P多路径传输之间这个的现象会引来抖动,这个buffer要是为了防止比较慢进行拉取用的 。第好十几个 是拉区间,在这个区间朋友一般会向邻居拉取三次,这之间的缓冲也要是与邻居之间的好十几个 RTT来回。可能三次没拉到,就会进入补偿区,补偿区就会向服务器拉取4次,可能越来越 拉取到数据则会返回拉区间。

推流

越来越 朋友考虑算不算还可否 通过调整编解码来实现,朋友都知道H.265从编码效果上来说还可否 减掉一半的成本,朋友也在小规模内尝试了替换,不过发现指在CPU消耗的现象,可能观看端的设备比较多样,既有移动端、就让 PC端,因此 设备的性能参差不齐,在较差的机器上会频繁总出 卡顿,根据统计大致有100%的用户无法接受这个方案。

以上是本次的分享,感谢朋友。

朋友假定可能选举好另一一好十几个 超级节点,越来越 边缘节点就会按照上图向下推送媒体数据到超级节点,超级节点再向下推给因此 节点或超级节点,这个推送这个是树型底部形态,而P2P是图形底部形态,因此 朋友引入了预先订阅的机制。举例说明,假设某个节点播装在 去媒体包的第十秒,它就要开始订阅第二十秒到三十秒的包。越来越 订阅是如可完成的呢?超级节点在选着自己身份就让 选着另一一好十几个 区域值,越来越 普通节点就会向所在区域的超级节点订阅(有可能会向多个超级节点订阅),对前面的例子而言,节点有可能会向超级节点A订阅一三五七九秒的包,向B订阅二四六八十秒的包。而超级节点也会做预先订阅,比如对于超级节点A而言,可能它自身负责一三五七九秒的包,越来越 直接向Edge server订阅;相反则须要向负责对应分片 的超级节点做订阅。

越来越 朋友先来看下这家平台的具体请况:它是南方三线城市的直播平台,PC占有率要花费有70%,移动端占有率在100%左右,码流也从320x240,20K升级到640x4100,要花费每秒的单路码流在100kbps左右,也要是100KB/S的样子 。可能它和YY累似 ,都属于聊天室形式的,也要是每另一一好十几个 观看端就让 有上麦的需求,也因此 须要要防止延迟的现象,可能延迟越来越 来很多,在上麦的过程中和下麦的过程涵盖可能会产生信息不对等,由此丢失一主次信息,因此 对于观看端延迟要求在两秒以内,而麦与麦之间的延迟要控制在100毫秒,这就对延迟有非常高的要求。

有了要是的订阅关系,Edge server和超级节点就会根据订阅的记忆信息向下推送。而这个推送路径一般最多达到两层,可能三层的拓扑太长,会引来延迟,并肩路径过长,一旦某另一一好十几个 节点退出,受影响的节点越来越 来很多。

向Edge sever发起补偿的条件一般有这个:第这个是在整个P2P网络中稀缺的包;第二种是迫切须要播放的包。但这底下还指在另一一好十几个 风险,也要是频繁的发起补偿请求确实对Edge server是非常大的冲击,尤其是几瓶指在稀缺块的就让 ,因此 朋友须要限制Edge server单位时间内的补偿请求,但可能有了这个限制可能会导致 因此 节点补偿失败,这时它就会通过前面拉取的过程,通过gossip协议做查找拉取 ,而就让 所有的都向Edge server拉取,这也是为了防止Edge server瞬间被补偿请求打死掉。

在选着了邻居和通讯请况以及探测机制后,朋友就要对整个通讯做评估。评估分为两主次:另一一好十几个 是评价邻居,主要通过丢包率、RTT、通信命中率以及流媒体传输的稳定性计算出另一一好十几个 亲和度分值;第二要是评估自己,主要通过CPU、强度复用、网络类型等计算出另一一好十几个 load(负载)值,通过它朋友就能知道本地节点跟因此 节点要花费指在哪些地方位置,朋友就能进行网络策略调节、通讯的QOS、节点区分以及网络收敛。朋友早期的网络收敛是通过对照表的办法实现的——也要是经验值,但在网络高度动态时,会总出 网络波动以及与邻居之间的通讯失效,因此 朋友采用另一一好十几个 简单的神经网络和另一一好十几个 收敛函数f(x) 来做参数的调整决策。

我的另一一好十几个 朋友是做直播平台的,每天要花费有6万人观看,在经历了2016年的千播大战就让,朋友升级了观看体验——主要是提高了分辨率和清晰度,但成本也因此 提高到了要是的5倍,也要是假使 要是是20G,现在每天要付出100G的强度流量,这对于另一一好十几个 普通的平台来说成本是致命的。

P2P下发媒体数据

P2P连接

基本请况

网络架构

单路径RUDP

最终效果

节点分层

下图是Edge server的对比数据,朋友在Edge server上做了另一一好十几个 开关——将它等分为开启P2P下发和不开启P2P下发,对同另一一好十几个 Edge sever以一天为单位下发数据:每5分钟下发一次当时每秒出去的强度,图中红色的线表示越来越 开启P2P,也要是删改使用Edge server来中转,淡蓝色的线表示开启P2P。图中朋友还可否 看得人在高峰期,开启P2P从Edge server输出的流量要花费只能100mb/s ,而未开启P2P的则是达到了将近4100mb/s ,也要是在 Edge server上还可否 节省到要是的1/4。

经过要是的循环过程最终包被播放,对于可能播放的包算不算要删除呢?朋友知道P2P是对等系统,可能别人缺少你可能播放的包,向你拉取,但你播放开始后就直接删除了,这就导致 越来越 命中,这个现象肯定就让 朋友希望看得人的,因此 朋友将可能播放的分片装在 去缓冲区中保留3秒,尽量使得拉取请求命中。以上要是整个下发过程。 

整个网络分为三主次:另一一好十几个 是推流主次,要是朋友要保证流是要推到边缘节点上;第二是边缘节点与边缘节点要做另一一好十几个 可靠、快速的下发,让所有数据尽量快到达Edge server,要是保证延迟比较小;第三主次是P2P,当数据到达Edge server上,朋友要快速通过P2P网络下发到各个观看端进行播放。在这个系统涵盖个锚点,要是所有Edge sever都应该尽快拿到所有的视频数据和音频数据。

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

下发 / LiveVideoStack

三阶段播放buffer

UDP还可否 很好的防止延迟和连接的现象,但可能它的不可靠,会产生丢包现象,因此 朋友借助了WebRTC的GCC 原理,在UDP之上设计了一层可靠,保证数据还可否 尽快、尽好的传到Edge server上。上图是它的原理,它通过一系列并发的发包,最后再通过确认机制来回馈要重传的包可能说哪些地方就让重传包。

由此朋友在RUDP之上设计了另一一好十几个 多链路的传输(如上图):首先Edge server之间是直连的,并肩有多个BGP server来做relay ,底下是无请况的,也要是即使某每根链路总出 现象,因此 十几个 链路还在并行传数据,要是就能保证尽量的可靠和可用。其次为了节省成本这里还有另一一好十几个 设计原则,Edge server之间尽量保证直连,不走BGP可能几瓶走BGP,要是就还可否 节省一大主次BGP流量,根据统计还可否 节省100%的成本。

要在P2P网络上做数据下发,就要构建另一一好十几个 鲁棒性的P2P网络——也要是动态可靠的P2P网络,构建要是另一一好十几个 网络须要分为三步:首先是连接——客户端之间要相互建立连接;第二是节点之间的评估;第三是节点分层。