WebRTC学习进阶之路系列总目录：https://blog.csdn.net/xiaomucgwlmx/article/details/103204274
什么是信令
信令是协调通信的过程。为了使WebRTC应用程序能够建立一个“通话”，其客户需要交换以下信息：
# 会话控制消息用于打开或关闭通信
# 错误消息
# 媒体元数据，如编解码器和编解码器设置，带宽和媒体类型
# **数据，用于建立安全的连接
# 网络数据，如外界缩减的主机IP地址和端口
这个信令过程需要一个方式使客户来回地进行消息传递。这个机制不是由WebRTC API来实现的：你需要自己去搭建它。我们在下面介绍一些构建信令服务的方法。首先，需要先有一些背景……
为什么信令不是由WebRTC定义的？
为了避免出现冗余，并最大限度地提高与已有技术的兼容性，WebRTC标准并没有规定信令方法和协议。JavaScript会话建立协议JSEP概述了这种方法：
WebRTC通话建立的思想是完全指定和控制媒体平面，但是尽可能将信令平面留给应用程序。其原理是，不同的应用程序可能更喜欢使用不同的协议，例如现有的SIP或Jingle呼叫信令协议，或者对于特定应用程序定制的东西，可能是针对新颖的用例。在这种方法中，需要交换的关键信息是多媒体会话描述，其指定了建立媒体平面所必需的传输和媒体配置信息。
JSEP的架构也避免了浏览器不得不保存状态，即作为一个信号状态机。如果信号数据在每次刷新页面的时候都会发生丢失，就会出现问题。相反，信号状态机可以保存在服务器上。
信令服务器
我们每一个人的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++编写的。
为什么要将他们分开？
因为他们彼此互不相同，有不同的功能，需要被设置在不同的地方，所以逻辑上要把它们分开配置，而且准备好在需要的时候也要在现实将它们分开。
后续我们有时间会来一步一步地自己搭建一个信令服务器。
WebRTC学习进阶之路系列总目录：https://blog.csdn.net/xiaomucgwlmx/article/details/103204274