WebRTC入门
WebRTC的历史
Web的最后一个主要挑战之一是通过语音和视频实现人与人之间的通信：实时通信，简称RTC。RTC在Web应用程序中应与在文本输入中输入文本一样自然。没有它，我们在创新和开发新的人们互动方式方面的能力将受到限制。
从历史上看，RTC一直是公司性的并且很复杂，需要昂贵的音频和视频技术才能在内部获得许可或开发。将RTC技术与现有内容，数据和服务集成在一起非常困难且耗时，尤其是在Web上。
Gmail视频聊天在2008年开始流行，2011年Google引入了环聊，该环聊使用Google Talk服务（与Gmail一样）。Google收购了GIPS，这是一家开发了RTC所需的许多组件的公司，例如编解码器和回声消除技术。Google开源了GIPS开发的技术，并与IETF和W3C的相关标准机构合作，以确保行业共识。2011年5月，爱立信构建了WebRTC的第一个实现。
WebRTC为实时，无插件的视频，音频和数据通信实施了开放标准。需求是真实的：
许多Web服务使用RTC，但需要下载，本机应用程序或插件。包括Skype，Facebook和Google Hangouts。
下载，安装和更新插件非常复杂，容易出错且令人讨厌。
插件很难部署，调试，故障排除，测试和维护，并且可能需要许可以及与复杂，昂贵的技术的集成。首先说服人们安装插件通常很困难！
WebRTC项目的指导原则是其API应该是开源的，免费的，标准化的，内置在Web浏览器中的，并且比现有技术更有效。
我们现在在哪？
WebRTC用于各种应用程序，例如WhatsApp，Facebook Messenger，appear.in和TokBox等平台。WebRTC也已与WebKitGTK +和Qt本机应用程序集成。
WebRTC实现了三个API：
*MediaStream（又名getUserMedia）
API在两个规范中定义：
Chrome，Safari，Firefox，Edge和Opera在移动设备和台式机上都支持这三种API。
getUserMedia：访问数据流，例如来自用户的相机和麦克风的数据流。
RTCPeerConnection：是WebRTC组件，用于处理对等点之间的流数据的稳定和高效的通信。音频或视频呼叫，具有用于加密和带宽管理的功能。
RTCDataChannel：除了音频和视频，WebRTC还支持其他类型数据的实时通信。RTCDataChannel API支持低延迟和高吞吐量的对等数据交换。通用数据的对等通信。
我的第一个WebRTC
WebRTC应用程序需要做几件事：
获取流音频，视频或其他数据。
获取诸如IP地址和端口之类的网络信息，并与其他WebRTC客户端（称为对等方）进行交换，以启用连接，即使通过NAT和防火墙也是如此。
协调信令通信以报告错误并启动或关闭会话。
交换有关媒体和客户端功能的信息，例如分辨率和编解码器。
交流流音频，视频或数据。
为了获取和传递流数据，WebRTC实现了以下API：
MediaStream：访问数据流，例如来自用户的相机和麦克风的数据流。
RTCPeerConnection：音频或视频呼叫，具有用于加密和带宽管理的功能。
RTCDataChannel：通用数据的对等通信。
信令：会话控制，网络和媒体信息
WebRTC使用RTCPeerConnection在浏览器（也称为对等设备）之间通信流数据，但还需要一种机制来协调通信并发送控制消息，该过程称为信令。WebRTC 未指定信令方法和协议：信令不是RTCPeerConnection API的一部分
相反，WebRTC应用程序开发人员可以选择他们喜欢的任何消息协议，例如SIP或XMPP，以及任何适当的双工（双向）通信通道。
信令用于交换三种类型的信息：
会话控制消息：初始化或关闭通信并报告错误。
网络配置：对于外界，我的计算机的IP地址和端口是什么？
媒体功能：我的浏览器及其要与之通信的浏览器可以处理哪些编解码器和分辨率？
在开始对等流传输之前，必须成功完成通过信令进行的信息交换。
1. 客户端通过信令服务器, 进行offer SDP 握手
SDP(Session Description Protocol)：描述建立音视频连接的一些属性，如音频的编码格式、视频的编码格式、是否接收/发送音视频等等SDP 是通过webrtc框架里面的PeerConnection所创建
2. 客户端通过信令服务器, 进行Candidate 握手
Candidate：主要包含了相关方的IP信息，包括自身局域网的ip、公网ip、turn服务器ip、stun服务器ip等Candidate 是通过webrtc框架里面的PeerConnection所创建
3 客户端在SDP 和Candidate握手成功后, 就建立起一个P2P端对端的链接, 视频流就能直接传输, 不需要经过服务器啦
1.Amy端通过 createOffer 生成 SDP 描述
2.Amy通过 setLocalDescription，设置本地的描述信息
3.Amy将 offer SDP 发送给用户Bob
4.用户Bob通过 setRemoteDescription，设置远端的描述信息
5.Bob用户通过 createAnswer 创建出自己的 SDP 描述
6.Bob用户通过 setLocalDescription，设置本地的描述信息
7.Bob用户将 anwser SDP 发送给主播Amy
8.Amy端通过 setRemoteDescription，设置远端的描述信息。
9.通过SDP握手后，两端之间就会建立起一个端对端的直接通讯通道。
由于我们所处的网络环境错综复杂，用户可能处在私有内网内，使用p2p传输时，将会遇到NAT以及防火墙等阻碍。这个时候我们就需要在SDP握手时，通过STUN/TURN/ICE相关NAT穿透技术来保障p2p链接的建立
RTCPeerConnection
RTCPeerConnection是WebRTC组件，用于处理对等点之间的流数据的稳定和高效的通信。
下面是WebRTC架构图，显示了RTCPeerConnection的角色。您会注意到，绿色部分很复杂！
从该图中可以理解的主要事情是RTCPeerConnection使Web开发人员免受潜在的各种复杂问题的困扰。WebRTC使用的编解码器和协议进行了大量工作，即使在不可靠的网络上也可以进行实时通信：
丢包隐藏 回声消除 带宽适应性 动态抖动缓冲 自动增益控制 降噪抑制 图像“清洁”。
RTCPeerConnection plus服务器
在现实世界中，WebRTC需要服务器（无论多么简单），因此可能发生以下情况：
* 用户彼此发现并交换“真实世界”的详细信息，例如姓名。
* WebRTC客户端应用程序（对等）交换网络信息。
* 对等方交换有关媒体的数据，例如视频格式和分辨率。
* WebRTC客户端应用程序遍历NAT网关和防火墙。
换句话说，WebRTC需要四种服务器端功能：
用户发现和交流。
发信号。
NAT /防火墙遍历。
对等通信失败时中继服务器。
NAT遍历，对等网络以及为用户发现和信令构建服务器应用程序的要求不在本文讨论范围之内。可以说ICE框架使用STUN协议及其扩展TURN来使RTCPeerConnection能够应对NAT穿越和其他网络问题。
ICE是用于连接对等方（例如两个视频聊天客户端）的框架。最初，ICE尝试通过UDP以尽可能短的延迟直接连接同级。在此过程中，STUN服务器只有一项任务：使NAT后的对等方能够找到其公共地址和端口。
如果UDP失败，ICE将尝试TCP。如果直接连接失败（尤其是由于企业NAT穿越和防火墙），ICE将使用中间（中继）TURN服务器。换句话说，ICE将首先使用带有UDP的STUN直接连接对等方，如果失败，将回退到TURN中继服务器。“寻找候选对象”一词是指查找网络接口和端口的过程
RTCDataChannel
除了音频和视频，WebRTC还支持其他类型数据的实时通信。RTCDataChannel API支持低延迟和高吞吐量的对等数据交换。
该API有很多潜在的用例
远程桌面应用程序 实时文字聊天 文件传输 分散网络
