P2P 技术如何降低实时视频直播带宽

实时视频直播经过去年的千播大战后已经成为互联网应用的标配技术，但直播平台的成本却一直居高不下，各个平台除了挖主播、挖网红以外，其背后高额的带宽费用也是他们最大的一块成本。

现阶段直播技术在传输方面分为两块：

    CDN ：负责流媒体的分发传输；
    连麦系统：负责解决同时多个主播间互动的实时通信传输问题。

我们始终认为基于 CDN+ 连麦系统的直播技术是一个高成本高消耗的技术，从各大直播平台纷纷亏损来看就验证了这一点。除了带宽成本，延迟问题也是现在直播技术的一个硬伤。我们很早就意识到现在这种传统的直播技术是无法大规模进行在线教育互动直播的，所以学霸君从 2016 年下半年就开始研发基于 UDP 和 P2P 技术的互动直播系统。

整个系统的设计目标是：

    端到端延迟控制在秒级范围之内；
    在不影响视频质量的情况下尽力节省分发带宽。

基于 P2P 技术的整个分发架构在一个 10W+ 直播平台上进行了 9 个月的测试和调优，初步达成了设计目标。

传输分发网络中我们把连麦系统和分发系统合二为一，将分布式推流与边缘节点分发作为一套传输体系，通过服务之间的 P2P 通信和路由选择来实现连麦的最小时延。

整个传输分发网络分为三部分：

推流部分；

服务之间 P2P；

客户节点 P2P。

这个传输网络有一个系统锚点：假定推流者 speaker 推到 Edge server 上是不会发生丢包和延迟的，Edge server 会通过服务间 P2P 快速将收到的流数据分发到其他的 Edge server，而且在这个过程也不会发生延迟和丢包。

为什么需要这样一个锚点？因为在客户节点的 P2P 网络需要保证流畅性和最小延迟，也就是要求所有的 Edge server 在最短时间周期内拥有完整的数据，至于为什么要这样，后面我们在流补偿环节重点介绍。

我将通过整个流数据传输过程来解析具体的技术细节，但在这之前首先要解决的就是媒体数据分片问题，所有的传输过程会基于分片 (segment) 来设计。

媒体数据分片是整个分发传输系统中最为基础的部分，我们在设计分片时主要考虑的是时延和消耗的问题，分片如果太大，传输的时延就会越高，例如 HLS；如果分片太细，网络中回馈报文就会很多，对 P2P 网络来说额外的消耗也是个问题。

最后我们借鉴了 RTP 和 FLV 中的经验，采用按帧来做数据分片，这样做有以下几个好处：

按帧分片延迟粒度小，可以在帧传输进行延时优化；

实现简单，与编解码器编码原则一致；

组合灵活，可以实现播放 buffer 无缝结合。

每一个分片称作为 segment，用一个自增长的 32 位 ID 来表示唯一性，传输过程都是以这个 ID 为标示来确定数据的完整性。即时通讯聊天软件app开发可以加蔚可云的v：weikeyun24咨询

确定好了媒体分片就可以进行推流了，我们把推流和分发的路径合二为一，上麦者是将流数据 segment 推送到离自己最近的 Edge server 上，而不是推送到专门的连麦系统上。我们推流传输使用的是 RUDP 传输算法，这个 RUDP 是采用了类似 BBR 基于延迟和丢包来设计的拥塞算法，并且对报文做了拥塞丢弃。

因为整个传输分发网络是分布式的，由多个 Edge server 组成，所以基于系统锚点，媒体数据分片到 Edge server 上必须尽快分发到其他 Edge server 上。最早我们是统一用 BGP server 来中转，这样耗费的 BGP 带宽很多，而且 BGP server 一旦异常，整个 Edge server 之间的通信就中断了。

媒体流数据通过 Edge server 间的 P2P 多路径传输网络到达各个 Edge server 上，接下来每个 Edge server 需要将流数据分片下发到各个客户节点上，我们针对上麦节点做了传输特殊处理让时延更小，过程和普通的 RTC 通信模型相似，这里就不赘述了。观看节点上分发采用自组织 P2P 网络，既然是通过 P2P 下发的，那么就要在客户节点群构建一个 P2P 网络，这个网络是怎么构建的？具体分为三步：连接、评估、分层。

