WebRTC基本概念（一）

WebRTC （Web Real-Time Communication),一个可以让用户用自己流量实现音视频实时通信的框架（APIs),支持浏览器（Firefox、Chrome、Opera）以及iOS、Android 原生系统（Poor WP,默哀）。对于觉得带宽贼贵又需要实现用户之间音视频通信的公司来说，这是一个大大的福利。本系列文章会从WebRTC基本概念慢慢说起。

官方介绍：

按照传统的通信流程，是这样的：
如下图所示，数据发送端和接收端都需要通过公网服务器进行转发（因为发送端和接收端通常都做了NAT，彼此并不知对方实际位置）。
eg：犹如一个中国人和一个外国人，他们彼此不懂对方的语言，不知道对方的地址，但是中间有一个邮局知道对方的地址，因为对方都在邮局做了注册地址并且获取了同一个编号，那么如果他们之间需要互相通信的话，就需要和邮局联系，邮局会进行翻译并发往同一编号的对应地址。 但是这中间就会产生一个问题，这时候如果有多个中国人和多个外国人都要进行通信，那么邮局的工作量就会越来越大，当他们的通信超过原有邮局人手可处理规模时，邮局要么扩招（需要钱）要么延缓发送（会造成延迟，甚至丢失信件）。

时间关系，以下内容不再举例说明，需要网络基础的同学才能继续观看。

在真实世界的网络中，因为IPv4的地址个数问题，我们基本都是采用NAT连接的：

STUN服务器提供的功能十分简单，它让使用者获取自己所在的公网地址和在NAT中所映射端口号，这个服务有什么用呢？当使用者知道自己所在公网地址以及内部NAT映射端口时，它便可以讲自己的公网地址和端口号通知对方，这样对方就可以在茫茫大网中找到自己。
在以往统计中，WebRTC通过STUN建立连接的成功率为86%。

TURN [2] 是一个client-server协议。TURN的NAT穿透方法与 STUN 类似，都是通过取得应用层中的公有地址达到NAT穿透。但实现TURN client的终端必须在通讯开始前与TURN server进行交互，并要求TURN server产生"relay port"，也就是relayed-transport-address。这时TURN server会建立peer，即远端端点（remote endpoints），开始进行中继（relay）的动作，TURN client利用relay port将资料传送至peer，再由peer转传到另一方的TURN client。

简介
WebRTC，名称源自网页实时通信（Web Real-Time Communication）的缩写，是一个支持网页浏览器进行实时语音对话或视频对话的技术，是谷歌2010年以6820万美元收购Global IP Solutions公司而获得的一项技术。

这是百度百科上的介绍，维基百科也差不多。对完全小白来讲，可能不是很理解这句话。

首先，什么是实时通信？
举个直白的例子，我们平时打电话就是实时通信。现在有很多实时通信的软件，比如 丁丁、有信……这是手机app。PC客户端像Xlite、Linphone等等。这些客户端接入网络，注册到相应的服务器上就可以进行音频通信了，支持视频的还能进行视频通信。拿Xlite来说，它的信令机制采用的是sip协议。SIP协议是IMS网络广泛使用的信令协议，已经很成熟。两个uesr 通过Xlite客户端注册到sip server（如 Asterisk）上，就可以互相拨打对方的号码音视频通信了，不过就Xlite来说，语音通话是免费的，但是视频的话，是要支付money软件才提供视频功能的……

其次，为什么要提出WebRTC？
一直以来，用户如果想通过互联网进行实时通信，就需要安装软件，要么就得在浏览器中安装插件。WebRTC的宗旨是不需用户安装任何插件，直接使用浏览器就可以进行实时音视频通信。就是如果WebRTC实现了，我们打开浏览器，输入网址，登陆进去，拨打号码，就可以互相音视频了。不再需要安软件，也不需要安装额外的浏览器插件。Web版QQ大家都用过吧，现在还只能发发消息发发表情，如果引入WebRTC，那音视频传文件都不在话下，现在QQ客户端有的功能，通过网页访问都能体验，估计到时候都不愿意再装体积越来越大的QQ客户端了吧。

最后，需要知道的内容

WebRTC已经纳入HTML5标准
目前支持webrtc的浏览器有 Chrome Firefox Opera，IE不支持~
WebRTC没有指定具体的信令协议，具体的信令协议留给应用程序实现。
webRTC使用JSEP协议建立会话，什么是JSEP后面说
WebRTC采用ICE实现NAT穿越
WebRTC客户端之间可以进行点对点的媒体传输。
JSEP
JSEP（JavaScript Session Establishment Protocol，JavaScript会话建立协议）是一个信令API，允许开发者构建更强大的应用程序以及增加在信令协议选择上的灵活性。

建立会话最关键的就是媒体的协商，WebRTC虽然没有指定具体的信令协议，但是媒体协商采用了SDP协议。JSEP是干什么的呢，一方面提供接口如createOffer()供web应用程序调用生成SDP，另一方面提供ICE功能接口。这些功能都由浏览器实现，浏览器
WebRTC传输信令（offer/answer）采用Websocket。
需要说明的是，如果web应用程序不使用额外的信令协议，仅使用JSEP，两个WebRTC client （同一个WebRTC client程序，两处登陆） 之间也是可以建立链接的，即只要应用程序能解析用WS传递过来的Offer/Answer消息，提取出其中的SDP和ICE信息就可以了。

