1.1什么是WebRTC

 从官网上的描述我们可以知道，WebRTC是一个免费的开放项目，它通过简单的API为浏览器和移动应用程序提供实时通信（RTC）功能

1.2 WebRTC框架

 上图的框架对于不同的开发人员关注点不同
(1）紫色部分是Web应用开发者API层
(2）蓝色实线部分是面向浏览器厂商的API层
(3）蓝色虚线部分浏览器厂商可以自定义实现

 特别是图中的PeerConnection为Web为Web开友人员提供了一个抽象，从复杂的内部军构中抽象出来我们只需要关注PeerConnection这个对象即可以开发音视频通话应用内。WebRTC架构组件介绍
Your Web App

 

 

 不可能像直播无线扩展房间人数 

 

声网最多 支持17人，视频带宽远远比语音带宽需求大

 

 

 用sdp这个协议做媒体协商，双方必须交换sdp的信息 

 

 在另一个局域网通话 通话B端 两个局域网，用他的局域网ip是不能连接的 外面有一个NAT路由器给我们分配了一个外网ip

a端如何和b端通话呢？ 这里有一个ip 但是他是在局域网里面的

这里需要 NAT 网络地址转换 

怎么去转换？其实他是通过端口映射，比如我这边是10.1.1.2他映射到外网里面 映射到外网的一个端口 它可以映射一个端口， 比如这个端口是60  就是说我跟外界做数据传输的时候 他先传到这个外网地址，以及端口60这里，他怎么去区别不同的局域网ip呢？其实10.1.1.3 他也可以去映射一个外网 做一个端口NAT的映射 比如端口61

这个b端也是类似的原理的 比如113.246.155.54我可以映射到60里面去，这样子映射过来，那他可以得到两个外网的ip的时候那就可以考虑113.246.153.54 60和113.246.155.54:60这两个端口，看他们是否可以相通，如果他们两个可以相通，那么我们通过端口映射，实现a和b的点对点的数据传输  还有一个情况，就算他能拿到端口这个打洞的端口，但是还是有可能两个端口不能直接互通 

 

 STUN

STUN（Session Traversal Utilities for NAT，NAT会话穿越应用程序）是一种网络协议它允许位于NAT（或多重NAT）后的客户端找出自己的公网地址义查出自己位于哪种类型的NAT之后以及NAT为某一个本地端口所绑定的Internet端端口。这些信息被用来在两个同时处于NAT路由器之后的主机之间创建UDP通信。该协议由RFC 5389定义

这边你拿到外网端口，怎么去拿，刚刚说，他需要这个外网端口的映射，但是这个外网端口映射需要别人告诉你，因为你自己在你局域网里本身不知道你NAT映射后他到底是映射成什么样子的，你需要一个服务器去告诉你，就是我们这里讲的stun这个服务器，就是要解决这个端口网络地址转换，你要实现这个网络地址转换你要知道他实际映射到外网端口是多少的时候，就是说我们拿到端口这一串数据113.246.153.54：60 外网ip加这个端口的时候我们是要通过服务器去获取的，我们要通过客户端连到服务器里面（ NAT）去，然后服务器里面知道这个113.246.153.54：60端口，服务器在把这个端口113.246.153.54：60 发送给我们 A 端 或者找个B端 10.1.1.2 他是通过STUN这种协议来获取的，STUN（Session Traversal Utilities for NAT，NAT会话穿越应用程序）是一种网络协议它允许位于NAT（或多重NAT）后的客户端找出自己的公网地址  NAT后面是哪里？就是客户端，就是我们局域网里面的机器，查找出自己的公网ip地址，在查出自己位于哪种类型的NAT之后，本地端口所绑定的lnternet端端口 也就是说我找个局域网ip 会绑定到外网ip+端口

局域网ip 他绑定的是外网ip+端口

这个STUN服务器是怎么工作的？

 你找个客户端peer 向服务器请求获取你的外网IP+端口的映射 后 STUN server  然后 两端a端跟b端 就用找个外网IP+端口

就是拿到找个地址后，两个地址之间可以去尝试做一个连接，看看自己是否正常的连接

使用一句诂说明STUN做的事情就是：告诉我你的公网IP地址+端口是什么 搭建STUN服务器很简单 就是通过coturn穿透和转发服务器去搭建就好了，coturn是开源的一个方案，他是集成了STUN这个协议

这边还有TURN找个协议，这个协议主要是用来做中继的，就是说假如这两端他有可能打不通 他直接映射外网端口映射不通的时候，要通过服务器去做转发了，需要有一个媒体服务器转发你的音视频数据，因为找个打洞 他是有一定成功率的，在我们国内 大概是50% 

 

那这个时候就要讲到这个 TURN 服务器

TURN他主要是刚才这个STUN协议的一个扩展，他主要是添加了Relay功能 Relay：中继

 在letto之后，他有可能两个他是不能做p2p的 这个a跟b不能直接做p2p的的时候，那就需要有一个公共的服务器作为一个中继 对来往的数据进行转发。这个转发的协议就被定义为TURN 

这个webrtc不只是需要用到STUN这个服务，如果能p2p成功，成功率是100%那你就可以只用这个STUN 就好了，但是很多情况下是不能p2p的 所以你需要通过公共的服务器来做数据转发 所以在上图的基础上加了一块中继服务，就是我们

 TURN这个服务，这个数据你可以对比一下，这个数据，先发到这个中继服务里面 发到 TURN这个服务里面Relay server  然后，再转发，

比如说很多人在聊天，那你这个中继服务器对这个带宽要求就非常大了，如果你用了Relay server中继的模式 那你一定要注意服务器的带宽，需要非常大的带宽 

比如常见的一个通话至少要200kbps 每秒， 一个人通话，一对一通话 而且他还是单向的数据码流

才会有一个好的通话效果，像微信其实通话效果不算很好，

单向是什么意思呢？

比如有一个中继服务TRURN  a端 单项 我要传输发送数据，那么就是一向，这里是200kbps

b要发送数据，也是一向  也是200kbps 我还要b发的数据，这里是不是也要200kbps b需要收a的数据也需要200kbps  所以这个一对一带宽就是单项*4 如果你没有p2p成功 你通过中继服务TRURN 

中继服务的方式是非常耗资源的 耗服务器带宽的  这个带宽还是比较贵的，你去查一下 贵 代表你的服务器成本就会非常的高，

 

 媒体协商 sdp

网络协商 candidate 两点都很重要，掌握概念就好了，为什么需要sdp 为什么需要candidate

一个sdp就是为了要彼此都能知道 彼此的编解码能力，

网络协商 就是了解彼此的外网端口映射，

媒体需要协商，网络信息需要协商，那么怎么去协商 交换？ 这就需要一个中间商做交换 这个时候我们就需要实现一个信令服务器 这个信令服务器 他不是一个标准 你可以自定义的，不管你是websocket 还是tcp 可以用不同的语言，比如说go语言，c++ 或者notjs等等之类的，反正只要保证你可以实现他们，a端给b端可以交换他们要交换的信息，就是你可以实现他们信息的交换 网络信息的交换就好了 

 

 

 信令服务器就是用来做数据交换的，信令服务器一般搭建在公网的 特别是要给外面的人用的时候肯定是要搭建到公网的

 如果你是在局域网内用的，那你可以把信令服务器搭在局域网里面 但是你要保证你说有的访问者都能访问到这个信令服务器 他们的目的就是这个sdp和Candidate网络信息的一个交换，当然它不只是交换这两种数据 

 比如房间管理：比如我这个信令服务器 我要支持 不同的人做通话，

小明跟小王通话的信息，不能发给张三或者其他人，只能发给彼此，这个时候就需要房间的概念，比如说房间100 ，这个数据里面，只在房间100里面去发 这只是说信令

比如说刚刚的sdp和Candidate 还有张三李四，他要通话，他们可以进另外的一个房间，房间200 

所以说这个信令服务器 他还需要实现这个房间的管理

 还有人员的进出 ，也是属于房间管理的一部分，但是我这里单独列出来是为了更方便的去讲解

比如我小明先加入了房间100 然后小王也加进房间100 这个时候信令服务器要做哪些事情呢？他是不是要通知小明？有人加入了？ 因为小明已经在这个房间里面了，所以要做人员进出房间的管理

至于这个信令服务器到底要怎么去设计，我们在一对一音视频通话实战里面 再去讲解 这个信令服务器应该怎样去设计  

MediaStream 他是我们要用到的媒体流 对于这个浏览器来讲 他是通过getUserMedia接口获取

RTCPeerConnection对我们音视频通话对我们api使用者来讲，他是最核心的一个对象 是最核心的一个类，

sdp和RTCPeerConnection是怎么产生，以及是怎么去传输。怎么去使用的，

对于webrtc来讲 他有一个发起者 以及接收者这个概念

 

发起者他会创建这个offer  对于接收者 是创建这个应答createAnswer 

a端和b端都会连接这个信令服务器 signal server 

PeerConnection 是一个重点，跟RTCPeerConnection其实是同一个东西，只是有些平台他带rtc 有些平台他是不带的， 两边都会创建一个PeerConnection 然后两边都会去 addStream 会加入本地媒体流 

对于发起者 他会CreateOffer 他会有一个回调，调这个api的时候，CreateOffer 是属于PeerConnection的 ，addStream和SetLocalDescription 都是属于PeerConnection的函数，属于他的一个方法，

CreateOffer他会产生一个回调，然后产生一个回调会获取到sdp 这时候你CreateOffer那他会通过这个回调函数拿到sdp，拿到sdp我们就知道我们的浏览器，有哪一些编解码能力，这个CreateOffer是从浏览器里面拿到的信息，然后我们可以把他设置到我们PeerConnection里面去，通过 这个SetLocalDescription设置到PeerConnection里面去，然后把这个Offer sdp发送给这个B端 接收者，那你就会先发到信令服务器，然后通过信令服务器转发到我们这个B端 B端做什么东西呢

 他会把这个sdp 会把A端的sdp设到他PeerConnection里面去，但是你要注意一下，这里设的时候你设到远端，你设到别人用 remote

我在b端，我把别人sdp设置进来以后，我自己，也会产生来一个sdp 就调用这个CreateAnswer这是应答，他是调CreateAnswer他也会有一个回调函数 通过回调函数获取到sdp 拿到sdp那我也设到本地里面去，就是我知道B浏览器 有哪些编解码能力，那我也会设到我这个PeerConnection里面通过SettLocalDescription设到本地里面去，然后，我会发送Send Answer SDP 我会发给对方，那也是通过 信令服务器去做转发的 a端我是收到Relay Answer SDP 我也是调用Remote 就是说别人的东西，我就认为是Remote 是远端传进来的，做完这两步就完成了 媒体协商

大家都是把自己的sdp设置了，然后也把自己的sdp告诉了别人，这个时候完成了媒体协商

那就开始网络协商了，可以看到ICERequest是什么呢？就是刚才我们讲的STUN 

ICE其实他不是一种协议，他其实是一种服务集成 是STUN 和TURN两种协议的服务集成，他就会去StunServer这个服务里面去请求 外网 公网的一个信息，就是如果请求到了 那我这边这个信令服务器会回发 给PeerConnection 在PeerConnection他怎么拿到onlceCandidate呢，就是我们这边 就是这一步他是有去回发

 

 但是他是在PeerConnection内部里面去做了，我们不用再去调一个ICE Request 他是在PeerConnection内部做了 那我们是怎么拿到这个Candidate呢？他是通过这个onlceCandidate 这个回调函数，就是说他这个回调函数，是绑到我们这个PeerConnection里面了  只要你请求到Candidate里的信息 那他这个onlceCandidate他这个回调，在我们应用api里面就会拿到Candidate的信息，那我们拿到这个onlceCandidate里面的信息，那我们就可以发给对方Send ICE Candidate

就可以通过这个中继 Signal Server这个信令服务器 发给对方，对方做了什么东西呢？他会调用这个AddlceCandidate  这个AddlceCandidate 他也是这个PeerConnection里面的一个方法 我们可以看到对于B端，B端也是一样的 B端​​​​​​​也是会去向这个 STUN 和TURN这个服务器去请求这个Candidate会请求这个外网 这个公网的一个网络信息，那也是通过这个onlceCandidate拿到我们这个Candidate 这个Candidate就会包含我们这个网络信息，然后也是通过这个信令服务器 Send ICE Candidate 去做转发 Relay ICE Candidate 可以看到整个A端 收到整个Candidate 他也是通过同样的接口AddlceCandidate 去加到PeerConnection 里面，然后这个PeerConnection 里面内部会去做互联了，这里内部他会去做互联的

这边是a端  b端 他是有多组Candidate 一般五六组都是很常见的 然后 b端也有五六组

那这个时候他能做什么东西呢？他们之间会做一个通话的尝试 相互之间交叉，做一个通话的尝试

比如说0和0之间做一个打洞 去做一个通话，看能不能相通 反正就是大家都会尝试能否去连接，如果 能成功连接，那他就会打洞成功 Candidate能够成功联通那就是我们说的p2p了 这个时候你就不用再经过 你这个音视频数据就不用再经过服务器了，那你就可以两端点对点的去传输就好了

然后这边会有一个什么响应呢？那如果你这个音视频数据传输 那你就要PeerConnection 那他就会还有一个响应函数，onAddStream 那他就会收到对方的音视频，就是说你这个onAddStream他是一个就是说是你这个onAddStream api可以去绑定 这个是你自己去按照他的接口去实现了，你可以理解为他是一个回调函数来的 就是说在这个webrtc里面只要是这个on有这个on这个前缀的 是回调函数， 像这个onAddStream那你就获取到对方的媒体流 然后你就可以把这个媒体流显示到我们这个web里面，这样整个web就显示出画面，还有播放出声音来了，如果单从整个流程上看，这个流程是没有特别的复杂， 因为很多具体的东西 都封装在内部了，比如说这个sdp内部是怎么去获取到  比如这个Candidate 内部是怎么获取到的， 还有这个Stream这些传输，比如要做一些数据缓存等等 之类的，他都是在内部里面做了，对于我们开发者来讲 我们只需要关注他这个api怎么去使用就好了

 这里主要是p2p通话成功的一个方式 一个时序图 就是说如果打洞不成功，如果p2p不成功 那你需要这个TURN这个服务器去转发数据的，那这个时候你这个数据的一个转发

 在这一部分里面👆 ，那你就不能点对点的去实现了，那你就要通过刚才讲的 通过TURN这个中继服务来传输的，但是有一点还是一样的，这个onAddStream还是一样的，只是这个Media这个媒体他是通过一个中继，由 比如说这个 他是这样子，有一个中继 ，他是这样子通过中继的方式，通过TURN做一个中继

 

 

 总结，