P2P如何将视频直播带宽降低75%

1、P2P技术如何将直播带宽降低75%?实时直播经过去年的千播大战后已经成为互联网应用的标配技术，但直播平台的成本却一 直居高不下，各个平台除了挖主播、挖网红以外，其背后高额的带宽费用也是他们最大的 一块成本。现阶段直播技术在传输方面分为两块：CDN和连麦系统，CDN负责流媒体的分发 传输，连麦系统负责解决同时多个主播间互动的实时通信传输问题。我们始终认为基于CD N+连麦系统的直播技术是一个高成本高消耗的技术，从各大直播平台纷纷亏损就验证了这 一点。除了带宽成本，延迟问题也是现在直播技术一个硬伤。我们很早就意识到现在传统 的直播技术是无法大规模进行在线教育互动直播，所以学霸君从2016年下半年就

2、开始研发 基于UDP和P2P技术的互动直播技术架构。整个系统的设计目标是：.端到端延迟控制在秒级范围之内。.在不影响视频质量的情况下尽力节省分发带宽。整个基于P2P技术的分发架构在一个10W+直播平台上进行了 9个月的测试和调优，初步达 成了设计目标。那整个系统是怎么设计的？使用了那些技术来达成目标的？那接下来重点 来说一说架构设计和技术细节。.P2P分发网络架构整个传输分发网络我们把连麦系统和分发系统合二为一，将分布式推流与边缘节点分发作 为一套传输体系，通过服务之间的P2P通信和路由选择来实现连麦的最小时延，架构如下 图：relaynodenodenOdenodenodenodesuper

3、Lnode superLnodleiuper node,relaynodenodenOdenodenodenodesuperLnode superLnodleiuper node,叵 UpePinode服W间p2P分发 推流BGP s e rve rEdge | server 图1整个传输分发网络分为三部分：推流部分、服务之间P2P和客户节点P2P。这个传输网络 有一个系统锚点：假定推流者speaker推到Edge server上是不会发生丢包和延迟的，Ed ge server会通过服务间P2P快速将收到的流数据分发到其他的Edge server,而且在这个 过程也不会发生延迟和丢包。为什么需

4、要这样一个锚点？因为在客户节点的P2P网络需要 保证流畅性和最小延迟，也就是要求所有的Edge server在最短时间周期内拥有的完整的 数据，至于为什么要这样，后面我们在流补偿环节重点介绍。我将通过整个流数据传输过程来解析具体的技术细节，但在这之前首先要解决的就是媒体 数据分片问题，所有的传输过程会基于分片(segment)来设计。媒体数据分片媒体数据分片是整个分发传输体系中最为基础的部分，我们在设计分片时主要考虑的是时 延和消耗的问题，分片如果太大，传输的时延就会越高，例如：HLS。如果分片太细，网络 中回馈报文就会很多，对P2P网络来说额外的消耗也是个问题。最后我们借鉴了 RTP和FL

5、V中的经验，采用按帧来做数据分片，这样做有以下几个好处：按帧分片延迟粒度小，可以在帧传输进行延时优化 实现简单，与编解码器编码原则一致组合灵活，可以实现播放buffer无缝结合。每一个分片称作为segment,用一个自增长的32位ID来表示唯一性，传输过程都是以这个 ID为标示来确定数据的完整性。推流与连麦确定好了媒体分片就可以进行推流了，我们把推流和分发的路径合二为一，上麦者是将流 数据segment推送到离自己最近的Edge server上，而不是推送到专门的连麦系统上。我 们推流传输使用的是RUDP传输算法，这个RUDP是采用了类似BBR基于延迟和丢包来设计 的拥塞算法，并且对报文做了拥

6、塞丢弃，示意图如下：rudp senderrudp receiver关于RUDP的细节可以参考我的另一篇文章UDP是怎么实现可靠的。至于为什么不采用 RTP或者RTMP/TCP来推流，RTP虽然是基于UDP的，但需要通过RTCP和NACK来保证可靠 性，需要设计拥塞算法，也需要对RTP进行改造扩展，而且还受RTP协议本身的限制，所 以我们并没有直接采用RTP。对于RTMP/TCP设计是很简单，但在弱网环境延迟很大，而且 容易引起重连，所以在设计之初就否定了。2.3server 间的 P2P 因为整个传输分发网络是分布式的，由多个edge server组成，而且其他的连麦者可能在 其他的edge

