3. HSMS物理层：TCP/IP基础、连接建立与断开、链路测试、会话管理
好，咱们进入HSMS物理层。说白了，HSMS就是把SECS-II报文打包，然后通过TCP/IP网络发出去。你想想看，如果设备之间没有物理连接，那上层协议再牛也白搭。这一章我重点讲TCP/IP基础、连接怎么建、怎么断、怎么保活，以及会话管理这些实操内容。
3.1 TCP/IP基础：HSMS的通信基石
HSMS全称是High-Speed SECS Message Services，它直接跑在TCP/IP协议栈上。我个人习惯把HSMS看作SECS-II的“快递员”——它不关心报文内容是什么，只负责把报文完整、有序地送到对端。
核心要点：HSMS使用TCP作为传输层协议，而不是UDP。为什么？因为SECS/GEM要求消息必须可靠到达，不能丢包。TCP的确认重传机制正好满足这个需求。
TCP连接有几个关键参数，我在项目中踩过坑，这里列出来大家注意：
| 参数 | 说明 | 典型值 |
|---|---|---|
| IP地址 | 设备网络标识 | 192.168.1.100 |
| 端口号 | HSMS服务端口 | 5000（标准） |
| 连接超时 | 等待连接建立的最长时间 | 10秒 |
| 重试间隔 | 连接失败后的重试等待 | 5秒 |
| 最大重试次数 | 放弃连接前的尝试次数 | 3次 |
我的经验：端口号虽然标准是5000，但有些半导体厂会改成其他端口。我曾经遇到一个项目，设备端用的5001，主机端配的5000，结果折腾了半天才发现是端口对不上。所以，配置前一定要跟设备厂商确认清楚。
3.2 连接建立：三次握手与HSMS协商
TCP连接建立靠三次握手，这个大家应该都熟悉。但HSMS在TCP连接之上，还有一层自己的握手——Selective和Deselect消息交换。
完整的连接建立流程是这样的：
- TCP三次握手：客户端发SYN，服务器回SYN+ACK，客户端再发ACK。连接建立。
- HSMS Select：主动方发送Select.req消息，声明自己要建立HSMS会话。
- HSMS Select响应：被动方回复Select.rsp，带上状态码（0表示成功）。
- 会话建立：双方进入Communicating状态，可以收发数据了。
注意：TCP连接建立成功不代表HSMS会话可用。我曾经见过一个案例，TCP已经连上了，但Select.req一直没发出去，结果两边都在干等。所以，调试时一定要确认HSMS层的握手也完成了。
Select.rsp的状态码含义：
| 状态码 | 含义 | 说明 |
|---|---|---|
| 0 | 成功 | 会话建立，可以通信 |
| 1 | 连接已存在 | 该设备已经有一个活跃会话 |
| 2 | 连接未就绪 | 设备尚未准备好接受会话 |
| 3 | 拒绝 | 设备拒绝建立会话 |
3.3 连接断开：优雅关闭与异常处理
断开连接有两种方式：优雅关闭和强制断开。优雅关闭走的是HSMS层的Deselect流程，强制断开就是直接拔网线或者TCP RST。
优雅关闭的步骤：
- 主动方发送Deselect.req，告诉对方我要断开了。
- 被动方回复Deselect.rsp，确认收到。
- 双方关闭TCP连接（四次挥手）。
但实际项目中，更多遇到的是异常断开。比如设备突然断电、网线被踢掉、防火墙超时等等。这时候怎么处理？
避坑指南：我曾经遇到一个项目，设备端断电后主机端一直没检测到连接断开，导致主机端认为设备还在线，一直发消息过去，结果全部超时。后来加了TCP keepalive机制才解决。
TCP keepalive的原理很简单：如果连接空闲超过一定时间，系统会自动发一个探测包。如果对端没回应，就认为连接断了。HSMS标准建议的keepalive间隔是：
- 探测间隔：10秒
- 探测次数：3次
- 超时判定：30秒无响应即断开
3.4 链路测试：T3超时与心跳机制
链路测试是HSMS保证连接健康的重要手段。它主要靠两个机制：T3超时和心跳消息。
T3超时是HSMS协议中最重要的定时器之一。它用来检测对端是否还活着。具体逻辑是：
- 发送一条消息后，启动T3定时器。
- 如果在T3时间内收到回复，重置定时器。
- 如果T3超时，认为对端可能挂了，触发重试或断开。
T3的典型值是45秒，但可以根据网络状况调整。我建议不要设得太短，否则网络稍微波动一下就会误判。
心跳消息（Linktest）是HSMS专门用来测试链路的消息。它不需要上层应用参与，由HSMS层自动发送和回复。
我的习惯：在生产环境中，我会把心跳间隔设为15秒。这样即使T3超时，也能在45秒内发现连接异常。太频繁的心跳会增加网络负担，太稀疏又会导致故障发现延迟。
心跳流程：
- 主动方发送Linktest.req。
- 被动方收到后立即回复Linktest.rsp。
- 如果主动方在T3时间内没收到回复，认为链路断开。
3.5 会话管理：状态机与多连接处理
HSMS的会话管理基于一个有限状态机。状态机定义了设备在不同阶段的行为。我画了一张图，大家可以直观地看看：
状态机看起来简单，但实际项目中多连接场景会复杂很多。比如一台设备同时跟多个主机通信，或者一个主机管理多台设备。这时候会话管理就要考虑：
- 设备ID：每个设备必须有唯一的设备ID，用来区分不同会话。
- 会话ID：HSMS用会话ID来标识一次连接，避免消息串扰。
- 并发限制：有些设备只支持一个活跃会话，有些支持多个。
我曾经踩过的坑：有一次设备配置了多会话模式，但主机端只开了一个连接。结果设备端一直等第二个连接，导致第一个连接的消息处理延迟。后来统一改成单会话模式才解决。所以，多会话一定要两端配置一致。
3.6 实际部署建议
最后，我总结几条实际部署HSMS物理层的建议：
- 网络隔离：HSMS流量最好走独立VLAN，避免跟办公网络混在一起。半导体工厂的电磁干扰本来就大，网络抖动会直接影响通信。
- 防火墙配置：确保TCP端口（默认5000）在防火墙上放行。我遇到过防火墙把心跳包当成攻击流量拦截的情况。
- 日志记录：所有连接建立、断开、超时事件都要记录日志。排查问题时，这些日志是救命稻草。
- 超时参数调优：T3、心跳间隔、重试次数要根据实际网络状况调整。不要照搬标准值，尤其是跨厂区通信的场景。
我的经验：调试阶段可以把日志级别调到最详细，连每个TCP报文都记录下来。等系统稳定了再调低级别，只记录连接状态变化和异常事件。这样既能保证问题可追溯，又不会产生太多日志。
嗯，HSMS物理层的内容就这些。TCP/IP基础、连接建立与断开、链路测试、会话管理，这几个点搞清楚了，HSMS的底层通信就不会出大问题。下一层咱们再讲HSMS传输层，也就是报文格式和收发机制。