B站直播的自研P2P理论 | 助力S十二英雄同盟总决赛

sabrina558

本期作者
姜军
持有软考中级软件设计师证书的直播P2P零碎设计工程师
朱俊炜
直播P2P零碎开发工程师
秦永芳
直播P2P智能算法工程师
李凯
多媒体技术部资深开发工程师
01 引言
跟着硬件的不停开展，直播观众的电脑机能不停晋升。芯片愈来愈快，显示器愈来愈大，显示器上的像素点愈来愈小，能展示的画面也愈来愈明晰；同时我国的网络建立提高飞速，光纤入户在大部份城市曾经遍及。这成为网络直播提供更高的画质的无利前提。
观众对画质的寻求愈来愈高，有需要就有市场，主播也使用愈来愈高的画质进行直播。在这个过程当中，直播平台需求担负的带宽本钱也迅速攀升。
事实上，网络带宽的收入在技术本钱侧是占比最大的部份。为了将本钱管制在一个能够承受的规模，各直播平台纷纭使用P2P技术来升高办事器带宽。云办事提供商也提供了成套的解决计划，能够为没有自研才能、无奈担负自研本钱或短期内无奈实现自研的直播平台提供疾速接入。
跟着B站外部对HLS协定直播的传输研发实现度不停进步，自研P2P的条件前提具备了。HLS自身是一种切片式的直播传输格局，详细细节能够参考后面的《HLS直播协定在B站的理论》。由于切片是动态文件，所以能够经过HTTP带Range头的申请下载这个文件的指定部份。假如让不同的观众下载同一个切片文件的不同部份，而后这些观众之间再相互替换一下数据，大家就都有残缺的数据了，而办事器事实上只传了一份数据出去，带宽本钱就大幅度升高了。
02 利用WebRTC通讯
WebRTC最先来源于被谷歌收购的Global IP Solutions公司的IP电话和视频会议解决计划。谷歌在收购之后对其进行了开源，并与IETF和W3C等机构协作推动其规范化。Chrome从28版本开始集成为了WebRTC，随后不同阅读器也进行了跟进；它们遵照同一种规范，可以相互衔接和通讯。
因为WebRTC是阅读器内建的一切数据传输形式中，独一一个不依赖Server-Client模式的。故只要使用WebRTC作为P2P的传输协定，能力兼容消费带宽占比最大的阅读器端用户。
2.1 WebRTC的衔接流程
WebRTC的衔接，靠的是会话形容协定（Session Description Protocol，简称SDP）进行握手。这个会话形容协定就好像是Socket编程中的Socket Name那样，要建设衔接的两方相互替换了SDP之后，衔接能力建设。这里用到的SDP分为Offer和Answer两种，被动创立的SDP属于Offer，为了回应他人的SDP而创立的属于Answer。
WebRTC提供的用于替换SDP的接口有如下几个：CreateOffer，SetLocalDescription，CreateAnswer，SetRemoteDescription。在最后创立Offer前，需求告知WebRTC要用甚么传输通道，例如音视频、数据通道等；由于咱们在这里不使用音视频通道，所以只添加数据通道。利用这些API的繁难建设衔接流程示意如下：


