WebRTC简介

WebRTC简介title:WebRTC简介categories:[WebRTC]tags:[音视频编程]date:2021/12/09作者:hackett微信公众号:加班猿WebRTC简介WebRTC(WebReal-TimeCommunications)是一项实时通讯技术,它允许网络应

大家好,欢迎来到IT知识分享网。


title: WebRTC简介

categories:[WebRTC]

tags:[音视频编程]

date: 2021/12/09

<div align = 'right'>作者:hackett</div>

<div align = 'right'>微信公众号:加班猿</div>

WebRTC简介

WebRTC (Web Real-Time Communications) 是一项实时通讯技术,它允许网络应用或者站点,在不借助中间媒介的情况下,建立浏览器之间点对点(Peer-to-Peer)的连接,实现视频流和(或)音频流或者其他任意数据的传输。WebRTC包含的这些标准使用户在无需安装任何插件或者第三方的软件的情况下,创建点对点(Peer-to-Peer)的数据分享和电话会议成为可能。

WebRTC架构

WebRTC简介

颜色标识说明

(1)紫色部分是Web开发者API层;

(2)蓝色实线部分是面向浏览器厂商的API层

(3)蓝色虚线部分浏览器厂商可以自定义实现

架构组件介绍

(1) Your Web App

Web开发者开发的程序,Web开发者可以基于集成WebRTC的浏览器提供的web API开发基于视频、音频的实时通信应用。

(2)Web API

面向第三方开发者的WebRTC标准API(Javascript),使开发者能够容易地开发出类似于网络视频聊天的web应用。

这些API可分成Network Stream API、 RTCPeerConnection、Peer-to-peer Data API三类,详细的API说明可以看这里。

Network Stream API

MediaStream:MediaStream用来表示一个媒体数据流。

MediaStreamTrack在浏览器中表示一个媒体源。

RTCPeerConnection

RTCPeerConnection: 一个RTCPeerConnection对象允许用户在两个浏览器之间直接通讯。

RTCIceCandidate :表示一个ICE协议的候选者。

RTCIceServer:表示一个ICE Server。

Peer-to-peer Data API

DataChannel:数据通道( DataChannel)接口表示一个在两个节点之间的双向的数据通道 。

(3)WebRTC Native C++ API

本地C++ API层,使浏览器厂商容易实现WebRTC标准的Web API,抽象地对数字信号过程进行处理。

(4)Transport / Session

传输/会话层

会话层组件采用了libjingle库的部分组件实现,无须使用xmpp/jingle协议

a. RTP Stack协议栈

Real Time Protocol

b. STUN/ICE

可以通过STUN和ICE组件来建立不同类型网络间的呼叫连接。

c. Session Management

一个抽象的会话层,提供会话建立和管理功能。该层协议留给应用开发者自定义实现。

重要API

WebRTC原生APIs文件是基于WebRTC规格书撰写而成,这些API可分成Network Stream API、 RTCPeerConnection、Peer-to-peer Data API三类。

Network Stream API

  • MediaStream:MediaStream用来表示一个媒体数据流。
  • MediaStreamTrack在浏览器中表示一个媒体源。

RTCPeerConnection

  • RTCPeerConnection:一个RTCPeerConnection对象允许用户在两个浏览器之间直接通讯。
  • RTCIceCandidate:表示一个ICE协议的候选者。
  • RTCIceServer:表示一个ICE Server。

Peer-to-peer Data API

  • DataChannel:数据通道(DataChannel)接口表示一个在两个节点之间的双向的数据通道。

WebRTC协议介绍

ICE

发送对等方能够用于通信的方法。

ICE 提供了一个框架,通信对等方可以通过该框架发现和通信其公共 IP 地址,以便其他对等方可以访问它。

STUN

用于 NAT (STUN) 的会话遍历实用程序 是一种协议,用于发现您的公共地址并确定路由器中会阻止与对等方直接连接的任何限制。

客户端将向 Internet 上的 STUN 服务器发送请求,该服务器将回复客户端的公共地址以及客户端是否可通过路由器的 NAT 访问。

WebRTC简介

  • STUN 是一种通信协议工具,用于检测和遍历位于两个通信端点之间的路径中的网络地址转换器
  • STUN 消息在用户数据报协议(UDP) 数据包中发送。由于 UDP 不提供可靠的传输,可靠性是通过应用程序控制的 STUN 请求的重传来实现的
  • STUN 与三种类型的 NAT 配合使用:全锥 NAT、受限锥 NAT和端口受限锥 NAT。在受限锥或端口受限锥 NAT 的情况下,客户端必须先向端点发送数据包,然后 NAT 才会允许从端点到客户端的数据包。STUN 不适用于大公司网络中常见的对称 NAT(也称为双向 NAT)。由于STUN 服务器的IP 地址与端点的IP 地址不同,在对称 NAT 情况下,STUN 服务器的 NAT 映射将与端点不同。TURN使用对称 NAT 提供更好的结果。

NAT

网络地址转换 (NAT)用于为您的设备提供公共 IP 地址。路由器将有一个公共 IP 地址,连接到路由器的每个设备都将有一个私有 IP 地址。请求将从设备的私有 IP 转换为具有唯一端口的路由器的公共 IP。这样一来,您就不需要为每台设备分配一个唯一的公共 IP,但仍然可以在 Internet 上找到它。

