webRTC架构说明

本文涉及的产品
数据传输服务 DTS,数据同步 small 3个月
推荐场景:
数据库上云
数据传输服务 DTS,数据迁移 small 3个月
推荐场景:
MySQL数据库上云
数据传输服务 DTS,数据同步 1个月
简介: WebRTC系列

首先我们通过webRTC官网上的一张图了解一下webRTC的架构:
WebRTC架构图

网上也有很多资料说这张图在webRTC的官网上,但是很多童鞋根本就找不到。这是因为很多童鞋没有进行科学上网:
WebRTC架构说明英文文档:https://webrtc.github.io/webrtc-org/architecture/

对于WebRTC的架构说明,官方的英文文档已经说的很清楚了,所以本文可能更多的是充当这一个翻译者的角色。下面我们从上往下分别了解WebRTC的架构设计。

三层架构

首先我们从图中可以看出webRTC被划分成了三部分,分别是绿色部分、深紫色部分以及浅紫色部分。

其中最上层的带箭头的浅紫色部分是指开发者的应用层,就是指开发者基于webRTC技术规范所开发的应用程序。严格来说这并不属于WebRTC的架构内容。

其中深紫色的中间层Web API (Edited by W3C WG)部分表示的是WebRTC开放给应用层开发人员调用的API(主要是JavaScript API 供web端使用),
在这层中开发者无需关心复杂的底层技术,只需了解webRTC的大致流程原理,调其API即可利用WebRTC实现点对点的通讯功能。

其次绿色部分才是WebRTC的核心功能层,而这一层又被分为了四个子核心功能层。分别是C++API层、会话管理层、引擎层、驱动层。

Your web app层

也就是带箭头的浅紫色层Your web app # 1...。上面已经提到严格来说这并不属于WebRTC的架构内容,所以这里就不作介绍了。

Web API层

Web API层也就是深紫色部分Web API (Edited by W3C WG),表示的是WebRTC开放给应用层开发人员的API(主要是JavaScript API 供web端使用),
在这层中开发者无需关心复杂的底层技术,只需了解webRTC的大致流程原理,调其API即可利用webRTC实现点对点的通讯功能。

WebRTC C++ API层

绿色部分包裹的浅紫色WebRTC C++ API (PeerConnection)部分,这部分主要是一些C++的接口层,这一层提供了一些 C++ API,主要是供浏览器支持WebRTC规范而调用的API,又比如需要Android上实现webRTC功能就需要编写JNI函数调用这一层API。
这一层的主要作用就是把WebRTC的核心功能暴露出来,如设备管理,音视频流数据采集等,方便各个软件厂商集成到自家应用中,比如浏览器厂商等。

其中 PeerConnection是该层最核心的一个模块,即对等连接模块;该模块中实现了很多功能,如P2P穿墙打洞、通信链路的建立和优选、流数据传输、非音视频数据传输、传输质量报告和统计等等。

Session management层

绿色部分被Session management / Abstract signaling (Session)标注的一层就是会话管理层。
这一层提供了会话功能管理功能,可进行创建会话、管理会话、管理上下文环境等。而这一层又会涉及到各种协议,比如说信令服务器的SDP协议等,主要用于进行信令交互和管理 RTCPeerConnection的连接状态。

引擎层

这一层为WebRTC核心层中最重、最复杂的一层。而这一层又分为三个小模块,分别是:Voice Engine(音频引擎)、Video Engine(视频引擎)以及Transport(传输模块)。

第一个模块 Voice Engine(音频引擎), Voice Engine是一个包含了系列音频处理功能的框架,如音频采集、音频编解码、音频优化(包括降噪、回声消除等)等一系列的音频功能。

第二个模块Video Engine(视频引擎),Video Engine是一个包含了系列视频处理功能的框架,如视频采集、视频编解码、根据网络抖动动态修改视频传输质量、图像处理等。

第三个模块Transport(传输模块),在WebRTC中,数据传输除了音视频等流媒体数据之外,还可以传输文件、文本、图片等其他二进制数据,这些功能就是这个模块所提供的。

从图中我们可以看出每个引擎的下面又包含多个子引擎,下面我们再来讲解各个引擎下的子引擎功能。

iSAC / iLBC Codec

iSAC和iLBC是WebRTC内置的音频编码器。其中iSAC是针对VoIP(Voice over Internet Protocol,即基于IP的语音传输)和音频流在宽带和超宽带环境中进行音频传输的编解码器,
是WebRTC音频引擎的默认的编解码器,技术成熟,且被广泛应用在各种实时通信软件中;而iLBC则是VoIP在窄带环境中的语音编解码器,在网络丢包较为严重的情况下仍能保持较好通话质量。

NetEQ for voice

NetEQ是网络语音信号处理的组件,这个算法能自适应网络环境的变化,有效的处理因网络抖动而导致数据丢包所造成的音频质量问题,这一技术可谓是当年WebRTC的前身GIPS的看家本领。

Echo Canceler/Noise Reduction

