RTCDataChannel API 不提供任何类型的流/控制或背压，这是否意味着发送方理论上可以使接收方的浏览器崩溃？在我看来，浏览器（Chrome、Firefox 等都在后台使用 SCTP）从 SCTP 连接中读取数据并安排运行 js-callback 来消耗数据包。如果事件队列跟不上发送者的速度，浏览器基本上会不断地读取数据包，同时将数据包存储在一个无限增长的缓冲区中。因此，当您连接两个浏览器时，发送方实际上总是可以压倒另一个，因为没有 TCP 接收窗口或类似的障碍。
这也适用于 websocket api。
我只是错过了一些东西还是这些 API 只是坏了？如果我是对的，那么在与未经身份验证的浏览器交谈时（例如在洪流场景中），这将是一个严重的安全问题。
webrtc 数据通道过去是基于 UDP 的。在那段时间里，浏览器进行了人为的限制，以防止网络泛滥。我相信在 chrome v32 之前就是这种情况。
如今，数据通道基于 SCTP，它具有内置的流量控制 (FC)，并且不再有浏览器限制（感谢上帝）。控制 FC 的参数不会通过 API 公开，但这并不意味着没有 FC。
我不熟悉 Chrome/FF 中 webrtc 的实现，但我不认为你可以通过简单的洪水攻击使浏览器崩溃。“生产者比消费者快”是一个相当古老的问题。
也就是说，我一直在使用数据通道一年多，几乎每天都看到我的浏览器崩溃，所以 webrtc 实现中可能存在很多错误。希望他们不会对安全构成任何威胁。
使用 webrtc 数据通道发送大块数据并不是特别愉快的体验。API 不提供“通道已准备好写入”回调或任何类似的功能，因此，是的！您必须轮询该bufferedamount值并尝试将其保持在最佳窗口内。雪上加霜的bufferedamount是，在 Windows 版本的 Chrome 下曾经被破坏，它总是 0。但我认为他们在 chrome v37 或大约在那个时候修复了这个问题。
恕我直言，webrtc API 没有经过深思熟虑，但它确实可以完成工作，老实说，我想不出任何经过深思熟虑的 js API。