Javascript 这可能是什么原因>；webrtc数据通道消息中的1000ms延迟？
当我在两个浏览器之间设置一个数据通道（在同一网络上的两台不同机器上进行测试）时，在以下两种情况下，我得到了关于延迟的不同结果 案例1：仅发送/接收 当我将一端设置为发送测试消息时，间隔为70毫秒，我看到它们在另一端传入，没有明显的延迟。每个接收到的消息之间的时间接近70毫秒。到目前为止还不错 案例2：双方轮流发送和接收 当我设置双方在收到另一方的消息后立即发送消息时，距离上次发送已经70多毫秒了，一切都很顺利，除了有时。每隔几秒钟（不一致），我测量约1000毫秒的延迟。奇怪的是，绝大多数消息之间的时间间隔不是<200ms就是>~1000msJavascript 这可能是什么原因>；webrtc数据通道消息中的1000ms延迟？,javascript,network-programming,webrtc,lag,Javascript,Network Programming,Webrtc,Lag,当我在两个浏览器之间设置一个数据通道（在同一网络上的两台不同机器上进行测试）时，在以下两种情况下，我得到了关于延迟的不同结果 案例1：仅发送/接收 当我将一端设置为发送测试消息时，间隔为70毫秒，我看到它们在另一端传入，没有明显的延迟。每个接收到的消息之间的时间接近70毫秒。到目前为止还不错 案例2：双方轮流发送和接收 当我设置双方在收到另一方的消息后立即发送消息时，距离上次发送已经70多毫秒了，一切都很顺利，除了有时。每隔几秒钟（不一致），我测量约1000毫秒的延迟。奇怪的是，绝大多数消息之间
我在chrome和firefox（组合）中测试了这两种情况，其行为是相似的。我还在一个移动电话网络上测试了它（使用拴绳），它显示出同样的滞后，尽管不太常见。数据通道未配置任何特殊选项，因此它使用可靠、有序的连接 这可能是什么原因造成的？在我看来，它是可以修复的，因为向一个方向发送（无论哪种方式）都可以无延迟地正常工作。我还尝试使用单独的数据通道进行发送/接收，这并不重要
例子 下面是第二种情况的测试结果示例。它列出了1000次往返中超过200ms的所有往返时间
(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"
[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.25499999997561839.9099999997441768.6449999998951167.92999999391139.17500000001751173.88500000000931245.66000000000351075.375]我仍然没有弄清楚是什么导致了这个延迟。我希望有一个更平滑的图表。我几乎可以肯定这是由你的回合服务器造成的。
我在上个月做了一个非常类似的测试，所有数据包都是在几毫秒内通过TURN（使用我们自己的TURN服务器）接收到的。测试是用Firefox和Chrome完成的。虽然我仍然不确定是什么导致了问题，但我已经找到了解决方案。我的最佳猜测是，当一个对等方有一段时间没有发送数据（或者他们只是没有到达另一个）时，流量控制导致了问题 我注意到，当两个对等点以70毫秒的间隔相互发送数据包时，它们不会等待对方发送的数据包。只要我在等待传入数据包时延迟发送数据包，我就会得到>1000毫秒的延迟
因此，我现在所做的实际上是以稳定的速率发送数据包，即使它们是空的。我的应用程序要求依次发送数据，但我只是每隔一段时间检查是否有要发送的数据包，如果没有，我仍然发送空的数据包。这样，在我迄今为止所做的测试中，问题似乎得到了解决！可能与10有关人们正在讨论的00毫秒延迟？（像这样）
您已将发送间隔配置为70毫秒，这是一个相对较小的间隔。您是否尝试使用较大的间隔？此外，您可能还希望使用WebRTC iOS或Android本机解决方案进行一些测试，以便您可以知道问题是否来自核心WebRTC实现（我觉得不太可能），或某些浏览器限制。可能是您的代码中存在错误。我被此帖子触发：。虽然我的问题不是关于在后台选项卡中设置超时，但我有一种感觉，这可能是由类似的原因造成的。感谢链接！当您遇到此问题时，您是否同时关注两个选项卡/浏览器？如果您取消对选项卡或浏览器的关注，则回答是n我希望如此。W3C仍在寻找驱动程序的规格。闻起来像垃圾收集只是一个愚蠢的想法，你使用带电池的设备吗？如果是的话，你能插上电源再测试一次吗？大约一年前，我的voip应用程序出现了奇怪的延迟，结果我的客户使用了一些没有电源线的平板电脑，这降低了我的工作效率e网卡的优先级和造成的延迟。实际上没有涉及TURN服务器，所以我想这不可能是我的情况造成的。我想知道，在修复之前，如果一个数据包丢失了，对话是如何恢复的？也许，一个丢失的数据包在大约1秒后被重新传输？正如前面提到的，我使用了一个可靠的、有序的数据通道，这意味着DROPEd个数据包将被重新传输。因此数据包迟早会到达：）。修复后的情况也是如此。我的应用程序本身不重新发送数据包，它只发送更稳定的数据包流（一些是空的）所以我的假设是很有可能的。如果你不控制重传，你就不能相信包到达的时间。当然，但问题是我没有对此做任何改变。我没有像你想象的那样重传任何包。我只是以稳定的间隔发送额外的空包。所以我仍然依赖于相同的填充包发送到一个服务器rrive很快，但不知何故（我猜是由于soms流控制），它现在到达得更快了。我知道在应用程序级别上没有重新传输。可能，在您的场景中，您应该选择不可靠的数据通道，如果您能够处理，一些数据将丢失。否则，您需要保护数据包突发（重新传输成功后，延迟的数据包可能会在没有预期延迟的情况下到达）。感谢您的回复