服务端心跳机制原理：心跳报文格式、心跳周期配置、心跳超时判定

心跳机制，说白了就是服务端告诉客户端「我还活着」。我在做第一个 SOME/IP 项目时，觉得心跳可有可无，结果测试阶段客户端频繁报错——服务端明明在跑，客户端却认为它挂了。后来才发现，没有心跳，客户端只能靠超时重连，效率极低。

这一节，我们就把心跳的三个核心问题讲透：报文长什么样、周期怎么配、超时怎么判。

2.1 心跳报文格式

SOME/IP 的心跳报文，本质上是一个空的 Notification Event。它不携带任何有效载荷，只靠 SOME/IP 头部来传递信息。

我习惯把心跳报文叫做「空壳报文」。它的结构如下：

字段	长度（字节）	值/说明
Message ID	4	Service ID + Method ID，标识具体事件
Length	4	固定为 8（仅头部后续字段长度）
Request ID	4	Client ID + Session ID，Session ID 通常递增
Protocol Version	1	固定 0x01
Interface Version	1	服务接口版本号
Message Type	1	0x02（Notification）
Return Code	1	0x00（E_OK）
Payload	0	无数据

我在项目中遇到过一个问题：有人把 Length 填成了 0，结果接收端直接丢弃了报文。嗯，这里要注意——Length 不包括 Message ID 和 Length 字段本身，只算后面的部分。

2.2 心跳周期配置

心跳周期不是拍脑袋定的。配得太短，网络带宽被浪费；配得太长，客户端发现故障的延迟就高。

我个人习惯遵循以下原则：

• 周期 < 超时时间 / 3：这是最保守的规则。如果超时判定是 3 秒，心跳周期就设 1 秒以内。
• 考虑网络抖动：在 CAN 或车载以太网上，偶尔丢一两个包很正常。周期太短反而容易触发误判。
• 与事件频率解耦：心跳是独立于业务事件的。即使业务数据频繁发送，心跳也不能停。

举个例子，我之前调试过一个 ADAS 服务：

参数	推荐值	说明
心跳周期	500 ms	每 500 ms 发送一次
超时次数	3 次	连续丢失 3 个心跳判定为超时
超时总时间	1500 ms	500 ms × 3

2.3 心跳超时判定

超时判定，说白了就是客户端怎么判断服务端「死了」。这里有两个关键点：判定时机和判定策略。

2.3.1 判定时机

客户端收到第一个心跳后，启动一个定时器。之后每收到一个心跳，就重置定时器。如果定时器超时，就认为服务端异常。

伪代码大概是这样的：

// 伪代码：心跳超时判定
void on_heartbeat_received() {
    reset_timer(heartbeat_timeout);
}

void on_timer_expired() {
    // 连续超时计数 +1
    missed_count++;
    if (missed_count >= max_missed_count) {
        service_status = SERVICE_DOWN;
        trigger_recovery();
    } else {
        // 继续等待下一个心跳
        reset_timer(heartbeat_timeout);
    }
}

2.3.2 判定策略

我常用的策略有两种：

• 固定次数法：连续丢失 N 个心跳，判定超时。N 通常取 3~5。
• 滑动窗口法：在最近 M 个心跳周期内，丢失比例超过阈值，判定超时。适合网络不稳定的场景。

我个人更推荐固定次数法，简单可靠。滑动窗口法虽然更平滑，但实现复杂，调试起来也麻烦。

2.4 心跳机制整体流程

下面这张图，把整个心跳机制串起来了。从服务端发送，到客户端判定，一目了然。

2.5 避坑指南

最后，分享几个我踩过的坑：

• 心跳与业务事件共用 Session ID：心跳的 Session ID 应该独立递增，不要和业务事件混用。否则客户端无法区分是心跳还是业务数据。
• 服务端重启后 Session ID 重置：服务端崩溃重启后，Session ID 从 0 开始。客户端如果发现 Session ID 跳变，应该立即触发恢复流程。
• 心跳周期不要小于 100 ms：车载网络的处理能力有限，太频繁的心跳反而会加重负载。我一般设 200~500 ms。