RTCDataChannel API不提供任何类型的流/控制或背压,这是否意味着从理论上讲,发送方可能会使接收方的浏览器崩溃?在我看来,浏览器(Chrome,Firefox等均在后台使用SCTP),从SCTP连接中读取数据并安排运行消耗数据包的js回调。如果事件队列无法跟上发件人的速度,浏览器基本上会连续读取数据包,同时将数据包存储在缓冲区中,缓冲区会无限期地增长。因此,当您连接两个浏览器时,发送者实际上总是会淹没另一个浏览器,因为没有像TCP接收窗口之类的障碍。
这也适用于websocket api。
我只是错过了一些东西还是这些API刚刚坏了?如果我是对的,那么在与未经身份验证的浏览器通信时(例如在洪流场景中),这将是一个严重的安全问题。
最佳答案
webrtc数据通道以前基于UDP。在此期间,浏览器施加了人为限制,以防止网络泛滥。我认为,直到chrome v32都是如此。
如今,数据通道基于SCTP,该SCTP具有内置的流控制(FC),不再有浏览器限制(感谢上帝)。控制FC的参数没有通过API公开,但这并不意味着没有FC。
我不熟悉Chrome / FF中webrtc的实现,但我认为您无法通过简单的泛洪攻击使浏览器崩溃。 “生产者比消费者快”是一个相当老的问题。
就是说,我已经使用数据通道一年多了,几乎每天都看到我的浏览器崩溃,因此webrtc实现中可能存在许多错误。希望他们不会对安全构成任何威胁。
使用webrtc数据通道发送大量数据并不是特别令人愉快的体验。该API不提供“通道已准备就绪”回调或任何形式的回调,因此,是的,您必须轮询bufferedamount
值并将其保留在最佳窗口内。为了增加侮辱性伤害,bufferedamount
以前在Windows版本的Chrome中会被破坏,它始终为0。但是我认为他们在chrome v37或大约那时修复了该问题。
恕我直言,webrtc API并不是经过深思熟虑的,但是它确实可以完成工作,老实说,我无法想到经过深思熟虑的任何js API。