RTCDataChannel API不提供任何类型的流量/控制或反压，这是否意味着发送者理论上可能会崩溃接收者的浏览器？在我看来，浏览器（Chrome，Firefox等都在引擎盖下使用SCTP），从SCTP连接读取并调度运行消耗数据包的js-callback。如果事件队列无法跟上发送者，则浏览器基本上会连续读取数据包，同时将数据包存储在缓冲区中，缓冲区会无限增长。因此，当你连接两个浏览器时，发送者实际上总是会压倒另一个浏览器，因为没有像TCP接收窗口或类似的东西那样的障碍。
这也适用于websocket api。
我只是错过了一些东西，或者这些API刚刚破解？如果我是对的，那么在与未经身份验证的浏览器交谈时（例如在torrent环境中），这将是一个严重的安全问题。
答案 0 :(得分：3)
webrtc数据通道曾经基于UDP。在此期间，浏览器强制进行人工限制以防止网络泛滥。直到chrome v32，我才相信这种情况。
现在数据通道基于SCTP，它具有内置流量控制（FC），并且不再有浏览器限制（感谢上帝）。控制FC的参数不通过API公开，但并不意味着没有FC。
我不熟悉Chrome / FF中webrtc的实现，但我不认为你可以通过简单的泛洪攻击来破坏浏览器。 ＆＃34;生产者比消费者更快＆＃34;是一个很老的问题。
那就是说，我一直在使用数据通道，已经有一年多了，并且我的浏览器几乎每天都在崩溃，所以webrtc实现中可能存在很多错误。希望他们不会对安全构成任何线索。
使用webrtc数据通道发送大量数据并不是一种特别愉快的体验。 API没有提供＆＃34;通道已准备好写入＆＃34;回调或任何类型的东西，所以，是的！你必须轮询bufferedamount值并尝试将其保持在最佳窗口内。在Windows版本的Chrome版本中，为了加重侮辱bufferedamount曾经被打破，它总是为0.但我认为他们已经在chrome v37或者那个时候解决了这个问题。
恕我直言，webrtc API并没有经过深思熟虑，但它完成了这项工作，说实话，我无法想到任何经过深思熟虑的js API。