7、 server上。所以基于系统锚点，媒体数据分片到edge server上必须尽快的 分发到其他的edge server上。最早我们采用的是统一用BGP server来中转，这样的耗费 的BGP带宽很多，而且BGP server 一旦异常，整个edge server之间的通信就中断了。其 实大部分时间跨运营商之间的edge server之间延迟也没有想象的那么大，这可以考虑使 用Edge server之间点对点通信来解决问题，所以我们设计了一个基于RUDP无窗口多路径 的传输模型来进行edge server之间的通信，如下图：上图的通信模型是一个多路径并联通信模型，我们在RUDP发送前添加了一

8、个路径路由表， 这个路由表记录了各个路径的分发概率，RUDP每次向接收端发送包时会通过路由表中的概 率来选取路径，那么确定路由表概率就是一个非常重要的事情。我们是通过RUDP实时的A CK反馈和路径实时ping探测来得到网络的状态（丢包，延迟，抖动），再将网络状态参数 输入到逼近函数来确定各条路由的概率，这里有条原则：如果edge server之间直连的延 迟和丢包足够小的情况下，直连通信路由的概率将会接近100%，如果某一条路由出现周期 性断开或者延迟超过200ms，它的概率会接近0。以下是整个路由概率评估的过程示意图:.P2P网络构建过程媒体流数据通过edgeserver间的P2P多路径传

9、输网络到达各个edge server上，接下每个 edge server需要将流数据分片下发到各个客户节点上，我们针对了上麦节点做了传输特 殊处理让时延更小，过程和普通的RTC通信模型相似，这里就不赘述了。观看节点上分发 采用的自组织P2P网络进行数据分发的，既然是通过P2P下发的，那么就要在客户节点群 构建一个P2P网络，这个网络是怎么构建的？具体分为三步：连接、评估、分层。连接客户节点程序是运行在客户机上的，大部分客户节点都会在路由器或者NAT后面，他们之 间要相互建立连接，必须穿越彼此的NAT和防火墙。虽然现在穿越NAT的方法，例如：STU N、ICE等。但穿越连通率始终是一个问题，如果

10、穿越率太低，会让很多优质的节点资源得 不到充分利用。在设计穿越方案时直连连通率放在第一位，我们通过修改STUN协议设计了 一种基于端口多次猜测和尝试的穿越机制，先会通过类似STUN协议判断NAT类型、NAT端 口变化规律、NAT是否有黑名单机制等信息，然后将这些信息存到辖区连接中的edge serv er中。当有伙伴节点来与它穿越，会交换彼此的这些信息，不同的排列组合会有不同的穿 越策略，每一次穿越的过程和结果都会记录到我们的后台数据库，我们会周期将这些数据 进行分析并调整协商穿越策略。如下图：stun protoC多次猾口君逑多谑者stun protoC多次猾口君逑多谑者图5穿越完成后，节点

11、之间就会进行连接握手和身份证书（关于为什么要证书后面细讲），建 立通信联系和邻居关系。那么邻居关系是怎么动态变化的呢？邻居关系与评估邻居问题 连接一旦完成，节点与节点之间就成为邻居，彼此会进行状态交换和心跳，那么问题来了， 一个直播系统有成千上万的节点参与，如果都两两相连的话光心跳通信就可以将客户节点 的上传带宽占满。我们基于这个原则设计了一个节点LRU淘汰链表，链表中保持40个联系 的邻居节点。但老的节点会退出，新的节点会加入，LRU会根据邻居与自己的通信状态来 进行LRU新增和淘汰，原则如下：就近原则，内网优先，同城同一营商网络次之。周期性评测延迟和媒体分片命中率，末位劣汰。当LRU列表中

