SOME/IP-SD 是车载以太网 AUTOSAR 标准里的服务发现协议，本质就是一张去中心化、所有 ECU 都能广播写入的动态服务目录，它不用中央服务器，设备上电后通过 UDP 组播对外宣告自己提供的服务、IP 端口、版本，其他节点可以主动查找、订阅服务，灵活适配智能车域控架构；但原生协议本身没有内置安全校验，任何人接入同网段都能发 Offer、Find 报文，很容易伪造服务、劫持订阅，工程落地的时候必须额外手动加上六道安全闸门做防护，从报文、身份、版本、订阅、生命周期、网络边界层层拦截风险，理解它的发现流程，再配套这六重校验，才能在车规项目里安全使用 SOME/IP-SD。
一、SOME/IP-SD 服务目录基础机制
SOME/IP-SD 默认 UDP 组播，固定端口 30490，组播地址 224.244.224.245，核心交互分成三步：
- 宣告（OfferService）：服务提供者周期性组播发布服务目录条目，包含 Service ID、Instance ID、主 / 次版本、端点信息、TTL；
- 查找（FindService）：客户端组播查询目标服务，匹配到的节点单播回复 Offer；
- 订阅（SubscribeEventgroup）：客户端确认服务后发起事件组订阅，服务端 ACK 确认，后续事件数据直接点对点传输。
| 关键字段 | 作用说明 |
|---|---|
| Service ID | 服务唯一编号，区分不同功能服务 |
| Instance ID | 同服务的多个实例标识 |
| Major/Minor Version | 服务接口版本，防止版本不兼容调用 |
| TTL | 服务存活时长，超时自动失效 |
| Endpoint | 实际通信的 IP、端口、传输协议 |
二、SOME/IP-SD 必须自己实现的六道安全闸门
原生 SOME/IP-SD 规范不包含认证、防伪造逻辑，下面六道闸门需要上层软件自主开发集成：
✅ 闸门 1：报文来源白名单校验
只信任预配置可信 ECU 节点 IP，丢弃陌生 IP 发来的 Offer、Find、Subscribe 报文，拦截外部非法节点注入虚假服务目录。
✅ 闸门 2：服务版本强匹配闸门
订阅、调用前强制校验 Major 版本，主版本不一致直接拒绝，避免接入接口不兼容的伪造服务。
✅ 闸门 3：订阅权限访问控制闸门
维护服务访问权限表，哪些客户端允许订阅哪个 EventGroup，不在权限列表里的订阅请求直接拒绝 ACK。
✅ 闸门 4：TTL 与周期刷新风控闸门
限制 Offer 报文最小、最大发送周期，过滤高频疯狂广播的异常报文；TTL 设置上下限，拒绝超长 TTL 恶意驻留虚假目录。
✅ 闸门 5：订阅防重放、防风暴闸门
增加报文序列号，拦截重复订阅报文；单服务限制最大订阅客户端数量，防止大量订阅把服务节点带宽打满。
✅ 闸门 6：VLAN / 网络域边界隔离闸门
把 SD 组播报文限制在对应域内（动力域、座舱域、智驾域隔离），不允许跨域组播互通，从网络层面隔断横向渗透。
三、适用场景与选型判断
适合：AUTOSAR 车载以太网、域控 SOA 架构、车内 ECU 动态服务发布订阅、OTA 服务管理。
不适合：需要强可信中心目录、高安全等级且无法自定义安全闸门的场景，原生 SD 没有加密和身份认证，直接裸跑有攻击风险。
【常见问题】
问题 1：SOME/IP-SD 的服务目录为什么说是人人可写，风险点在哪？
回答 1：SOME/IP-SD 采用去中心化组播机制，同一网段任意节点都能发送 OfferService 报文往全网广播服务目录条目，协议原生没有身份校验；攻击者接入车内以太网后就能伪造虚假服务条目，诱导其他 ECU 订阅恶意节点，所以需要六道闸门管控。
问题 2：SOME/IP-SD 六道安全闸门是协议自带的吗？
回答 2：不是，六道安全闸门不属于 SOME/IP-SD 标准定义内容，AUTOSAR 的 SD 规范只定义服务发现交互逻辑，认证、白名单、权限、版本校验这些安全能力，都要开发者在应用层或者 COM 层自己编码实现。
问题 3：SOME/IP-SD 和传统中心化服务目录最大差别是什么？
回答 3：SOME/IP-SD 是去中心化，没有中心服务器存目录，每个 ECU 本地维护收到的服务目录，靠组播同步；中心化目录所有服务注册、查询都走中心节点，管控更简单，但灵活性、热插拔能力弱，车载域控更偏好 SOME/IP-SD 这种动态发现模式。
【参考资料】
[2026-01-15]（SOME/IP-SD 安全防护实践指南）VxLabs Security
[2025-10-20]（汽车以太网 SOME/IP-SD 从 CAN 到 SOA 架构解析）智驾星闻
[2024-11-18]（AUTOSAR SOME/IP-SD 模块规范解读）牛喀网
[2024-04-24]（SOME/IP-SD 报文结构与通信流程）火龙果 UML
【免责声明】
- 本文讲解的 SOME/IP-SD 服务目录机制、六道安全闸门属于工程落地方案，不替代 AUTOSAR 官方规范，正式项目以 AUTOSAR 标准文档为准；
- 六道安全闸门仅为基础防护手段，高功能安全、信息安全等级项目，还需要叠加 IPsec、MACsec、身份证书等方案；
- SOME/IP-SD 组播报文天然存在广播域扩散风险，实际部署必须配合车载网络规划、交换机策略；
- 本文内容仅为技术科普，不直接作为车规软件的安全设计交付依据。