【ZeroRange WebRTC】RFC 5766:TURN 协议规范(中文整理与译注)

RFC 5766:TURN 协议规范(中文整理与译注)

说明:本文对 RFC 5766(Traversal Using Relays around NAT, TURN)进行中文整理与译注,聚焦工程落地所需的核心章节与流程,并辅以图示帮助理解。

参考:RFC 5766(https://datatracker.ietf.org/doc/html/rfc5766)\[0\]


摘要(Abstract)

  • 当终端位于 NAT 后,某些场景下直连不可行,需要使用中继服务器转发媒体/数据。
  • TURN 定义了一种"客户端控制中继并通过中继与对端交换包"的协议;可结合 ICE 使用,也可独立使用。
  • 相较其他中继协议,TURN 支持客户端使用"单个中继地址"与多个对端通信(通过权限与通道机制)。

运行概览(Overview of Operation)

  • 传输层:支持 UDP/TCP/TLS‑over‑TCP,常用 443 端口以提升企业网络可达性。
  • 分配(Allocation):
    • 客户端向 TURN 请求分配一个"中继地址"(Relayed Address);分配由 5 元组(客户端 IP/端口、服务器 IP/端口、传输协议)标识;有生命周期(Lifetime)。
    • 成功后,服务器返回 RELAYED-ADDRESS(中继地址)与 XOR-MAPPED-ADDRESS(客户端对外可见地址)。
  • 权限(Permission):
    • 客户端为"允许与之通信的对端地址"创建权限;权限有生命周期,过期则拒绝转发。
  • 发送机制(Send/Data):
    • 两种方式:Send Indication(开销较高、灵活)与 ChannelData(高效、需要通道绑定)。
  • 通道(Channel):
    • 为某对端绑定一个通道号,后续通过精简的 ChannelData 帧高效传输;通道也有生命周期。

术语与数据模型(Terminology & Model)

  • Allocation:一次分配,提供中继地址与状态,生命周期由 LIFETIME 控制。
  • Permission:允许向某对端地址转发数据,默认 300s;可刷新。
  • Channel:绑定某对端地址的通道号(14 位),减少包头与属性开销,提升效率。
  • Attributes(属性):TLV 结构,常见有 RELAYED-ADDRESSXOR-MAPPED-ADDRESSXOR-PEER-ADDRESSLIFETIMECHANNEL-NUMBERMESSAGE-INTEGRITYFINGERPRINT 等。
  • Long-Term Credential:长期凭证机制(USERNAME/REALM/NONCE/MESSAGE-INTEGRITY),用于认证与防重放(401/438)。

创建分配(Creating an Allocation)

  • Allocate Request:
    • 必带 REQUESTED-TRANSPORT(UDP/TCP),可带 LIFETIME(建议值根据应用而定)。
    • 使用长期凭证进行认证:携带 USERNAME/REALM/NONCEMESSAGE-INTEGRITY;若缺失或过期,服务端返回 401/438 并提供挑战参数(REALM/NONCE)。
  • Allocate Success Response:
    • 返回 RELAYED-ADDRESS(供对端向中继发送包)与 XOR-MAPPED-ADDRESS(客户端对外可见地址)。
    • 可返回实际的 LIFETIME,指明分配有效期。
  • 刷新(Refresh):
    • 在分配过期前发送 Refresh Request;设置 LIFETIME=0 可释放分配。

权限(Permissions)

  • CreatePermission:
    • 为一个或多个 XOR-PEER-ADDRESS 创建权限;服务器只转发来自被许可对端的包。
    • 默认有效期 300 秒;过期需要重新创建。
  • 安全性:防止无授权对端滥用中继;结合认证头字段,抵御攻击与误用。

发送机制:Send 与 Data Methods

  • Send Indication:
    • 客户端向 TURN 发送 Send Indication(含 XOR-PEER-ADDRESS 与负载),TURN 转发给对端;每个包带完整属性,开销较大。
  • Data Indication:
    • TURN 收到对端的数据时,向客户端发送 Data Indication(含对端地址与负载)。
  • 适用:控制面与低吞吐场景;或在通道绑定前临时使用。

通道(Channels)与高效传输

  • ChannelBind:
    • 将某对端地址绑定到通道号;成功后,客户端可使用 ChannelData 帧(短头部)收发,减少属性与解析开销。
  • ChannelData:
    • 高效承载 RTP 等实时媒体;要求已创建对应权限并通道绑定有效。
  • 生命周期与刷新:
    • 通道号绑定有超时;需定期刷新以保持有效。

安全与认证(Security & Auth)

  • 长期凭证:
    • REALM/NONCE/USERNAME/MESSAGE-INTEGRITY;防重放与挑战应答;错误码如 401 未授权、438 Stale Nonce。
  • 传输安全:
    • 在企业网络中,推荐使用 TLS‑over‑TCP(turns:,端口 443),提升可达性并与代理/负载均衡兼容;媒体承载可为 UDP 或 TCP(?transport=udp|tcp)。
  • 资源与防滥用:
    • 服务器可限制每账户的分配数量、权限数量与带宽;可记录审计与计费数据。

与 ICE 的关系(Usage with ICE)

  • TURN 是 ICE 的"最后手段"(relay 候选),在 host/srflx 失败时保证可达性。
  • ICE 将 RELAYED-ADDRESS 作为候选与对端交换;连接提名成功后,媒体经 TURN 中继转发。
  • 成本与时延:中继路径引入额外延迟与云端带宽/出网成本;UDP 优先、TCP/TLS 为退路。

工程要点(Practical Notes)

  • 避免分片:尽量控制包大小与 MTU,RTP 场景慎重设计负载。
  • 多对端通信:一个分配可服务多个对端,通过权限与通道实现隔离与高效。
  • 刷新策略:分配/权限/通道都需要在到期前刷新;保持 keepalive。
  • IPv6 支持:TURN 规范支持 IPv4/IPv6;注意地址族的权限与通道绑定一致性。

参考

  • 0\] RFC 5766 - TURN: https://datatracker.ietf.org/doc/html/rfc5766

相关推荐
赖small强3 小时前
【ZeroRange WebRTC】ICE 服务器列表解析(KVS WebRTC)
webrtc·stun·turn·ice
xinyu_Jina11 小时前
WebRTC的P2P实践:局域网文件传输中的信令、ICE与DataChannel架构解析
架构·webrtc·p2p
赖small强13 小时前
【ZeroRange WebRTC】TLS 底层原理与工作机制(深入解析)
webrtc·tls·ecdhe·tls 1.3·前向保密(pfs)·密钥派生(hkdf)·流量密钥
阿珊和她的猫13 小时前
WebRTC 技术深度解析:实时通信的未来引擎
前端·webpack·node.js·webrtc
赖small强13 小时前
【ZeroRange WebRTC】WebRTC 基于 STUN 的 srflx 直连原理与实现
webrtc·stun·turn·srflx·binding request
小柯博客13 小时前
STM32MP1 没有硬件编解码,如何用 CPU 实现 H.264 编码支持 WebRTC?
c语言·stm32·嵌入式硬件·webrtc·h.264·h264·v4l2
RTC老炮1 天前
webrtc降噪-PriorSignalModelEstimator类源码分析与算法原理
算法·webrtc
卜锦元1 天前
Mediasoup的SFU媒体服务转发中心详解(与传统SFU的区别)
音视频·webrtc·媒体
pp-周子晗(努力赶上课程进度版)1 天前
Node.js 模块系统选择-学习 CommonJS 和 ESM
node.js·webrtc