写在开篇·蓉儿继续挖坑
上回说到，郭靖搞清楚了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。