WebRTC（Web Real-Time Communication),一个可以让用户用自己流量实现音视频实时通信的框架（APIs),支持浏览器（Firefox、Chrome、Opera）以及iOS、Android 原生系统（Poor WP,默哀）。对于觉得带宽贼贵又需要实现用户之间音视频通信的公司来说，这是一个大大的福利。
What is WebRTC？官方介绍：
WebRTC is a free, open project that provides browsers and mobile applications with Real-Time Communications (RTC) capabilities via simple APIs.The WebRTC components have been optimized to best serve this purpose.
Our mission: To enable rich, high-quality RTC applications to be developed for the browser, mobile platforms, and IoT devices, and allow themall to communicate via a common set of protocols.
WebRTC是一个free的开源项目，该项目提供了一组可以在浏览器、手机应用平台（再次声明，目前只支持iOS和Android。）实现实时通信的简单API(s),WebRTC的目标是将实时通信过程做得最优化。
我们的任务（指WebRTC官方）：在手机应用平台、浏览器和物联网设备之间用同一组协议实现高质量实时通信。
RTC基本框架按照传统的通信流程，是这样的：
如下图所示，数据发送端和接收端都需要通过公网服务器进行转发（因为发送端和接收端通常都做了NAT，彼此并不知对方实际位置）。
e.g.：犹如一个中国人和一个外国人，他们彼此不懂对方的语言，不知道对方的地址，但是中间有一个邮局知道对方的地址，因为对方都在邮局做了注册地址并且获取了同一个编号，那么如果他们之间需要互相通信的话，就需要和邮局联系，邮局会进行翻译并发往同一编号的对应地址。 但是这中间就会产生一个问题，这时候如果有多个中国人和多个外国人都要进行通信，那么邮局的工作量就会越来越大，当他们的通信超过原有邮局人手可处理规模时，邮局要么扩招（需要钱）要么延缓发送（会造成延迟，甚至丢失信件）。
怎么办？这时我们就要考虑另外一种解决方案了。我们让发送端直接发送数据给接收端，这样就可以省掉服务器的转发功能了是不是？当然是，但是如我们上述例子所说，中国人不懂俄语，俄罗斯人不懂中文，鸡同鸭讲眼碌碌。他们之间怎么通信呢？邮局觉得上述方式太不靠谱了，于是决定通过一种技术，当有一个中国人或者外国人寻求转发时，邮局通过“魔法”查找出了对方地址，并且不说话丢给了对方一只翻译面包，对方接收到翻译面包后可以习得对方语言，直接和对方通话。
例子中的“魔法”就是本文要介绍的 ICE框架，而翻译面包就是NAT穿越技术。
在真实世界的网络中，因为IPv4的地址个数问题，我们基本都是采用NAT连接的：
当处于以上网络时，Peer和Peer之间基本都是通过NAT和防火墙连接上互联网的，所以当我们要建立两端之间的直接通信时，我们需要服务器对两端进行Signalling，具体如何进行Signalling会在下篇文章中介绍。本文假设两端已经Signalling完毕。
ICE框架 （ICE会尝试找到端与端之间最优连接路径）会完成以下工作：
·首先ICE会直接利用主机地址和网卡地址进行连接，如果刚好端拥有公网IP（无NAT），那么此时可以直接建立连接。
·如果第一步失败，ICE会尝试建立STUN连接。
·如果第二步失败，ICE会利用TURN服务器建立连接。
STUN（Session Traversal Utilities for NAT）
STUN服务器提供的功能十分简单，它让使用者获取自己所在的公网地址和在NAT中所映射端口号，这个服务有什么用呢？当使用者知道自己所在公网地址以及内部NAT映射端口时，它便可以讲自己的公网地址和端口号通知对方，这样对方就可以在茫茫大网中找到自己。
在以往统计中，WebRTC通过STUN建立连接的成功率为86%。
TURN（Traversal Using Relay NAT）TURN是一个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。
TURN 和 STUN
STUN服务在查询出客户端所在IP和端口后，其所成功建立的连接是直接通过端与端之间的连接的。
TURN服务是通过TURN服务器（拥有公网地址）作为中间人进行转发，所以如果TURN服务速度比STUN慢，而且是需要消耗TURN服务器带宽。