WebRTC 如何工作?如何实现WebRTC

WebRTC 是一种免费的开源技术,它通过简单的应用程序编程接口 (API) 为浏览器和移动应用程序提供实时通信 (RTC) 功能。它允许直接的点对点音频和视频通信,无需安装任何额外的插件或本机应用程序。它由谷歌于 2011 年 5 月创建,作为一种基于浏览器的实时通信的开源技术。目前,WebRTC 完全稳定,其最后一个版本 (v1.0) 于 2018 年 5 月发布。它已通过万维网联盟 (W3C) 和互联网工程任务组 (IETF) 进行标准化,并得到 Apple、Google、Microsoft 的支持、Mozilla 和 Opera。

WebRTC 是如何工作的

WebRTC 带有预定义的消息传递算法,必须在软件解决方案中配置该算法才能使 WebRTC 通信正常启动和工作。下图说明了建立 WebRTC 连接时发生的情况。

WebRTC 自带预定义的消息传递算法,必须在软件解决方案中配置该算法才能使 WebRTC 通信正常启动和工作

总结起来,启动一个WebRTC会话主要有四个步骤:

a) 对等点需要使用 STUN——NAT 会话遍历实用程序——服务器找到他们的公共 IP 地址。

b) 在对等点找到他们的公共 IP 地址后,客户端 A 需要通过信令服务器向客户端 B 发送“Offer SDP”,之后客户端 B 需要验证该提议并向客户端 A 提供一个“Answer SDP”。 SDP——会话描述协议——是一种描述流媒体通信参数的格式,用于宣布会话和验证其参数。

c) 会话被宣告和验证后,客户端A需要通过信令服务器向客户端B发送’ICE Candidates’,之后客户端B需要验证ICE候选并回复相同类型的消息。ICE——交互式连接建立——是一种用于检索所有可用候选地址(IP 地址)的方法,然后将其传递给客户端。

d) 当会话完全验证并且 ICE 候选人准备就绪时,WebRTC 音频和视频通信可以直接或通过 TURN 开始——使用中继遍历 NAT 服务器。

在幕后,WebRTC 使用其他几种不同的协议来提供可靠的音频和视频通信。

WebRTC 使用其他几种不同的协议来提供可靠的音频和视频通信

如上图所示,WebRTC 在传输层使用 UDP——用户数据报协议,主要是因为 UDP 协议是现代浏览器实时通信的基础。除此之外,WebRTC 使用提到的 ICE、STUN 和 TURN 协议通过 UDP 建立和维护对等连接。最后,SCTP – 流控制传输协议 – 和 SRTP – 安全实时传输协议 – 用于多路复用不同的流,提供安全性和拥塞,并在 UDP 之上提供部分可靠的交付。

如何实现WebRTC

正如在 WebRTC 消息传递算法的解释中所见,为了在软件解决方案中实施 WebRTC,需要配置三个主要内容:

a) 信令服务器

b) STUN 和 TURN 服务器

c) 客户端应用程序(网络或移动)

信令服务器

信令服务器是客户端应用程序用来相互通信的必要服务器端应用程序。它使用网络套接字技术(WebSocket、socket.io 或类似的解决方案)将客户端组织到特定的组(通常称为房间)中,以便收听它们的消息并将它们重定向到正确的接收者。信令服务器的实现通常非常简单,但它必须与客户端应用程序中实现的消息传递算法同步。

STUN 和 TURN 服务器

STUN 服务器是用于帮助客户端找到其公共 IP 地址的轻量级服务器。它们的设置并不难,而且通常也可以免费访问(例如,Google STUN 服务器完全可以免费使用)。当对等点知道他们的公共 IP 地址时,他们可以继续消息传递过程,之后建立连接,媒体传输就可以开始了。而且,您可能会问 TURN 服务器呢?在一个完美的世界中,STUN 服务器总是足以建立 WebRTC 连接。然而,在大约 30% 的情况下,通过 STUN 服务器找到对等点的公共 IP 地址不足以建立连接。这主要是因为在对等点的网络配置中使用了严格的防火墙规则或对称 NAT(网络地址转换)。在那些情况下,

包括几个 STUN 服务器,以及 WebRTC 配置中的几个 TURN 服务器

TURN 服务器可以自定义实现(完全或使用开源解决方案,例如coTURN),也可以作为服务购买(例如Xirsys)。建议您在 WebRTC 配置中包含多个 STUN 服务器以及几个 TURN 服务器。事实上,您使用的服务器越多,连接就越稳定。然而,同样值得记住的是,超过某个点,使用太多会使连接过程变慢。

客户端应用程序(网络或移动)

WebRTC 实施的最后一步是配置客户端应用程序(Web 或移动应用程序)。在对客户端应用程序进行编程时,必须配置两个主要内容才能使 WebRTC 充分发挥作用:

a) 获取客户端特定的用户媒体——它包括在程序代码中使用一些预定义的 WebRTC API。WebRTC 的开发人员使程序员实现这部分变得非常简单,因此每种技术只需几行代码就可以解决问题。

b) 通过套接字定义通信——这意味着在程序代码中创建一个消息传递算法,这将允许每个对等点以正确的顺序执行前面描述的 WebRTC 消息传递算法的每个步骤。

当通过套接字的通信被正确定义并与信令服务器实现同步时,客户端只需加入套接字组,从设备获取用户媒体并通过信令服务器启动消息传递模式。如果一切配置正确,WebRTC 会话应该会自动初始化并且可以开始通话。

如果一切配置正确,WebRTC 会话应该会自动初始化并且可以开始通话

为什么选择 WebRTC

考虑到目前所说的一切,我们可以得出结论,WebRTC 绝对不是实时通信技术的领导者。WebRTC 与同类型的类似技术相比的主要优势在于其实施简单、预定义的多层安全性、实施连接 Web 浏览器和移动操作系统的跨平台解决方案的可能性,以及最后但并非最不重要的一点,易于由最终用户使用。无论是同一平台上两个客户端之间的简单网络聊天,还是不同平台上多个客户端之间复杂的实时通信解决方案。

版权声明:本文内容转自互联网,本文观点仅代表作者本人。本站仅提供信息存储空间服务,所有权归原作者所有。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至1393616908@qq.com 举报,一经查实,本站将立刻删除。

(0)

相关推荐

发表回复

登录后才能评论