3、车载以太网协议栈：TCP/IP协议栈在车内的适配与裁剪
说实话，做车载以太网这些年，我最大的感触就是：标准TCP/IP协议栈，在车里根本跑不动。
你想想看，咱们平时在电脑上用的TCP/IP，那是给服务器和PC准备的。车里呢？一个ECU可能只有几百KB的RAM，主频才几十兆赫兹。把完整的Linux协议栈搬上去？不现实。
所以，适配与裁剪就成了必修课。我个人习惯把这件事分成三个层面来考虑：资源约束、实时性要求、功能必要性。
3.1 资源约束：内存与CPU的极限拉扯
先说说最现实的问题——内存。
标准的TCP实现，每个连接需要维护发送缓冲区、接收缓冲区、拥塞控制状态机。一个连接轻松吃掉几十KB。车里一个网关可能要同时管理几十个Socket连接，你算算这得多少内存？
我在项目中遇到过一台ADAS域控制器，RAM总共就1MB。跑个完整的LwIP协议栈，光协议栈本身就要占掉300KB。剩下的700KB要跑应用、存数据，捉襟见肘。
怎么办？
- 裁剪缓冲区：把TCP的收发缓冲区从默认的64KB砍到4KB甚至2KB。对于车内短报文通信，完全够用。
- 去掉不必要的功能：比如选择性确认（SACK）、窗口缩放（Window Scaling），这些在车内局域网场景下基本用不到。
- 使用轻量级实现：比如uIP、TinyTCP，这些协议栈的代码量只有标准LwIP的十分之一。
关键数据：我实测过，一个裁剪后的uIP协议栈，ROM占用不到10KB，RAM占用不到2KB。跑个简单的DoIP诊断服务，完全没问题。
3.2 实时性：TCP的“慢”是原罪
TCP的可靠性是靠重传和确认机制保证的。但重传意味着延迟。在车里，有些消息是等不起的。
举个例子：摄像头数据流。如果一帧图像丢了，你重传？等重传到了，下一帧都来了。这时候，丢帧比延迟更可接受。
所以，车内协议栈的裁剪，核心思路是：该用TCP的地方用TCP，不该用的地方果断换UDP。
我个人习惯这样划分：
| 通信场景 | 推荐协议 | 原因 |
|---|---|---|
| 诊断（DoIP） | TCP | 需要可靠传输，数据量小 |
| 固件升级 | TCP | 数据完整性要求高 |
| 传感器数据流 | UDP | 实时性优先，允许少量丢包 |
| 控制指令 | UDP + 应用层ACK | 既要快，又要确认 |
| 日志传输 | TCP | 不能丢，但可以慢一点 |
嗯，这里要注意：UDP虽然快，但没有拥塞控制。在车内这种相对封闭、可控的网络里，问题不大。但如果多个ECU同时发UDP广播，还是可能把总线打爆的。我建议在应用层做简单的速率限制。
3.3 功能裁剪：哪些可以砍？
标准的TCP/IP协议栈，功能太多了。我列一下在车里通常可以砍掉的部分：
- IP分片与重组：车内以太网MTU通常是1500字节，报文很少超过这个值。砍掉分片逻辑，能省不少代码。
- 多播路由：车里用不到复杂的IGMP协议，简单广播就够了。
- ARP缓存老化：车内设备数量固定，ARP表可以做成静态的，省掉老化定时器。
- TCP的Nagle算法：这个算法是为了减少小包数量，但会增加延迟。车里通信，延迟敏感，建议关掉。
- TCP的Keep-Alive：车里连接状态由应用层管理，协议层的Keep-Alive是多余的。
我的经验：我曾经在一个项目中，把LwIP的代码从2万行砍到了8000行。砍完之后，编译出来的二进制体积小了60%，运行时的CPU占用率从15%降到了3%。代价是什么？有些高级功能用不了，但那些功能本来就用不到。
3.4 适配：让协议栈“认识”车载总线
裁剪完了，还得适配。车载以太网和普通以太网有个很大的不同：它跑在特定的物理层上，比如100BASE-T1或1000BASE-T1。
这意味着，协议栈的底层接口需要做适配：
- MAC层驱动：要支持车载PHY芯片的寄存器配置，比如休眠唤醒、链路状态检测。
- VLAN支持：车里常用VLAN做网络隔离，比如把诊断流量和娱乐流量分开。协议栈要支持802.1Q。
- AVB/TSN支持：如果要做音视频同步或时间敏感网络，协议栈需要支持802.1AS（时间同步）和802.1Qav（流量整形）。
说白了，裁剪是减法，适配是加法。减掉不需要的，加上车里特有的。
3.5 一张图看懂协议栈裁剪逻辑
下面这张图，是我自己总结的车载TCP/IP协议栈裁剪决策流程。你可以把它当作一个检查清单：
这张图的逻辑很简单：先评估资源，再分析场景，最后做裁剪决策。资源够的，保留完整功能；资源不够的，按需裁剪。裁剪清单我列在右侧了，你可以对照着看。
3.6 避坑指南：我曾经踩过的坑
最后，分享几个我亲身经历过的坑：
坑1：裁剪过度导致兼容性问题
我曾经为了省内存，把TCP的窗口大小砍到了1KB。结果和某个诊断工具通信时，对方发了一个大报文，直接把我这边的缓冲区撑爆了。后来我才意识到，裁剪要留余量，不能卡着极限值来。
坑2：忘了关Nagle算法
有一次做DoIP诊断，发现每次发送诊断请求后，要等200ms才能收到响应。查了半天，发现是Nagle算法在作祟——它把小包攒起来再发，攒包的过程引入了延迟。关掉之后，延迟降到了5ms以内。
坑3：UDP不做速率限制
这个坑我印象特别深。一个ECU在启动时疯狂发UDP广播，直接把网关的CPU打到了100%。其他ECU的报文全被堵住了。后来我在UDP发送端加了一个简单的令牌桶限速，问题解决。
嗯，关于TCP/IP协议栈在车内的适配与裁剪，核心思路就是这些。说白了，没有最好的协议栈，只有最合适的协议栈。根据你的硬件资源和应用场景，做出取舍，这就是车载嵌入式工程师的日常。
公众号:蓝海资料掘金营，微信deep3321