12、节点不足40个时会从备用节点列表中选取进行新的节点进行连接并加 入到LRU中。节点评估 每个客户节点的计算能力、通信能力、网络分区等都不一样，这使得我们必须对每个节点 做一个评价，对一个节点的评价分为两部分：邻居节点对自己的评价和自己对自己的评估。 邻居评价主要是： RTT丢包率请求命中率通过这三个参数会对每个邻居计算出一个亲和力分值score，这个值会用于后面的分发选 择。评估自己主要是：CPU、内存网络类型/讦1/46/有线网络上传带见节点会周期性计算这两类参数，通过一个网络QOS收敛函数来计算节点能力和对邻居QOS 策略。节点分层节点评估最终的目的是让有能力的节点成为超级节点(super

13、 node)来分担edge server 的分发压力。那么一个节点成为超级节点的条件是什么呢？有以下几个条件：有足够的上传带宽，4G和弱WIFI下不能成为超级节点有空闲的CPU和内存，计算能力不够的低端移动设备不能成为超级节点对邻居通信友好，不是通信孤岛得到edge server的任命，和edgeserver之间通信顺畅。超级节点如果性能衰减了怎么办？答案是会退化成普通节点，因为节点评估是周期性实时 进行的，如果发现节点性能衰减，edge server会让其退化。既然任命了超级节点，那么超级节点是怎么工作的？每一个超级节点在被任命时都会分配 到一个分组ID，edge server会根据自己辖区

14、超级节点数量进行分组，每个分组有多个超 级节点组成，分组内的超级节点群负担自己分组的媒体分片分发。例如：有5个超级节点 分组，这时单位周期内有120个segment，那么第一个分组负责1、6、11、16编号的s egment分发，以此类推第二组负责2、7、12、17。这样做是防止单个超级节点失效造 成网络，增强P2P分发的稳定性。示意图如下：.P2P流媒体分发过程 通过上面的P2P网络构建过程我们知道整个P2P网络其实是一个分层有向图分发网络，那 么具体是怎么进行流数据分发的呢？也分三步：先推(push)、后拉(pull)、再补偿，下面 来仔细解释是怎么实现的。4.1push 在介绍超级节点时

15、有提到会根据segment ID将数据推到对应的超级节点分组群上，超级节 点收到这些segment后怎么要怎么处理呢？按照P2P设计的原理应该将数据转发到其他分 组的超级节点或者普通节点上，但是如果都这样推有可能会造成网络发送冗余而消耗过多 的带宽。为了解决这个问题设计了一个预先订阅机制，原理就是每个P2P客户节点会根据 自己缓冲区最大的segment ID来进行预订，提前预订10秒以后的媒体数据分片，预订请 求是根据节点评估出来的亲和力值score来做权衡随机请求，收到这些请求的超级节点会 将预订的分片请求信息保存下，等到edge server推送到这个分片到这个超级节点，它就 会无条件转发

16、这些被预订的报文给发起预订的节点，如下图所示：从edge server到所有节点路径最多两层，这样做是为了控制链路延迟不同分组supernode之间会相互订阅对应分组的segment普通node只会向super node发起订阅4.2pull数据segment通过预先点阅的方式进行push推送到各个客户节点，但网络是会丢包，supe r node也有可能会中途退出，这样就会造成最终的节点发生丢包，那丢包了我们怎么办？ 我们设计一个向邻居拉取缺失分片的机制，大致的流程如下：.节点周期性检查丢失分片的信息和收到分片的信息，构建一个gossip协议向邻居交换 缓冲区信息.节点收到邻居的gossip信

17、息，将对方拥有的分片信息记录到本地.本地根据记录邻居的分片信息查找自己丢失的分片，通过邻居亲和力值score进行权 衡随机选取邻居，并向选取的邻居发起pull请求.收到邻居拉取分片请求，将分片发往请求的节点。整个步骤会周期性尝试多次拉取，示意图如下：nodenodenode /yPull nodenodenode /yPull segment - 1puli= 5pull SGgntesit = 6oss s-egmejits. = 1? 57 6)图8这里值得一说的是因为会周期性交换缓冲区的gossip信息，这意味着缓冲区的gossip 信息越小越好，我们设计了一个类似bloom filte

