即构自研WebRTC网关服务器架构实践

简介: 即构为什么要自研WebRTC网关服务器?我们从开源和自行研发的优劣势说起。

演讲 / 黄开宁
整理 / 小极狗

作为实时音视频领域最火的开源技术,WebRTC点对点的架构模式,无法支持大规模并发。如何在架构中引入服务端,一直是开发者关注的热点。5月20日,在WebRTCon大会上,即构科技资深音视频架构师黄开宁带来了他的实践分享。

我们对他的演讲内容做了整理,整理后的文章分为上下两篇,本文为第二篇,欢迎阅读。关注本公众号,回复“webrtc”还可获取他的演讲视频和PPT。

_

前面(第一篇:WebRTC网关服务器搭建:开源技术VS自行研发)我给大家分享了:

第一,为什么需要WebRTC网关。对于即构来说,目前所使用的系统已经较为成熟,也经过了市场的检验,为什么还要在如此成熟的商用系统中加入WebRTC?

第二,WebRTC通信模型对比。分析了目前的WebRTC通信模型以及不同模型的适用场景,以便大家在选型时能结合自己的需求匹配对应的场景。

第三,开源VS自研。分享了目前市面上的一些开源系统及其特点以及即构自研WebRTC网关的目的和出发点。

下面,我将结合即构自研的WebRTC网关服务器方案,分享在开发过程中遇到的难点和解决办法。

Zego-Gateway架构的改进

在加入WebRTC网关之前,即构自研系统架构如下图所示,主要分成两部分,左边是低延时用户,而右边是围观用户。低延时用户主要是通过ZEGO的实时传输网络进行推拉流。

_1

由于RTMP的实时性并不是很好,在浏览器端没有办法通过RTMP进行上行传输达到低延时的特点,所以即构对原有的系统架构进行了升级,在低延时的实时传输网络中加入了WebRTC网关服务器,具体如下图所示。

_2

在加入了WebRTC网关服务器后(图中红线部分所示),即构的系统已经能全面支持网页端视频互动场景,同时实现了APP、微信小程序、WebRTC三端的连麦互通。浏览器登录 https://videotalk.zego.im/  即可体验 Web版 demo。

Zego-Gateway架构的实践

在开发WebRTC网关的过程中,我们遇到了不少的难题。下面我将结合即构的方案给大家一一分享。

_3

首先我们需要了解网关在架构中的地位。如上图,左边是浏览器端的接入方式,右上角是后台房间、信令等服务,中间就是Gateway。通过网关可以连接即构现有的实时音视频架构,而即构的架构是基于UDP私有协议的,同时搭配CDN分发网络,或者是自主实现的RDN服务器。同时即构的架构体系中还包含了部署在全球范围的实时音视频架构。通过网关与原有的媒体服务器进行连接,可以轻易实现跨国实时音视频通信。目前,即构的架构体系在路由器选择和负载平衡方面都非常完善,只需要在中间的Gateway中进行对接就能获得原本架构中的实时音视频能力。

_4

上图是Gateway的系统架构,与WebRTC的架构图十分类似。这个图包含了Gateway的一些模块,对比上一篇文章中介绍的开源项目,可以发现大多数开源项目只包含最右边的四个模块。如果只是需要实现WebRTC网关,只需要右边的四个模块,就可以搭建一个最简单的服务器架构。但是若想实现功能较为完善的WebRTC网关,MCU的模型、路由带宽预测、JitterBuffer、Codec等都是需要实现的模块。下面主要根据不同的模块,分享即构在自研过程中实现的技术难点和模块间的结合应用。

_5

图中所示的是非常典型的RTMP的转协议流程,左边是浏览器,中间是RTP、RTCP的模块,右边是RTMP的模块。由于RTMP的TCP是有序的,所以在网关的内部,需要引用JitterBuffer,进行丢包和抖动的处理。另外,由于RTP、RTCP和RTMP的时间戳处于不同的体系,不是基于同一个标准的,所以需要实现时间戳的同步。RTP是基于NTP,而且音频和视频会根据各自采样时钟来打时间戳的,而RTMP却是一个绝对时钟,需要通过RTCP的SendReport反馈对音频和视频时间戳进行同步校对。实现同步后,还需要实现转码,一般来说是将OPUS转成AAC。在这个模块中,包含了JitterBuffer、时间戳同步和转码等技术,虽然有些技术看上去很简单,但是实际上要做到很好的实时性,也是比较困难的。