Echo Canceler是处理回声消除模块,能有效的消除采集音频带来的回声影响,比如说在实时音视频通话的过程中,打开手机扬声器的话,
本来的需求是录制本人的声音实时发送给对方的,但是由于存在回声,也会把对方说话的声音也录制进去。目前笔者测试发现市场上的一些手机录音的时候
本身是自带了回音消除功能,而且Android也提供有相关的API,但是好像大多数情况下,这个API都没起作用,可能是由于厂商兼容性问题,甚至有可能是直接阉割掉这个功能了。
因此想要做到录音是全平台适配回声消除功能的话就可以使用WebRTC的这个功能。而iOS平台上的录音是带有回声消除功能的。

而Noise Reduction则是抑制噪音模块(也就是降噪),如有效的抑制多种噪音(如嘶嘶声,风扇噪音等)。

VP8 Codec

VP8是第八代的On2视频,能以更少的数据提供更高质量的视频,而且只需较小的处理能力即可播放视频,为致力于实现产品及服务差异化的网络电视、IPTV和视频会议公司提供理想的解决方案。

其数据压缩率和性能方面比市场上其他编解码器高,其功能特点非常适合实时通信,是WebRTC中默认的视频编解码器。

VP9是Google提供的开源的免费视频codec,是VP8的后续版本,初始开发时命名为下一代开源视频或者VP-NEXT。

VP9的开发始于2011年Q3,试图降低VP8的50%的码率而保持相同的质量,另外希望VP9比H.265( High Efficiency Video Coding)有更好的编码效率。

Video Jitter Buffer

Video Jitter Buffer——视频抖动缓冲器,实时视频通信难免会因为网络的原因导致视频的抖动或者视频数据的丢失,
视频抖动缓冲器依靠独特的算法,有效的解决这类情况对直播会议质量造成较大的影响。

Image enhancements

mage enhancements——图像质量增强模块,这个模块是用来做图像处理以提升视频画面质量的,如图像明暗度检测、颜色增强、降噪处理等。

SRTP

SRTP属于传输模块中的内容,在了解SRTP之前我们先来了解一下RTP。

RTP 是(Real Time Protocol)提供了具有实时特征的、端到端的数据传送服务协议。而我们通常所说的RTCP等则是对RTP的控制协议。

RTP不像http和ftp等可完整的下载整个影视文件,它是以固定的数据格式在网络上发送数据,如果RTP的头部几个字节表示什么,音频数据或者视频数据包含在RTP中那几个字节中等等。

在RTP中,并未考虑到数据传输的安全性,比如没有加密功能,所以不符合安全性要求较高的应用需求,因此为了解决此问题,SRTP应运而生。
SRTP(SecureReal-time Transport Protocol)是在RTP的基础上加入了安全机制的传输协议,SRTP为数据提供了加密、消息认证、完整性保证和重放保护等功能,最大程度保障了数据传输的安全性。
所以RTP与SRTP的关系大概就是http与https的关系。

Multiplexing

Multiple exing,通道复用,即多个流数据传输共用一个通道, 以此提高传输效率。

说实话,目前笔者也不懂这个是如何复用的,先搁置一下呗。。。

P2P STUN+TURN+ICE

前面已经说过WebRTC是一种基于P2P的通信技术。而STUN、TURN、ICE这些则是实现P2P的一些关键技术。

STUN、TURN、ICE又称为NAT穿透,在现实生活中不同局域网中的内外ip是无法直接通信的,比如说局域网A中192.168.2.1与局域网B中192.168.2.2是无法互相直接发送消息的,
那么如果要在两个不同的局域网中建立起可以直接通信的通道就得依靠STUN+TURN+ICE这些技术。

而STUN、TURN和ICE又是使用不同方案进行穿透的,这个不是三言两语可以说的清楚的,后面我们结合例子再详细了解一下。

驱动层

也就是浅蓝色虚线部分,这部分有Audio Capture/Render(音频的采集和渲染模块)、Video Capture(视频采集模块)和Network I/O(网络IO模块)组成。

而这些音视频的采集和渲染,网络IO的传输功能,我们都是直接调用各平台提供的相关API即可实现,至于底层的驱动是如何实现的,笔者也不清楚,也就不在这里误人子弟了。

总结

从WebRTC优秀的分层架构设计中,我们至少学习到优秀的架构设计大多都能做到分而治之。每一层都是一个小的功能点,我们要做的就是将每一层都做得足够优秀,然后再将最优的每一层通过各种组装而铸造一个伟大的项目。

WebRTC其实是一个很庞大的内容,如果能把每一个模块都做得足够优秀,优化得足够好,甚至都可以单独提取出来做一个专业的项目运营了。可想而知要想深入学习研究通透WebRTC需要花费多少的精力以及时间。

WebRTC最为一个建立在音视频基础之上的项目,不仅仅需要了解学习通讯相关的知识,还需要音视频的相关知识,而这些知识想要吃得通透都是需要大量的实战的,
如果要做到知其然也知其所以然,那么就需要童鞋们有强大的自控力以及持续学习的持久力呀。

参考资料

《搞定WebRTC音视频直播通信技术(核心技术精讲篇)》

