1. Introduction (简介)

NAT 后面的主机可能希望与其他主机交换数据包，其中一些主机也可能位于 NAT 后面。为此，相关主机可以使用"打洞 (Hole Punching)"技术（参见 [RFC5128]）来尝试发现直接通信路径，即从一台主机到另一台主机的通信路径，该路径穿过中间的 NAT 和路由器，但不经过任何中继。

如 [RFC5128] 和 [RFC4787] 中所述，如果两台主机都位于行为不佳的 NAT 后面，打洞技术将会失败。例如，如果两台主机都位于具有"地址依赖映射 (Address-Dependent Mapping)"或"地址和端口依赖映射 (Address- and Port-Dependent Mapping)"映射行为的 NAT 后面，那么打洞技术通常会失败。

当无法找到直接通信路径时，必须使用充当数据包中继的中间主机的服务。该中继通常位于公共互联网中，并在两台都位于 NAT 后面的主机之间中继数据包。

本规范定义了一种称为 TURN 的协议，该协议允许 NAT 后面的主机（称为 TURN 客户端 (TURN Client)）请求另一台主机（称为 TURN 服务器 (TURN Server)）充当中继。客户端可以安排服务器向某些其他主机（称为对等方 (Peers)）中继数据包和从这些主机中继数据包，并可以控制中继的执行方式。客户端通过在服务器上获取 IP 地址和端口来实现这一点，该地址和端口称为中继传输地址 (Relayed Transport Address)。当对等方向中继传输地址发送数据包时，服务器将数据包中继给客户端。当客户端向服务器发送数据包时，服务器使用中继传输地址作为源将其中继到适当的对等方。

使用 TURN 的客户端必须有某种方式将中继传输地址传达给其对等方，并了解每个对等方的 IP 地址和端口（更准确地说，是每个对等方的服务器反射传输地址 (Server-Reflexive Transport Address)，参见第2节）。如何实现这一点超出了 TURN 协议的范围。一种可能的方式是客户端和对等方交换电子邮件消息。另一种方式是客户端及其对等方使用专用的"介绍 (Introduction)"或"会合 (Rendezvous)"协议（有关更多详细信息，请参见 [RFC5128]）。

如果 TURN 与 ICE [RFC5245] 一起使用，则中继传输地址以及对等方的 IP 地址和端口将包含在会合协议必须携带的 ICE 候选信息中。例如，如果 TURN 和 ICE 用作使用 SIP [RFC3261] 的多媒体解决方案的一部分，则 SIP 充当会合协议的角色，在 SIP 消息体内携带 ICE 候选信息。如果 TURN 和 ICE 与其他会合协议一起使用，则 [MMUSIC-ICE-NONSIP] 提供了有关会合协议必须执行的服务的指导。

尽管使用 TURN 服务器在两台位于 NAT 后面的主机之间实现通信非常可能成功，但这对 TURN 服务器提供商来说成本很高，因为服务器通常需要与互联网的高带宽连接。因此，最好仅在无法找到直接通信路径时才使用 TURN 服务器。当客户端和对等方使用 ICE 来确定通信路径时，ICE 将首先使用打洞技术搜索直接路径，仅在无法找到直接路径时才使用 TURN 服务器。

TURN 最初是为了支持使用 SIP 信令的多媒体会话而发明的。由于 SIP 支持分叉 (Forking)，TURN 支持每个中继传输地址有多个对等方，这是其他方法（例如 SOCKS [RFC1928]）不支持的功能。但是，已经注意确保 TURN 适用于其他类型的应用程序。

TURN 被设计为更大的 ICE NAT 穿透方法的一个组成部分。敦促 TURN 的实现者研究 ICE，并认真考虑将其用于他们的应用程序。但是，也可以在没有 ICE 的情况下使用 TURN。

TURN 是 STUN (Session Traversal Utilities for NAT，NAT 会话穿透实用程序) 协议 [RFC5389] 的扩展。大多数（尽管不是全部）TURN 消息都是 STUN 格式的消息。本文档的读者应熟悉 STUN。