javascript - WebRTC DataChannel 流量/控制/背压

Question

RTCDataChannel API 不提供任何类型的流量/控制或背压，这是否意味着发送方理论上可以使接收方的浏览器崩溃？在我看来，浏览器(Chrome、Firefox 等都在底层使用 SCTP)从 SCTP 连接读取并计划运行 js-callback 来消耗数据包。如果事件队列跟不上发送者，浏览器基本上会不断读取数据包，同时将数据包存储在缓冲区中，缓冲区会无限增长。因此，当您连接两个浏览器时，发送方实际上总是可以压倒另一个浏览器，因为没有像 TCP 接收窗口或类似的障碍。

这也适用于 websocket api。

是我遗漏了什么，还是这些 API 坏了？如果我是对的，那么在与未经身份验证的浏览器通信时(例如在 Torrent 场景中)，这将是一个严重的安全问题。

Answer 1

webrtc数据通道过去是基于UDP的。在那段时间里，浏览器施加了人为的节流以防止网络泛滥。我相信在 chrome v32 之前就是这种情况。

如今，数据通道基于具有内置流量控制 (FC) 的 SCTP，并且不再有浏览器节流(感谢上帝)。控制 FC 的参数没有通过 API 公开，但这并不意味着没有 FC。

我不熟悉 webrtc 在 Chrome/FF 中的实现，但我不认为你可以通过简单的洪水攻击使浏览器崩溃。 “生产者比消费者快”是一个很老的问题。

也就是说，我一直在使用数据通道，现在已经一年多了，几乎每天都看到我的浏览器崩溃，所以 webrtc 实现中可能有很多错误。希望它们不会对安全构成任何威胁。

使用 webrtc 数据通道发送大块数据并不是一种特别愉快的体验。 API 不提供“ channel 已准备好写入”回调或任何类似的东西，所以，是的!您必须轮询 bufferedamount 值并尝试将其保持在最佳窗口内。雪上加霜的是，bufferedamount 曾经在 Windows 版本的 Chrome 下被破坏，它始终为 0。但我认为他们在 chrome v37 或大约那个时候修复了这个问题。

恕我直言，webrtc API 没有经过深思熟虑，但它完成了工作，老实说，我想不出任何经过深思熟虑的 js API。