干上位机这些年被问得最多的问题就是我这套系统通信速度能到多少说实话这个问题没法一句话回答。厂家手册写的支持115200波特率、响应时间10ms看着挺美真到现场跑起来实际速度能打对折就不错了。今天不扯虚的从物理层到应用层一个个拆开算顺便把那些年我踩过的速度坑都倒出来。一、串口RTU理论速度和实际速度是两码事先算理论天花板。波特率9600意味着每秒9600个比特。但别忘了串口每个字节有起始位、停止位有的还有校验位。8N1格式下一个字节实际要传10个比特1个起始位8个数据位1个停止位。所以每秒能传的字节数 9600/10 960字节/秒。一个读寄存器的请求帧大约8字节回复帧大约9字节读2个寄存器的话一来一回算上帧间隔大概20字节。960/20 48次/秒。也就是说9600波特率下理论极限每秒能读48次。波特率提到115200理论速度 115200/10 11520字节/秒11520/20 576次/秒。看着挺美对吧但是这是理想值现实立马打折。第一个折从站响应时间。很多设备收到请求后不是立马回复的内部要处理、要读内存、要组包这个过程少则几毫秒多则几十上百毫秒。你发得再快它回得慢总线照样空等。第二个折帧间隔。RTU靠3.5字符静默判断帧结束9600下约3.5ms115200下约0.3ms。但很多设备的收发切换需要时间RS485从发转收也需要稳定时间实际间隔往往要加几毫秒甚至十几毫秒的延时。第三个折总线占用。多从站共享一条总线主站轮询时每个从站得排队等。你挂32个设备就算每个只花10ms一圈下来320ms一秒只能轮三圈出头。我实际测试过的结果9600波特率单从站、读4个寄存器稳定跑下来大概25~30次/秒。115200能跑到150~200次/秒。跟理论极限都差着一截。二、TCP/IP以太网快但没那么快TCP走以太网带宽动不动就100Mbps甚至千兆这点Modbus数据量连牙缝都塞不满。理论算一下一帧TCP请求约70字节含以太网头、IP头、TCP头、MBAP头、数据回复约80字节。千兆网理论传输速度125MB/s算下来一秒能发一百多万帧。但实际上呢第一个卡脖子的是从站处理能力。大多数PLC或者嵌入式设备协议栈是软实现的CPU就那么点算力。你一秒发1000个请求过去它直接CPU跑满响应延迟从10ms飙升到500ms甚至开始丢包。我测过某国产PLC一秒发200个读请求就开始丢包了300个直接死机重启。第二个是TCP协议栈本身的开销。每次收发都有系统调用、内存拷贝、中断处理这些在PC上不是事但在嵌入式设备上每帧几微秒到几十微秒的开销累积起来就大了。第三个是连接数限制。很多设备同时只支持几个TCP连接你开太多连接不但不加速反而因为连接切换和资源竞争拖慢速度。实际工程中一个TCP连接稳定跑下来每秒读30~50次是常态。优化得好的能到100次/秒再往上就要看设备和网络环境了。三、真正拖慢速度的从来不是协议而是架构很多人一上来就盯着波特率、网速其实那点差异在架构缺陷面前不值一提。案例一串行轮询一个卡全部卡挂了20个从站每个读10个寄存器。单次通信耗时30ms包含收发和从站延迟20个站串行轮询一圈600ms。如果其中一个从站响应慢比如某老设备要100ms才回一圈直接飙到1秒以上。优化方案把轮询周期拉长或者把慢设备单独拎出来用另一个线程处理。别让一颗老鼠屎坏了一锅粥。案例二UI线程和通信线程混在一起早期写过这种代码DataReceived事件里直接更新DataGridView数据一多界面卡死。通信线程被UI渲染阻塞通信速度直接掉到个位数。解决方案生产者消费者模式通信线程只管收数据丢进队列UI线程从队列取数据刷新。两不耽误。案例三读写操作抢锁多线程环境下读操作频繁写操作偶尔触发。用一把大锁把整个通信对象锁住写操作执行时所有读操作阻塞等待。表面上单次读写很快但平均下来吞吐量被锁竞争拖累。改善方法读写分离读走一个连接写走另一个连接或者用读写锁ReaderWriterLockSlim让多个读可以并发。四、如何测出真实速度别信软件显示很多人用Modbus调试工具测速度看软件上显示的XX次/秒就当真了。这里面水分大得很。正确的测法抓包时间戳。用Wireshark抓TCP包看两次请求之间的时间间隔。用串口监听工具抓RTU数据看每帧的起始时间戳。这才是真实数据。还要注意区分发送频率和有效吞吐量。你一秒发1000个请求出去设备回了500个软件计数可能显示1000次/秒但实际有效数据只有一半。另外测的时候得加负载。空载条件下测出来很快但现场总线上一堆设备同时在跑干扰、重传、帧冲突速度立马掉。要在实际工况下测才准。五、优化手段能跑多快全看这些细节串口层面波特率能高就高但别超过设备支持上限。115200是安全值再高有些设备扛不住。帧间隔调小。软件里设的延时从20ms降到5ms肉眼可见速度提升。批量读写。读20个连续寄存器一次读完比读20次单个寄存器快20倍不止。TCP层面长连接保持别频繁建链拆链。建链的三次握手每次都要几十毫秒频繁建链等于慢性自杀。关闭Nagle算法。Nagle会把小包攒起来一起发对Modbus这种小包通信是致命的。socket.SetSocketOption(SocketOptionLevel.Tcp, SocketOptionName.NoDelay, true);发送缓冲区调大。默认8KB通常够用但如果你一次读写很多寄存器数据包超过MSS通常1460字节调大缓冲区能减少系统调用次数。接收缓冲区同样调大防止网络突发流量导致丢包。接收超时设合理。设太短设备响应稍微慢点就超时重试反而更慢。设太长设备真挂了要等半天才报故障。我一般设500ms兼顾速度和容错。架构层面异步优先。同步Receive会阻塞线程多连接场景下线程资源浪费严重。用异步或者单独线程池让CPU在等待IO时干别的活。连接池。需要跟多个从站通信时预先建好连接池用时取、用完还省去建链时间。数据缓存。变化率不高的数据比如室温、液位可以降低采集频率没必要每次都实时读。把节省出来的带宽留给变化快的信号量。六、实测数据不同场景下的真实速度以下是我在不同项目里实测的数据供参考场景介质配置实测吞吐量单设备读10个寄存器RS485,9600常规配置20~25次/秒单设备读10个寄存器RS485,115200优化延时120~150次/秒单设备读10个寄存器TCP局域网常规配置40~60次/秒单设备读10个寄存器TCP局域网优化Nagle缓存80~100次/秒20个设备轮询各读10个RS485,9600串行轮询约1.5~2秒/圈20个设备轮询各读10个RS485,9600批量读优化间隔约0.8~1秒/圈4连接并发各读32设备TCP局域网线程池连接池约6~8秒/全量最后一行的案例就是之前提过的电池化成项目从最初的40秒优化到8秒全靠架构调整。七、一个暴论多数项目根本不需要极限速度说完这么多提速手段我反而要说句实在话大部分工业场景10次/秒的刷新率就够用了。温度、压力、液位、流量这些物理量变化以秒甚至分钟为单位你读再快也没意义。每秒读100次显示的数值跟每秒读10次几乎没有差别。只有高速运动控制、振动监测、电能质量分析这类场景才需要高频率采集。普通的数据采集和监控系统把精力花在稳定性、容错、数据完整性上比死磕速度有价值得多。不要为了跑得快把系统搞得不稳定。我见过为了追求高刷新率把PLC跑死机的见过频繁超时重试把总线堵死的见过为了快1毫秒把代码写得谁也看不懂的。最后用户根本不关心你那点速度差异只关心系统稳不稳定、数据准不准确。速度够用就行别卷。