WebRTC 简介（一）
1：支持的浏览器和平台
| Chrome |
Firefox |
Opera |
Safari |
Android |
iOS |
|
| Latest ✔ |
Latest ✔ |
Latest ✔ |
11+ ✔ |
Latest ✔ |
11+ ✔ |
2：WebRTC （Web Real-Time Communications）
WebRTC 是一项实时通讯技术，它允许网络应用或者站点，在不借助中间媒介的情况下，建立浏览器之间点对点（Peer-to-Peer）的连接，实现视频流和（或）音频流或者其他任意数据的传输。WebRTC包含的这些标准使用户在无需安装任何插件或者第三方的软件的情况下，创建点对点（Peer-to-Peer）的数据分享和电话会议成为可能。
3：WebRTC 内部结构
架构图颜色标识说明：
- 紫色部分是Web开发者API层
- 蓝色实线部分是面向浏览器厂商的API层
- 蓝色虚线部分浏览器厂商可以自定义实现
WebRTC有三个模块：
- Voice Engine（音频引擎）
(1):Voice Engine包含iSAC/iLBC Codec（音频编解码器，前者是针对宽带和超宽带，后者是针对窄带）
(2):NetEQ for voice（处理网络抖动和语音包丢失）
(3):Echo Canceler（回声消除器）/ Noise Reduction（噪声抑制）
- Video Engine（视频引擎）
(1):VP8 Codec（视频图像编解码器）
(2):Video jitter buffer（视频抖动缓冲器，处理视频抖动和视频信息包丢失）
(3):Image enhancements（图像质量增强）
- Transport（传输/会话层）
(1):SRTP（安全的实时传输协议，用以音视频流传输）
(2):Multiplexing（多路复用）
(3):P2P，STUN+TURN+ICE（用于NAT网络和防火墙穿越的）
(4):除此之外，安全传输可能还会用到DTLS（数据报安全传输），用于加密传输和密钥协商
(5):整个WebRTC通信是基于UDP的
4：WebRTC 的核心组件
- 音视频引擎：OPUS、VP8 / VP9、H264
- 传输层协议：底层传输协议为 UDP
- 媒体协议：SRTP / SRTCP
- 数据协议：DTLS / SCTP
- P2P 内网穿透：STUN / TURN / ICE / Trickle ICE
- 信令与 SDP 协商：HTTP / WebSocket / SIP、 Offer Answer 模型
5：WebRTC 音频和视频引擎
- 最底层是硬件设备，上面是音频捕获模块和视频捕获模块
- 中间部分为音视频引擎。音频引擎负责音频采集和传输，具有降噪、回声消除等功能。视频引擎负责网络抖动优化，互联网传输编解码优化
- 在音视频引擎之上是 一套 C++ API，在 C++ 的 API 之上是提供给浏览器的Javascript API
VoiceEngine
音频引擎是包含一系列音频多媒体处理的框架。VoiceEngine是WebRTC极具价值的技术之一，是Google收购GIPS公司后开源的。在VoIP上，技术业界领先。
(1)：Opus：支持从6 kbit/s到510 kbit/s的恒定和可变比特率编码，帧大小从2.5 ms到60 ms，各种采样率从8 kHz（4 kHz带宽）到48 kHz（20 kHz带宽，可复制人类听觉系统的整个听力范围）。由IETF RFC 6176定义。
(2)：NetEQ模块是Webrtc语音引擎中的核心模块 ，一种动态抖动缓冲和错误隐藏算法，用于隐藏网络抖动和数据包丢失的负面影响。保持尽可能低的延迟，同时保持最高的语音质量。
VideoEngine
WebRTC视频处理引擎。VideoEngine是包含一系列视频处理的整体框架，从摄像头采集视频到视频信息网络传输再到视频显示整个完整过程的解决方案。
VP8 视频图像编解码器，是WebRTC视频引擎的默认的编解码器
VP8适合实时通信应用场景，因为它主要是针对低延时而设计的编解码器。
6：WebRTC 协议栈
- WebRTC 核心的协议都是在右侧基于 UDP 基础上搭建起来的
- 其中，ICE、STUN、TURN 用于内网穿透, 解决了获取与绑定外网映射地址，以及 keep alive 机制
- DTLS 用于对传输内容进行加密，可以看做是 UDP 版的 TLS。由于 WebRTC 对安全比较重视，这一层是必须的。所有WebRTC组件都必须加密，并且其JavaScript API只能用于安全源（HTTPS或本地主机）。信令机制并不是由WebRTC标准定义的，所以您必须确保使用安全协议。
- SRTP 与 SRTCP 是对媒体数据的封装与传输控制协议
- SCTP 是流控制传输协议，提供类似 TCP 的特性，SCTP 可以基于 UDP 上构建，在 WebRTC 里是在 DTLS 协议之上
- RTCPeerConnection 用来建立和维护端到端连接，并提供高效的音视频流传输
- RTCDataChannel 用来支持端到端的任意二进制数据传输
- WebRTC 协议栈解释
- ICE：互动式连接建立（RFC 5245）
- STUN：用于NAT的会话遍历实用程序（RFC 5389）
- TURN：在NAT周围使用继电器进行遍历（RFC 5766）
- SDP：会话描述协议（RFC 4566）
- DTLS：数据报传输层安全性（RFC 6347）
- SCTP：流控制传输协议（RFC 4960）
- SRTP：安全实时传输协议（RFC 3711）
1.原理
webRTC 连接建立流程
1、彼此要了解对方支持的媒体格式、支持的最大分辨率等媒体信息
比如：peerA端可支持MPEG-1/2、H264多种编码格式，而peerB端支持MPEG-4、H264，要保证二端都正确的编解码，最简单的办法就是取它们的交集H264
就象2个不同国家的人交流，1个只会讲英文、中文，另1个只会讲德语、英文，他俩肯定要能相互正常沟通，肯定会用双方都懂的英文来交流一样。
注：有一个专门的协议 ，称为Session Description Protocol (SDP)，可用于描述上述这类信息，在webrtc中，参与视频通讯的双方必须先交换SDP信息，这样双方才能知根知底，而交换SDP的过程，也称为"媒体协商"。
2、彼此要了解对方的网络情况，这样才有可能找到一条相互通讯的链路
类似的道理，在复杂的网络环境中，要建立二个端的连接，得有一条双方都能访问的链路。
如上图，peerA端具体有公网ip以及192网段的内网环境，而peerB没有公网，只有192、198二个内网地址，从图中可知，它俩可以使用公用的192网段来通讯。webrtc通讯过程中，这些网络相关的信息，也得相互交换，找出共同的交集，这个过程也称为“网络协商”。
顺着这个思路再琢磨一下，刚开始前，这2个端还没建立连接，既然连都没连上，又如何交换“媒体信息”、“网络信息”?
这时候就该所谓的信令服务器signal server出场了：
如上图，2个浏览器端的上层，可以抽象出一层信令服务器（可以是1台或多台，看实际应用的情况，如果2端的浏览器都能访问某个公共的网络环境，比如公网，可以让它们都连到这台公用的信令服务器上；如果没有公共的网络环境，可以在2端各搭一组服务器，即signal serverA、signal serverB，但是这二组信令服务器之间要能互通），借助信令服务器，就可以实现上面提到的SDP信息及网络信息交换。
交换SDP的过程，大致如上图：
1、Amy(1个假想的人名)，把自身的SDP信息，通过setLocalDescription方法保存起来，然后通过offer方法，发给信令服务器。
2、信息服务器把Amy的SDP向前传递到另1端的Bob(另1个假想的人名)，Bob会先调用setRemoteDescripition把Amy的SDP保存下来。
3、然后Bob调用setLocalDescription方法保存自己的SDP，然后再通过answer方法，把自己的SDP通过信令服务器发给Amy
4、Amy收到Bob的SDP后，调用setRemoteDescription保存起来，这样双方就完成了SDP交换，然后找出其中的交集，如果能达成一致，就可以建立p2p连接，开始通讯了。
但是现实往往是残酷的，在中国的网络环境中，据一些统计数据显示，至少1半的网络是无法直接穿透打通的(我个人认为根本原因是：IP4地址资源在互联网发展早期绝大多数都被国外占用了，轮到中国这些发展中国家使用时IP地址严重不足，所以大多数电脑都不具备公网ip，只能通过路由器、交换机做NAT转换，而相当一部分NAT是对称型的，基本上没法空透），这种情况下只能借助turn服务器中转。
WebRTC项目是开源的，我们可以借助WebRTC源码快速构建自己的音视频对聊功能。无论是使用前端JS的WebRTC API接口，还是在WebRTC源码上构建自己的对聊框架，都需要遵循以下执行流程：
WebRTC并不提供Stun服务器和Signal服务器，服务器端需要自己实现。Stun服务器可以用google提供的实现stun协议的测试服务器（stun:stun.l.google.com:19302），Signal服务器则完全需要自己实现了，它需要在ClientA和ClientB之间传送彼此的SDP信息和candidate信息，ClientA和ClientB通过这些信息建立P2P连接来传送音视频数据