网络地址转换( NAT ) 是一种通过在数据包通过流量路由设备传输时修改数据包IP 标头中的网络地址信息来将 IP地址空间映射到另一个IP地址空间的方法。

某些路由器会限制谁可以连接到网络上的设备。这可能意味着即使我们拥有 STUN 服务器找到的公共 IP 地址,也不是任何人都可以创建连接。在这种情况下,我们需要转向 TURN。

  • 一对一:最简单的 NAT 类型提供 IP 地址的一对一转换。
  • 一对多:大多数网络地址转换器将多个私有主机映射到一个公开的 IP 地址。一对多 NAT 的额外好处之一是它是IPv4 地址耗尽的实用解决方案。即使是大型网络也可以使用单个公共 IP 地址连接到 Internet

TURN

一些使用 NAT 的路由器采用称为“对称 NAT”的限制。这意味着路由器将只接受来自您之前连接过的对等方的连接。

使用中继绕过 NAT (TURN)旨在通过打开与 TURN 服务器的连接并通过该服务器中继所有信息来绕过对称 NAT 限制。您将创建与 TURN 服务器的连接,并告诉所有对等方将数据包发送到服务器,然后该服务器将转发给您。这显然会带来一些开销,因此只有在没有其他选择的情况下才会使用它。

WebRTC简介

SDP

会话描述协议 (SDP)是用于描述连接的多媒体内容(例如分辨率、格式、编解码器、加密等)的标准,以便在数据传输后双方可以相互理解。这实质上是描述内容的元数据,而不是媒体内容本身。

那么,从技术上讲,SDP 并不是真正的协议,而是一种用于描述设备之间共享媒体的连接的数据格式。

SDP 规范纯粹是一种会话描述格式。它旨在根据需要分布在不同的传输协议上,包括SAP、SIP和RTSP。SDP 甚至可以通过电子邮件或作为 HTTP 负载传输

SDP offer

由代理发送的 SDP 消息,代理生成会话描述以创建或修改会话。它描述所需媒体通信的各个方面。

SDP answer

应答者响应从提议人收到的提议而发送的 SDP 消息。应答指出了已接受的各个方面。例如,提议中的所有音频和视频流是否都被接受。

STUN、TURN 和 ICE 如何协同工作

让我们来看看两个对等方 A 和 B 的情况,它们都使用 WebRTC 对等双向媒体流式传输(例如,视频聊天应用程序)。当 A 想打电话给 B 时会发生什么?

要连接到 B 的应用程序,A 的应用程序必须生成 SDP 提议。SDP 提议包含有关 A 的应用程序要建立的会话的信息,包括要使用的编解码器、这是音频会话还是视频会话等。它还包含 ICE 候选项列表,这些候选项是 B 的应用程序可以尝试用来连接到 A 的 IP 和端口对。

要构建 ICE 候选项列表,A 的应用程序向 STUN 服务器发出一系列请求。服务器返回发起请求的公有 IP 地址和端口对。A 的应用程序将每个对添加到 ICE 候选项列表中,换句话说,它收集 ICE 候选项。一旦 A 的应用程序完成收集 ICE 候选项,它可以返回 SDP。

接下来,A 的应用程序必须通过这些应用程序用于通信的信令通道将 SDP 传递给 B 的应用程序。WebRTC 标准中未指定用于此交换的传输协议。它可以通过 HTTPS、安全 WebSocket 或任何其他通信协议执行。

现在,B 的应用程序必须生成 SDP 应答。B 的应用程序遵循 A 在上一步中使用的相同步骤:收集 ICE 候选项等。然后,B 的应用程序需要将此 SDP 应答返回给 A 的应用程序。

晚于A 和 B 交换 SDP,然后执行一系列连接性检查。每个应用程序中的 ICE 算法从它在另一方的 SDP 中收到的列表中获取候选项 IP/端口对,并向其发送 STUN 请求。如果从另一个应用程序返回响应,发起方应用程序会认为检查成功,并将该 IP/端口对标记为有效的 ICE 候选项。

在所有 IP/端口对上完成连接性检查后,应用程序协商并决定使用剩余的有效对之一。当选择一个对时,媒体开始在应用程序之间流动。

如果其中一个应用程序找不到通过了连接性检查的 IP/端口对,它们将向 TURN 服务器发出 STUN 请求以获取媒体中继地址。中继地址是一种公有 IP 地址和端口,用于将接收的数据包转发到应用程序或从应用程序中转发收到的数据包,以设置中继地址。然后,将该中继地址添加到候选项列表中,并通过信令通道进行交换。

这里对WebRTC整体做一个总结备忘。

如果你觉得文章还不错,可以给个”三连“,文章同步到以下个人微信公众号[加班猿]

我是hackett,我们下期见

参考文档:

WebRTC

WebRTC协议介绍

免责声明:本站所有文章内容,图片,视频等均是来源于用户投稿和互联网及文摘转载整编而成,不代表本站观点,不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益,请在线联系站长,一经查实,本站将立刻删除。 本文来自网络,若有侵权,请联系删除,如若转载,请注明出处:https://yundeesoft.com/32216.html

(0)

相关推荐

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注

关注微信