3. TRDP协议头深度解析
TRDP（Train Real-time Data Protocol）的报文分析，第一步永远是“把头部读对”。TRDP 报文头固定为 40 字节（不含应用数据），它决定了这帧数据是谁发的、发给谁、属于哪类通信、携带多少有效载荷，以及是否允许丢包。抓包工具默认只把 TRDP 当作普通 UDP 展示，若不逐字段对照协议规范，很容易把 ComId 当成端口号、把序列号当成时间戳。本节先建立字段语义，再用一帧真实结构的示例报文做逐字节标注。
一、40 字节头部到底装了什么
TRDP 头部按大端序（网络字节序）编码，可划分为三个逻辑区：通信标识区（版本号、消息类型、ComId）、路由与生命周期区（源/目的 IP、序列号、时间戳、生存时间）、数据集描述区（数据集长度、保留字段、数据集标识）。理解这个分区比死记偏移量更重要，因为抓包时我们通常先看消息类型和 ComId 定位业务，再看序列号和数据集长度判断数据是否连续、长度是否异常。
各字段的偏移与含义如下表所示（偏移从 TRDP 头首字节起算）：
| 偏移 | 长度 | 字段 | 含义与判读要点 |
|---|---|---|---|
| 0 | 2 B | 版本号 Version | 高字节主版本、低字节次版本，常见 0x0100 表示 1.0 |
| 2 | 2 B | 消息类型 MsgType | 区分过程数据 PD、消息数据 MD、报警等，决定后续解析路径 |
| 4 | 4 B | ComId | 通信标识，业务层面的“数据通道号”，不是 UDP 端口 |
| 8 | 4 B | 序列号 SeqNo | 发送端递增计数，用于检测丢帧与乱序 |
| 12 | 4 B | 时间戳 TimeStamp | 发送时刻，单位通常为 1 μs 或 10 μs，取决于实现 |
| 16 | 4 B | 数据集长度 DatasetLength | 应用数据字节数，不含 40 字节头 |
| 20 | 4 B | 数据集标识 DatasetId | 标识数据集结构模板，用于校验载荷布局 |
| 24 | 4 B | 源 IP / 目的 IP | 冗余与路由判断依据，与 UDP 层地址应一致 |
| 32 | 4 B | 生存时间 / 保留 | PD 通信的时效约束，超时即视为无效数据 |
需要强调：ComId 与 UDP 端口是两个维度。同一端口上可以承载多个 ComId，抓包过滤时应先按端口缩小范围，再按 ComId 区分业务流。序列号则是判断“数据是否新鲜”的关键——PD 数据周期性发送，若序列号长时间不递增，说明发送端卡死或链路中断，而不是数据没变。
二、抓一帧真实报文并逐字段对照
假设在车载网络中抓取一帧过程数据（PD），Wireshark 显示 UDP 目的端口 17224，载荷十六进制前若干字节如下（示例数据，用于讲解字段位置，非实测抓包）：
01 00 50 64 01 02 03 04 00 00 00 1A
00 01 E2 40 00 00 00 20 00 00 00 64
C0 A8 0A 0B C0 A8 0A 14 00 00 00 64
...逐段读：前两字节 01 00 是版本号 1.0；50 64 是消息类型，PD 过程数据的典型取值；01 02 03 04 是 ComId，说明这帧属于编号 0x01020304 的数据通道；00 00 00 1A 是序列号 26，下一帧应为 27；00 01 E2 40 是时间戳；00 00 00 20 是数据集长度 32 字节，意味着头部之后还有 32 字节应用数据；00 00 00 64 是数据集标识 100，用来对照数据集结构定义；随后 8 字节是源/目的 IP，与 UDP 层地址应一致；最后 00 00 00 64 是生存时间，示例中为 100（单位依实现，常为 ms）。
这里有一个非常实用的校验动作：用 UDP 长度反推数据集长度。若 UDP 载荷总长为 72 字节，减去 40 字节头，应得 32 字节，与头部 DatasetLength 一致；若不一致，说明抓到了分片、头部被截断，或发送端长度字段填错。这个交叉验证能在几秒内排除大部分“看起来像 TRDP 但解析错位”的问题。
三、字段之间的联动关系
单看一个字段往往得不出结论，真正有价值的是字段组合。消息类型决定了解析路径：PD 数据周期性强，重点看序列号与 TTL；MD 消息数据是请求/应答式，重点看 ComId 配对与数据集长度是否随请求变化。ComId 与数据集标识共同锁定“这帧数据是什么结构”，前者是业务通道，后者是结构模板，二者对不上就说明配置表与实际上线版本不一致。
序列号与时间戳的组合用于判断链路健康：正常情况下序列号逐帧加一、时间戳单调递增；若序列号跳变而时间戳连续，多为中间节点丢帧；若两者同时停滞，则是发送端停止发布。TTL 则给出时效边界，接收端在 TTL 内未收到新帧就应判定数据失效，而不是继续沿用旧值——这一点在制动、门控等安全相关业务上尤其关键。
四、把字段读成结论
头部解析的终点不是“认全字段”，而是能对一帧报文下判断。看到 ComId 属于某车门控制通道、消息类型为 PD、序列号连续、数据集长度与结构定义吻合、TTL 未超时，就可以判定这帧数据有效可用；反之，任何一项异常都应记录为待排查点，并回到发送端配置、网络链路或数据集定义中定位。掌握这套“字段—联动—结论”的读法，后续的丢帧分析、冗余切换判断和故障复现才有可靠的数据基础。