嵌入式 Linux 网络变化监测方案： Netlink Socket 与 Heartbeat

author: 周均扬

date: 2026.08.10

Netlink Socket 与 Heartbeat 并不是完全替代关系，它们监测的是不同层级：

• Netlink Socket：观察“本机 Linux 网络栈发生了什么变化”。
• Heartbeat：验证“本机到目标设备或目标服务的实际通信是否正常”。

因此，工程上最可靠的方案通常不是二选一，而是组合使用。

1. 本质区别

可以将两者理解为：

Netlink：网卡、IP、路由“看起来是否正常”
Heartbeat：目标设备或服务“实际上是否可用”

2. Netlink Socket 方案

2.1 工作原理

Linux 内核通过 Netlink Socket 向用户空间发送网络事件。应用订阅特定事件组后，可以收到以下变化：

• 网卡创建、删除；
• 网卡启用、禁用；
• 网线插入、拔出；
• Carrier UP/DOWN；
• IPv4/IPv6 地址增加或删除；
• 默认路由、静态路由变化；
• 网关或邻居表变化；
• Wi-Fi、VLAN、Bond、Bridge 等接口变化。

常用协议和订阅组包括：

socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE);

RTMGRP_LINK
RTMGRP_IPV4_IFADDR
RTMGRP_IPV6_IFADDR
RTMGRP_IPV4_ROUTE
RTMGRP_IPV6_ROUTE
RTMGRP_NEIGH

典型事件：

2.2 Netlink 可以识别的状态

Netlink 可以帮助区分：

接口不存在
    ↓
接口存在但管理状态 DOWN
    ↓
接口管理状态 UP，但没有 Carrier
    ↓
接口 UP 且 Carrier UP，但没有 IP
    ↓
接口有 IP，但没有默认路由
    ↓
接口、IP、路由均正常

常见接口标志：

需要特别注意：

IFF_UP = 1

只说明执行过类似操作：

ip link set eth0 up

它不代表网线已连接。

而：

IFF_LOWER_UP = 1

通常表示物理链路或底层虚拟链路已建立，但仍不表示网关、服务器或业务服务可用。

2.3 Netlink 的优点

反应速度快

网卡、地址或路由发生变化时，由内核立即通知用户空间。通常不需要等待轮询周期。

适合检测：

• 网线拔插；
• USB 网卡插拔；
• 网卡重新初始化；
• DHCP 地址更新；
• 4G/5G 拨号接口创建或删除；
• 默认路由切换；
• 主备网卡切换；
• VLAN、Bridge、Bond 状态变化。

资源开销低

没有网络变化时，进程可以阻塞在：

recv()

或者：

poll()
epoll_wait()

不会持续轮询 /sys/class/net 或执行外部命令。因此非常适合嵌入式设备。

不需要对端配合

只依赖 Linux 内核，不需要服务器、PLC或其他设备提供心跳服务。

能获得变化原因

Netlink 不只告诉应用“通信失败”，还可以提供更具体的本地原因：

• 接口被关闭；
• Carrier 丢失；
• IP 地址被删除；
• 默认路由变化；
• 网卡被移除；
• 邻居项进入失败状态。

这有利于故障诊断和日志审计。

2.4 Netlink 的缺点

不能证明端到端通信正常

以下情况下，Netlink 可能显示“一切正常”，但业务仍然不可用：

• 交换机上联端口故障；
• 网关故障；
• 中间路由器故障；
• VLAN 配置错误；
• 防火墙阻断；
• 对端服务器宕机；
• 对端进程卡死；
• 对端业务端口未监听；
• DNS 服务不可用；
• TCP 建连失败；
• 应用协议异常。

例如：

eth0: IFF_UP + IFF_LOWER_UP
IP: 192.168.10.20
Default Route: 存在

这只能说明本机网络配置看起来正常，不能说明：

192.168.10.100:9000

上的设备或服务可用。

只能在 Linux 中使用

Netlink 是 Linux 内核接口。若系统需要同时支持：

• Linux；
• Windows；
• RTOS；
• QNX；
• Android；
• 裸机控制器；

则需要为不同平台提供不同实现。

主要提供“变化事件”，不是完整初始状态

应用启动时，如果网络已经处于某个状态，不能只等后续事件。生产实现必须先获取一次完整快照：

RTM_GETLINK
RTM_GETADDR
RTM_GETROUTE
RTM_GETNEIGH

然后再监听增量变化。

否则可能出现：

进程启动时 eth0 已经断网
→ 没有新的变化事件
→ 应用一直不知道当前状态

事件可能丢失

当用户空间处理过慢或接收缓冲区不足时，Netlink 可能出现：

ENOBUFS

这意味着部分事件可能已经丢失。生产程序应：

1. 增大接收缓冲区；
2. 检测 ENOBUFS；
3. 触发一次完整状态重建；
4. 避免在 Netlink 接收线程执行耗时操作。

