1. TRDP协议概述与抓包环境搭建

TRDP（Train Real-time Data Protocol，列车实时数据协议）是 IEC 61375 系列标准中定义在列车通信网络应用层的关键协议，主要用于列车控制、诊断与状态监测等场景中设备之间的实时数据交换。理解 TRDP 的第一步，是把它放回列车通信网络的整体架构中去看：它并不直接跑在以太网上，而是建立在 UDP/TCP 传输层之上，通过一套轻量的报文头与通信机制，为车载设备提供过程数据（PD）和消息数据（MD）两类通信服务。

TRDP 在列车通信网络中的定位

现代列车通信网络通常分为列车级网络（ETB，Ethernet Train Backbone）和车辆级网络（ECN，Ethernet Consist Network）。ETB 负责贯通整列车的骨干通信，ECN 负责单节车厢内部设备的互联，两者之间通过列车骨干网节点（ETBN）连接。TRDP 运行在这两层以太网之上，为编组内的牵引、制动、车门、空调、信号等子系统提供统一的通信语义。相比直接使用原始 UDP，TRDP 的价值在于：它规定了设备如何声明自己的通信端点、如何周期性发布过程数据、如何按需发送带确认的消息数据，以及如何在网络异常时进行监督与恢复。

从协议栈角度看，TRDP 位于应用层与传输层之间，其下依次是 UDP/TCP、IP、以太网 MAC 与物理层。过程数据 PD 通常基于 UDP 组播或单播，强调周期性与低延迟；消息数据 MD 通常基于 TCP，强调可靠传输与请求应答。抓包分析时，我们看到的帧结构就是“以太网头 → IP 头 → UDP/TCP 头 → TRDP 头 → 应用数据”的层层封装，这也是后续逐层解析的基础。

典型应用场景与报文特征

在列车网络中，TRDP 的典型应用可以归纳为三类。第一类是周期性状态广播，例如牵引变流器每隔 20 ms 通过 PD 报文向网络发布当前电压、电流、温度等数据集，订阅方按 ComId 接收并刷新本地状态。第二类是命令与确认交互，例如车门控制单元收到开门指令后，通过 MD 报文返回执行结果，这类通信带有请求—应答语义，适合用 TCP 承载。第三类是诊断与事件上报，设备在故障发生时主动发送带时间戳的消息数据，供诊断系统记录与分析。

这些场景在抓包时呈现出不同的特征：PD 报文周期稳定、长度固定、源和目的端口往往成对出现；MD 报文则表现为请求与应答成对出现，且可能伴随 TCP 三次握手。掌握这些特征，才能在大量报文中快速定位目标通信。

Wireshark 安装与 TRDP 解析插件配置

Wireshark 是 TRDP 抓包分析的主力工具。安装时建议选择较新的稳定版本，并在安装过程中勾选 Npcap（Windows 平台）或确保 libpcap 可用（Linux 平台），这是捕获原始以太网帧的前提。安装完成后，先确认网卡列表能正常显示，再考虑 TRDP 解析。

Wireshark 原生并不一定内置 TRDP 解析器，具体取决于版本。若“协议”列表中找不到 TRDP，可通过两种方式补充：其一，使用官方或社区提供的 TRDP Lua 解析插件，将其放入 Wireshark 的个人插件目录（菜单“帮助 → 关于 Wireshark → 文件夹”可查看路径），重启后生效；其二，若已有编译好的 dissector 动态库，则放入相应插件目录。配置完成后，在过滤栏输入 trdp 应能看到报文被识别为 TRDP 协议，而不是停留在 UDP 数据阶段。

# Linux 下查看 Lua 插件目录示例
ls ~/.local/lib/wireshark/plugins/
# 将 trdp.lua 放入后重启 Wireshark
tshark -G protocols | grep -i trdp   # 确认协议已注册

需要提醒的是，TRDP 报文的端口并非固定唯一，实际项目中常使用 17224 等约定端口，也可能由项目配置决定。因此解析插件通常依据端口或报文头特征进行识别，配置时应结合项目实际参数核对，避免“抓到了却解析不出”的情况。

虚拟网卡与物理网卡抓包环境准备

抓包环境分为两类。物理网卡抓包最贴近真实：将分析电脑通过交换机镜像端口或 TAP 设备接入列车网络，确保能收到目标方向的流量。此时需注意网卡是否开启混杂模式、是否被操作系统防火墙干扰，以及抓包位置是否能看到完整的双向通信。

虚拟网卡抓包则适合实验室与教学环境。常见做法是用虚拟化软件创建多台虚拟机，分别模拟发布端与订阅端，通过虚拟交换机互联，再在虚拟网卡上抓包。这种方式便于构造可控的 PD/MD 流量，也便于反复复现异常场景。配置时要确认虚拟网卡的“混杂模式”和“允许所有”策略已开启，否则可能只看到本机相关流量。