_6

在评价一个系统时,时间是非常重要的考量指标。大家会发现使用WebRTC进行接入测试的时候速度非常慢,这是由于WebRTC用到的ICE流程非常复杂,导致耗时过长。在STUN中,首先需要做IP的映射识别出内网的IP,然后根据需要进行协助打洞。为了减少接入时间,我们首先要去掉STUN。

为什么在有服务器的情况下还需要打洞?从图上可以看到在ICE流程中,首先是左边的浏览器发起了Offer,接下来是信令阶段,主要是SDP Candidate的协商交换,随后会进入连通性检测。在ICE标准中,需要Answer方是要先发起Binding Request请求,假如在Candidate的协商交换时没有经过STUN做IP的映射,那么浏览器端的IP是内网地址。而Gateway在云端,对应的IP是公网的地址。很明显,这种地址的不对称会导致连通失败。这也是为什么需要打洞,或者是中间服务器的原因。

这个时候可以利用TURN的方案,在上一篇文章所介绍的开源系统中,可能有相当一部分的TURN方案都是独立部署的。独立部署的优点是扩展性比较好,缺点是可能会造成资源浪费。针对此即构的方案是在TURN的基础上做了一个整合,直接在Gateway中实现TURN。这样,既节省了资源,在部署上也有保持一定的优势。

通过整合去掉了STUN服务器后,只需要几步简单的连通性检测,不需要再经过中间服务器的转发,所以即构的方案在连通时间上可以达到毫秒级。

_7

有关连通性的另一个方面是端口复用。在使用WebRTC的过程中,会接收到弹框提示相关的权限申请,但是作为播放端可能并没有音视频的采集设备,在这种情况下,弹框的出现会影响用户的体验感。在每次调用getUserMedia的时候都会有弹框出现,如果不调用getUserMedia,则createOffer会失败,所以即构的方案将Offer换到Gateway方发起,这个时候浏览器作为Answer方就不会出现弹框了。除了弹框的问题外,由于网关的端口是随机分配的,所以可能会出现防火墙对某些端口受限,这种情况下可能会无法建立连接。因此通常情况下需要将对端的随机端口换成公共端口,例如80或者8080,这样有利于提高连通性。

_8

在分布式的系统中,由于节点众多,所以可能会出现Nack风暴。

Nack风暴是如何引发的?假设现在Publish方需要将序列号为7、8、9的三个包传输到Gateway1,网关只是做简单的转发。在传输过程中,发生了8号序列包丢失的状况,这个时候网关会实时将7、9号序列包转发给所有用户,同时判定8号序列包丢失并给Publish方发送丢包重传的Nack请求。而下方的用户在收到7、9号序列包时,同样会发现8号序列包丢失并发送Nack请求。假设接入用户有10万,在序列包丢失时会瞬间产生10万个重传请求,这个就是Nack风暴。

对于Nack风暴,即构有几个设想方案。

第一在服务器间增加扩展协议,因为在RTP中没有相关的协议,如果与Gateway1连接的服务器是自建的,可以在RTP中扩展头处理。第二可以考虑上行端不用Nack机制而用FEC。但是由于FEC本身冗余较大且复杂度高,所以不太建议采用这种方式。第三就是WebRTC只用在上行端,下行端采用RTMP或者其他替代方案,这个方案需要基于对下行的实时性要求不高的情况下才能使用。而在线娃娃机就是典型的不需要上行的例子,但是对于摇杆操作的实时性还是非常高的,所以还是需要使用RTC的方案。这种情况下,即构的方案是将Gateway下一个节点转换成基于私有协议的服务器。由于Gateway跟UDP服务器是通过私有协议进行传输的,所以Gateway会在包里增加一些相关信息,UDP服务器会根据信息判断包的完整性。当Gateway收到了重传的包后,自然会传给UDP服务器,当然UDP服务器也有一个超时机制,通过评估判定超时后也会发起重传请求。最后是隔离和负载,前面通过接入UDP服务器起到隔离的作用,接下来通过接入Gateway集群实现负载平衡。

