FIBERIOT / 故障排查
电脑能连上PLC，链路灯也一直亮着，读取参数却偶尔停顿一下；过一会儿又恢复，数据似乎没有少。这样的现象不一定是设备算得慢，也可能是TCP正在补发缺失的数据。TCP是许多上位机、网关和控制器使用的传输机制，它努力把一串字节按顺序交给对方。本文不推公式，用一段数据的旅行讲清：谁在记账，谁在等待，为什么“最后收到了”仍可能影响生产节拍。
01先分清：网线运送数据，终端负责补发
上位机把数据交给自身的TCP程序，再经网卡、工业交换机到达PLC。交换机通常根据以太网地址转发帧，并不替这条TCP连接确认每个字节。真正保存发送记录、接收确认和决定重传的，是通信两端的协议程序。若设备作为网关终止并重新建立连接，则要按两段连接分别分析，不能把整条线路看成一个无差别通道。
可以把TCP理解为带编号的连续书稿：运输途中允许分成不同大小的包裹，但收件方最终应得到正确次序的内容。这个类比只解释编号与补缺，不表示TCP理解书稿的含义。它不知道一段字节是温度值、参数文件还是启停命令；业务是否有效，还要由设备程序判断。
02序号与确认号：盯住字节，不是数包裹
为便于阅读，假设一条已经建立的连接发送三段数据，分别包含字节1001到1100、1101到1200、1201到1300。这里的数字只作教学示例，真实初始序号不是固定值。SEQ是本段数据的起始序号；ACK是接收方当前希望连续收到的下一个字节序号。收到第一段后，ACK可以指向1101，表示前面的连续内容已经到达。
若第二段缺失、第三段先到了，接收方通常可暂存后面的数据，但连续确认仍停在1101。它不能用“我看到1300了”代替“中间全部收齐了”。缺口补上后，确认号才可向前推进。ACK也不是“第几个包”的编号，因此不能只数抓包列表中有几行，就判断缺了多少业务内容。
03发现缺口：重复确认和计时器各有作用
发送方不会发完就忘记，而是保留尚未确认的数据。如果后续数据不断到达，接收方可能反复报告同一个确认号，让发送方看到前方有缺口。经典快速重传示例中，三个重复ACK会触发对缺失段的补发。现代实现还可能使用其他丢失检测方式；并非所有设备都严格按一张简化时序图行动。
如果流量很少，后面没有足够的数据带来重复确认，就可能依靠重传计时器。RTO可以理解为“这次确认等到什么时候”：终端参考往返耗时及其变化安排等待，而不是所有连接固定等同一个数值。计时器到期后仍未确认，就补发相应数据；连续没有反馈时通常会拉长等待。本文不把某个毫秒数写成飞畅设备承诺。
04为什么能补回来，画面仍会顿一下
补发需要时间，接收方还可能等缺口齐了，才能继续把连续字节交给应用程序。因此，后面的内容即使已经到达网卡，也不一定立即让界面显示新数值。这个等待是传输机制的结果之一，不能从链路灯亮就推断应用刷新始终准时；也不能把一次停顿直接归因于某个交换机端口。
此外，TCP会依据网络状况控制同时发出的数据量。丢失可能被当作拥塞信号，发送节奏随之收敛。这里说的节奏来自终端协议，并非端口协商速率自动变小。即使仍显示千兆连接，某条连接的有效传输也可能暂时下降。可靠交付努力修复缺失，但不提供工业控制所需的固定截止时间保证。
05最容易误解：TCP确认不是业务完成通知
收到TCP ACK，只能说明对应字节在对端TCP接收侧得到确认，不能证明PLC程序已经审核参数、写入目标位置或让电机完成动作。业务协议往往还有自己的响应、异常码或完成状态。排查时要分别记录“传输确认”“协议响应”“设备执行结果”，不要把三个时间混在一张成功提示里。
同一条连接补发重叠字节时，TCP按序号去重，一般不会把它们当作新的连续内容交给应用。但应用程序超时后重新发出一条命令，那是新的业务请求，不能指望TCP判断两次请求意思相同。重连后尤其要按业务协议核对请求标识、执行状态和重复请求处理规则；涉及动作的命令，不应靠无休止重试来保证完成。
06怎样排查：把丢失方向和业务时间对起来
先记录出现卡顿的时间、通信双方、协议、数据量与操作，再看端口错误和丢弃计数、连接日志及两端抓包。同一连接中，相同字节范围再次发送，是值得关注的线索；还要观察ACK是否前进、是否乱序、是否出现接收窗口很小或为零。窗口告诉对方接收缓冲能容纳多少数据，它与“线缆是否连接”是不同问题。
抓包工具标注“重传”是依据观察到的数据推断，不是直接测到了某个元件故障。镜像口带宽不足、采集丢帧、抓包开始得太晚，都可能造成误判；主机的网卡卸载功能也可能改变看到的分段形态。应结合两侧记录，先判断是数据去程缺失、确认回程缺失，还是只是抓包漏看，随后检查对应路径。
若端口校验错误同步增长，优先检查接头、线缆、屏蔽与现场干扰；若丢弃随业务突发增长，检查出口竞争与缓存；若只在跨路由或隧道的大数据业务发生，补查路径尺寸限制。一次改变一个条件，保留改善前后记录。不要只提高应用超时值：它可能隐藏现象，却没有消除传输等待。
还有一种值得留意的情况：数据已经到达，返回的确认却在另一方向丢失。发送方看不到确认，仍可能补发；接收方则按序号识别重复内容。因而看到重复发送，不能立刻断言前一次数据没到对方。把去程和回程分别画出来，结合接收端记录，才能避免只更换发送端旁边的网线而忽略返回路径。测试也应覆盖双向业务，不能只用一次单向传输代表整条连接。
07验收：既要内容正确，也要在需要的时间内有效
飞畅管理型工业交换机产品资料可作为核对接口与管理能力的起点，现场仍须按实际型号、说明书和固件确认可读取哪些计数或日志。本文讲通用TCP机制，不宣称交换机能代替终端处理TCP，也不将第三方协议实现的行为当成某款飞畅设备性能。
恢复后先核对文件或参数内容，再观察连续运行期间的响应分布和异常次数；有动作的业务还要检查完成状态与重复命令行为。以现场约定的业务时限验收，区分偶发停顿、持续恶化与真正断开。最后记住三件事：TCP按字节补缺，补缺会花时间，收到数据与完成任务必须分别确认。
维护报告最好写清实际症状和证据，例如某时间段的哪些字节范围重复出现、业务响应是否随之推迟、相关端口计数有没有变化，而不是只写“网络不好”。这样的记录可以交给网络、设备和软件人员共同分析，减少各自只看自己设备正常的争论。若抓包时间不同步，应先校准记录的时间关系，避免把两段无关事件拼成一个原因。
参考资料：RFC 9293：TCP序号与确认；RFC 6298：重传计时器；RFC 5681：经典快速重传与拥塞控制；Wireshark：TCP分析与观察限制；飞畅管理型工业交换机资料。原创原理图为通用示意，示例字节范围非产品实测。