客户节点程序是运行在客户机上的，大部分客户节点都会在路由器或者 NAT 后面，他们之间要相互建立连接，必须穿越彼此的 NAT 和防火墙。虽然现在穿越 NAT 的方法有很多，如 STUN、ICE 等，但穿越连通率始终是一个问题，如果穿越率太低，会让很多优质的节点资源得不到充分利用。

在设计穿越方案时我们将直连连通率放在第一位，通过修改 STUN 协议设计了一种基于端口多次猜测和尝试的穿越机制。首先通过类似 STUN 协议判断 NAT 类型、NAT 端口变化规律、NAT 是否有黑名单机制等信息，然后将这些信息存到辖区连接中的 Edge server 中，当有伙伴节点来与它穿越，会交换彼此的这些信息，不同的排列组合会有不同的穿越策略，每一次穿越的过程和结果都会记录到我们的后台数据库，我们会周期性地将这些数据进行分析并调整协商穿越策略。

【邻居问题】：

连接一旦完成，节点与节点之间就成为邻居，彼此会进行状态交换和心跳，那么问题来了，一个直播系统有成千上万的节点参与，如果都两两相连的话光心跳通信就可以将客户节点的上传带宽占满。我们设计了一个节点 LRU 淘汰链表，链表中保持 40 个联系的邻居节点，老的节点会退出，新的节点会加入，LRU 会根据邻居与自己的通信状态来进行 LRU 新增和淘汰，原则如下：

    就近原则，内网优先，同城同一运营商网络次之；
    周期性评测延迟和媒体分片命中率，末位淘汰；
    当 LRU 列表中节点不足 40 个时会从备用节点列表中选取新的节点进行连接并加入到 LRU 中。

【节点评估】：

每个客户节点的计算能力、通信能力和网络分区等都不一样，这使得我们必须对每个节点做一个评价，对一个节点的评价分为两部分：邻居节点对自己的评价和自己对自己的评估。

邻居评价主要是：

    RTT；
    丢包率；
    请求命中率。

通过这三个参数会对每个邻居计算出一个亲和力分值 score，这个值会用于后面的分发选择。

主要评估自己这几点：

    CPU、内存；
    网络类型：WIFI/4G/ 有线网络；
    上传带宽。

节点会周期性计算这两类参数，通过一个网络 QOS 收敛函数 f (x) 来计算节点能力和对邻居 QOS 策略。

节点评估最终的目的是让有能力的节点成为超级节点（super node）来分担 Edge server 的分发压力。

那么一个节点成为超级节点的条件是什么呢？有以下几个条件：

有足够的上传带宽，4G 和弱 WIFI 下不能成为超级节点；

有空闲的 CPU 和内存，计算能力不够的低端移动设备不能成为超级节点；

对邻居通信友好，不是通信孤岛；

得到 Edge server 的任命，和 Edge server 之间通信顺畅。

超级节点如果性能衰减了怎么办？答案是会退化成普通节点，因为节点评估是周期性实时进行的，如果发现节点性能衰减，Edge server 会让其退化。

既然任命了超级节点，那么超级节点是怎么工作的？每一个超级节点在被任命时都会分配到一个分组 ID，Edge server 会根据自己辖区的超级节点数量进行分组，每个分组由多个超级节点组成，分组内的超级节点负担自己分组的媒体分片分发。例如：有 5 个超级节点分组，这时单位周期内有 1 ~ 20 个 segment，那么第一个分组负责 1、6、11、16 编号的 segment 分发，以此类推第二组负责 2、7、12、17 …… 这样做是为了防止单个超级节点失效，增强了 P2P 分发的稳定性。

通过上面的 P2P 网络构建过程我们知道整个 P2P 网络其实是一个分层有向图分发网络，那么具体是怎么进行流数据分发的呢？也分三步：先推 (push)、后拉 (pull)、再补偿。