_9

第一种是联播方式。假设上行是4M的码流,下行端用户的网络状况不一样,对高于4M带宽的用户来说没有影响,但是对带宽低于4M的用户来说,由于带宽不足会导致无法观看。在WebRTC的RTP体系中包含专有的联播方案,会在评估了用户节点的能力之后,根据节点选择对应码率的视频流。假设两个用户节点中,最高分别支持2M和0.6M的宽带能力,这种情况下,联播方案会在上行中分为两路编码,一个是2M或者是2.5M的编码,另一个是0.6或者是更小的编码。这两路视频编码会同时上传,根据用户的带宽能力选择对应的码流进行传输。但是,这种方案对于带宽能力良好的用户来说并不公平,因为在足够的带宽条件下却无法获取更好的画质。这种方案在WebRTC及Gateway中已经实现,尽管这种方案有一定的缺陷,但是根据不同的场景,也是一个值得考虑的方案。

_10

另外一种方案是分层编码。大家应该知道在视频中,帧和帧之间是有一定的关联性,根据帧率的不同,关联的帧数目也不太一样。假设目前有三种帧率,分别是30fps、15fps和7.5fps,对应用蓝色、红色和绿色进行标记。在15fps的帧率下,在两个标记帧中间也就是没有被红色标记的帧是不需要的,换句话说,在网络情况不好的情况下,只转发红色标记的帧就能进行解码,同时流畅性也很好。因为降低了帧率,对应的码率就也可以随之降低。在不同的带宽情况下,同时保证流畅性的前提下,可以选择不同帧率的码流进行转发,充分利用带宽的能力获取对应是高清视频体验。而绿色标记的部分是我们在评估了所有下行方的能力情况后,选择了QCIF作为转发视频的分辨率。QCIF具体是一个177*144像素的画面,在视频会议中会经常用到的一个标准视频采集分辨率。尽管画面比较差,但是这个分辨率下的视频非常流畅。

为了支持直播中大量的分发性需求,即构的方案采用的是H.264编解码,而不是WebRTC中的VP8、VP9。因为如果使用VP8或者VP9的编解码格式,就必须在服务器中进行转码,这样会造成延时。另外,H.264是支持SVC,类似分层编码的能力,基于这些,即构选择了H.264编码格式。而在RTP协议里面,包括头和扩展协议,暂时没有帧之间关联性的描述,或者可以说WebRTC没有实现。由于分层编码是基于帧的关联性,所以说如果没有层关系的描述,就没有办法区分帧之间的关系。

而VP9是支持分层编码的,可以在网页端或者是WebRTC场景下进行编解码,因为编码信息中带有PictureID信息,可以直接分析出帧之间的关联性。但是VP9的编码开销非常大,如果需要支持分层编码的话开销会更大,特别在移动端中性能还是比较差。分层编码不仅是编码端和解码端的结合,更重要的是要和服务器结合,在服务器中根据不同用户的带宽情况选择不同的码流进行转发,这样可以显著降低带宽的需求。

以上为我的分享内容,谢谢大家!

