直播平台的成本却一直居高不下,各个平台除了挖主播、挖网红以外,其背后高额的带宽费用也是他们最大的一块成本。

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

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 网络来说额外的消耗也是个问题。即时通讯聊天软件app开发可以加蔚可云

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

按帧分片延迟粒度小,可以在帧传输进行延时优化;
    实现简单,与编解码器编码原则一致;
    组合灵活,可以实现播放 buffer 无缝结合。

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

确定好了媒体分片就可以进行推流了,我们把推流和分发的路径合二为一,上麦者是将流数据 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技术如何降低实时视频直播带宽相关推荐

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

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

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

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

  3. 浅析即时通讯开发之移动端实时音视频直播技术编码和封装

    视频编码是本系列一个重要的部分,如果把整个流媒体比喻成一个物流系统,那么编解码就是其中配货和装货的过程,这个过程非常重要,它的速度和压缩比对物流系统的意义非常大,影响物流系统的整体速度和成本.同样,对 ...

  4. 浅析即时通讯开发中移动端实时消息推送技术

    实时消息推送在移动端互联网时代很平常,也很重要,它的存在让智能终端真正成为全时信息传播的工具.本文将从移动端无线网络的特点来谈谈实时消息推送的技术原理及相关问题,希望能给你带来些许启发. 移动端实时消 ...

  5. 浅析即时通讯开发实时通信技术中的视频编解码

    RTC(Real-time Communications),实时通信,是一个正在兴起的风口行业,经过短短一年的时间,已经有很多玩家进入了这个行业,最典型的应用就是直播连麦和实时音视频通信.但是,很多开 ...

  6. P2P技术是如何将直播带宽降低75%的

    实时直播经过去年的千播大战后已经成为互联网应用的标配技术,但直播平台的成本却一直居高不下,各个平台除了挖主播.挖网红以外,其背后高额的带宽费用也是他们最大的一块成本.现阶段直播技术在传输方面分为两块: ...

  7. 技术干货:实时视频直播首屏耗时400ms内的优化实践

    本文由"逆流的鱼yuiop"原创分享于"何俊林"公众号,感谢作者的无私分享. 1.引言 直播行业的竞争越来越激烈,进过2018年这波洗牌后,已经度过了蛮荒暴力期 ...

  8. Android 即时通讯开发小结(二)

    <Android 即时通讯开发小结>基于IM Andriod 开发的各种常见问题,结合网易云信即时通讯技术的实践,对 IM 开发做一个全面的总结. 相关推荐阅读:. Android即时通讯 ...

  9. 谈谈即时通讯开发平台

    由于即时通讯系统的复杂性和对服务器稳定性的很高要求,一般即时通讯系统开发至少需要1年左右的时间,而这还只是测试版,离"稳定"还有一定距离,而这时匆匆上马的不稳定的系统会让你失去用户 ...

最新文章

  1. linux技术工程师,LINUX系统工程师技术(Engineer)-------第四天
  2. nvidia docker容器不支持中文的解决办法_用docker搭建深度学习实验环境
  3. 忘却的旋律java2_mc忘却的旋律启动器下载
  4. 简述osi参考模型各层主要功能_OSI网络模型
  5. matlab直扩序列生成,基于matlab的直接序列扩频通信系统仿真毕业论文
  6. observable java_java源码阅读Observable(观察者模式)
  7. VUE3.0引入本地js文件
  8. §3—1 复式记账法 [第三章 复式记账 ]
  9. 如何使用mac自带录屏截图功能?真的超好用
  10. linux下升级glibc-2.14问题
  11. php中的数据库操作类、分页类,以及smarty扩展类
  12. Oracle动态执行表不可访问解决方法
  13. java自学路线图(超全超详细)
  14. Netapp存储性能调优
  15. 乐高大颗粒作品23:磁悬浮列车
  16. python seo 采集内容_SEO如何处理采集内容(4)–转自{GoGo闯}
  17. 序列回帖与multi-mapped reads的处理
  18. lab2 binary bomb 详解
  19. 关于premiere中遮罩的几点总结 数媒0802 宋志超
  20. 解决DeepL翻译器翻译出来的文档是只读模式,不能编辑

热门文章

  1. nginx支持text html,BT面板重启Nginx提示“nginx: [warn] duplicate MIME type “text/html””解决办法...
  2. Visual Studio 2010已安装,sql server 2008 management studio安装教程
  3. VS2010、SQL Server 2008安装详解
  4. 如何区分斜杠和反斜杠?
  5. 2020前端工程师的发展前景
  6. scipy 三次样条插值
  7. Power Method for dominate eigenvalue
  8. IntellIdea+SpingMVC简单项目
  9. DVWA靶场通关教程
  10. vue路由router的props配置