WebRTC的相关内容

最新推荐文章于 2025-10-13 16:49:28 发布

原创最新推荐文章于 2025-10-13 16:49:28 发布 · 202 阅读

0 ·

CC 4.0 BY-SA版权

WebRTC 专栏收录该内容

4 篇文章

订阅专栏

本文详细介绍了WebRTC的会话流程，包括通过WebSocket的WSS进行会话描述协议SDP的交换，以及ICE框架的STUN和TURN服务器在NAT穿越中的作用。还探讨了WebRTC的点对点连接，如Mesh、SFU和MCU三种不同的分布式连接拓扑架构及其优缺点。

一 WebRTC会话流程

当浏览器A，B因为应用中的某种需要，要建立WebRTC在两个浏览器之间的直接连接，当A开始联系B时，首先通过WebSocket的WSS（通过https协议时）向信令服务器发送一个会话描述协议，信令服务器做中介，介绍两个互不相识的人认识。A发过来的是offer，信令服务器将这个会话描述协议发送到浏览器B，B收到会话描述协议之后回应一个answer，信令服务器再将其发送到A浏览器。交换完成会话描述协议后，两个终端之间开始尝试通过ICE候选字进行打洞，如果NAT类型符合要求可以成功就开始协商秘，到这里就可以进行一个安全的媒体数据会话了，这个会话流程如图1所示。

图1 WebRTC会话流程

二 WebRTC架构

WebRTC的架构[21]主要由以下几部分组成：

Web App：开发者通过编码完成的应用，可以在其内部提供基于WebRTC的某些服务。
Web API：面向开发者的WebRTC标准API接口。开发者通过API可以方便快捷的开发出自己想要的应用功能。
PeerConnection：面向浏览器厂商本地API，可以通过该API从底向上的实现面向开发者的Web API。
Session：传输层包括数据通道。
Voice Engine/Vudie Engine：包含所有的音视频媒体流处理相关内容。
NetWork I/O / Video Capture / Audio Capture/Render:网络I/O模块即音视频抓捕模块。

WebRTC架构图如图2所示。

图2 WebRTC架构

三点对点连接

在建立连接之前，需交换会话描述协议（Session Description Protocol,简称SDP）和ICE候选（ICE Candidate）

3.1 会话描述协议SDP

SDP是一种会话描述协议，包含了一系列信息包括会话使用的媒体种类，双方ip地址和端口,带宽，会话属性等。因为其本质上是一个字符串，相互交换时需要采用Offer/Answer形式。这个过程如图3所示。

图3 SDP交换示意图

这个过程描述如下

首先请求方方通过new PeerConnection()建立PeerConnection。
请求方生成SDP（offer），通过setlocalDescription（）方法设置为localDescription，并通过信令服务器将offer发送给应答方。
应答方收到SDP（offer),发现并没有与之对应的点连接,新建peerConnection,并通过setRemoteDescription（方法）设置remoteDescription为收到的SDP（offer）。
应答方生成SDP（answer）,设置为localDescription,并经过信令服务器发送给应答方。
应答方收到SDP（answer）,设置为remoteDescription。
SDP交换结束，WebRTC连接完成[23]。

3.2 ICE框架

ICE是一种通过STUN和TURN服务器实现NAT[17](防火墙穿越)的框架，可以实现P2P直接通信，使用STUN服务器实现突破NAT的P2P通信，使用TURN中继服务器实现突破防火墙的中继通信。交换过程如图4所示。

图4 ICE框架

1) 双方在建立连接后，当网络候选者可用时，会触发icecandidate事件。

2）在onicecandidate事件处理程序中将candidate通过信令服务器发送给对方。

3）双方在接受到彼此的candidate后，通过addIceCandidate方法将对方的candidate加入到PeerConnection实例中[24]。

图5 STUN工作简图

在上述过程中，采用了ICE，这个框架在STUN和TURN服务器的基础上完成网络穿透。如图5所示，A、B两终端通过STUN服务器得知对方公网IP和端口，并得知NAT类型。

当A处于公网或Full Cone NAT下，两客户端直接通信。当A处于Restrict ConeNAT或者Port Restrict NAT下，TURN在STUN拿到A，B终端的公网地址和端口之后，直接在两终端间打洞，即向两终端之间发送信息，为NAT留下信息，使它们之间可以相互通讯，此过程如图6所示。

图6 TURN工作简图

四终端之间的分布式连接拓扑架构

当使用WebRTC做1VN或者NVN的功能时，根据终端之间的媒体流拓扑结构，大体上可以分为Mesh、SFU和MCU结构[26]，其具体介绍如下。

4.1 Mesh结构（P2P结构）

该结构中任意两个终端之间都要建立点对点的连接通道，如图7所示。该结构的长处是去核心化，服务器端没有太大压力，只要实现信令服务交换即可。短处随着参与终端的增多，链接数量阶乘式的增长，对终端编解码能力要求较高，对宽带的依赖更严重。当呼叫方很少时，可以考虑该模式的解决方案。

图7 Mesh结构示意图

4.2 SFU结构

所有终端都与服务器建立连接而不是终端之间连接，数据通过服务器交互，服务器转发到需要接收该数据流的所有终端，这个过程中服务器只做数据包检测及重发，不涉及编码和解码的工作，如图8所示。长处是对终端编码能力要求不高和对带宽不用太过依赖，同时服务器可以按要求定制性发送相关内容。缺点是服务器需要处理所有终端的连接和所有上传终端的数据并转发给所有下载终端，给服务器本身带来了巨大挑战。