原文：https://bloggeek.me/google-free-turn-server/
没有免费的午餐，或者免费TURN服务器。
现在是2017年，WebRTC已经伴随我们5年多了。你可能会认为，现在人们对WebRTC已经有了足够的了解，这样我们就不会有任何问题了。但事实并非如此。
有一个问题总是不时的出现，为什么谷歌(或者其他公司)不提供免费的TURN服务器?
除了因为当发生出错时你没有办法控制它们，导致你不应该使用免费STUN或TURN服务器这个事实以外，让我们首先了解一下这两种服务器——更准确来说是协议有什么区别，因为STUN和TURN通常部署在一起。
STUN是怎么工作的
下面的插图应该会告诉你STUN工作原理:
当STUN被使用时，浏览器或任何其他支持WebRTC的设备向STUN服务器发送一条消息，问他“我是谁?”。这里的想法是，STUN是用来找出你的公共IP地址。这是你的机器自己不知道的事情，因为你的机器“分配”在NAT后面(且总是在NAT后面)。这些信息事实上也是动态的——你不能真的指望每次都收到相同的答案——或者由查询本身产生的通道保持开放。
这是一个简单的问题，STUN可以提供一个单一的答案。此外，这是在UDP上进行的，使其轻量级和快速，甚至不需要建立一个长期的连接或有适当的上下文。
一旦浏览器得到了答案，他就可以分享它，如果其他一切都像预期的那样工作，他将直接接收媒体信息。
一开始，STUN的这里的作用仅限于这一个问题。
TURN是怎么工作的
以下是TURN的工作原理:
当涉及到TURN时，我们从绑定请求开始—我们的浏览器实际上是在询问TURN服务器是否可以用作一个中继点。如果TURN服务器可以，那么它现在可以用来接收来自会话中其他设备的所有媒体信息，并将其转发到我们自己的浏览器。
虽然初始绑定请求并不费力(尽管在TURN服务器上仍然比发送到STUN服务器的查询更昂贵)，但真正的问题是传输的媒体信息。
如果你看一个简单的WebRTC视频，限制在500kbps左右，那么15分钟的视频就会消耗掉超过50MB的流量。
假设我们在回合服务器上平均每小时只进行10次会话，那么我们每个月的流量将达到360GB。这也许是一项非常小的服务，也不是很贵，但如果你按想比例扩大规模的话就会很贵：每次会话使用更多的带宽，而且平均每小时也会有有更多的会话——最终你将会有大量的数据流量。
以下是我们最近在testRTC上进行的压力测试的结果:
在一个有500名参与者的压力测试中，我们将参与者分成5个浏览器组，每段多方通话只运行6.5分钟，最终我们在每个方向都获得了52Gb的媒体流量。不到10分钟。
现在想想如果所有的流量都需要通过一个TURN服务器会发生什么，而且那个TURN服务器对所有人都是免费的。
把它们放在一起
STUN和TURN完全不同。在实际生产中我们都需要WebRTC服务。我们通常认为它们是部署在后台的单个服务器实体——我们并不担心STUN对于资源的需求，而专注于我们需要什么来实现TURN在相当规模和多个地理位置上运行。
关闭TURN服务器并为其配置凭据也是一种标准实践。对于WebRTC，这些凭据在本质上需要是短暂的——按需为每个会话创建，而不是为每个用户创建(在SIP中常常是这样)。
所以…
- 你就不要再想知道为什么没有免费的TURN服务器，或者为什么github上没有已经把配置好TURN的代码了。对任何人来说，免费提供这些都是毫无意义的
- 如果你碰巧碰到一个可以工作的服务器的用户/密码凭证，那么请不要利用，有人会为你的行为最终埋单，他可能是不知道这件事(我假设他不知道潜在的滥用)
- 如果你最终仍然使用那个TURN服务器，那个人在某个时候发现它并将您拒之门外，这明显不是你在为用户服务时想要发生的东西