作者：LENNART SCHULTE, JÖRG OTT, VARUN SINGH, CHARLOTTA LIUKAS
翻译：刘通
端到端通信的一个主要问题是，在许多情况下，这些端点并不在公共互联网中，而是位于网络（和端口）地址转换器（NAT）后面的专用地址空间中。随着互联网从DARPA项目发展成为全球范围的网络，很快就会明白IPv4的232地址空间早晚会用尽。
在20世纪90年代，开发了多种策略来延迟IPv4地址耗尽的时间，其中之一就是NAT的设计。NAT将端点的真实IP地址隐藏于世界其他地方，这使得端点之间建立端到端直接连接变得困难。这就是协助框架—包括STUN和TURN（或使用中继NAT穿越）—派上用场的地方。
平均约有30%的P2P会议有一个端点通过TURN服务器连接。如果没有TURN中继服务器的帮助，这些用户将无法进行通信。因此，开发者需要知道TURN服务器是什么，以及为什么它对WebRTC通话的重要性。
ICE和STUN
在讨论TURN之前，我们需要定义两个缩略词。
ICE是交互式连通性建立（Interactive Connectivity Establishment）的缩写，它定义了一种系统化的方式来寻找两个端点（通过NAT和防火墙）之间可能的通信选项，包括必要时使用中继。
STUN是NAT的会话遍历实体（Session Traversal Utilities for NAT）的缩写。STUN向请求端点提供其公共IP地址。STUN是一个相对轻量级的过程，之所以是轻量级是因为一旦STUN为请求者提供了可公开访问的IP地址，它就不再参与对话了。
当一个端点在NAT后面时，它只能看到它的本地IP地址。通话中的其他端点将无法使用此本地IP地址连接到端点，因为它可能是专用地址，或者防火墙不允许进行访问。在这种情况下，该端点可以要求STUN服务器提供其公共IP地址。参与者然后使用ICE过程并尝试使用公共IP地址建立连接，并且如果连接成功建立，则媒体直接在用户之间流动，而没有任何主动中继。处于所有实际的目的，STUN就会退出，然后等待下一次使用。
但是，上述情况只对某些NAT有用。在一些NAT实现中，端口将被转换为其他端口以及它所连接的IP地址。这种情况被称为“对称NAT”。STUN过程的公共IP地址不足以建立连接，因为端口也需要进行IP地址转换。
这就是为什么TURN服务器至关重要的原因。
TURN如何工作
上图简化了ICE的操作。该图分别描绘了具有两个和一个网络接口的Alice（A）和Bob（B）的节点，它们都支持IPv4和IPv6。
结果是，Alice有四个主机地址（A1，A1v6，A2，A2v6），Bob有两个（B1，B1v6）。 这些地址是它们自己的寻址领域内的地址，即在NAT A和NAT B后面的特定情况下。这些主机地址是从操作系统（1）本地获得的。
为了确定它们的公共领域IP地址，每个节点与STUN服务器进行交互并分别学习其服务器反射地址：C（A1），C（A2）和D（B1），D（B1v6）以及过程（2）。TURN中继服务器还可以提供STUN功能，并向终端提供其（公共）地址之一以中继分组。在这种情况下，节点（B）可以绑定到驻留在TURN服务器上的中继地址：D，Dv6。另个端点在offer（3）和answer（4）中交换他们的地址，并且一旦这个，两个端点就开始探测（以优先级顺序）以确定哪些地址可以互相访问（5）。一旦找到至少一个可用的地址对，节点就可以开始发送媒体流（6）。
上述过程说明了TURN服务器如何促成NAT防火墙后的对等端之间的通话。它还充当了中继—在将内容转发给客户端之前，将内容保存并缓存，然后将其发送到客户端的公共IP地址，并将其编目到客户端。TURN服务器需要合理数量的网络I/O容量才能在参与者之间中继媒体，而服务器的大小通常取决于并发端点的数量。
进行你的TURN过程
有很多开源的TURN服务器（比如Coturn或restund）。这些服务器维护良好，非常适合你的服务。或者你可以使用多个TURN平台即服务（PaaS）提供商中的一个，而不是缩放你自己的服务器（特别是在媒体流量较低时）。
缩放TURN服务器时主要需要注意发夹问题。当相对靠近的参与者将他们的媒体发送到位于相对较远位置的TURN服务器时，发夹问题就会发生。例如，德国的两名用户可能会将他们的媒体发送到美国东海岸的TURN服务器。另一方面，当特定地区的用户群可能较低时，服务器可能发生发夹问题。例如，东南亚的用户可能会被香港货新加坡的服务器转发。
TURN服务器非常重要，每个WebRTC实现都会根据其服务需求和客户所在的位置对TURN组件提出不同要求。最好的方法是从项目一开始就确保使用稳定、可缩放的TURN服务器。监控TURN服务器的使用情况，并尝试在WebRTC流量增加时对使用率的增长进行建模。
