据我了解,Node 事件 IO 模型的后果之一是,一旦您连接了接收事件处理程序(或否则开始监听数据)。
如果接收方不能足够快地处理传入的数据,则可能会导致“无限并发”,即引擎盖下的节点继续尽可能快地从套接字读取数据,在事件循环上调度新的数据事件而不是阻塞套接字,直到进程最终耗尽内存并死亡。
接收方不能告诉节点放慢它的读取速度,否则会允许 TCP 的内置流量控制机制启动并向发送方指示它需要放慢速度。
首先,到目前为止我所描述的是否准确?有什么我错过的东西可以让节点避免这种情况吗?
Node Streams 备受吹捧的功能之一是自动处理背压。
AFAIK,(tcp 套接字的)可写流可以判断它是否需要减速的唯一方法是查看socket.bufferSize
(指示写入套接字但尚未发送的数据量)。鉴于接收端的 Node 总是尽可能快地读取,这只能表明发送方和接收方之间的网络连接速度较慢,而不是接收方是否跟不上。
其次,Node Streams 自动背压能否在这种情况下以某种方式工作以处理无法跟上的接收器?
这个问题似乎也影响了通过 websockets 接收数据的浏览器,原因类似,websockets API 没有提供一种机制来告诉浏览器减慢它从套接字读取的速度。
对于 Node(和使用 websockets 的浏览器)来说,这个问题的唯一解决方案是在应用程序级别实现手动流控制机制,明确告诉发送进程放慢速度吗?