Cloudflare TURN 的计费基于从 Cloudflare 边缘发送到 TURN 客户端的数据量，如 RFC 8656 图 1 ↗ 中所述。这意味着这涵盖了成功身份验证后从 TURN 服务器发送到 TURN 客户端的所有数据，包括 TURN 协议开销。
Cloudflare Realtime TURN 服务的使用价格为每 GB 数据 0.05 美元。
位于 stun.cloudflare.com 的 Cloudflare STUN 服务是免费且无限制的。
在开始收费之前，有 1,000 GB 的免费额度。Cloudflare Realtime 账单作为 Cloudflare 账单上的单个行项目出现，涵盖 SFU 和 TURN。
Cloudflare Realtime TURN 与 Cloudflare Realtime SFU 或 Cloudflare Stream (WHIP/WHEP) 之间的流量不产生任何费用。
---
title: Cloudflare Realtime TURN 计费
---
flowchart LR
Client[TURN 客户端]
Server[TURN 服务器]
Client -->|"入网 Ingress（免费）"| Server
Server -->|"出网 Egress（收费）"| Client
Server <-->|不计入账单| PeerA[Peer A]
请查看 Cloudflare 的认证和合规性资源 ↗，并联系您的 Cloudflare 企业账户经理了解更多信息。
当使用加密（例如 TURN over TLS）时，Cloudflare Realtime TURN 支持 FIPS 140-3。TURN 本身无法控制在 TURN 数据层下方流动的数据的加密。为了对中继的媒体或数据进行端到端加密，TURN 之上的层必须提供该加密（例如，当 TURN 与 WebRTC 结合使用时使用 DTLS）。
Cloudflare Realtime TURN 服务器运行在 Cloudflare 的全球网络 ↗上。这是一个不断增长的全球网络，拥有分布在数百个地点的数千台机器，但 Cloudflare 的中国网络明显除外。
在企业版或自助服务计划中，Cloudflare Realtime TURN 服务在性能或功能水平上没有区别，但企业版计划 ↗的用户将获得优先支持、可预测的固定费率定价和 SLA 保证的优势。
Cloudflare 的中国网络不参与处理 Realtime 流量，来自中国的 TURN 流量将连接到中国以外的 Cloudflare 地点。
TURN 使用量会在 30 秒内显示在分析中。
当 Cloudflare Realtime TURN 与 WebRTC 结合使用时，Cloudflare 无法访问中继媒体的内容。这是因为 WebRTC 对所有媒体流都采用了数据报传输层安全（DTLS）加密，这在数据到达 TURN 服务器之前在通信的 peer 之间对数据进行了端到端加密。因此，Cloudflare 仅中继加密的数据包，无法解密或检查媒体内容，这可能包括音频、视频或数据通道信息。
从数据隐私的角度来看，Cloudflare 为运行 TURN 服务而处理的唯一信息是建立和维护中继连接所必需的元数据。这包括 TURN 客户端的 IP 地址、端口号和会话时间信息。Cloudflare 无法访问加密媒体流本身中包含的任何个人身份信息。
这种架构确保了通过 Cloudflare Realtime TURN 中继的媒体通信在参与者之间保持端到端加密，而 Cloudflare 仅作为中间中继服务运行，对加密内容不具备可见性。
TURN 协议 RFC 8656 ↗ 并没有讨论包装协议（例如 TURN over TLS）之外的加密。如果您将 TURN 与 WebRTC 结合使用，它将在 WebRTC 级别对数据进行加密。
Cloudflare Realtime TURN 的分配通过 anycast 路由归巢在距离 TURN 客户端最近的可用 Cloudflare 数据中心。如果连接的双端都使用 Cloudflare Realtime TURN，Cloudflare 将能够控制路由，并在可能的情况下通过 Cloudflare 骨干网路由 TURN 数据包。
TURN 和 SFU 解决不同的问题，通常结合使用。
使用 TURN 当您在两个 peer 之间有对等连接，且需要穿越 NAT 或防火墙时。两个 peer 直接通过中继交换媒体，无需任何服务器端媒体处理。
使用 SFU 当您需要扇出（即一个发布者将媒体发送给许多订阅者，或者许多发布者在一个组中交换媒体）时。SFU 在参与者之间转发选定的媒体流，并支持 simulcast 和订阅者端轨道选择等功能。
如果您的使用场景是一对一通信，例如操作员与远程设备之间的遥操作系统链路，通常仅使用 TURN 就足够了。对于该拓扑结构来说，添加 SFU 会带来不必要的复杂性。
没有。Cloudflare Realtime TURN 和 SFU 运行在 Cloudflare 全球网络的同一批机器上，并共享相同的数据路径。选择其中一个与另一个相比，没有实质性的延迟或吞吐量损失。
这一决定应由拓扑结构驱动，而不是性能：
- 使用 TURN 进行点对点中继。
- 使用 SFU 当您需要扇出、群组通话或轨道的选择性转发时，使用 SFU。
不一定。当两个 peer 都通过 Cloudflare Realtime TURN 中继时，两个 Cloudflare 边缘之间的流量可以使用 Cloudflare 骨干网，这意味着 Cloudflare 端到端地控制了路径。当只有一个 peer 使用 TURN 时，另一段链路需要通过公共互联网，延迟和数据包丢失率取决于该 peer 与最近的 Cloudflare 数据中心之间的互连情况。
双端使用 TURN 带来更一致的改善是可靠性和数据包丢失行为，而不是纯粹的延迟。骨干网延迟通常优于公共互联网，但延迟改善的大小因地理位置而异。数据包丢失率的降低通常更可预测。
可以。Cloudflare Realtime TURN 非常适合机器人遥控、远程车辆控制和车队管理工作负载，这些工作负载需要操作员与远程设备之间进行低延迟、双向的媒体或数据通道传输。
遥控操作通常在点对点模式下使用 TURN，一端位于操作员的网络上，另一端位于机器人的蜂窝网络或有线网路上联。WebRTC 和 DTLS 对媒体流提供端到端加密，Cloudflare Realtime TURN 负责 NAT 穿透并在两个端点之间中继。当两个端点都通过 TURN 连接时，Cloudflare 边缘之间的流量可以走 Cloudflare 骨干网，从而改善长距离链路上的丢包特性。
对于需要将机器人的遥测数据或摄像头画面分发给多个订阅者（例如操作员、主管和车队仪表板）的工作负载，除了 TURN 之外，还可以使用 Cloudflare Realtime SFU。在您控制连接双端的情况下，Cloudflare 的 Media over QUIC (MoQ) 实现也值得在遥测和遥控操作中进行评估，因为与 WebRTC 相比，它给您更明确的可靠性和重传行为控制。
与其它服务商相比，Cloudflare Realtime TURN 易于拥有严格防火墙的 IT 管理员使用，因为需要列入允许列表的 IP 地址非常少。您必须同时将 IPv6 和 IPv4 地址列入允许列表。
请将以下 IP 地址加入允许列表：
2a06:98c1:3200::1/1282606:4700:48::1/128141.101.90.1/32162.159.207.1/32
尽管不推荐这样做，但我们理解在极少数情况下硬编码 IP 地址可能是有用的。在这种情况下，您必须设置警报来检测来自 turn.cloudflare.com 的 DNS 响应（A 和 AAAA 记录）的变化，并在 DNS 更改后的 14 天内相应地更新硬编码的 IP 地址。请注意，此 DNS 响应可能会返回多个 IP 地址。此外，如果在连接到硬编码的 IP 地址时出现问题，您必须设置故障转移到 DNS 查询。除非在您的企业合同中另有规定，否则 Cloudflare 会尽力而为，但无法保证用于 TURN 服务的 IP 地址不会改变。有关静态 IP、保证和其他安排的更多细节，请与您的企业账户团队讨论。
位于 turn.cloudflare.com 的 TURN 服务也将响应绑定请求（“STUN 请求”）。
Cloudflare Realtime 凭据生成函数返回的 JSON 结构类似于 已过期的 RFC 草案 "draft-uberti-behave-turn-rest-00" ↗，但不包括 TTL 值。如果您需要此格式的响应，您可以在您的后端服务器或 Cloudflare Workers 中，将来自 Cloudflare Realtime 凭据生成端点的 JSON 修改为所需的格式。
数据包丢失在 UDP 中是正常现象，即使在可靠的连接上偶尔也会发生。但是，如果您观察到系统性的数据包丢失，请考虑以下情况：
- 您是否正在从单个 TURN 客户端以高吞吐量（>50-100Mbps）发送或接收数据？Realtime TURN 可能会丢包以指示您减慢速度。
- 您是否正在从单个 TURN 客户端发送或接收大量数据包，且数据包尺寸非常小（高数据包速率 > 5-10kpps）？Cloudflare Realtime 可能会丢包。
- 您是否正在以类似于端口扫描 ↗的高速率将数据包发送到新的唯一地址？
对于凭据的生成没有明确的限制。建议从 500 凭据/秒开始，并线性扩展。确保您使用了超过 50% 的已生成凭据。
您可以将凭据的过期时间设置为最长 48 小时。如果您需要您的 TURN 分配持续时间超过此限制，您将需要更新 ↗ TURN 凭据。
是。对于 TURN 客户端到 TURN 服务器的通信，Cloudflare Realtime 在 IPv4 和 IPv6 上均可用，但它不会像 RFC 6156 ↗ 中描述的那样发放 IPv6 中继地址。
不发放。如果指定了 REQUESTED-ADDRESS-FAMILY STUN 属性，Realtime TURN 不会遵循该属性，而将仅发放 IPv4 地址。
不支持。Realtime 未实现 RFC6062 ↗，且不会遵循 REQUESTED-TRANSPORT STUN 属性。
如果使用私有 IP 地址范围（例如环回地址、链路本地单播或多播网段）或属于 BYOIP 的 IP 地址，Cloudflare Realtime 将拒绝 CreatePermission 或 ChannelBind 请求。
如果您是 Cloudflare BYOIP 客户，并希望通过 Realtime TURN 连接到您的 BYOIP 范围，请联系您的账户经理获取进一步的详细信息。
TURN 分配没有最大持续时间限制。根据 RFC 8656 第 3.2 节 ↗，一旦分配了中继传输地址，客户端必须保持分配的存活。为此，客户端会定期向服务器发送 Refresh 请求。Refresh 请求需要使用有效的 TURN 凭据进行身份验证。凭据的最大持续时间为 48 小时。如果需要更长的分配时间，必须至少每 48 小时生成一次新凭据。
尽管这并不常见，但在某些情况下，TURN 分配可能会中断。这可能是由处理分配的 Cloudflare 服务器的维护引起的，也可能与导致 TURN 数据包到达不同 Cloudflare 数据中心的互联网网络拓扑结构变化有关。无论出于何种原因，强烈建议客户端支持 ICE 重启（ICE restart） ↗。
Cloudflare Realtime 将立即停止计费并停止记录分析使用情况。在短暂的延迟后，连接将被断开。