写在开篇·蓉儿继续挖坑

上回说到，郭靖搞清楚了Offer Service的基本原理——服务端广播“我会啥，我在这”，TTL告诉客户端有效期。

郭靖合上笔记本，突然皱起眉头：“蓉儿，我有个问题——如果每个ECU都每隔1.5秒发一次Offer，那车上几十个ECU，网络岂不是要炸？”

黄蓉咬了口糖葫芦：“问得好！实际上SD根本不是一直高频发的。 今天就把SD的发送策略讲透——启动时快稍后慢，断断续续哥还在。”

一、不是“一直发”，是“启动时多发，稳定后少发”

黄蓉在白板上画了一条时间线：

┌─────────────────────────────────────────────────────────────────────┐
│                    SD的“三段式”发送策略                              │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│  上电瞬间                                                           │
│     │                                                              │
│     ▼                                                              │
│  ┌─────────────────────────────────────────────────────────────┐   │
│  │ 第一阶段：Initial Repetition Phase（快速重复期）              │   │
│  │  ┌─────┬─────┬─────┬─────┬─────┐                            │   │
│  │  │ 0ms │100ms│200ms│400ms│800ms│  → 间隔越来越长             │   │
│  │  └─────┴─────┴─────┴─────┴─────┘                            │   │
│  │  目的：让客户端快速发现，不用等很久                            │   │
│  └─────────────────────────────────────────────────────────────┘   │
│                              ↓                                     │
│  ┌─────────────────────────────────────────────────────────────┐   │
│  │ 第二阶段：Repetition Phase（重复期）                          │   │
│  │  ┌──────┬──────┬──────┐                                     │   │
│  │  │ 1.5s │ 1.5s │ 1.5s │  → 每隔固定时间发                    │   │
│  │  └──────┴──────┴──────┘                                     │   │
│  │  目的：稳定客户端缓存，确认服务还活着                          │   │
│  └─────────────────────────────────────────────────────────────┘   │
│                              ↓                                     │
│  ┌─────────────────────────────────────────────────────────────┐   │
│  │ 第三阶段：Main Phase（稳定期）                                │   │
│  │  ┌──────┬──────┬──────┬──────┐                              │   │
│  │  │ 3s   │ 3s   │ 3s   │ ...  │  → 稀疏发送                   │   │
│  │  └──────┴──────┴──────┴──────┘                              │   │
│  │  目的：维持存在感，减少网络负载                                │   │
│  └─────────────────────────────────────────────────────────────┘   │
│                                                                    │
└─────────────────────────────────────────────────────────────────────┘

郭靖恍然大悟：“哦～～原来不是一直高频发，是启动时多发几次让客户端快速知道，稳定后就少发了！”

二、为什么不能一直高频发

黄蓉反问：“你想啊，车上几十个ECU，如果每个都每隔1.5秒发一次Offer，网络会怎样？”

车辆规模	每个ECU频率	每秒总消息数	带宽占用（约100字节/条）
30个ECU	1.5秒/次	20条/秒	约16Kbps
50个ECU	1.5秒/次	33条/秒	约26Kbps
100个ECU	1.5秒/次	67条/秒	约53Kbps

“虽然53Kbps对于100Mbps以太网来说很小（0.05%），但没必要。 稳定后完全可以把频率降到3秒甚至10秒一次。”

三、三段式参数详解

黄蓉列了一张典型配置表：

参数	典型值	说明
Initial Repetition Base Delay	100ms	初始重试基时
Initial Repetition Count	5次	启动时快速发5次
Repetition Base Delay	1.5s	重复期间隔
Repetition Count	3次	重复期发3次
Main Phase Delay	3s	稳定期间隔
TTL	3s	有效期（必须大于Main Phase Delay，否则有空窗期）

重点：Main Phase Delay 必须 ≤ TTL，最好 ≤ TTL/2，否则客户端会认为服务过期。

四、郭靖的追问：那TTL到底是啥？

郭靖盯着TTL字段：“TTL=3秒，意思是3秒后服务就下线了？那3秒后还没发新Offer，客户端怎么办？”

黄蓉画了一个时序图：

时间线：
0.0秒：车窗ECU发Offer（TTL=3）→ 座舱记：“服务活到3.0秒”
0.5秒：没收到新Offer
1.0秒：没收到新Offer
1.5秒：车窗ECU发新Offer（续约）→ 座舱刷新：“服务活到4.5秒”
...
3.0秒：如果车窗ECU挂了，没发新Offer → 座舱：“3.0秒到了，服务下线，删掉”

“TTL是客户端用来判断服务是否过期的，不是服务端自己倒计时。服务端要定时续约，告诉客户端‘我还活着’。”

五、那为什么还要TTL？不能靠心跳吗？

郭靖又问：“那直接用心跳不就行了？TTL是不是多余？”

黄蓉摇头：“心跳只能告诉客户端‘我还在’，但TTL还能告诉客户端‘我如果不在了，你多久能知道’。**

没有TTL	有TTL
客户端不知道服务什么时候会过期	客户端明确知道“有效期X秒”
服务端挂了，客户端永远不知道	服务端挂了，TTL超时后客户端自动清理

“TTL给了客户端一个‘确定性’——最长等X秒，没消息就可以认为服务没了。”

六、黄蓉的小本本

郭靖翻开她的笔记本，上面写着：

SD的三段式发送策略：

阶段	频率	目的
快速重复期	密集（几十到几百毫秒）	让客户端快速发现
重复期	中等（1-2秒）	稳定缓存
稳定期	稀疏（几秒到几十秒）	维持存在感，省带宽

TTL不是发送间隔，是“有效期”

Main Phase Delay 必须 ≤ TTL，否则有空窗期

一句口诀：启动时快稍后慢，断断续续哥还在

写在最后

郭靖合上笔记本：“原来SD不是一直高频发，是启动时多发几次让客户端快速发现，稳定后就稀疏发了。TTL是有效期，不是发送间隔。Main Phase Delay必须小于TTL，否则客户端会以为服务下线。”

黄蓉咬了口糖葫芦：“那如果客户端启动晚了，没听到启动时那几次Offer怎么办？”

郭靖摇头。

“下篇预告：客户端主动问Find，谁会啥快出现——Find Service详解。”

打完收工，886。