Node-RED TCP request节点字节发送丢失 传输速率仅达预期1/10问题咨询

核心问题是你用错了Node-RED的TCP节点，和JS二进制处理逻辑无关：

• 你现在用的tcp request是请求-响应模式节点，设计用途是类似HTTP请求那样「发一次数据、等一次对端返回、再结束这次交互」：它每次收到待发送的消息，都会完整走一遍「新建TCP连接 → 发送数据 → 等待对端响应/等待超时 → 断开连接」的流程。该节点默认等待响应的超时时间为1秒，如果你Python服务端收到数据后没有回包，节点会等满1秒超时才会处理下一条待发消息，建连、等待的开销极大，根本支撑不了100ms间隔的高频连续发送。
• 你在debug节点看到的每秒10条消息，是function节点生成消息的频率，不是TCP节点实际发出去的频率。待发送的消息会在tcp request节点里排队，节点处理速度跟不上生成速度，最终实际发送速率就刚好只有你预期的1/10左右。
• 你写的二进制数据生成逻辑完全没问题：Python侧校验收到的字节内容正确、payload长度为20480，已经证明ArrayBuffer转Node.js Buffer的代码没有错误，这部分不需要修改。

• 将发送侧的tcp request节点替换为**tcp out节点**，这个才是用于TCP流式持续发送的节点。配置时选择「连接到远程TCP端口」，填入本地Python服务的监听地址和端口即可，节点会提前建立并长期保持TCP连接，不需要每次发送时重复建连，也不会等待服务端回包才发下一条，完全可以满足你100ms间隔发送20KB数据的需求。
• 额外提醒：TCP本身是无边界的流协议，Python服务端调用recv()时不保证每次刚好拿到20480字节，会出现粘包、半包情况，如果你要精准统计接收速率、解析完整数据帧，需要自己在应用层加拆包逻辑（比如固定长度帧、帧头+数据长度标识等方案）。

内容的提问来源于stack exchange，提问作者davegravy