关注我,一起进步,人生不止coding!!!

相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
Sqoop 企业级大数据迁移方案实战
Sqoop是一个用于在Hadoop和关系数据库服务器之间传输数据的工具。它用于从关系数据库(如MySQL,Oracle)导入数据到Hadoop HDFS,并从Hadoop文件系统导出到关系数据库。 本课程主要讲解了Sqoop的设计思想及原理、部署安装及配置、详细具体的使用方法技巧与实操案例、企业级任务管理等。结合日常工作实践,培养解决实际问题的能力。本课程由黑马程序员提供。
目录
相关文章
|
Web App开发 算法 JavaScript
WebRTC整体架构分析
1 设计WebRTC的目的 WebRTC(Web Real-Time Communication)项目的最终目的主要是让Web开发者能够基于浏览器(ChromeFireFox...)轻易快捷开发出丰富的实时多媒体应用,而无需下载安装任何插件,Web开发者也无需关注多媒体的数字信号处理过程,只需编写简单的Javascript程序即可实现。
3368 0
|
Web App开发 编解码 ice
即构自研WebRTC网关服务器架构实践
即构为什么要自研WebRTC网关服务器?我们从开源和自行研发的优劣势说起。
3879 0
|
19天前
|
运维 Kubernetes Cloud Native
云原生技术浪潮下的微服务架构演进
在数字化转型的风潮中,云原生技术以其灵活性、可扩展性和弹性成为企业IT战略的核心。本文深入探讨了微服务架构如何借助云原生环境进行优化,并分析了容器化、服务网格等技术如何助力微服务更好地适应云原生生态。通过案例分析,我们揭示了微服务在现代云平台上的实践挑战与解决策略,同时对未来的技术趋势进行了预测。
36 0
|
2天前
|
监控 负载均衡 API
从单体到微服务:架构转型之道
【8月更文挑战第17天】从单体架构到微服务架构的转型是一项复杂而系统的工程,需要综合考虑技术、团队、文化等多个方面的因素。通过合理的规划和实施策略,可以克服转型过程中的挑战,实现系统架构的升级和优化。微服务架构以其高度的模块化、可扩展性和灵活性,为业务的持续发展和创新提供了坚实的技术保障。
|
11天前
|
Cloud Native 云计算 微服务
云原生时代:企业分布式应用架构的惊人蜕变,从SOA到微服务的大逃亡!
【8月更文挑战第8天】在云计算与容器技术推动下,企业分布式应用架构正经历从SOA到微服务再到云原生的深刻变革。SOA强调服务重用与组合,通过标准化接口实现服务解耦;微服务以细粒度划分服务,增强系统灵活性;云原生架构借助容器化与自动化技术简化部署与管理。每一步演进都为企业带来新的技术挑战与机遇。
38 6
|
9天前
|
设计模式 监控 API
探索微服务架构中的API网关模式
在微服务的宇宙里,API网关是连接星辰的桥梁。它不仅管理着服务间的通信流量,还肩负着保护、增强和监控微服务集群的重任。本文将带你走进API网关的世界,了解其如何成为微服务架构中不可或缺的一环,以及它在实际应用中扮演的角色和面临的挑战。
|
17天前
|
运维 监控 负载均衡
探索微服务架构中的API网关
在现代软件开发中,微服务架构已成为设计灵活、可扩展系统的首选方法。本文将深入探讨API网关的核心作用,包括它如何简化客户端与微服务之间的交互,提供请求路由、负载均衡、认证、限流及监控等关键功能。我们将通过实际案例分析,揭示API网关在提升系统性能、增强安全性和提高开发效率方面的重要性。
|
15天前
|
负载均衡 监控 API
探索微服务架构中的API网关模式
在微服务架构的海洋中,API网关扮演着枢纽的角色。它不仅是客户端请求的接收者,也是各个微服务间通信的协调者。本文将深入探讨API网关的设计原则、实现策略以及它在微服务生态中的重要性。我们将通过实际案例分析,了解API网关如何优化系统性能、提高安全性和简化客户端与服务的交互。
31 4
|
15天前
|
运维 监控 负载均衡
探索微服务架构中的API网关设计
在微服务架构的复杂性中,API网关作为客户端和后端服务间的桥梁,扮演着至关重要的角色。本文将深入探讨如何设计一个高效、可扩展且安全的API网关,包括处理请求转发、负载均衡、身份验证、监控与日志记录等核心功能,并讨论如何在保障性能的同时确保系统的高可用性和安全性。通过具体案例,我们将了解API网关在实际生产环境中的实现方式及其对整个微服务生态系统的影响。
37 3
|
15天前
|
Kubernetes 监控 开发者
探索后端开发的新境界:微服务架构与容器化技术
在数字化时代的浪潮中,后端开发不断演进,涌现出创新的架构与技术。本文深入探讨了微服务架构和容器化技术如何重塑后端开发,提升系统的可维护性、可扩展性和部署效率。通过实际案例分析,我们揭示了这些技术背后的原理,并提供了实施的最佳实践和面临的挑战,为后端开发者提供一条清晰的技术升级路径。
39 3