github上codelabdemo 就是不用其他信令协议，直接使用JSEP生成offer/answer信令，然后采用ws协议传输实现的。

JSEP并不是信令协议，可以在JSEP的基础上引入SIP等信令协议，使WebRTC应用功能更加完备。

WebRTC与SIP互通
要想让WebRTC与sip互通，要解决两个层面的问题：信令层和媒体层。
两个网络使用的信令机制不同，所以要进行信令的转换，才能完成媒体的协商，建立会话。媒体层要完成编码的转换，以及rtp/srtp转换等功能。这里主要说项信令层面的互通。

信令互通方案
目前sip和webrtc信令上互通有两种解决方案：

用JavaScript实现sip协议栈，webrtc应用程序基于这个协议栈开发。这样webrtc client发出的信令就是sip信令，但一般采用websocket为信令传输协议。这样的webrtc client就可以直接注册到支持ws的sip server上了。
jssip 、sipml5 都是这种解决方案。
通过转换网关实现协议的转换，从而互通。一个开源的网关项目就是 webrtc2sip。
webrtc2sip是一个功能很完善的网关，既实现了信令层，也实现了媒体层，编码转换功能很强大，也可以直接当做媒体网关，用于编解码，沟通两端的媒体。

在不同的网络环境(带有摄像头/麦克风多媒体设备)中，为两个浏览器实现点对点实时视频/语音通信有什么困难

1、了解对方的媒体格式、支持的最大分辨率和其他媒体信息？

2、要了解彼此的网络，就有可能找到一条通信链路？

3、两个终端还没有建立连接时,如何交换“媒体信息”和“网络信息”呢
为了保证两端都有正确的编码和解码，最简单的方法就是取它们的交集H264

注:有一种特殊的协议叫做Session Description protocol (SDP)，可以用来描述上述信息 。

在webrtc中，参与视频通信的双方必须首先交换SDP信息，这样双方才能了解基本的SDP交换过程。
同样，在复杂的网络环境中，要在两端之间建立连接，必须有一个双方都可以访问的链路。
从图中可以看出，他们可以使用公用网段192沟通。

在web brtc通信过程中，这些与网络相关的信息也必须进行交换，以找到共同的交集。这个过程也被称为“网络协商”。
两个终端还没有建立连接时,如何交换“媒体信息”和“网络信息”呢

此时，所谓信号服务器信号服务器应该出现:
如上图所示,两个浏览器可以抽象的上层一层信令服务器(可以是一个或多个,根据实际的应用程序中,如果两个浏览器可以访问公共网络环境,如公共如果没有公共网络环境中,您可以设置一组服务器两端,即信号服务器A和信号服务器B，但这两套信令服务器必须能够相互通信)，在信令服务器的帮助下，可以实现上述SDP信息和网络信息的交换。
交换SDP的过程大致如图所示:
1 Amy(假设一个人的名字)通过setLocalDescription方法保存自己的SDP信息，然后通过offer方法发送给信令服务器。

2 信息服务器将Amy的SDP转发给另一端的Bob(另一个虚构的名字)，Bob将首先调用setremotedescription来保存Amy的SDP。

3然后Bob调用setLocalDescription方法来保存他的SDP，然后使用answer方法通过信令服务器将他的SDP发送给Amy

4 Amy收到Bob的SDP后，调用setRemoteDescription进行保存，双方完成SDP交换，找到交集。如果他们能达成协议，他们就可以建立一个p2p连接并开始通信。
但现实往往是残酷的。在中国的网络环境下，据统计，至少有一半的网络不能直接连接。我个人认为根本原因是:在互联网发展的早期，绝大多数IP4地址资源都被国外所占据。当轮到中国等发展中国家使用IP地址时，大多数计算机没有公网IP地址，只能通过路由器和交换机进行NAT转换，相当一部分NAT是对称的。基本上，没有办法播放它。在这种情况下，您只能使用前一节提到的转向服务器进行转移。此外，在视频对话框中，通常会有房间(或组)的概念，用来隔离一些服务。这部分逻辑也在信号服务器中实现。对端、信令服务器、stun/转接服务器后，整个1对1实时视频通信顺序图如下:
主要流程如下:

1 双方首先调用getUserMedia打开本地摄像头

2 向信令服务器发送apply_join请求以加入房间

3信令服务器通知我成功加入(joined)，同时向其他人广播加入消息(other_joined)

4 第二个端开始创建peerConnection连接

5 PeerB创建报价，同时将SDP保存到本地机器(setLocalDescription)，并通过信令服务器将SDP传递给peerA

6 在setLocalDescription之后，PeerB将异步触发“候选网络链接”的集合，这大致决定了它自己所有的NAT映射通过Stun退出。如果Stun返回的NAT是“对称的”，它将基本上无法穿透。再次通过Turn得到中继应答地址，并通过信令服务器将网络候选链接信息发送给peerA(即:启动网络协商)

