原文：WebRTC in the real world: STUN, TURN and signaling By Sam Dutton
WebRTC 实现了网页点对点交流。
但是…
WebRTC 仍然需要服务器来:
本文将向你展示如何建立一个信令服务器，并使用STUN和TURN服务器来处理实际应用中出现的一些怪异的连接问题。也将解释WebRTC应用是如何处理多方通讯并与类似VoIP、PSTN的服务互动的。
如果你没有了解过WebRTC，我强烈建议你在看这篇文章之前先看看这篇文章 Getting Started With WebRTC
1.Ubuntu下安装coturn：
apt-get install coturn，源码：http://turnserver.open-sys.org/downloads/
安装类似下面：
sudo -i
# ignore if you already in admin mode
apt-get update && apt-get install libssl-dev libevent-dev libhiredis-dev make -y
# install the dependencies
让人类通过网络进行音视频通信是网络最后的巨大挑战：实时通信( RTC )。实时通信就像网络上在文本框中输入文本一样自然，没有它，就限制了我们开发新的方式使人们互动交流起来。
从历史上看，RTC 变化很大很复杂，需要昂贵的音视频技术授权或者花费巨大代价去开发，RTC 技术与现有的内容、数据和服务整合一直都很困难和耗时，在网络上尤其如此。
Gmail 视频聊天在 2008 年开始流行，在 2011 年 Google 推出视频群聊，它使用 GoogleTalk 服务，就像 Gmail 一样。Google 收购了 GIPS，它是一个为 RTC 开发出许多组件的一个公司，例如编解码和回声消除技术。Google 开源了 GIPS 开发的技术，与相关机构 IET 和 W3C 制定行业标准。在 2011 年 5 月，爱立信实现第一 个 WebRTC应用。
WebRTC 已经实现了对于实时通信，免插件音频数据传输的标准制定。需求是：
- 许多网络服务已经使用了 RTC，但是需要下载，本地应用或者是插件。包括 Skype、Facebook、Google Hangouts。
- 下载安装升级插件是复杂的，可能出错的，令人厌烦的。
- 插件可能很难部署、调试、故障排除等——可能需要技术授权，复杂集成和昂贵的技术。说服人们去安装插件是很难的。
WebRTC 项目的指导原则是APIs应该是开源的，免费的，标准化的，浏览器内置的，比现有技术更高效的。
这两年来，WebRTC 越来越频繁地出现在人们的视野，在在线教育、在线医疗等领域的应用也越来越多。大家研究 WebRTC 的热情也越来越高涨，不过 WebRTC 的入门门槛个人觉得稍微有些高，特别是各种概念，比如 NAT 穿越，ICE、STUN、TURN、Signaling server等，刚开始可能会觉得比较繁杂，不易理解。然后建立连接的整个过程，异步调用比较多，很容易搞混。那么这篇文章里我们会根据 WebRTC 的官方 demo AppRTC 的 iOS 版本来分析一下 WebRTC 从进入房间到建立音视频连接的过程，为了便于了解，我们本次的讨论不涉及到底层的具体实现。
我们首先来简单地了解几个概念：
因为 WebRTC 是 P2P 的，很多时候 peer 是隐藏在 NAT 之后，没有外网的 IP 地址，如果两个 peer 都在 NAT 后面，都没有外网的 IP (或者说都不知道自己的外网 IP)，是无法建立连接的。那么 NAT 穿越就是用来解决这个问题的，NAT 穿越也俗称 “P2P 打洞”。常见的两种穿越方式是 STUN 和 TURN。
如果我们想要理解 HTML5 视频，首先需要知道，你应该知道，但你不知道的内容？那怎么去判断呢？ ok，很简单，我提几个问题即可，如果某些童鞋知道答案的话，可以直接跳过。
.）这些叫做什么吗？当然，还有一些问题，我这里就不废话了。上面主要想说的其实就两个概念：视频文件格式（容器格式），视频编解码器（视频编码格式）。当然，还有另外一种，叫做音频编解码器。简而言之，就是这三个概念比较重要：
这里，我们主要讲解一下前面两个。视频一开始会由两个端采集，一个是视频输入口，是一个音频输入口。然后，采集的数据会分别进行相关处理，简而言之就是，将视频/音频流，通过一定的手段转换为比特流。最终，将这里比特流以一定顺序放到一个盒子里进行存放，从而生成我们最终所看到的，比如，mp4/mp3/flv 等等音视频格式。
视频编码格式就是我们上面提到的第一步，将物理流转换为比特流，并且进行压缩。同样，它的压缩编码格式会决定它的视频文件格式。所以，第一步很重要。针对于 HTML5 中的 video/audio，它实际上是支持多种编码格式的，但局限于各浏览器厂家的普及度，目前视频格式支持度最高的是 MPEG-4/H.264，音频则是 MP3/AC3。（下面就主要说下视频的，音频就先不谈了。）
目前市面上，主流浏览器支持的几个有：
Web 进制操作是一个比较底层的话题，因为平常做业务的时候根本用不到太多，或者说，根本用不到。
老铁，没毛病
那什么情况会用到呢？
上面只是列了部分内容。现在比较流行的就是音视频的处理，怎么说呢？
如果，有涉及直播的话，那么这应该就是一个非常！非常！非常！重要的一块内容。我这里就不废话了，先主要看一下里面的基础内容。
本篇主要聚焦于 RTMP 直播协议的相关内容，也就是说，本篇将会直接进行实际操作 Buffer 的练习和协议的学习。
RTMP 全称即是 Real-Time Messaging Protocol。顾名思义就是用来作为实时通信的一种协议。该协议是 Adobe 搞出来的。主要是用来传递音视频流的。它通过一种自定义的协议，来完成对指定直播流的播放和相关的操作。和现行的直播流相比，RTMP 主要的特点就是高效，这里，我就不多费口舌了。我们先来了解一下 RTMP 是如何进行握手的。
RTMP 是基于 TCP 三次握手之后的，所以，RTMP 不是和 TCP 一个 level 的。它本身是基于 TCP 的可靠性连接。RTMP 握手的方式如图：
WebRTC 全称为：Web Real-Time Communication。它是为了解决 Web 端无法捕获音视频的能力，并且提供了 peer-to-peer（就是浏览器间）的视频交互。实际上，细分看来，它包含三个部分：
但通常，peer-to-peer 的场景实际上应用不大。对比与去年火起来的直播业务，这应该才是 WebRTC 常常应用到的地方。那么对应于 Web 直播来说，我们通常需要两个端：
这里，我就不谈观众端了，后面另写一篇文章介绍（因为，这是在是太多了）。这里，主要谈一下会用到 WebRTC 的主播端。 简化一下，主播端应用技术简单可以分为：录制视频，上传视频。大家先记住这两个目标，后面我们会通过 WebRTC 来实现这两个目标。
【 从头到脚 】会作为一个系列文章来发布，它包括但不限于 WebRTC 多人视频，预计会有：
WebRTC 实战（一）：也就是本期，主要是基础讲解以及一对一的本地对等连接，网络对等连接。
WebRTC 实战（二）：主要讲解数据传输以及多端本地对等连接、网络对等连接。
WebRTC 实战（三）：实现一个一对一的视频聊天项目，包括但不限于截图、录制等。
WebRTC + Canvas 实现一个共享画板项目。
作者开源作品 ???Vchat — 一个社交聊天系统（vue + node + mongodb） 的系列文章