1. WebRTC的实现原理

WebRTC的音视频通信时基于P2P的

1.1 P2P模式

(1) 传统的连接模式
传统的音视频通话过程中，其模式是以服务器为中介进行数据的转发实现音视频通话。

• 类似http协议：客户端⇋服务端（这里服务端返回的箭头仅仅代表返回请求数据）。
• 在进行客户端A和客户端B的即时通讯时，进行文字、图片、录音等传输的时候：客户端A⇨服务器⇨客户端B。

(2) P2P连接模式
点对点的连接恰恰数据通道一旦形成，中间是不经过服务端的，数据直接从一个客户端流向另一个客户端：

• 客户端A⇋客户端B … 客户端A⇋客户端C …（可以无数个客户端之间互联）

WebRTC是基于P2P模式实现的，但是这并不代表WebRTC不需要服务器的参与。

1.2 WebRTC服务器与信令

WebRTC提供了浏览器到浏览器（点对点，P2P）之间的通信，但并不意味着WebRTC不需要服务器。基于WebRTC的双方要建立通信连接，至少有两个过程必须要用到服务器：

• 浏览器之间交换建立通信的元数据（信令）必须通过服务器。
• 为了穿越NAT和防火墙。

除此之外还有一些基于服务器的扩展性业务。

(1) 信令的交互
我们在A和B需要建立P2P连接的时候，至少要服务器来协调和控制连接建立。而连接断开的时候，也需要服务器来告知另一端P2P连接已断开。这些我们用来控制连接的状态的数据称之为信令，而这个与服务端连接的通道，对于WebRTC而言就是信令通道。

上图signalling就是往服务端发送信令，然后底层调用WebRTC，WebRTC通过服务端得到的信令，得知通信对方的基本信息，从而实现虚线部分Media通信连接。

当然信令能做的事还有很多，这里大概列了一下：

• 用来控制通信开启或者关闭的连接控制消息
• 发生错误时用来彼此告知的消息
• 媒体流元数据，比如像解码器、解码器的配置、带宽、媒体类型等等
• 用来建立安全连接的关键数据
• 外界所看到的的网络上的数据，比如IP地址、端口等

在建立连接之前，客户端之间显然没有办法传递数据。所以我们需要通过服务器的中转，在客户端之间传递这些数据，然后建立客户端之间的点对点连接。但是WebRTC API中并没有实现这些，这些就需要实际需求来实现。