信令服务器
我们每一个人的WebRTC产品中一定都有信令服务器。
这是为什么呢？
因为没有信令服务器，就没有网络通话。完全进行不了任何通话，甚至连简单的Hello World都完成不了。答案就是这么简单。
你可以将信令服务器和你的应用服务器配置在一起。
下面这些关于服务器的特点你可能已经知道了：
#1 你可以配置一个服务器来平行地处理1000个，甚至100,000个连接和会话。
#2 这些服务器必须有所连接用户的状态，以保证它们很难超出容量范围。
#3 通常，这些服务器所作出的决定是依据外部数据库得出的。
#4 几百毫秒的延迟对于这些服务器来说是可以接收的，但是但是如果没有正确的设计和实施的话，它很容易出错
另外信令服务器还是用高层语言编写的，比如Java，Node.js，Rails，Python，PHP（我的天啊）等等。
NAT穿越服务器
我在这里说的是STUN和TURN。
而且是的，通常我们会把STUN“塞”到TURN中去。在这二种之中，TURN是一头占用资源的巨兽，但是STUN可以被依附到同一个服务器上，因为STUN和TURN的目的是一样的（以合适的方式获取媒体流）。
这就是我为什么在这里忽略STUN而只是将注意力集中在TURN上的原因。
有的时候人们会忘记TURN。他们之所以会忘记的原因是WebRTC在两个浏览器标签页之间，或者同一个办公室的两个同事之间运行的很好。这是因为这两个场景根本不需要用到TURN。然后他们就把产品发出去了。后果可想而知。
TURN作用是在会话参与方无法直接连接其他参与者的时候，在他们之间传递媒体。这种传递机制的两个特点：
#1 TURN会吞噬掉大量的带宽资源。
#2 你要做的是尽可能将你的TURN服务器部署在参与方附近。这是从TURN服务器出发提高媒体质量、降低延时的唯一方法。而你会对网络有更多的控制。
尽管你有可能不需要用很多TURN服务器，但是你最好还是从你使用的云服务提供商那里办一个。
我所知的绝大多数NAT穿越服务器都是用C/C++编写的。
媒体服务器
媒体服务器不是必需的。媒体服务器其实并不是规范的一部分—只是用来满足你的一些特定功能的。群组通话和录音就是一个好例子，基本上都是要通过媒体服务器才能进行传输的。
但是问题是，相比于WebRTC所需的其他服务器，媒体服务器所消耗的资源要多的多。
而且媒体服务器的规范与其他服务器都不一样。这就是为什么大多数情况下都把媒体服务器“隔离”安放的原因。
可以将媒体服务器和TURN服务器配置在一起。但是我大多数情况下不赞成这种做法，因为相比于媒体服务器，TURN更要面向网络。而且我现在还没听说过有黑客攻击过媒体服务器，我觉得这可能只是一个时间早晚问题。
媒体服务器通常是用C/C++编写的。
为什么要将他们分开？
因为他们彼此互不相同。
它们有不同的工作。
而且他们需要被设置在不同的地方。
所以逻辑上要把它们分开配置，而且准备好在需要的时候也要在现实将它们分开。