WebRTC是Google开发出来的一种技术，用来实现在browser之间的音视频实时交流，用来取代以往的Flash为主的VideoChat。它的特点是P2P方式，也就是在双方或多方的通话中，不需要使用服务器来进行Media Stream的中转分发等操作，好处是服务器架构相对简单，服务器，用户在使用中不需要额外下载功能插件，但不好的地方是目前只有chrome，firefox和opera等才支持这种技术，IE和safari在短期内还看不到会支持的可能。

要实现P2P，首先要解决的问题是通信的亮点之间要建立直接的connection，复杂的网络环境下还需要通过打洞的方式来让双方能够找到彼此，所以Google在WebRTC中使用了ICE的协议来解决这个问题。

在WebRTC的ICE支持中，使用了STUN Server和TURN Server，这两种的区别是，STUN实现了打洞，通过访问STUN Server，这个节点将会获得自己所在网络的对外IP和端口映射，这样，别的节点就可以访问到，如果STUN的方式不能成功，则会回落到TURN Server；在这种情况下，两个节点无法建立直接的P2P连接，将会通过TURN Server的Media Stream转发来实现VideoChat，也就是目前通常的通过服务器转发的方式。在实际中，TURN Server都会支持STUN的功能，所以时常只部署一个TURN Server也能满足简单的应用。

在WebRTC的运行中，还需要一个Signaling Server（信号服务器），这个东西并不包含在WebRTC的标准中，所以需要用户自己来找方案实现。这个Signaling的功能是用来交换两个节点之间的信息，比如网络，音视频信息等。我们所使用的是SignalMaster，它是用socket.io写的，属于事件驱动的方式，就是收到什么事件，触发相应的动作。在WebRTC的简单应用中，通过SignalMaster（信号服务器）来交换的信息种类并不算多，主要就是两种：SDP和ICE Candidate信息。SDP全称是Session Description Protocol，是用来表示媒体信息的，比如编解码格式，分辨率，尺寸，单双音频通道等；ICE Candidate是网络打洞信息，当WebRTC应用的两端要建立PeerConnection时，如何实现直连，需要的就是这个信息。所以当这两种信息成功交换后，PeerConnection就可以建立了。

这一篇暂当作简介，下一篇开始介绍如何在iOS上做native的WebRTC功能的应用，一个很多坑的东西