相关文章
|
7天前
|
搜索推荐 NoSQL Java
微服务架构设计与实践:用Spring Cloud实现抖音的推荐系统
本文基于Spring Cloud实现了一个简化的抖音推荐系统,涵盖用户行为管理、视频资源管理、个性化推荐和实时数据处理四大核心功能。通过Eureka进行服务注册与发现,使用Feign实现服务间调用,并借助Redis缓存用户画像,Kafka传递用户行为数据。文章详细介绍了项目搭建、服务创建及配置过程,包括用户服务、视频服务、推荐服务和数据处理服务的开发步骤。最后,通过业务测试验证了系统的功能,并引入Resilience4j实现服务降级,确保系统在部分服务故障时仍能正常运行。此示例旨在帮助读者理解微服务架构的设计思路与实践方法。
51 16
|
8天前
|
存储 消息中间件 小程序
转转平台IM系统架构设计与实践(一):整体架构设计
本文描述了转转IM为整个平台提供的支撑能力,给出了系统的整体架构设计,分析了系统架构的特性。
44 10
|
10天前
|
机器学习/深度学习 弹性计算 人工智能
阿里云服务器ECS架构区别及选择参考:X86计算、ARM计算等架构介绍
在我们选购阿里云服务器的时候,云服务器架构有X86计算、ARM计算、GPU/FPGA/ASIC、弹性裸金属服务器、高性能计算可选,有的用户并不清楚他们之间有何区别,本文主要简单介绍下这些架构各自的主要性能及适用场景,以便大家了解不同类型的架构有何不同,主要特点及适用场景有哪些。
|
3天前
|
编解码 运维 Kubernetes
政采云业务网关实践:使用 Higress 统一替代 APISIX/Kong/Istio Ingress
政采云基础架构团队技术专家朱海峰介绍了业务网关项目的背景和解决方案。
|
29天前
|
弹性计算 Java 关系型数据库
Web应用上云经典架构实践教学
Web应用上云经典架构实践教学
Web应用上云经典架构实践教学
|
15天前
|
负载均衡 Serverless 持续交付
云端问道9期实践教学-省心省钱的云上Serverless高可用架构
详细介绍了云上Serverless高可用架构的一键部署流程
41 10
|
14天前
|
人工智能 监控 测试技术
阿里云磐久服务器稳定性实践之路
阿里云服务器质量智能管理体系聚焦自研服务器硬件层面的极致优化,应对高并发交付、短稳定性周期、早问题发现和快修复四大挑战。通过“三个重构”(质量标准、开发流程、交付模式)、“六个归一”(架构、硬件、软件、测试、部件、制造)策略,实现芯片、整机和云同步发布,确保快速稳定上量。此外,全场景测试体系与智能预警、分析、修复系统协同工作,保障服务器在萌芽阶段发现问题并及时解决,提升整体质量水平。未来,阿里云将继续深化大数据驱动的质量管理,推动服务器行业硬件质量的持续进步。
|
15天前
|
存储 人工智能 运维
面向AI的服务器计算软硬件架构实践和创新
阿里云在新一代通用计算服务器设计中,针对处理器核心数迅速增长(2024年超100核)、超多核心带来的业务和硬件挑战、网络IO与CPU性能增速不匹配、服务器物理机型复杂等问题,推出了磐久F系列通用计算服务器。该系列服务器采用单路设计减少爆炸半径,优化散热支持600瓦TDP,并实现CIPU节点比例灵活配比及部件模块化可插拔设计,提升运维效率和客户响应速度。此外,还介绍了面向AI的服务器架构挑战与软硬件结合创新,包括内存墙问题、板级工程能力挑战以及AI Infra 2.0服务器的开放架构特点。最后,探讨了大模型高效推理中的显存优化和量化压缩技术,旨在降低部署成本并提高系统效率。
|
17天前
|
运维 监控 安全
天财商龙:云上卓越架构治理实践
天财商龙成立于1998年,专注于为餐饮企业提供信息化解决方案,涵盖点餐、收银、供应链和会员系统等。自2013年起逐步实现业务上云,与阿里云合作至今已十年。通过采用阿里云的WA体系,公司在账号管理、安全保障、监控体系和成本管控等方面进行了全面优化,提升了业务稳定性与安全性,并实现了显著的成本节约。未来,公司将持续探索智能化和全球化发展,进一步提升餐饮行业的数字化水平。
|
17天前
|
运维 安全 架构师
架构师工具箱:Well-Architected云治理提效实践
本次分享基于阿里云Well-Architected Framework的最佳实践案例,涵盖企业从上云到优化的全过程。安畅作为国内领先的云管理服务提供商(Cloud MSP),拥有800多名员工,其中70%为技术工程师,为企业提供架构安全、数据智能等技术服务。内容包括Landing Zone与Well-Architected的关系、企业云治理现状及需求分析,重点探讨了安全合规、成本优化、资源稳定性和效率提升等方面的最佳实践,并通过具体客户案例展示了如何通过自动化工具和定制化解决方案帮助企业提升云上业务价值。

热门文章

最新文章