从流程中能够看出，在衔接胜利建设以前，需求一台办事器在两个用户之间直达，传递Offer和Answer的数据，使得单方都实现SetLocalDescrption和SetRemoteDescription（图中加粗部份）。咱们开发了一台Tracker办事器，经过WebSocket协定和阅读器页面实时通讯，用于观看同一路直播流的观众之间相互发现、相互替换Offer和Answer，从而帮忙这些观众之间建设衔接。
2.2 运用层协定
在实现了WebRTC的衔接之后，其中的DataChannel数据通道就能用来实时收发数据了。数据通道的发送单位为一个“动静”。动静能够是字符串也能够是二进制。斟酌到二进制类型更为通用，咱们选择了二进制协定作为传输类型。协定的可扩展性也很首要，这瓜葛到后续降级的时分是否能够更易地相互兼容。在Web开发畛域通常会使用JSON作为数据构造的序列化、反序列化协定。但JSON不克不及间接兼容二进制数据的封装，Base64等编码又会使得数据的体积减少三分之一。为了同时知足便利使用、可扩展、传输二进制的要求，咱们选择了Message Pack作为传输协定。它自形容，额定开消少，原生反对包容二进制数据。
WebRTC的DataChannel以动静为单位、采取的是SCTP协定进行数据传输。只管规范中给出了如何拆分大的动静体，但并不是一切阅读器都完成了它。所以在不同的WebRTC完成之间，传输大的动静领会泛起奥妙的兼容性问题。文档中提到小于16KB的数据块能够没有顾虑地收发，但这关于咱们来讲有点过小了。通过咱们在需求反对的阅读器间两两测试，终究发现64KB是一个能用的最大值。为了开发和调试便利，咱们定义单次申请和单次响应的最大大小为64KB，这样在运用层能够不需求额定开发数据的拆分和合并逻辑。斟酌到Message Pack自身协定完成需求一定开消，为了后续可扩展性斟酌也不该把64KB吃干抹净，所以咱们定义单次传输的数据块最大下限为60KB。
为了进步吞吐量，咱们允许DataChannel里的通讯并非严格遵照申请——响应——申请——响应这样的流程，而是允许前一个申请失掉应对以前，间接发送下一个申请，这样在网络提早大、用户处置申请慢的状况下，战胜了“住手等候协定”似的缺陷。由于存在晚发的申请需求更少的时间处置这类状况，所以还要允许不根据申请程序发送应对。所以咱们设计了一个申请ID，经过ID来关联申请和对应的响应。
综上，协定设计如下所示：


咱们将通讯流程设计成HTTP似的主动提供办事的形式。例如有A和B两个用户。A向B申请一个数据块，B回给A一个数据块。A没有向B发送申请的时分，B不会给A发送数据。申请和申请之间没无关联，协定是无形态的，这样能够加重提供办事一方的担负。
单个动静限度在60KB之内，而HLS协定的直播流中，单个分片随意都能超过60KB。所以咱们把每个分片（即M4S文件）拆分红许多60KB的数据块，以数据块为单位分片传输。同时需求一个接口，能查问该用户对某个分片的下载进度——每个数据块的已下载、正在下载、未下载的形态。
03 Peer间分工
3.1 工作调配困难
当初，用户之间怎么相互衔接、连上之后怎么通讯、怎么利用这类通讯来节俭CDN的带宽损耗曾经都探讨完了。到把它们串通起来一同运转的时分了。
首先，我关上直播间页面，网页上的直播播放器组件被创立，随后加载直播流的地址并开始播放。
与此同时，在网页上看不见之处，P2P组件开始衔接到Tracker办事器，告知办事器播放器正在看的是哪一路直播流；办事器前往了一个包孕了也在看这路直播的用户的列表；P2P组件按照要连的用户数量、创立一批PeerConnection对象，并逐个调用CreateOffer获取建设衔接要用的SDP字符串；这些SDP字符串经过Tracker办事器发给了不同的人，而收到了的人也创立PeerConnection对象、承受了Offer并发生Answer，而后经过Tracker办事器发还给我。这样一套流程上去，这一批PeerConnection对象就同时开始尝试与替换了SDP的直播间内其余观众衔接。
遭到繁杂的网络构造影响，不同用户间的WebRTC衔接不包管能胜利。假如终究连上的用户数没有抵达预期，那末能够持续向Tracker申请下一批用户列表。
当初，我曾经和观看同一路直播流的几个小火伴建设了衔接。下一步就是用下面引见的那些协定，从其余观众那边下载我要的数据：






