车载以太网正在从高端车型向主流平台渗透。随着域集中式架构和中央计算架构的推进，车内通信不再只是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号永远是对方序号加1，SYN和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保证实时，代价是可靠性需要应用层自己兜底。理解了这一点，选型就不再是“哪个更好”的问题，而是“哪个更合适”。
