TURN RFC中为何要单独定义TURN client而非仅使用Peer？

RFC 8445的术语定义对“TURN client”和“Peer”做了明确区分：

TURN client:
实现本规范的STUN客户端。

TURN server:
实现本规范的STUN服务器，负责在TURN client与其Peer之间中继数据。

Peer:
TURN client希望与之通信的主机。TURN server在TURN client与其Peer之间中继流量。Peer不使用本文档定义的协议与TURN server交互，仅接收TURN server发送的数据并向其发送数据。

我理解WebRTC是双向对等（Peer to Peer）模式，而非客户端/服务器模式。为什么RFC要专门定义“client”这个术语，而不是直接用“Peer”？如果没有“client”术语，TURN协议的哪些部分会无法明确规范？

Peer L和Peer R都可能在NAT之后，通过STUN获取服务器反射地址，这时两者都是TURN client。“client”术语是不是为了单独处理其中一方不在NAT后的场景？

“client”是不是指“会话发起方”，用来明确协议流程里的发起角色？但我觉得不用定义“TURN client”也能做到这一点。

核心原因：角色责任的本质差异 #

首先要明确：TURN协议本身是客户端-服务器架构，和WebRTC的P2P模式是互补关系，不是一回事。WebRTC用TURN来解决穿透失败后的中继问题，这时候TURN的角色划分不能直接套WebRTC的Peer概念。

• 协议交互的义务不同
  TURN client必须实现完整的TURN/STUN协议逻辑：比如发送分配请求、维护分配的生命周期、发送权限请求、处理中继地址的绑定等。而Peer不需要懂任何TURN协议——它只需要像和普通主机通信一样收发数据，完全不知道中间有TURN服务器存在。如果只用“Peer”，根本没法区分谁要和TURN服务器做协议交互，谁只负责纯数据收发。

• 解决非对称场景的必要性
  你提到的“一方不在NAT后”的场景确实是典型场景，但不是唯一场景：

  • 比如其中一方是公网服务器（比如直播服务器），它不需要用TURN，只需要接收TURN中继过来的数据，这时候它就是纯Peer，另一方是TURN client。
  • 即使双方都是NAT后的Peer，当它们通过TURN中继通信时，各自都是自己和TURN服务器交互的client，同时是对方的Peer。这时候“client”是相对于TURN服务器的角色，“Peer”是相对于通信对方的角色，两者不冲突。

• 和“会话发起方”无关
  “TURN client”和谁发起会话没关系，只看谁和TURN服务器建立协议交互。比如即使是被动接收连接的一方，只要它需要通过TURN中继来接收数据，它就得先向TURN服务器分配中继地址，这时候它就是TURN client。如果只用“Peer”，没法区分这个角色——总不能说“某个Peer要和TURN服务器发协议包，另一个Peer不用”，这样表述太混乱。

简单说：WebRTC的Peer是通信对等方的角色，而TURN client是和TURN服务器交互的协议角色，两者维度不同，必须分开定义才能把TURN的协议流程、责任边界说清楚。

内容的提问来源于stack exchange，提问作者mon