3. Heartbeat 方案

3.1 工作原理

Heartbeat 由监测端周期发送探测报文，对端收到后返回响应。

基本流程：

监测端发送 Heartbeat Request
             ↓
       网络与对端处理
             ↓
对端返回 Heartbeat Response
             ↓
监测端计算 RTT、连续成功数和失败数

Heartbeat 可以基于不同协议实现。

Heartbeat 的价值取决于探测深度。

例如：

ICMP Ping 成功

并不一定意味着：

OPC UA 服务正常

同样：

TCP 端口连接成功

也不一定意味着：

PLC 数据更新正常

3.2 Heartbeat 的优点

可以验证端到端路径

Heartbeat 可以覆盖：

本机网卡
→ 交换机
→ 网关
→ 路由
→ 防火墙
→ 对端网卡
→ 对端协议栈
→ 对端业务进程

Netlink 只能观察其中靠近本机的一小部分。

可以验证真实业务服务

如果使用应用层 Heartbeat，可以进一步发现：

• 对端进程退出；
• 线程死锁；
• 端口未监听；
• 服务内部依赖异常；
• 数据停止更新；
• 应用响应超时；
• 协议状态异常；
• 主从连接断开；
• PLC 通信虽然连接存在，但数据冻结。

例如，工业平台不应只判断：

PLC TCP 502端口可以连接

还应判断：

PLC状态寄存器是否能够读取
数据时间戳是否持续更新
通信序列号是否递增

可以获得链路质量指标

Heartbeat 除了在线/离线，还能统计：

• RTT；
• 超时率；
• 丢包率；
• 抖动；
• 连续失败次数；
• 恢复时间；
• 可用率；
• P95/P99 响应时间。

这些指标可用于：

• 网络质量监测；
• 主备链路选择；
• 无线网络质量评估；
• 异常趋势预警；
• SLA 统计；
• 安全系统降级决策。

跨平台

Heartbeat 可以基于标准 UDP、TCP、HTTP 等协议实现，适用于 Linux、Windows、QNX、RTOS 和微控制器。

3.3 Heartbeat 的缺点

存在检测延迟

假设参数为：

周期：5秒
超时：1秒
连续3次失败判定离线

最坏检测时间大约为：

代入后：

若周期过长，故障发现慢；周期过短，则增加资源消耗和误报概率。

持续占用网络和系统资源

每次 Heartbeat 都需要：

• 定时器唤醒；
• 网络报文收发；
• 协议栈处理；
• 对端线程或服务处理；
• 日志及状态更新。

对于以太网设备，通常问题不大。但对于：

• 4G/5G；
• NB-IoT；
• 电池供电设备；
• 深度休眠设备；
• 大规模物联网终端；

高频 Heartbeat 可能显著增加：

• 功耗；
• 流量费用；
• 无线模组唤醒次数；
• 服务端并发压力。

例如，10,000 台设备每秒一次心跳会产生每秒 10,000 次请求，且可能出现同步惊群。

容易因短时丢包误判

单次超时不应立即判定离线，因为可能只是：

• 网络瞬时拥塞；
• 无线信号波动；
• CPU 短时高负载；
• 服务端 GC 或调度暂停；
• 路由短时收敛；
• 报文偶发丢失。

因此 Heartbeat 必须采用防抖策略：

连续失败 N 次 → Offline
连续成功 M 次 → Online

并且通常满足：

恢复门限 ≥ 2

避免链路在 Online 和 Offline 之间反复跳变。

需要定义“对端正常”的语义

收到响应不一定代表真正正常。例如服务器可能返回：

{
  "status": "ok"
}

但其数据库、消息总线或设备连接已经失败。

所以业务级 Heartbeat 应包含：

• 服务状态；
• 依赖状态；
• 数据更新时间；
• 设备状态；
• 服务实例 ID；
• 版本号；
• 单调递增序列号；
• 对端时间戳；
• 降级状态。

4. 故障检测能力对比

5. 实时性对比

Netlink 检测时间

Netlink 是事件驱动，理论检测时间为：

通常是毫秒级，但取决于：

• 网卡驱动是否及时报告 Carrier；
• 内核调度；
• 用户空间进程优先级；
• Netlink 接收线程是否被阻塞。

注意，一些网卡或无线驱动的链路状态上报本身可能较慢。

Heartbeat 检测时间

Heartbeat 检测时间主要由以下参数决定：

其中：

• $T_i$：心跳周期；
• $T_o$：单次响应超时；
• $N$：连续失败门限。

举例：

因此，单纯使用低频 Heartbeat 无法满足快速故障发现要求。

6. 资源占用对比

Netlink

稳定期间基本没有报文和处理任务：

CPU：接近零
网络流量：零
对端负载：零
定时器唤醒：不需要

其主要资源是：

• 一个 Netlink Socket；
• 接收缓冲区；
• 一个事件循环或 epoll 文件描述符；
• 少量状态缓存。

