WebRTC简介

WebRTC

1.什么是WebRTC

都需要通过服务器进行中转。比如现在有两个客户端—甲、乙，他俩想要进行通信，首先需要甲和服务器、乙和服务器之间建立信道。甲给乙发送消息时，甲先将消息发送到服务器上，服务器对甲的消息进行中转，发送到乙处，反过来也是一样。这样甲与乙之间的一次消息要通过两段信道，通信的效率同时受制于这两段信道的带宽。同时这样的信道并不适合数据流的传输，如何建立浏览器之间的点对点传输，一直困扰着开发者。因此WebRTC应运而生。
WebRTC是一个开源项目，旨在使得浏览器能为实时通信（RTC）提供简单的JavaScript接口。说的简单明了一点就是让浏览器提供JS的即时通信接口。这个接口所创立的信道并不是像WebSocket一样，打通一个浏览器与WebSocket服务器之间的通信，而是通过一系列的信令，建立一个浏览器与浏览器之间（-to-peer）的信道，这个信道可以发送任何数据，而不需要经过服务器。并且WebRTC通过实现MediaStream，通过浏览器调用设备的摄像头、话筒，使得浏览器之间可以传递音频和视频。

2.使用WebRTC能做什么？
能用于音视频实时互动
能用于游戏、即时通讯、文件传输等等
它是一个百宝箱，传输、音视频处理（回音消除、降噪等）

3.学习WebRTC的过程中我们能掌握什么？
音视频设备的访问与管理
音视频数据的采集
数据的传输与实时互动
WebRTC的整体工作机制

4.学习WebRTC思路
(1). 学习NodeJS的基本使用，尝试搭建一个简单的Web服务器并实现简单的HTTP服务。

(2). 学习JavaScript，了解并掌握其基本的使用方法，为后续开发及完善Web服务做技术铺垫。

(3). 了解音视频设备相关的Web API，尝试使用MediaDevices实现音视频设备的访问，包括摄像头、麦克风及屏幕采集。

(4). 学习使用Socket.IO，尝试使用Socket.IO实现简单的聊天室，为后续开发WebRTC信令服务器做技术铺垫。

(5). 了解和学习使用SDP，并使用WebRTC的Web API实现本地的1v1视频互通。

(6). 搭建STUN/TURN服务器，使用ICE框架及Socket.IO实现WebRTC正式的1V1连麦

(7). 实现WebRTC的移动端开发，做到浏览器和手机客户端能进行连麦操作。

二、WebRTC 架构

整体架构分为应用层和核心层。应用层提供实现相关业务逻辑Api，核心层提供应用层需要的核心API。

其中核心层分为四层：

第一层为C++ API，其中最主要的是PeerConnection，这个接口需要重点学习和掌握。

第二层为Session层，为上下文管理层，应用里的音频和视频及非音视频的数据处理逻辑都可以在这层进行。

第三层为引擎和传输层，包括音频引擎和视频引擎，以及音视频的传输，这也是整个架构中最重要的一层。

第四层与硬件相关，包括音视频的采集和网络的IO。

注：WebRTC的核心层无视频的渲染，所有的渲染都需要应用层自行实现。

这里着重提一下第三层：

Voice Engine（音频引擎模块）：包含编码能力、音频缓冲Buff（防网络抖动）、回音消除（实时连麦关键点）。
Video Engine（视频引擎模块）：包含编码能力（如VP8）、视频缓冲、图像增强。
Transport（传输模块）：传输协议在底层使用UDP，上层使用的RTP（为安全起见增加SRTP），还有P2P机制，包括STUN、TURN 和 ICE。

目录结构分析
api：WebRTC 接口层。包括 DataChannel, MediaStream, SDP相关的接口。各浏览器都是通过该接口层调用的 WebRTC。

call：存放的是 WebRTC “呼叫（Call）” 相关逻辑层的代码。

audio：存放音频网络逻辑层相关的代码。音频数据逻辑上的发送，接收等代码。

video：存放视频逻辑层及视频引擎层的相关的代码。视频数据逻辑上的发送，接收等代码。

voice_engine：存放音频引擎代码。主要是控制音频的采集，处理，编解码的操作。

sdk：存放了 Android 和 IOS 层代码。如视频的采集，渲染代码都在这里。

pc：存放一些业务逻辑层的代码。如 channel, session等。

common_audio：存放一些音频的基本算法。包括环形队列，博立叶算法，滤波器等。

