3. 断连检测场景分析：物理层断开、网络层超时、应用层无响应、设备重启等典型场景
在 SECS/GEM 通信中，连接中断并非单一原因造成。从 OSI 模型底层到应用层，每一层都可能出现故障，导致 Link Test 失败。工程配置必须针对不同场景采取差异化的检测策略与恢复机制。本章逐一剖析四种典型断连场景，并给出对应的检测参数配置建议。
3.1 场景分类与检测层级
下表归纳了四种断连场景在 OSI 模型中的对应层级、典型表现及 Link Test 的检测方式：
| 场景 | OSI 层级 | 典型表现 | Link Test 检测方式 |
|---|---|---|---|
| 物理层断开 | 物理层 (L1) | 网线拔出、交换机断电、光模块故障 | Socket 连接立即断开，TCP RST 或 FIN |
| 网络层超时 | 网络层/传输层 (L3/L4) | 路由不可达、防火墙丢包、TCP 重传超时 | Socket 写超时或连接挂起，Link Test 无响应 |
| 应用层无响应 | 应用层 (L7) | 设备 HSMS 服务进程挂死、消息队列阻塞 | TCP 连接保持，但 Link Test 请求无回复 |
| 设备重启 | 全栈 | 设备断电重启、软件升级重启 | 连接先断开，重启后重新建立连接 |
工程要点： 物理层断开和设备重启通常能被操作系统 Socket 事件快速感知（毫秒级），而网络层超时和应用层无响应则需要依赖 Link Test 主动探测（秒级）。配置 Link Test 间隔时，应优先覆盖后两种场景。
3.2 物理层断开场景
物理层断开是最直接的断连方式。当网线被拔出、交换机端口 down 或光模块失效时，物理信号中断，操作系统 TCP/IP 栈会在极短时间内检测到链路状态变化。
检测特征
- Socket 事件： 对方主机发送 TCP RST 报文，或本地网卡检测到 carrier loss，Socket 进入 CLOSED 状态。
- 检测延迟： 通常 < 100ms，取决于网卡驱动和操作系统 TCP 栈实现。
- Link Test 角色： 在此场景下，Link Test 并非主要检测手段，而是作为连接状态变化的确认机制。
工程配置建议
- 启用 Socket 异常事件回调（如 WinSock 的 FD_CLOSE、Linux 的 POLLRDHUP），优先于 Link Test 处理。
- Link Test 间隔可适当放宽（如 30s），因为物理断开已被底层快速捕获。
- 配置自动重连逻辑：检测到物理断开后，立即进入重连状态机，无需等待 Link Test 超时。
避坑提示： 某些虚拟化环境或容器网络桥接模式下，物理层断开可能不会立即触发 Socket 关闭事件。此时应依赖 Link Test 作为兜底检测，不可完全信任底层事件。
3.3 网络层超时场景
网络层超时是工程中最隐蔽的断连场景。物理链路正常，但中间网络设备（路由器、防火墙、交换机）出现拥塞、路由黑洞或 ACL 丢包，导致 TCP 报文无法到达对端。
检测特征
- Socket 状态： 连接保持 ESTABLISHED 状态，但数据发送无响应。
- TCP 重传： 操作系统会进行多次 TCP 重传（默认 5~15 次），耗时 30s~2min 不等。
- Link Test 角色： 主要检测手段。Link Test 请求发出后，若在超时时间内未收到回复，判定连接中断。
工程配置建议
- Link Test 超时时间应小于 TCP 重传总耗时，建议设为 5~10s。
- Link Test 间隔建议设为 10~15s，确保在 TCP 重传耗尽前完成 2~3 次探测。
- 配置网络层健康检查：结合 ICMP ping 或 TCP keepalive 辅助判断。
注意： 网络层超时场景下，TCP keepalive 默认间隔通常为 2 小时，无法满足半导体设备实时性要求。必须依赖 HSMS Link Test 主动探测。
3.4 应用层无响应场景
应用层无响应是最难诊断的场景。TCP 连接完好，网络通畅，但设备端的 HSMS 服务进程因死锁、内存泄漏、消息队列溢出等原因无法处理 Link Test 请求。
检测特征
- Socket 状态： 连接保持 ESTABLISHED，TCP 窗口正常，无重传。
- 应用层表现： 设备能接收数据（TCP ACK 正常），但不回复应用层消息。
- Link Test 角色： 唯一有效的检测手段。必须通过应用层请求-应答机制确认对方进程存活。
工程配置建议
- Link Test 超时时间不宜过长，建议 3~5s，避免长时间等待无响应的进程。
- Link Test 间隔建议 5~10s，快速发现应用层挂死。
- 配置连续失败阈值：连续 2~3 次 Link Test 无响应，判定为应用层故障，触发重连。
- 在设备端实现看门狗机制：HSMS 服务进程定期检查自身状态，若发现异常主动断开连接。
案例： 某晶圆厂设备在长时间运行后，HSMS 消息处理线程因内存泄漏进入死循环。TCP 连接正常，但 Link Test 连续 5 次无响应。由于配置了连续失败阈值 3 次，主机端及时触发重连，避免了生产数据丢失。
3.5 设备重启场景
设备重启是半导体工厂常见的运维操作，包括计划内重启（软件升级、维护）和计划外重启（电源故障、系统崩溃）。
检测特征
- 阶段一（断电/重启中）： 物理层断开，Socket 关闭，类似物理层断开场景。
- 阶段二（重启完成）： 设备重新发起 TCP 连接，HSMS 服务启动，进入 Select 状态。
- Link Test 角色： 重启完成后，Link Test 用于验证设备 HSMS 服务是否已完全就绪。
工程配置建议
- 主机端配置重连等待时间：设备重启通常需要 30s~2min，建议重连间隔设为 5s，最大重试次数不限。
- 设备重启后，主机应主动发送 Link Test 确认服务可用性，再恢复生产通信。
- 配置会话恢复策略：设备重启后，主机应重新发送 S1F13 (Establish Communications Request) 建立会话。
最佳实践： 在设备重启场景中，Link Test 不仅用于断连检测，还用于重启后的服务就绪确认。建议在设备重启完成后，主机主动发起一次 Link Test，若成功则立即恢复数据交换。
3.6 断连检测场景对比总结
下表从检测速度、Link Test 依赖度、配置重点三个维度对比四种场景：
| 场景 | 检测速度 | Link Test 依赖度 | 配置重点 |
|---|---|---|---|
| 物理层断开 | 极快（<100ms） | 低（Socket 事件优先） | 启用底层事件回调 |
| 网络层超时 | 中等（5~30s） | 高（主要检测手段） | Link Test 超时 < TCP 重传时间 |
| 应用层无响应 | 慢（依赖 Link Test 间隔） | 极高（唯一检测手段） | 短间隔 + 连续失败阈值 |
| 设备重启 | 分阶段（先快后慢） | 中（重启后用于就绪确认） | 重连间隔 + 会话恢复 |
3.7 断连检测流程总览
下图展示了从连接建立到断连检测的完整流程，涵盖四种场景的检测路径：
3.8 工程配置参数速查
根据上述场景分析，下表给出推荐的 Link Test 工程配置参数范围：
| 参数 | 推荐值 | 适用场景 | 说明 |
|---|---|---|---|
| Link Test 间隔 | 5~15s | 网络层超时、应用层无响应 | 间隔越短，检测越快，但增加网络开销 |
| Link Test 超时 | 3~10s | 网络层超时、应用层无响应 | 应小于 TCP 重传总耗时 |
| 连续失败阈值 | 2~3 次 | 应用层无响应 | 避免误判，同时保证快速响应 |
| 重连间隔 | 3~5s | 设备重启、物理层断开 | 设备重启时需考虑启动时间 |
| Socket 事件优先级 | 高于 Link Test | 物理层断开 | 底层事件优先处理，减少延迟 |
重要提醒： 以上参数为通用推荐值，实际工程中需根据设备性能、网络延迟、生产节拍等因素进行微调。建议在实验室环境中模拟四种断连场景，验证参数配置的有效性后再部署到生产环境。