news 2026/4/23 18:50:07

TCP 报文错乱的根本原因

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
TCP 报文错乱的根本原因

您遇到的问题是非常典型的TCP 粘包/拆包问题。让我详细解释原因和解决方案:

问题原因分析

  1. TCP 是流式协议,不是消息协议

    • TCP 把数据看作连续的字节流,没有消息边界

    • 发送方发送:"报文1" + "报文2"

    • 接收方可能收到:"报文1报文2"(粘包)或 "报" + "文1"(拆包)

  2. 您的代码问题分析

// 您的原始 TCP 代码可能类似这样: socket.on('data', (data) => { // 问题:这里可能收到不完整的报文或多个报文合并 console.log('收到数据:', data); // 直接发送响应 const response = messageFactory(type, deviceAddress, data); socket.write(response); // 如果前一次响应还没发完,就会和这次合并 });
  1. 缓冲区问题

    • Node.js 的socket.write()异步非阻塞

    • 快速连续调用write()会导致数据在缓冲区合并

    • 操作系统 TCP 缓冲区也会合并小数据包(Nagle 算法)

Socket.IO 为什么没有这个问题?

Socket.IO 在底层做了这些工作:

  1. 消息帧封装

    // Socket.IO 的消息格式 { type: 2, // 消息类型 data: [...], // 实际数据 id: 123, // 消息ID nsp: '/' // 命名空间 }
  2. 自动分包/组包

    • 添加消息长度前缀

    • 添加消息边界标识

    • 保证消息完整性

  3. 消息队列管理

    • 有序发送,避免并发写入冲突

    • 流量控制,避免缓冲区溢出

TCP 解决方案对比

方案原理优缺点
长度前缀法在消息前添加长度字段最可靠,但需要解析
分隔符法用特殊字符分隔消息简单,但分隔符不能出现在数据中
固定长度法所有消息等长简单,但不够灵活
Socket.IO完整的消息协议功能强大,但依赖特定库

为您的 Modbus 应用实现可靠 TCP 通信

方案1:基于 Modbus TCP 协议标准
const net = require('net'); // Modbus TCP 报文头:事务标识(2) + 协议标识(2) + 长度(2) + 单元标识(1) const MBAP_HEADER_LENGTH = 7; class ModbusTCPServer { constructor() { this.buffers = new Map(); // 存储每个连接的缓冲区 } createServer() { return net.createServer((socket) => { const connectionId = `${socket.remoteAddress}:${socket.remotePort}`; this.buffers.set(connectionId, Buffer.alloc(0)); socket.on('data', (chunk) => { this.handleData(socket, connectionId, chunk); }); socket.on('close', () => { this.buffers.delete(connectionId); }); }); } handleData(socket, connectionId, chunk) { // 1. 追加到缓冲区 let buffer = Buffer.concat([this.buffers.get(connectionId), chunk]); this.buffers.set(connectionId, buffer); // 2. 循环解析完整报文 while (buffer.length >= MBAP_HEADER_LENGTH) { // 读取报文长度(第5-6字节) const length = buffer.readUInt16BE(4); const fullMessageLength = MBAP_HEADER_LENGTH + length; // 3. 检查是否收到完整报文 if (buffer.length >= fullMessageLength) { // 提取完整报文 const message = buffer.slice(0, fullMessageLength); // 剩余数据保留在缓冲区 buffer = buffer.slice(fullMessageLength); this.buffers.set(connectionId, buffer); // 4. 处理报文 this.processMessage(socket, message); } else { // 等待更多数据 break; } } } processMessage(socket, message) { // 这里处理 Modbus 报文逻辑 console.log('收到完整报文:', message); // 发送响应(确保一次只处理一个请求) const response = this.createResponse(message); this.sendResponse(socket, response); } sendResponse(socket, response) { // 确保发送完整性 return new Promise((resolve, reject) => { socket.write(response, (err) => { if (err) reject(err); else resolve(); }); }); } }
方案2:请求-响应队列(避免并发写入)
class TcpConnection { constructor(socket) { this.socket = socket; this.sendQueue = []; this.isSending = false; this.buffer = Buffer.alloc(0); } // 接收数据处理(防粘包) onData(chunk) { this.buffer = Buffer.concat([this.buffer, chunk]); // 基于 Modbus TCP 长度字段解析 while (this.buffer.length >= 7) { // MBAP 头长度 const pduLength = this.buffer.readUInt16BE(4); const frameLength = 6 + pduLength; if (this.buffer.length >= frameLength) { const frame = this.buffer.slice(0, frameLength); this.buffer = this.buffer.slice(frameLength); this.handleFrame(frame); } else { break; // 等待更多数据 } } } // 发送数据(防并发写入) send(data) { return new Promise((resolve, reject) => { this.sendQueue.push({ data, resolve, reject }); this.processQueue(); }); } async processQueue() { if (this.isSending || this.sendQueue.length === 0) return; this.isSending = true; const { data, resolve, reject } = this.sendQueue.shift(); try { // 使用 drain 事件确保缓冲区清空 if (!this.socket.write(data)) { await new Promise(resolve => this.socket.once('drain', resolve)); } resolve(); } catch (err) { reject(err); } finally { this.isSending = false; this.processQueue(); } } }
方案3:使用现有库(推荐)
const Modbus = require('jsmodbus'); const net = require('net'); // 使用成熟的 Modbus 库处理协议细节 const server = net.createServer((socket) => { const modbusServer = new Modbus.server.TCP(socket, { // 设备寄存器 0: [0, 0, 0, 0], // 保持寄存器 1: [1, 1, 1, 1] // 输入寄存器 }); // 自动处理粘包拆包问题 modbusServer.on('readCoils', (request) => { // 处理请求 }); }); server.listen(502, () => { console.log('Modbus TCP 服务器启动'); });

总结

