WebRTC入门-doola

WebRTC (Web Real-Time Communications) 是一项实时通讯技术，它允许网络应用或者站点，在不借助中间媒介的情况下，建立浏览器之间点对点（Peer-to-Peer）的连接，实现视频流和（或）音频流或者其他任意数据的传输。

通讯流程的建立

WebRTC 通讯过程不需要中间媒介（P2P）

1. 如果需要通讯的两台设备的网络环境是局域网，该如何建立连接？

可以通过内网映射（NAT）的方式解决

2. 如果通讯的两台设备建立连接后，无法解析对方的音视频格式该如何？

在连接之前先互相确定好双方支持的格式（一方支持 H264 和 VP8，另一方支持 H264 和 VP9，那么就可以在连接之前确定好双方的编解码格式是 H264 格式，此格式是双方都支持的）。

通信流程：

媒体协商（SDP）：两个用户在连接之前相互确定并交换双方支持的音视频格式的过程就是媒体协商。SDP 是描述信息的一种格式，其格式组成可自行查找了解；
网络协商（candidate）：两个用户在 NAT 后交换各自的网络信息的过程就是网络协商。candidate 也是一种描述信息的一种格式，其格式组成可自行查找了解。
信令服务器：传递双方信息的服务器就是信令服务器，此服务其实就是 web 服务，其职责也不止传输媒体格式以及网络信息，还可传输业务信息。其传输信息的协议可是 HTTP 或 Socket 等。
STUN：STUN 是一种网络协议，其目的是进行 NAT 穿越。内网进行 NAT 后进行 P2P 连接会有两个问题：

由于 NAT 的安全机制，NAT 会过滤掉一些外网主动发送到内网的报文，而 P2P 恰恰就需要主动发起访问；

NAT 后，会得到一个 IP + 端口的地址，而在进行 P2P 连接时并不知道这个地址，难道要用户手动填写吗。

所以 STUN 的作用就是能够检测网络中是否存在 NAT 设备，有就可以获取到 NAT 分配的 IP + 端口地址，然后建立一条可穿越 NAT 的 P2P 连接（这一过程就是打洞）。

TURN：TURN 是 STUN 协议的扩展协议，其目的是如果 STUN 在无法打通的情况下，能够正常进行连接，其原理是通过一个中继服务器进行数据转发，此服务器需要拥有独立的公网 IP。

TURN 很明显的一个问题就是其转发数据所产生的带宽费用需要由自己承担！

ICE：ICE（Interactive Connectivity Establishment），是一种用于实现网络连接的技术框架，用于在对等连接（如实时通信、P2P 文件共享等）中解决 NAT（Network Address Translation）和防火墙等网络障碍的问题。 ICE 是一种框架，可以通过使用多种技术（如 STUN、TURN、NAT 透明性检测等）来搜索可用的网络路径，并选择最优的路径建立连接，从而解决了 NAT 和防火墙等网络障碍的问题。 ICE 框架包含了以下几个步骤：

用户 A 和用户 B 都需要先连接到信令服务器；
用户 A 和用户 B 都创建一个 PeerConnection（此时 WebRTC 会自动向 STUN/TURN 服务获取 candidate 信息, WebRTC 内置了 ICE）；
用户 A 将本地音视频流添加到 PeerConnection 中（通过 getUserMedia 获取音视频流）；
用户 A 作为发起方创建 offer（offer 中包含了 SDP 信息），并将获取的本地 SDP 信息添加到 PeerConnection 中（setLocalDescription），然后再通过信令服务器转发给用户 B;
用户 B 接收到用户 A 的 offer 后，将其添加到 PeerConnection 中（setRemoteDescription）；
用户 B 将本地音视频流添加到 PeerConnection 中（通过 getUserMedia 获取音视频流）；
用户 B 创建一个 Answer，并添加到 PeerConnection 中（setLocalDescription）;
用户 B 通过信令服务器将 answer 转发给用户 A；
用户 A 接收到 answer 后将其添加到 PeerConnection 中；
用户 A 和用户 B 都接收到了 candidate 信息后，都通过信令服务器转发给对方并添加到 PeerConnection 中（addIceCandidate）；
媒体信息和网络信息交换完毕后，WebRTC 开始尝试建立 P2P 连接；
建立成功后，双方就可以通过 onTrack 获取数据并渲染到页面上。

上图是以用户 A 为发起方，用户 B 为接收方。

MCU:MCU表示多点控制单元。由使用peer建立连接变为只需要连接到中心服务器，中心服务器反过来发送信息到其它peers，并且对其它peers也是这样。

中心服务器，接收媒体服务器的名字，并掌控处理被发送到peers的媒体流和数据。这个过程对于不同的实现方案有所不同，但是可以简化为五步：

MCU设备从peers接收媒体流，对其进行解码并创建一个布局，之后它对其进行编码最终发送到peers。现在每一个peer只需要在流中发送和接收。这个过程如下图所示：

通过使用MCU，我们避免了Mesh中的所有问题。即使用户数量增加，这也不会对用户处理能力和带宽产生影响，因为每一个用户只连接到一个peer，媒体服务器。

使用了这种方案，你需要将一台服务器放在中间，一个非常昂贵的服务器，因为它将要掌控处理媒体信息。这个过程消耗大量CPU因为它必须对媒体编解码。

与MCU不同，SFU不对音视频进行混流，收到某个终端共享的音视频流后，直接将该音视频流转发给房间内的其他终端。实际上是一个音视频路由转发器。

上图四个参与者，如果每个音视频流占1M带宽，那每个参与者需要把音视频流发给SFU服务器，需要1M上行带宽，同时从SFU服务器获取其他三个参与者音视频流，需要3M下行带宽，即每个参与者总共需要4M上下行带宽。

缺点：