什么可能导致 webrtc 数据通道消息延迟 > 1000 毫秒？答案

【问题标题】：What might cause this >1000ms lag in webrtc data channel messages?什么可能导致 webrtc 数据通道消息延迟 > 1000 毫秒？
【发布时间】：2016-05-05 18:11:21
【问题描述】：

当我在 2 个浏览器之间设置数据通道（在同一网络上的 2 台不同机器上测试）时，在以下 2 种情况下，我得到了不同的延迟结果。

案例1：只发送/接收

当我设置一侧发送测试消息时，间隔例如 70 毫秒，我看到它们从另一侧进入，没有明显的延迟。每条接收消息之间的时间接近 70 毫秒。到目前为止一切顺利。

案例2：双方依次发送和接收

当我设置双方在收到对方的消息后立即发送消息，并且距离上次发送超过 70 毫秒，一切都很好，除了有时。每隔几秒（不一致），我会测量约 1000 毫秒的延迟。奇怪的是，绝大多数消息之间的时间要么 ~1000ms。

我在 chrome 和 firefox（组合）中测试了这两种情况，行为相似。我还在移动电话网络（使用网络共享）上对其进行了测试，结果显示相同的延迟，尽管频率较低。数据通道未配置任何特殊选项，因此它使用可靠、有序的连接。

这可能是什么原因造成的？在我看来，它可以修复，因为向一个方向（无论哪种方式）发送都可以正常工作而没有延迟。我还尝试使用单独的数据通道进行发送/接收，这没关系。

示例

这是第二种情况的测试结果示例。它是 1000 次往返时间超过 200 毫秒的所有往返时间的列表。

(Delay index) round trip time - round trip number - time
(0) 2192 - 0 - "2016-05-06T12:34:18.193Z"
(1) 1059 - 111 - "2016-05-06T12:34:22.777Z"
(2) 1165 - 372 - "2016-05-06T12:34:32.485Z"
(3) 1062 - 434 - "2016-05-06T12:34:35.585Z"
(4) 1157 - 463 - "2016-05-06T12:34:37.598Z"
(5) 1059 - 605 - "2016-05-06T12:34:43.264Z"
(6) 1160 - 612 - "2016-05-06T12:34:44.633Z"
(7) 1093 - 617 - "2016-05-06T12:34:45.857Z"
(8) 1158 - 624 - "2016-05-06T12:34:47.204Z"
(9) 1162 - 688 - "2016-05-06T12:34:50.401Z"
(10) 1158 - 733 - "2016-05-06T12:34:52.962Z"
(11) 1161 - 798 - "2016-05-06T12:34:56.163Z"
(12) 1157 - 822 - "2016-05-06T12:34:58.077Z"
(13) 1158 - 888 - "2016-05-06T12:35:01.281Z"
(14) 1160 - 893 - "2016-05-06T12:35:02.563Z"
(15) 1085 - 898 - "2016-05-06T12:35:03.768Z"

这是另一个示例，包括来自 chrome://webrtc-internals 的“PacketsSentPerSecond”图表：

在此测试中，发送了约 2100 个数据包，导致以下 26 次往返耗时超过 900 毫秒： [1762.6050000000014, 1179.7200000000012, 1765.375, 1149.945000000007, 1180.1399999999994, 1180.9550000000017, 1246.2450000000026, 1750.2649999999994, 1388.0149999999994, 1100.7499999999854, 4130.475000000006, 1160.1150000000052, 1082.4399999999878, 1055.2300000000105, 1498.715000000011, 1105.8850000000093, 1478.1600000000035, 2948.649999999994, 1538.2549999999756, 1839.9099999999744, 1768.6449999999895, 1167.929999999993, 1139.1750000000175, 1173.8850000000093, 1245.6600000000035, 1075.375]

我仍然没有弄清楚是什么导致了这种滞后。我希望得到一个更平滑的图表。

【问题讨论】：

可能是您的代码中的错误。
我被这篇帖子触发了：stackoverflow.com/questions/19475894/…。虽然我的问题与后台选项卡中的设置超时无关，但我有这种感觉，它可能是由类似的东西引起的......
感谢您的链接！当您遇到这种情况时，您是否保持两个选项卡/浏览器都集中？如果您不关注选项卡或浏览器，是的，那么我会期待这一点。 W3C 仍在寻找驱动程序来规范datachannel in workers。
闻起来像垃圾收集
只是一个愚蠢的想法，您使用带电池的设备吗？如果是这样，您可以在插入电源的情况下再次测试吗？大约一年前，我的 voip 应用程序出现了奇怪的延迟，结果我的客户使用了一些没有电源线的平板电脑，这降低了网卡的优先级并导致了延迟。

标签： javascript network-programming webrtc lag

【解决方案1】：

虽然我仍然不确定是什么导致了问题，但我已经找到了解决方案。我最好的猜测是，当其中一个节点有一段时间没有发送数据（或者他们只是没有到达另一个节点）时，问题是由流量控制引起的。

我注意到，当两个对等方以 70 毫秒的间隔相互发送数据包时，当他们不等待彼此的数据包时，没有问题。一旦我在等待传入数据包时延迟发送数据包，就会出现 >1000 毫秒的延迟。

所以我现在所做的实际上是以稳定的速率发送数据包，即使它们是空的。我的应用程序需要依次发送数据，但我只是每隔一段时间检查一下是否有要发送的内容，如果没有，我仍然发送一个空包。这样，问题似乎在我目前所做的测试中解决了！

【讨论】：

我想知道，在修复之前，如果数据包丢失，对话是如何恢复的？也许，大约 1 秒后重新传输了丢弃的数据包？
如前所述，我使用了可靠、有序的数据通道，这意味着丢弃的数据包将被重新传输。所以数据包迟早会到达:)。这同样适用于修复后的情况。我的应用程序本身不会重新发送数据包，它只是发送更恒定的数据包流（有些是空的）
所以我的假设很有可能。如果你不控制重传，你就不能相信包裹到达的时间。
当然，但问题是我没有对此进行任何更改。我不会像您假设的那样重新传输任何数据包。我只是以稳定的间隔发送额外的空包。所以我仍然依赖于相同的填充数据包很快到达，但不知何故（我猜是由于 soms 流控制），它现在更快到达。
我了解到应用层没有重传。可能，在您的场景中，您应该更喜欢不可靠的数据通道，如果您可以应对某些数据会丢失的情况。否则，您需要对数据包突发进行保护（重传成功后，延迟的数据包可能会在没有预期延迟的情况下到达）。

【解决方案2】：

也许这与人们正在讨论的 1000 毫秒延迟有关？（像这样setTimeout/setInterval 1000ms lag in background tabs (Chrome and Firefox)）

您将发送间隔配置为 70 毫秒，这是一个相对较小的间隔。您是否尝试过使用更大的间隔？此外，您可能还想使用 WebRTC iOS 或 Android 原生解决方案进行一些测试，以便您知道问题是来自核心 WebRTC 实现（对我来说似乎不太可能），还是某些浏览器限制。

【讨论】：

感谢您的回答。我确认它与 setTimeout/setInterval 无关。我不知道那个本机代码，谢谢你的建议！

【解决方案3】：

我几乎可以肯定这是由您的 TURN 服务器引起的。上个月我做了一个非常相似的测试，所有的数据包都是在几毫秒内通过 TURN 接收的（使用我们自己的 TURN 服务器）。测试是在 Firefox 和 Chrome 上完成的。

【讨论】：

实际上并没有涉及到 TURN 服务器，所以我猜这可能不会导致它。