在WebRTC中我们经常用到的2个协议是：STUN和TURN。
WebRTC在成功视频对话之前，需要做三件事情，这三件事情分别是：
获得音频和视频
传输音频和视频
传输其他数据
每一件事情对应着一个API，他们分别是：
MediaStream
RTCPeerConnection
RTCDataChannel
WebRTC主要实现的是浏览器对浏览器之间的实时通信，理想的状态应该是这样的：
显示情况是：我们的电脑和电脑之前或大或小都是在某个局域网中，需要NAT（Network Address Translation，网络地址转换），显示情况如下图：
在解决WebRTC使用过程中的上述问题的时候，我们需要用到STUN和TURN。
STUN
在遇到上述情况的时候，我们可以建立一个STUN服务器，这个服务器做什么用的呢？主要是给无法再公网环境下的视频通话设备分配公网IP用的。这样两台电脑就可以共同在公网IP中，可以愉快的进行通话了。
使用一句话说明STUN做的事情就是：告诉我你的公网IP地址是什么。搭建STUN服务器很简单，媒体流传输是按照P2P的方式。
那么问题来了，STUN并不是每次都能成功的为需要NAT的通话设备分配IP地址的，P2P在传输媒体流时，使用的本地带宽，在多人视频通话的过程中，通话质量的好坏往往需要根据使用者本地的带宽确定。那么怎么办？TURN可以很好的解决这个问题。
TURN
在上图的基础上，再架设几台TURN服务器：
在STUN分配公网IP失败后，可以通过TURN服务器请求公网IP地址作为中继地址。这种方式的带宽由服务器端承担，在多人视频聊天的时候，本地带宽压力较小，并且，根据Google的说明，TURN协议可以使用在所有的环境中。
以上是WebRTC中经常用到的2个协议
WebRTC在实现视频通话之前需要做三件事情，这三件事情和三个API相关。
getUserMedia
媒体流包括两种：视频流和音频流，在API中通过不同的参数设置可以设置获取音频流还是视频流。
获取视频流的代码如下:
获取音频流的示例代码如下：
RTCPeerConnection
RTCPeerConnetcion做的事情就是把获取到的媒体流传输到另外一台视频播放设备。
看起来很简单，但是这个API做的事情却很多，例如：信令处理、编译处理、P2P链接、安全、带宽管理……
The RTCPeerConnection interface represents a WebRTC connection between the local computer and a remote peer. It provides methods to connect to a remote peer, maintain and monitor the connection, and close the connection once it's no longer needed.
——Mozilla Developer NetWork
RTCDataChannel
这个API做的事情是：保证已经建立连接的设备之间的任意数据的双向通信。举个例子：
左侧的onreceivemessage中的myData和右侧的onreceivemessage中的myData可以双向实时进行传输。
以上是本文的全部内容，相关API的详细情况我们在以后的文章中再一一详细说。
参考资料：
WebRTC：https://webrtc.org/
《WebRTC权威指南》