📚 课程目录第4章 SOME/IP-SD服务发现机制

4. SOME/IP-SD服务发现机制

SOME/IP-SD（Service Discovery）是 SOME/IP 协议栈中负责“服务在哪里、是否可用、如何订阅”的核心协议。它不传输业务数据，却决定了业务数据能否被正确找到和接收。理解 SD，需要同时掌握服务注册、事件组订阅、心跳维持、TTL 生命周期、状态机迁移，以及组播与单播两种通信方式的配合。

一、核心原理：SD 报文与 Entry 结构

SOME/IP-SD 报文本身也是 SOME/IP 消息，Service ID 固定为 0xFFFF，Method ID 为 0x8100，采用通知（Notification）方式发送。其载荷由 Flags、Entries 数组和 Options 数组组成。Entries 描述“发生了什么”，Options 描述“通过什么地址和协议访问”。

Service Entry：用于服务注册与查找，包含服务实例 ID、TTL、Minor Version 等。
Eventgroup Entry：用于事件组订阅，包含 Eventgroup ID、Counter、TTL 等。
Endpoint Option：携带 IP、端口、传输层协议（UDP/TCP），供对端建立通信。
Configuration Option：用于传递配置参数，如组播地址、心跳周期等。

TTL 是 SD 的灵魂字段。TTL 为 0 表示“停止提供”或“停止订阅”；TTL 大于 0 表示在指定秒数内有效。服务端必须周期性地重新发布 OfferService，客户端必须周期性地重新发送 SubscribeEventgroup，否则条目过期，通信关系自动解除。

二、服务注册、订阅与心跳流程

服务发现通常遵循“服务端 Offer、客户端 Find/Subscribe、服务端 Ack、双方维持 TTL”的闭环。下面用一张信号链图展示组播与单播的交互路径。

图中①到⑥是典型的冷启动流程：服务端先组播 OfferService，客户端收到后以单播方式发送 SubscribeEventgroup，服务端再以单播回 Ack。之后进入 TTL 维持阶段，双方通过周期性重发刷新有效期。若 TTL 过期，服务端发送 StopOfferService，客户端停止接收事件；若客户端仍需要服务，则重新进入 FindService 流程。

三、状态机与 TTL 参数关系

SOME/IP-SD 的状态机可简化为四个状态：Down、Ready、Subscribed、Stopped。服务端在 Down 状态等待服务就绪，进入 Ready 后开始组播 OfferService；客户端在 Down 状态发送 FindService，收到 Offer 后进入 Ready，再发送 SubscribeEventgroup 进入 Subscribed。TTL 到期或收到 StopOffer 后回到 Down。

状态	触发条件	发送报文	TTL 行为
Down	服务未就绪 / 订阅未建立	FindService（客户端）	无有效 TTL
Ready	服务就绪 / 收到 Offer	OfferService（服务端）	TTL 开始计时
Subscribed	收到 SubscribeEventgroupAck	SubscribeEventgroup（客户端）	周期刷新 TTL
Stopped	TTL 过期 / 收到 StopOffer	StopOfferService / StopSubscribe	TTL 置 0

TTL 的取值需要权衡：过短会导致频繁重发，增加网络负载；过长则故障发现延迟大。工程中常见 TTL 为 3 秒，重发周期为 TTL 的 1/3 到 1/2。例如 TTL=3s，则约每 1s 重发一次 OfferService 或 SubscribeEventgroup。

四、抓包分析与常见误区

使用 Wireshark 抓包时，过滤条件可写为 someip.service == 0xFFFF && someip.method == 0x8100。重点观察以下字段：

someip.sd.entry.type == 0x01   // OfferService
someip.sd.entry.type == 0x00   // FindService
someip.sd.entry.type == 0x06   // SubscribeEventgroup
someip.sd.entry.type == 0x07   // SubscribeEventgroupAck
someip.sd.entry.ttl            // 生命周期
someip.sd.option.ipv4_address  // 单播地址
someip.sd.option.port          // 端口

抓包技巧：先看组播 OfferService 是否周期出现，再看单播 SubscribeEventgroup 是否被 Ack。若只有 Offer 没有 Ack，通常是服务端未监听单播端口或 Eventgroup ID 不匹配。

常见误区：把 SD 当成业务数据通道。SD 只负责“发现和订阅”，真正的服务数据通过单播 UDP/TCP 传输。另一个误区是忽略 TTL 刷新，导致服务在运行中“莫名消失”。

复盘时建议按“组播 Offer → 单播 Subscribe → 单播 Ack → TTL 刷新 → 异常停止”五步核对。若某一步缺失，优先检查网络是否允许组播、防火墙是否放行单播端口、Eventgroup ID 与 Service ID 是否一致。只有 SD 链路稳定，SOME/IP 的高可靠通信才有基础。