18、r来描述gossip信息，不仅可以减小go ssip报文的数据大小，而且比对速度也很快。补偿因为P2P的客户节点是不稳定的，有可能某个segment通过拉取多次还是没有收到，这 个segment又临近播放位置，那么缺失这个segment的节点会直接向edge server请求补 偿让其尽快传送这个分片，这样做的目的是防止因为P2P通信造成丢包的卡顿。这也就是 说每个edge server需要拥有所有分片数据，也是系统锚点。流程入下图：superget segment = 2 gat segment = 3loss segment superget segment = 2 gat segment

19、 = 3loss segment = 3这个流程大部分情况下没有问题，但如果同一时刻大部分客户节点都缺失某几个segment 分片时，会有大量的补偿请求到edge server上会造成网络风暴。我们在应对这个问题设 计了个稀缺评估和拒绝服务的机制。这个机制当单位时间内太多个补偿请求到达edge ser ver会拒绝自己能承受之外的请求，只重发承受范围之内的分片。而且这个过程还会对补 偿请求做稀缺评估，如果某个分片大部分节点都没有，它会主动将这个分片通过super no de群再推送一次。缓冲buffer与时延控制 通过上面的三个阶段可以将所有数据segment分发到每个客户节点上，但客户节点需

20、要一个缓冲buffer来配合这个三个阶段和本地的播放，buffer如果缓冲时间过长，会引起不必要的延迟，如果过短会造成卡顿和三个阶段不完整。为此我们设计了一个三阶段buffer动态缓冲区,入下图所示：evictplaygetpull3000msj1 0RTT)13 kRTT.10i过期区间补盆区间pull区间时间轴图10来解释下上图的各个区间的意思：Push区间：因为分片是通过不同的supernode推送过来的，那么必然会造成一定的抖动， 所以在buffer最开始的头上会有一个jitter缓冲阶段，直到第一个邻居节点gossip信息 中有这个分片push位置结束，这个阶段一般100300ms。

21、Pull区间：分片时序进入pull区间后，会周期性检查丢失的分片，根据gossip掌握的邻 居进行权衡拉取，会进行3次尝试，每一次尝试时间是本地节点与邻居之间的RTT值。3 次失败进入补偿区间。补偿区间：分片时序进入补偿区间后，也会周期检查丢失的分片，根据丢失的分片ID直接 向edge server请求拉取，尝试4次，每次尝试时间一个本地节点与edge server之间的 RTT。如果4失败进行waiting状态，等待邻居gossip或者edge server主动推送。过期区间：被播放后的分片会放到这个过期区间中而不是立即删除掉，为什么呢？因为每 一个节点的播放时间点不同，有可能本地播放的分片

22、正是其他节点丢失的分片，有可能其 他节点会通过pull来拉取，所以我们会把播放后的分片放在过期区间3秒后再删除。秒开问题上面分发的三个阶段和buffer控制解决了流持续分发和播放延迟控制问题，但现阶段所有 的直播技术必须要有秒开，其实P2P分发在解决秒开比单纯的server CDN转发来的更加简 单。秒开就是用户进入直播间时瞬间能看到主播的视频图像，那秒开的宗旨是新进入的客 户节点要求服务端边缘节点从视频的上一个GOP关键帧开始发送数据，客户节点再根据视 频编码器从这个GOP关键帧0等待加速播放即可。我们在P2P分发网络中新进入的节点 会收Edgeserver的上一个GOP关键帧分片ID,客户

23、节点根据这个ID从各个邻居中快速拉 取整个GOP分片数据，而不是单纯的让Edge server来发，秒开的速度平均缩短了 100毫 秒。.P2P内容授权直播分发技术除了传输分发以外，还需要考虑内容防盗和授权，P2P系统中更加需要考虑 系统安全性。我们引入了 CA证书和双端协商加密方案来保证链路的合法性。大致的做法是 每个合法的节点单元（edge和所有的客户节点）会向CA发起合法校验，如果检验通过，C A会根据节点的ID、节点RSA公钥、授权起始时间、授权终止时间等信息利用CA的RSA进 行证书生成。每个拿到证书的节点单元需要和其他的节点进行通信，会先交换证书，校验对方证书的合法性，让后利用证书中的RSA公钥加密一