  1. Socket.IO 解决了 TCP 粘包问题是因为它实现了完整的消息协议

  2. 如果要支持原始 TCP,必须自己处理消息边界

  3. 推荐使用长度前缀法,这是最可靠的方式

  4. 避免并发写入,使用队列控制发送顺序

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/4/1 17:16:56

【2025最新】基于SpringBoot+Vue的图书进销存管理系统管理系统源码+MyBatis+MySQL

摘要 随着信息技术的快速发展,图书进销存管理系统的需求日益增长,传统的手工管理方式已无法满足现代图书行业的高效运营需求。图书进销存管理系统通过数字化手段实现对图书采购、销售、库存等环节的精准管理,有效提升工作效率并减少人为错误。…

作者头像 李华
网站建设 2026/4/23 11:35:40

elasticsearch数据库怎么访问:零基础实战入门

零基础也能上手:如何真正“访问”Elasticsearch?实战全解析你有没有遇到过这样的问题——想查点日志、做个搜索功能,别人随口一句:“用 Elasticsearch 啊。”可当你兴冲冲打开浏览器准备连接数据库时,却发现……它没有…

作者头像 李华
网站建设 2026/4/23 11:32:10

SpringBoot+Vue 电影评论网站管理平台源码【适合毕设/课设/学习】Java+MySQL

摘要 随着互联网技术的快速发展,在线电影评论平台逐渐成为用户分享观影体验和获取电影信息的重要渠道。传统的电影评论方式受限于时间和空间,无法满足用户即时互动的需求。基于SpringBoot和Vue的电影评论网站管理平台旨在提供一个高效、便捷的评论交流环…

作者头像 李华
网站建设 2026/4/23 16:13:50

slice / map 在 Go GC 与内存碎片上的真实成本

在 Go 服务的性能问题中,GC 压力与内存碎片往往比 CPU 更早成为瓶颈。而在绝大多数业务系统里,真正制造这些问题的,并不是“复杂对象”,而是被大量、无意识使用的 slice 与 map。它们语义简单,却是 内存行为最复杂的两…

作者头像 李华
网站建设 2026/4/23 14:49:15

usblyzer解析自定义USB协议的数据方法指南

用 usblyzer 破解自定义 USB 协议:从抓包到逆向的实战全解析你有没有遇到过这样的场景?手头一个工业传感器,只有驱动程序和上位机软件,却拿不到通信协议文档。你想写个自己的控制程序,但完全不知道主机发了什么命令、设…

作者头像 李华
网站建设 2026/4/23 13:17:38

USB Serial Port驱动下载与设备管理器状态分析全面讲解

从驱动下载到设备识别:彻底搞懂USB转串口的那些坑你有没有遇到过这样的场景?刚拿到一块崭新的ESP32开发板,兴冲冲插上电脑准备烧录程序,结果打开设备管理器——“未知设备”,连个COM口影子都没有。或者更糟&#xff1a…

作者头像 李华