Heartbeat

若有 (D) 台设备、每台监测 (P) 个目标、周期为 (T)，每秒请求量约为：

例如：

则：

若设备同时启动，可能形成 Heartbeat 惊群。因此应加入随机抖动：

其中 (J) 可以取基础周期的 5%～20%。

7. 可靠性与误判对比

Netlink 的典型误判

Netlink 最常见的问题是“假在线”：

Carrier UP
IP 地址存在
默认路由存在

但实际情况可能是：

网关不可达
服务器宕机
业务端口阻断
应用进程卡死

因此 Netlink 的 Online 更准确地说应该叫：

LOCAL_NETWORK_READY

而不应该直接叫：

SERVICE_ONLINE

Heartbeat 的典型误判

Heartbeat 最常见的问题是“假离线”：

• 单个报文丢失；
• 短时拥塞；
• 无线网络抖动；
• 服务端暂时忙；
• 调度延迟超过超时；
• 探测目标自身故障，但其他业务仍正常。

因此不应采用：

一次超时 → 整个网络离线

建议采用：

连续失败门限
连续恢复门限
多目标验证
状态滞回
冷却时间

8. 多目标 Heartbeat 的重要性

只探测一个服务器可能把“目标服务器故障”误判成“网络故障”。

推荐至少区分三个目标：

示例判定：

最后一种情况说明不能把 ICMP Ping 当成唯一依据。

9. 嵌入式平台适用性

Netlink 更适合

• Linux 网关；
• 工业边缘计算设备；
• ARM Linux 控制器；
• 车载 Linux；
• 多网卡主备切换设备；
• 需要低功耗或低资源占用的设备；
• 需要监测本机接口、IP、路由变化的场景。

Heartbeat 更适合

• 检测 PLC、AGV、Robot 或服务器在线状态；
• 检测业务进程是否存活；
• 跨平台设备互联；
• 网络质量评估；
• 服务 SLA 监测；
• 主备服务器选择；
• 云边通信状态监测。

需要特别处理的嵌入式场景

10. 安全系统中的使用原则

对于Safety OS 或工业空间安全系统，将网络状态分层定义：

关键原则是：

Netlink 可以触发降级，但不能单独触发恢复放行。

例如，网线重新插入时：

Carrier UP
→ IP恢复
→ 路由恢复

不能直接从 OFFLINE 切换到 ONLINE，必须继续完成：

Heartbeat连续成功
→ 业务数据恢复更新
→ 时间同步有效
→ 状态一致性检查通过
→ ONLINE或RECOVERY_CHECK

11. 推荐组合架构

flowchart TB
    A["Linux内核网络事件"] --> B["Netlink监听器"]
    B --> C{"接口、地址或路由变化"}
    C --> D["进入VERIFYING"]
    D --> E["启动快速Heartbeat"]
    E --> F{"连续验证结果"}

    F -->|"连续成功达到门限"| G["ONLINE"]
    F -->|"连续失败达到门限"| H["OFFLINE"]
    F -->|"部分目标异常"| I["DEGRADED"]

    G --> J["低频Heartbeat"]
    J -->|"失败或Netlink变化"| D
    H -->|"Netlink恢复或重试定时器"| D
    I -->|"重新验证"| D

建议职责划分：

• Netlink 监听器：产生网络变化事件；
• Heartbeat Manager：维护探测目标和 RTT；
• Network State Machine：执行门限、防抖和状态迁移；
• Supervisor：决定降级、切换、重连或安全动作；
• Event Recorder：记录证据和状态变化。

12. 最终选型建议

只使用 Netlink

适合：

• 只关心网卡、网线、IP和路由变化；
• 不需要知道服务器是否可用；
• 极度受限的 Linux 嵌入式设备。

不适合：

• 工业控制；
• 云边通信；
• PLC/AGV/机器人在线判断；
• 安全相关系统。

只使用 Heartbeat

适合：

• 非 Linux 平台；
• 只关心一个确定服务是否可用；
• 不需要区分本地接口、路由和对端故障。

不足是：

• 故障定位能力较弱；
• 物理断网检测依赖超时；
• 稳定期持续消耗资源。

Netlink + 固定高频 Heartbeat

可靠性较高，但长期资源开销偏大。适合：

• 对检测时间要求严格；
• 设备数量有限；
• 有线网络；
• 功耗和流量不敏感。

Netlink + 快速验证 + 低频 Heartbeat

这是嵌入式工业平台的推荐方案：

Netlink负责快速发现
Heartbeat负责真实性验证
低频Heartbeat负责持续确认
状态机负责防抖、降级和恢复

默认参数：

最终可概括为：Netlink 判断本机网络环境是否发生变化，Heartbeat 判断端到端业务链路是否真正可用。对于嵌入式工业和安全系统，应以 Netlink 作为快速事件源，以应用层 Heartbeat 作为最终验证依据。