WebRTC基础知识详解
前言
WebRTC近几年发展尤其迅速，例如比较火的直播带货，疫情期间的线上直播课，远程视频会议，实时人脸识别等等，都有它的身影。基于此，很多小伙伴想学WebRTC知识，但网上资料大多比较零散，讨论的方向也不一样，为了给想学习WebRTC的读者一份系统的学习资料，遂有了本文。看完该篇文章你就会对webrtc有一个清晰的认识。
WebRTC简介
WebRTC（Web Real-Time Communication）是Google开源的一个互联网浏览器间实时通信的平台，同时，它提供了视频会议的核心技术，包括音视频的采集、编解码、网络实时传输、显示等功能，并且还支持跨平台：windows, linux, mac, android。WebRTC是目前音视频通话主流开发框架，在不涉及源码修改、功能扩展、模块抽取的情况下，使用webrtc仅需要少量代码即可实现常规的1对1音视频通话功能。
WebRTC框架介绍
WebRTC框架图
（1）紫色部分是Web应用开发者API层
（2）蓝色实线部分是面向浏览器厂商的API层
（3）蓝色虚线部分浏览器厂商可以自定义实现
注：作为开发者我们重点关注紫色部分Web API层，并且需要重点掌握1）MediaStream类：该类通过getUserMedia接口获取，允许访问输入设备如摄像头来获取媒体流。2）RTCPeerConnection类：允许用户在两个浏览器间直接通讯。
Your Web App
Web开发者开发的程序，Web开发者可以基于集成WebRTC的浏览器提供的web API开发基于视频、音频的实时通信应用。
Web API
面向第三方开发者的WebRTC标准API（Javascript），使开发者能够容易地开发出类似于网络视频聊天的web应用。
WebRTC Native C++ API
本地C++ API层，使浏览器厂商容易实现WebRTC标准的Web API，抽象地对数字信号过程进行处理。
Transport / Session
传输/会话层。
VoiceEngine
音频引擎是包含一系列音频多媒体的处理框架。
VideoEngine
VideoEngine是包含一系列视频处理的整体框架，从摄像头采集视频到视频信息网络传输再到视频显示整个完整过程的解决方案。
WebRTC发展前景
WebRTC虽然介绍里说的是基于浏览器的通信平台，但它其实并不受限于传统互联网应用或浏览器的终端运行环境。无论终端运行环境是浏览器、桌面应用、移动设备（Android或iOS）还是IoT设备，只要IP能连接并且符合WebRTC规范就可以互相通信。这让智能终端上App的实时通信能力得到了极大的提升，同时也打开了许多对于实时交互性要求较高的应用场景的想象空间，比如前言里提到的远程视频会议，实时人脸识别等等都是其合适的应用领域。
1对1音视频通话基础
在讲解使用WebRTC进行音视频通话原理之前，我们需要先来了解几个在介绍音视频通话原理过程中会使用到的专业名词。
媒体协商（SDP:Session Description Protocol）
视频的编解码有多种方式，假设上图中Peer-A要与Peer-B进行通话，必须要保证两端都能正确的编解码，
那么我们就只能取它们的交集H264格式。在WebRTC中SDP就是用来描述上述这类信息的协议。参与音视频通信的双方必须先交换SDP信息，这种交换过程我们把它叫做“媒体协商”。
网络协商
同样Peer-A要与Peer-B进行音视频通话的话，除了需要媒体协商，还需要有一条双方都能访问的链路。图中peer-A具有公网ip以及192网段的内网环境，而peer-B没有公网环境，只有192、198二个内网地址，因此它们可以使用公用的192网段来通讯。我们把参与音视频通信过程中交换的网络相关信息的过程叫做“网络协商”。
信令服务器
媒体协商与网络协商都是基于双方建立连接后，那么双方如何建立连接呢？这时候就用到信令服务器（Signal Server）了，一般搭在公网或者两端都可以访问到的局域网中。
图中2个浏览器端的上层，可以抽象出一层信令服务器（可以是1台或多台），如果2端的浏览器都能访问某个公共的网络环境，比如公网，那么就可以让它们都连到这台公用的信令服务器上进行点对点连接。如下图
如果没有公共的网络环境，那么就需要2端各搭一组服务器signal serverA和signal serverB，然后这两组服务器借助信令服务器实现互通，就可以实现上面提到的SDP信息及网络信息的交换了。如下图
网络地址转换（NAT:Network Address Translation）
我们在上图中的实际情况（无法访问公网）下进行网络通信时，需要通过NAT进行网络穿透，来实现两台局域网设备连接到公网的信令服务器上。转换原理如下图
在NAT进行转换时，需要使用到STUN和TURN。
STUN（Simple Traversal of UDP Through NATs）
简单的用UDP穿透NAT，是个轻量级的协议，是基于UDP的完整的穿透NAT的解决方案。它的作用是使位于NAT后的客户端找出自己的公网IP地址与端口号，这些信息被用来在两个同时处于NAT路由器之后的主机之间创建UDP通信。
总结来说STUN的作用就是给无法在公网环境下的视频通话设备分配公网IP，这样两台设备就可以在公网IP中进行通话了。STUN工作原理如下图
STUN并不是每次都能成功的为需要NAT通话的设备分配IP地址，而TURN可以解决这个问题。
TURN（Traversal Using Relays around NAT）
使用中继穿透NAT，是STUN的一个扩展。如果STUN不能成功的为需要NAT通话的设备分配IP地址，就需要公网的服务器作为一个中继，对客户端的数据进行转发，这个转发的协议就是TURN。TURN工作原理如下图
使用这种方式在进行音视频通话时，带宽由服务器来承担，本地带宽压力较小。
ICE（Interactive Connectivity Establishment）
翻译为互动式连接建立，ICE不是一种协议，它是一个框架，整合了STUN和TURN，使各种NAT穿透技术可以实现统一。当穿越网络时，ICE会先尝试STUN，查出自己位于哪种类型的NAT之后以及NAT为某一个本地端口所绑定的Internet端端口从而建立UDP连接，如果失败了ICE就会再尝试TCP（先尝试HTTP，再尝试HTTPS），如果仍然失败就使用中继的TURN服务器。因此，ICE可以实现在未知网络拓扑结构中实现的设备互连。另外，由于该技术不需要为VoIP流量手动打开防火墙，所以也不会产生潜在的安全隐患。
1对1音视频通话实现原理
在看完1对1音视频通话基础后再来看通话实现原理就比较简单了。具体步骤如下：
1、双方先调用getUserMedia打开本机摄像头。
2、向信令服务器发送加入房间请求。
3、信令服务器通知本人加入成功，同时向其它人广播加入消息。
4、二端开始创建peerConnection连接。
5、peerA端创建offer，同时将SDP保存到本机（setLocalDescription），并通过信令服务器传递到peerB。
6、peerB在setLocalDescription后，会异步触发“候选网络链路”收集，大致是通过Stun确定自己所有的NAT映射出口，如果Stun返回NAT是“对称型”的，基本上就没法穿透了，会再通过Turn拿到中继reply地址，并通过信令服务器，将网络候选链路信息发到peerA，即开始网络协商。
7、peerA收到的peerB的SDP后，开始回应（createAnswer），仍然通过信令服务器，将SDP发送到peerB
8、同时peerA也会开始网络候选链路的收集，并将自己的网络信息，通过信令服务器，发到peerB。
这样peerA, peerB就相互交换了媒体信息及网络信息，如果能达到一致（找到交集），就可以开始通讯了。
结语
笔者尽量对WebRTC基础技术要点做了比较详细的介绍，一些相关的技术细节需要读者自己做进一步的学习。另外由于本文旨在讲解webrtc基础，并没有开发代码与技术细节。有些技术观点也不一定非常准确，希望读者谅解。如果有问题欢迎留言交流。
参考：
https://baike.baidu.com/item/WebRTC
https://www.cnblogs.com/yjmyzz/p/webrtc-basic.html