104 通道"白天好好的，晚上开始丢点""重启就好一段时间"，这类现象十有八九不在应用层，而在 k、w 与 t1/t2/t3 这几个参数上。它们都是 IEC 60870-5-104 里定义好的，本文把语义和现场的判断方法讲清楚。
104 的 APDU 以启动字符 0x68 开头，第二字节是长度，随后 4 个字节是控制域。控制域最低两位决定帧类型：
| 类型 | 控制域特征 | 作用 |
|---|---|---|
| I 帧 | 最低位 0 | 携带 ASDU，同时带发送序号 N(S) 和接收序号 N(R) |
| S 帧 | 最低两位 01 | 只做确认，携带 N(R)，没有 ASDU |
| U 帧 | 最低两位 11 | 链路控制：STARTDT / STOPDT / TESTFR 的启动与确认 |
U 帧的六个编码值得记住：STARTDT 启动 0x07、确认 0x0B；STOPDT 启动 0x13、确认 0x23；TESTFR 启动 0x43、确认 0x83。抓包里看到 68 04 07 00 00 00，就是客户端在请求建立数据传输；没等到 0x0B 的确认，业务数据一帧都不会有。
这两个值必须成对配置，而且 w 必须小于等于 k。只调大 k 不调 w，发送方会以为可以一直发，接收方却按 w 卡确认节奏，结果就是发送窗口被自己的确认策略堵住——表面看像"对端不回确认"，其实是本方 w 太小。
| 定时器 | 语义 | 默认值 | 超时后果 |
|---|---|---|---|
| t1 | 发送 I 帧（或带 N(R) 的 U 帧）后，等待对方确认的最长时间 | 15 s | 超时视为链路故障，关闭 TCP 连接 |
| t2 | 收到 I 帧但没有数据要发时，最长多久必须补一个确认 | 10 s | 对端 t1 先到 → 对端断链 |
| t3 | 链路空闲多久发一次 TESTFR 心跳 | 20 s | 不发则 NAT/防火墙把长连接"静默丢弃" |
约束关系是 t2 < t1。把 t2 配得比 t1 还大，等于要求对端在自己的超时之后才等到确认，链路会被反复重建——很多"每 15 秒断一次"的现场就是这个原因。
| 现场现象 | 优先怀疑 |
|---|---|
| 大批量变化时丢点，平时正常 | k 太小或 w 太大，窗口在突发时被塞满 |
| 每 15 s 左右固定断一次 | t2 ≥ t1，或对端根本不回确认 |
| 闲置一段时间后第一条命令超时 | t3 太长且中间设备回收了空闲连接；或对端 NAT 表项已老化 |
| 抓包看到 STARTDT 反复重发 | 确认帧回不来（ACL、路由不对称、双网选了错的口） |
| 总召拿得到数据，变化上送几乎没有 | 不是定时器问题，看传送原因与 ASD U 的 COT 是否允许突发 |
这三个定时器和两个窗口值都是两端协商一致才有意义的东西：改一侧必须确认对侧能接受。工程上稳妥的做法是先用无扰监听把一小时的报文完整抓下来，统计最大突发 I 帧数、确认帧的平均间隔、以及有没有出现 t1 临界（确认迟到）。有了这三个数，再决定调 k/w 还是调定时器，而不是照着默认值硬套。