真巧，其余人也是这么想的。所以这个P2P网络就这么把本人憋死了。
数据不成能平空泛起，破局的症结是，必需要有人从办事器下载一份原始数据，大家才有得货色相互同享。还有一个问题，上传数据假如太多，对正常使用网络形成不良影响，用户端体验就会很差，所以不克不及一集体下载数据之后传给太多的人。用户和用户之间使用的网络不同，而家喻户晓网络是有“相性”问题的：用户A和用户B相互传数据很快，用户B和用户C相互传数据很快，但这不克不及推理得出用户A和用户C相互传数据很快。再加之，后面提到过用户间相互衔接是有一定的胜利率的，虽然实践上衔接胜利与否遭到这两个用户的路由器类型无关，但WebRTC的STUN协定完成，在代码里写死了不承受指定办事器和端口之外的来源发来的数据包；在这类限度下，在阅读器中利用STUN协定只能区别出对称型和非对称型路由器，无奈持续细分，对咱们帮忙不太大。
衔接数太多又会对机能有欠好的影响，不成能做到应连尽连。虽然实践上，只有投入一份残缺的数据到P2P网络中，通过足够长的时间，全部网络里的一切人就都能失掉一份残缺的数据；但直播的数据拥有很高的实时性要求，不成能提供有限长的时间在观众之间相互传数据。由此，分工变得特别难题。
3.2 自在市场
假如咱们让观众之间随机自在衔接，在无限的衔接胜利率下，他们能组成一个特别繁杂的网状构造。因为用户间存在后面提到的“网络相性”问题，网络中节点与节点之间的边就有了不同的权重值。再加之直播间内的观众进进出出瞬息万变，假如有一个算法能在这样繁杂的网状构造中计算出工作调配形式，算法也必需实时更新，这类超高的算力要求是微小的应战。所以咱们换了个思绪，从播放真个P2P SDK听从办事器的一致办理，切换到P2P SDK自我办理。
首先定义下载流程。由于对HLS协定中每一个个分片文件，假如间接开始P2P数据替换，就会泛起后面说的相互憋死的问题。所以必需要有一部份用户，先从办事器下载一些数据，而且要求不同人下载的数据尽量不同，这样能力互通有没有。数据从办事器进入P2P网络之后，用户间的相互数据分享就开始了。由于每个用户的分享才能有下限，咱们定义的是分享的数据量不得大于其下载的数据总量。再加之传输过程当中数据可能有消耗之类的状况，终究是会有用户无奈获取残缺的数据的。所以在用户之间相互分享之后，会有一个终究阶段，经过办事器把缺失的部份补完。


在这个流程中，三个环节是相互影响的：假如初始做种获取的数据太多，那末P2P发扬的CDN带宽节俭作用就无限；而假如初始做种获取的数据太少，由于用户的分享数据量无限制，所以间接致使终究补完阶段需求损耗少量的带宽。所以在初始做种阶段，哪些观众下载哪部份数据就变得特别症结。
咱们发现，在这个流程中，终究补完和初始做种都是从办事器下数据，从节俭率来讲是没有影响的。只有让三个阶段的实行能够相互影响，困难就能破局。这里的情景很像是自在市场，而这两件事的产生则对应了供不该乞降供大于求：某些数据块需求在终究补完阶段从办事器下载，阐明这个数据块供不该求，那末咱们能够在初始做种阶段获得这些数据，增补供应；某些数据块在相互替换阶段没人要，阐明这个数据块曾经供大于求了，当前初始做种阶段就不下载这些数据，从供应角色转变成需要角色。自在市场中“看不见的手”发扬了作用，自动进行供需调剂。


由于一切观众会履行同样的战略，所以假如这些用户同时进行了供需角色的转变行动，那末会间接致使这个P2P网络中从一个极端转向另外一个极端，而后下一次再转回来，难以达到一种不乱的均衡形态。所以咱们让用户在筹备进行角色转变以前，先进行一次几率判别，就像摇骰子，只要摇中的那些人进行角色转变。假如这些人的角色转变没有解决供需不屈衡的问题（转变的人不敷，或者转变的人太多），那末就还会有下一次摇骰子。利用这类形式，每个观众就只有看着本人的数据进行调剂，办事器侧也没有额定的计算需要，也不需求额定斟酌用户进出的问题，P2P网络就可以一直朝着最优的标的目的变动。
04 结语
至此，一个简略高效的直播P2P零碎就构建起来了。P2P内核在上传量小于等于下载量的束缚下相互分工和合作，在无限的本钱估算下，撑持海量观众看直播的需要。
作者:姜军,朱俊炜,秦永芳,李凯
出处:http://mp.weixin.qq.com/s/s-lNjrOMHnh2HfgMVcm-aA