车载以太网正在从高端车型向主流平台渗透。随着域集中式架构和中央计算架构的推进车内通信不再只是CAN总线的天下以太网承载的业务越来越多——DoIP诊断、SOME/IP服务通信、UdpNM网络管理全部跑在传输层协议之上。而传输层的两个核心协议TCP和UDP决定了这些业务能不能稳定运行。很多工程师在做车载网络设计时对这两个协议的理解停留在“TCP可靠、UDP快”的层面但具体到端口规划、连接管理、重传策略往往需要更细的判断。传输层的职责进程到进程的交付网络层的IP协议负责把数据送到目标主机但主机里跑着几十上百个进程真正需要通信的是进程不是主机。传输层要解决的就是这个问题把数据交付给具体的应用进程。识别进程靠端口号16位范围0到65535。这个区间分三段0到1023是熟知端口由IANA统一分配系统设计中不能占用1024到49151是登记端口需要在IANA登记防止重复车载场景中的DoIP用13400端口、SOME/IP SD用30490端口都属于这一段49152到65535是动态端口客户端自由使用。在整车架构设计中动态端口区间需要按域做分段规划。比如自动驾驶域、智能座舱域各划一段避免不同域的应用在端口分配上发生冲突。这个问题在项目早期容易被忽略等到多个域集成时才发现端口撞车返工成本很高。传输层通信的端点叫套接字Socket由IP地址加端口号组成。一条连接由五元组唯一标识源IP、目的IP、源端口、目的端口、协议。这个五元组在车载以太网抓包分析时是基础中的基础——看到一条异常流量第一步就是确认五元组是否符合预期。TCP可靠性是怎么实现的TCP面向字节流每个字节都有编号。序列号是本报文段第一个数据字节的编号确认号是期望收到的下一个字节序号。这个设计决定了TCP的确认机制是累积确认而不是逐个确认。TCP首部前20字节固定选项可变最长40字节所以首部长度范围是20到60字节。几个字段直接决定抓包分析的思路数据偏移字段取值5到15单位是4字节对应首部20到60字节六个控制位中SYN建连、FIN释放、ACK确认、RST复位、PSH立即上交应用、URG紧急数据窗口大小是接收方告诉发送方还能收多少数据这是流量控制的依据。校验和的覆盖范围除了首部和数据还要在前面补12字节伪首部包括源IP、目的IP、协议号和长度。这个设计是为了校验数据有没有送错主机。选项字段中MSS最大报文段长度是建连时双方协商的关键参数。以太网MTU是1500字节减去IP头20字节和TCP头20字节MSS最大1460。MSS设小了网络利用率低设大了会导致IP层分片两种情况都会影响车载网络的实时性。窗口扩大选项解决的是16位窗口最大只有64KB的问题在高延迟带宽积网络中64KB的窗口远远不够用移位因子最大14窗口可以扩到2的30次方减1。时间戳选项用于计算RTT和防止序号绕回SACK选择确认则让接收方在收到不连续字节时通知发送方只重传缺失部分而不是重传整个窗口。连接建立与释放的实际影响TCP建连需要三次握手释放需要四次挥手。握手过程中ACK号永远是对方序号加1SYN和FIN各占一个序号所以客户端最后一次挥手的ACK要等2MSL才算真正关闭。在车载场景中这个机制带来的直接影响是诊断设备与车辆建立DoIP连接时需要预留足够的建连时间。如果ECU在启动阶段就尝试建立TCP连接而网络栈还没完全初始化握手失败会导致诊断会话建立延迟。很多整车厂的诊断规范里会明确要求ECU上电后需要等待一段时间才允许建立诊断连接原因就在这里。四次挥手同样需要注意。主动关闭方在发送最后一个ACK后需要等待2MSL才能释放连接。如果车辆在诊断过程中频繁建立和断开连接这个等待时间会累积影响诊断效率。这也是为什么DoIP诊断通常建议保持长连接而不是每次操作都重新建连。可靠性三件套重传、流量控制、拥塞控制TCP的可靠传输等于ACK确认加重传这套机制叫ARQ自动重传请求。超时重传RTO中每个报文段设一个计时器超时未确认就重传。RTO要动态计算设长了链路空转设短了无谓重传。RFC 2988给出的公式是RTO等于加权平均往返时间加4倍偏差。在车载以太网中RTT通常很小RTO的设置需要根据具体链路的实测数据来调整不能直接套用公网的默认值。快速重传解决的是超时等待太长的问题。接收方收到乱序报文立即回ACK告知缺号发送方连续收到3个重复ACK就判定丢包不等超时立即重传。这个机制在车载诊断刷写大块数据时特别重要——如果等RTO超时再重传刷写时间会明显拉长。流量控制解决的是发送方太快、接收方来不及收的问题。TCP用滑动窗口让发送方不要超过接收方的处理能力。发送缓冲分成四段已发送已确认、已发送未确认、可发送、不可发送。窗口内序号用完还没收到确认就必须停下。拥塞控制解决的是全局问题。流量控制是端到端的事拥塞控制是网络整体的事。核心思路是没拥塞就把拥塞窗口调大拥塞了就调小。慢启动阶段窗口从小值开始指数增长达到慢启动阈值后转入拥塞避免窗口线性增长。一旦超时阈值降为当前一半窗口重新慢启动。收到3个重复ACK时触发快速重传和快速恢复不必回到慢启动只把阈值减半。车载网络的特点是拓扑固定、链路质量可控拥塞控制的激进程度可以适当调整。比如在封闭的车内网络中慢启动的初始窗口可以设置得比公网更大减少建连初期的等待时间。UDP极简路线在车载场景的价值UDP只在IP之上加了两样东西端口复用分用和差错检测。特点四个无连接、尽力交付、面向报文、无拥塞控制。首部只有8字节四个字段各占2字节。在车载场景中UDP的价值不在于“快”而在于“合适”。SOME/IP SD服务发现用UDP 30490端口因为服务发现是周期性的广播或组播丢一两个包不影响整体功能下一周期会重新发送。UdpNM网络管理同样用UDP因为网络管理报文是周期性发送的偶尔丢包不会导致网络状态判断错误。反过来如果这些场景强行用TCP每个报文都要建连、确认、重传网络管理报文的实时性反而会下降。用错协议比不用协议更麻烦。车载场景怎么选几个实际判断维度看业务是否需要可靠交付。DoIP诊断刷写大块数据丢一个字节都可能导致刷写失败必须用TCP。周期性的网络管理报文丢一两个包不影响功能用UDP更合适。看通信模式是一对一还是一对多。TCP只支持一对一UDP支持一对多和组播。SOME/IP SD服务发现需要组播用UDP是必然选择。看实时性要求。UDP没有拥塞控制随发随走实时性更好。但这也意味着UDP需要应用层自己做流量控制否则可能压垮接收方。看首部开销。TCP首部20到60字节UDP首部8字节。在车载这种带宽相对受限的环境中首部开销的差异在大量小报文场景下会累积成可观的带宽占用。车载以太网的设计本质上是在可靠性和实时性之间做权衡。TCP保证可靠代价是延迟和开销UDP保证实时代价是可靠性需要应用层自己兜底。理解了这一点选型就不再是“哪个更好”的问题而是“哪个更合适”。