7 peerA收到peerB的SDP后，开始响应(createAnswer)，仍然通过信令服务器将SDP发送给peerB

8 同时，peerA也会开始收集网络候选链路，并通过信令服务器(即网络协商)将自己的网络信息发送给peerB。

通过这种方式，peerA和peerB相互交换了媒体信息和网络信息。如果他们能达成一致(即找到交叉点)，他们就能开始沟通。

WebRTC ，名称源自 网页即时通信 （英语：Web Real-Time Communication）的缩写，是一个支持网页浏览器进行实时语音对话或视频对话的 API。它于 2011 年 6 月 1 日开源并在 Google、Mozilla、Opera 支持下被纳入万维网联盟的 W3C 推荐标准。

首先，他即是 API 也是协议。

其次，他是浏览器进行音频与视频通话的 API，其实还有屏幕共享的功能。

最后，它现在已经处于 W3C 标准，各大浏览器厂商已经对他进行兼容了。

但是如果我们想使用好 webrtc，就得先了解 websocket。而对于 websocket，大家应该都比较熟悉了，比如社交聊天、多人 游戏 、协同编辑、视频会议、基于位置的应用(地图)、等等需要高实时的场景。我们比较常用的微信、QQ、某些直播软件等等也都是基于 websocket 实现消息与信令的转发。大家看到这里可能在信令这里迟疑了，接着看。

webrtc 是 P2P 的一种技术，什么是 P2P？其实就是 端对端，就说是你的音频、视频流不经过服务器中转，直接由一端发送到另一端。

不经过服务器中转，也就说时候，如果通过过程中服务器突然崩溃，是不是通话还能继续？

是的！但是发送音频视频流前，一定是需要建立 P2P 连接的，建立连接前一定需要服务器进行信令转发，这个信令就是通话两端的标识。

而如果想用 webrtc 实现通话，就得先中转信令、建立连接。而建立连接的话最好是要用 websocket 进行信令转发的。大家都知道，websocket 是个通道，在这个通道的所有端，都可以收到任意一端的消息流，包括发消息的本人。

为什么不经过服务器就可以直接获取到对方的视频音频流呢？是因为建立了 P2P 通道，这个 P2P 在中转信令的时候就已经通了，传输视频音频流的时候还要啥服务器啊。这个时候，肯定有小伙伴表示怀疑，音频视频流可以不通过服务器？是的，我骗了大家，确实要经过服务器，但是只是线上需要服务器转发，如果我们是本地两台或者多台同一局域网的端 进行 webrtc 音频视频流的转发，确实不需要中转服务器，但是线上有可能需要，也有可能不需要，这里又涉及到了一个 打洞 的概念。

我们平常可能会听到比较牛 x 的词汇，什么打洞、内网穿透、NAT 穿越，各种高大上的东西，其实也是蛮好理解的。大家都知道，两个不同网络下的两台主机不可以直接进行通信，而是需要走公网或者说各自的网关。打洞、内网穿透、NAT 穿越其实就是一个意思，就是使用 udp 让我们两台非同一网络的主机互联，不走公网，直接实现连接。有玩过花生壳的同学一定能理解内网穿透这个概念。

本地开发的话，两台主机连同一局域网，根本不需要内网穿透，就可以直接通信。

线上开发的话，如果能够 STUN 打洞成功，也不需要中转服务器。但是，有打洞不成功的概率，为什么呢，因为没有走公网，没有给运营商带来收益却带来通信成本，肯定要限制。国外打洞成功的概率在 70%，但是国内 50%都不到。

所以，为了防止打洞不成功的情况，我们使用 TURN 中转服务器 转发流媒体数据进行一个最后保障。此外还有一种方式为 逆向连接 ，也可以帮助我们实现 P2P 建立，他的原理是必须是一方走公网，也是有局限性的。

coturn 中继服务器由两部分组成 STUN 与 TURN，STUN 帮助我们打洞，TURN 帮助我们转发流媒体数据。

##连接过程

以下所有 API 截止到 20211206 为最新

##我有疑问

给大家看看 sdp 的本质，就是自身的媒体信息和编解码信息

一个 offer，一个 answer，我们彼此都知道对方的媒体信息与编解码信息，这样我们才能好好协商，我这边该用什么方式对你的视频音频流进行解码、渲染。

过程有些繁杂，具体流程小伙伴们可以看这篇文章 WebRTC TURN 协议初识及 turnserver 实践。

了解 webrtc 的音视频采集、桌面采集；

了解 websocket 和 webrtc 的整个链路建立过程；

实现 1V1 文字传输、视频通话、语音通话、屏幕共享；

实现视频通话、语音通话、屏幕共享过程中的截图、录音、录屏及 截图、录音、录屏的在线播放与下载;

将以上功能部署上线；

在这里，我们要对音视频建立过程画一个基本的流程图。

基本流程图

对于这些信令，我们使用 websocket 进行转发，这里大家会问，为什么不使用 >