WebRTC 上的延迟/带宽答案

【问题标题】：Latency/bandwidth on WebRTCWebRTC 上的延迟/带宽
【发布时间】：2015-12-07 06:40:37
【问题描述】：

我研究了使用 webRTC 构建应用程序的带宽使用情况。

我知道 WebRTC 用于实时 P2P 通信。

我不确定外部信令服务器或本地信令服务器是否会影响应用程序的延迟/带宽？由于信令服务器仅在初始连接期间用于建立主机和对等方之间的通信。

就使用的带宽而言，使用外部信令服务器与本地服务器相比会有什么不同吗？

【问题讨论】：

标签： webrtc

【解决方案1】：

一些信令解决方案提供 TURN 功能，而另一些则不提供。这两种情况都会影响您的延迟和带宽。

如果 TURN 可用，您的对等方可能会回退到中继连接。这将不可避免地增加延迟，并且还可能限制带宽。

如果您的信令基础设施不包括 TURN，这两个对等点将具有无限延迟和零带宽（换句话说，它们将无法进行实时通信）。

你可以在http://www.html5rocks.com/en/tutorials/webrtc/infrastructure/找到精美的插图。

【讨论】：

其实信令服务器本身对TURN和STUN一无所知。它不能提供 TURN，因为这不是它应该使用的东西。虽然，某些框架可以将 TURN/STUN 产品集成到他们的信号解决方案中。
信令确实携带与 STUN/TURN 间接相关的 ICE 候选。
@fycth：我会说你接受对信号的“狭隘”解释。为了便于讨论，我认为信令服务器（请注意，我试图谨慎地使用术语信令解决方案）作为负责建立 P2P 连接的基础设施。
@AlexCohn 信令的作用是让对端在建立直连之前交换数据。 TURN/STUN 参数在创建新的对等连接时由 Web 浏览器传递给 RTCPeerConnection。这个阶段甚至发生在信令之前——首先，你创建一个对等连接对象（将 TURN/STUN 选项传递给函数），然后你才能进入信令阶段——调用提议或应答函数。因此，TURN/STUN 与信令基础设施无关。尽管如此，某些框架可以将 TURN 选项集成到信令中——但这不是规则
是否有任何软件/工具可以测量视频广播使用了多少带宽？

【解决方案2】：

信令服务器仅用于建立直接连接。通过信令服务器传输的数据量非常低。直连建立后，信令服务器不在表中。

关于 Alex 的评论和 TURN/STUN 解决方案：信令服务器与 TURN 或 STUN 无关 - 这与您正在处理的某个网站（或特定框架）有关。信令服务器本身对 TURN 或 STUN 一无所知。信令的作用是允许对等点在建立直接连接之前交换数据：对等点交换网络和媒体细节，它们通过信令服务器进行，因为在那个阶段他们还不能建立直接连接。 TURN/STUN 参数在创建新的对等连接时由 Web 浏览器传递给 RTCPeerConnection 方法。这个阶段甚至发生在信令之前：首先，您创建一个对等连接对象（将 TURN/STUN 选项传递给函数），然后您才能进入信令阶段 - 调用 createOffer 或 createAnswer 方法。因此，TURN/STUN 与信令基础设施无关。尽管如此，某些框架可以将 TURN 选项集成到信号中——但这不是规则。

所以，对您的问题的简短回答：信令服务器不会影响延迟/带宽。虽然，某些特定的 WebRTC 框架/解决方案可能会违反这一点。

【讨论】：