P2P技术如何将实时视频直播带宽降低75%？

前言

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

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

• CDN ：负责流媒体的分发传输；

• 连麦系统：负责解决同时多个主播间互动的实时通信传输问题。

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

整个系统的设计目标是：

• 端到端延迟控制在秒级范围之内；

• 在不影响视频质量的情况下尽力节省分发带宽。

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

那整个系统是怎么设计的？使用了哪些技术来达成目标？接下来我来重点分享一下架构设计和技术细节。

基于P2P的实时视频直播分发网络架构

基本架构

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

架构如下图：

​

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

• 推流部分；

• 服务之间 P2P；

• 客户节点 P2P。

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

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

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

媒体数据分片

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

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

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

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

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

每一个分片称作为 segment，用一个自增长的 32 位 ID 来表示唯一性，传输过程都是以这个 ID 为标示来确定数据的完整性。

推流与连麦

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

示意图如下：

​

至于为什么不采用 RTP 或者 RTMP/TCP 来推流，因为 RTP 虽然是基于 UDP 的，但需要通过 RTCP 和 NACK 来保证可靠性，需要设计拥塞算法，也需要对 RTP 进行改造扩展，而且还受 RTP 协议本身的限制ÿ