翻译：刘通
很遗憾的通知您。。。是的。。。
这是我最近突然想到的问题，而且令我惊讶的是这个问题并不是那么容易想出答案，这也让我所开的WebRTC架构课程更加的有必要参加了。有一家公司认为他们既然有在公共IP地址上的媒体服务器，所以应该就不再需要运行TURN服务器了。但显然，这么做只会使他们的服务的连接率降低。
在我写这篇文章的时候，这种事情很常见，仅仅在去年我就遇到了运营商的三种做法使他们自己服务的连接受到不好的影响：
1.他们根本不用TURN，完全依赖于在公共IP地址上的媒体服务器
2.他们根本不用TURN，觉得STUN对于P2P服务就完全够用了（！）
3.他们在TCP和TLS连接的时候不配置TURN，认为UDP中继完全够用了
简单的评价一下：这些完全不够！
我有点跑题了，下面我想要解释一下为什么第一个例子会使连接失败：
为什么对于你的媒体服务器来说只是有公共IP地址是不够的呢？
WebRTC的通信传输是端到端形式的，至少是这样的：
但是上述情况并不是每次都会正常运行，因为可能两个浏览器的其中一个，或者两个浏览器都处于专用网络上，所以他们其实并没有一个公共地址可以使用—或者我们不知道地址。如果二者其一具有公共IP，问题都会简单的多—一端会将数据传递给这个IP地址，然后通过这个生成的“针孔”，数据就可以以另一种方式传输了。
最终结果呢？如果你将你的媒体服务器搭建与公共IP地址上—你觉得自己在某种程度上成功了。但实际情况并不是这样。
需要注意的是，你应该只打开那些需要用到的端口。但是所有的互联网数据都是通过HTTP（s）传输，而且HTTP（s）是通过TCP传输—你只能够阻拦UDP，并且只能用它。
经常会被忽视的一点是WebRTC会为了保证其媒体流而使用UDP。除非需要中继TCP/TLS的TURN服务器，并且被配置好。我咨询了一下我的同事关于他们所观察到的数据传输，得到了如下图表所示的情况：
大约有20%的会话需要用到TCP或者TLS上的TURN服务器—难怪只是有一个配置了公共IP地址的媒体服务器是不够的。
哦，还有当我们讨论安全性的时候—从长远角度上看，我不确定你是否真的想让你的媒体服务器没有任何保护的暴露在互联网上，更不要说还要处理像DDoS这样的麻烦的事情。
那么你应该怎么做呢？
确保你的服务中配置有TURN服务器
·但是确保在其中TCP和TLS能够工作并且在搭建在你的对等端连接配置中
·我不在乎你是否将这个工作做为你媒体服务器的一部分，但是一定要有你自己搭建的TURN服务器，或者使用第三方的服务
测试已经有了的配置
·在你的测试机上限制UDP，并且在现实网络中完成这件工作
·或者就用testRTC好了—我们提供这项在特定场景下使用的简单机制
最后，无论你怎么做，千万不要觉得在你的媒体服务器中有公共IP地址就足够了！
