4. T3定时器与连接保活的关系
T3定时器（Reply Timeout）是SECS/GEM协议中用于等待单条消息回复的超时机制，而连接保活（Keep-Alive）则是维持TCP长连接不被中间设备（防火墙、NAT网关）中断的底层策略。两者看似独立，但在实际半导体设备通信中，T3超时与连接状态之间存在紧密的因果链，且必须与Linktest定时器（T6）协同工作，才能构建健壮的长连接通信系统。
4.1 T3超时对连接状态的影响
当T3定时器超时时，HSMS协议栈会认为当前消息传输失败，并触发以下状态转换流程：
- 消息重试：协议栈自动重发原消息，并重置T3定时器（重试次数由系统配置决定，通常为3次）。
- 连接降级：若重试全部超时，HSMS会话状态从SELECTED降级为NOT SELECTED，控制通道失效。
- TCP断开：在NOT SELECTED状态下，若T6定时器（Linktest间隔）也超时，底层TCP连接将被主动关闭。
- 业务中断：所有正在进行的GEM事务（如配方下载、设备状态采集）立即失败，上位机需重新建立连接并恢复会话。
关键指标： 在300mm半导体产线中，T3超时导致的连接中断占所有通信故障的40%~60%，是影响设备OEE（Overall Equipment Effectiveness）的主要通信因素。
| T3超时次数 | 连接状态 | 业务影响 | 恢复方式 |
|---|---|---|---|
| 0（正常） | SELECTED | 无影响 | — |
| 1~3（重试中） | SELECTED（挂起） | 单条消息延迟 | 自动重试 |
| 超过重试上限 | NOT SELECTED | 控制通道失效 | 重新Select |
| NOT SELECTED + T6超时 | TCP断开 | 完全断连 | 重新建立TCP连接 |
4.2 T3与Linktest定时器（T6）的协同机制
Linktest定时器（T6）是HSMS协议中用于检测连接健康状态的保活机制。T3与T6的协同关系可以概括为“短超时保消息，长超时保连接”：
- T3（消息级超时）：负责单次消息交互的可靠性，超时后触发重试，防止因瞬时网络抖动导致误判。
- T6（连接级保活）：在空闲连接上定期发送Linktest.req消息，确认对端仍然存活，防止NAT会话过期或防火墙静默断开。
两者协同的核心逻辑：
- 时序互补：T6的发送间隔（通常5~30秒）远大于T3（通常5~45秒），避免保活消息与业务消息冲突。
- 状态联动：当T3连续超时导致连接降级为NOT SELECTED时，T6定时器停止发送Linktest，转而等待Select.req恢复会话。
- 故障隔离：T3超时仅影响单条消息，T6超时则判定连接完全失效，两者共同防止“假连接”现象。
4.3 参数调优的协同策略
在实际工程中，T3与T6的配置必须遵循以下协同原则：
| 参数 | 推荐范围 | 调优方向 | 与对端的关系 |
|---|---|---|---|
| T3 | 5~45秒 | 根据网络RTT和消息处理时间设定 | 必须小于T6的1/2，避免T3重试与T6保活冲突 |
| T6 | 5~30秒 | 根据NAT超时和防火墙策略设定 | 必须大于T3×重试次数，确保T3重试期间不触发T6超时 |
| 重试次数 | 2~5次 | 根据网络稳定性设定 | 重试总耗时 = T3 × 重试次数，应小于T6间隔 |
最佳实践： 在300mm半导体工厂中，推荐配置T3=15秒、重试次数=3次、T6=10秒。这样T3重试总耗时45秒，T6在空闲10秒后发送Linktest，两者互不干扰，且能快速检测连接失效。
4.4 常见问题与避坑指南
- T3设置过大（>60秒）：消息失败后长时间等待，导致业务堆积，且T6可能先于T3超时，造成连接误判。
- T3设置过小（<5秒）：正常处理时间稍长即触发重试，产生大量重复消息，增加网络负载。
- T6设置大于NAT超时：中间设备已断开连接，但T6尚未检测到，形成“假连接”状态。
- 忽略重试次数限制：无限重试会导致消息风暴，耗尽系统资源。
注意： 在修改T3或T6参数后，必须同时调整对端设备的对应配置。例如，上位机T3=15秒，设备端T3也必须设为15秒，否则会出现“一端已超时重试，另一端仍在等待”的协议错配问题。