common_video：存放了视频算法相关的常用工具，如libyuv, sps/pps分析器，I420缓冲器等。

modules：这个目录是 WebRTC 代码中最重要的一个目录。里面包括了音视频的采集，处理，编解码器，混音等。

modules 目录下还包括以下几个子目录：

audio_coding : 音频编解码相关代码。

audio_conference_mixer : 会议混音相关代码。

audio_device : 音频采集与音频播放相关代码。

audio_mixer : 混音相关代码，这部分是后加的。

audio_processing : 音频前后处理的相关代码。

bitrate_controller : 码率控制相关代码。

congestion_controller : 流控相关的代码。

desktop_capture : 桌面采集相关的代码。

media_file : 播放媒体文件相关的代码。

pacing : 码率探测相关的代码。

remote_bitrate_estimator : 远端码率估算相关的代码。

rtp_rtcp : rtp/rtcp协议相关代码。

video_capture : 视频采集相关的代码。

video_coding : 视频编解码相关的代码。

video_processing : 视频前后处理相关的代码。

media：存放媒体相关的代码。

p2p：p2p相关的代码。

rtc_base：存放了一些基础代码。如线程，事件，socket等相关的代码。

rtc_tools：存放了一些工具代码。如视频帧比较，I420转RGB，视频帧分析。

stats：存放各种数据统计相关的类。

libjingle：网络库。

system_wrapper：与操作系统相关的代码，如 CPU特性，原子操作，读写锁，时钟等。

ICE
互动式连接建立（Interactive Connectivity Establishment）提供的是一种框架，使各种NAT穿透技术（STUN，TURN…）可以实现统一。该技术可以让客户端成功地穿透远程用户与网络之间可能存在的各类防火墙。

NAT
网路位址转换(Network Address Translation)可为你的装置提供公用IP位址。路由器具备公用IP位址，而连上路由器的所有装置则具备私有IP位址。接着针对请求，从装置的私有IP对应到路由器的公用IP与专属的通讯端口。如此一来，各个装置不需占用专属的公用IP，亦可在网路上被清楚识别。

STUN
NAT 的UDP简单穿越（Simple Traversal of UDP over NATs）是一种网络协议，它允许位于NAT（或多重NAT）后的客户端找出自己的公网地址，查出自己位于哪种类型的NAT之后以及NAT为某一个本地端口所绑定的Internet端端口。这些信息被用来在两个同时处于NAT路由器之后的主机之间建立UDP通信。

即使透过 STUN 服务器取得了公用 IP 位址，也不一定能建立连线。因为不同的NAT类型处理传入的UDP分组的方式是不同的。四种主要类型中有三种是可以使用STUN穿透：完全圆锥型NAT、受限圆锥型NAT和端口受限圆锥型NAT。但大型公司网络中经常采用的对称型 NAT（又称为双向NAT）则不能使用，这类路由器会透过 NAT 布署所谓的「Symmetric NAT」限制。也就是说，路由器只会接受你之前连线过的节点所建立的连线。这类网络就需要TURN技术。

TURN
中继NAT实现的穿透（Traversal Using Relays around NAT）就是透过TURN服务器开启连线并转送所有数据，进而绕过Symmetric NAT的限制。你可透过TURN服务器建立连线，再告知所有端点传送封包至该服务器，最后让服务器转送封包给你。这个方法更耗时且更占频宽，因此在没有其他替代方案时才会使用这个方法。

1.连接双方（Peer）通过第三方服务器来交换（Signalling）各自的SessionDescription数据。
2.连接双方（Peer）通过STUN协议从STUN Server那里获取到自己的NAT结构，子网IP和公网IP，端口，这里的IP和端口对我们称之为ICE Candidate。
3.连接双方（Peer）通过第三方服务器来交换（Signalling）各自ICE Candidates，如果连接双方在同一个NAT下那他们仅通过内网Candidate就能建立起连接，反之如果他们处于非对称型NAT下，就需要STUN Server识别出的公网Candidate进行通讯。
4.如果仅通过STUN Server发现的公网Candidate仍然无法建立连接，换句话说就是连接双方（Peer）中至少有一方处于对称NAT下，这就需要处于对称NAT下的客户端（Peer）去寻求TURN Server提供的转发服务，然后将转发形式的Candidate共享（Signalling）给对方（Peer）。
5.连接双方（Peer）向目标IP端口发送报文，通过SessionDescription中涉及的密钥以及期望传输的内容，建立起加密长连接。