Fast DDS实战用Wireshark抓包拆解HelloWorld示例的完整通信流程附pcap文件当你第一次运行Fast DDS的HelloWorld示例时看到终端输出Publisher matched with Subscriber的提示是否好奇这两个进程究竟在背后交换了哪些信息本文将带你像网络侦探一样用Wireshark揭开DDS通信的神秘面纱。1. 实验环境搭建与准备工作在开始抓包前我们需要一个干净的实验环境。建议使用两台物理机或虚拟机IP分别为192.168.1.10和192.168.1.20避免本地回环接口抓包的复杂性。安装以下组件Fast DDS v2.10.0当前最新稳定版Wireshark 4.2.0需安装RTPS协议解析插件DDSHelloWorld示例程序Fast DDS自带配置关键点# 在Publisher端执行 DDSHelloWorldExample publisher -s 100 -i 1000 # 在Subscriber端执行 DDSHelloWorldExample subscriber -s 100 -i 1000参数说明-s 100发送100条消息-i 1000每条消息间隔1000毫秒提示建议关闭防火墙和SELinux避免干扰网络抓包。同时确保两台机器时钟同步NTP服务这对分析时间戳字段至关重要。2. 抓包策略与RTPS协议基础在Subscriber端启动Wireshark选择正确的网卡后应用以下过滤规则rtps !rtps.participant_guid.prefix 00:00:00:00:00:00:00:00:00:00:00:00RTPS报文结构速览字段类型长度(bytes)说明示例值Protocol ID4固定为RTPS0x52545053Protocol Major1主版本号通常为20x02Protocol Minor1次版本号通常为30x03Vendor ID2厂商标识Fast DDS为0x010f0x010f关键子消息类型及其作用INFO_DST标识目标参与者类似IP包头中的目标地址INFO_TS携带时间戳信息纳秒精度DATA实际传输的用户数据HEARTBEATWriter的状态通告ACKNACKReader的确认反馈3. 发现阶段报文深度解析启动程序后首先观察到的是发现阶段的报文交换。这个阶段分为两个子阶段3.1 参与者发现PDP典型抓包序列组播SPDP消息目的地址239.255.0.1单播SPDP响应重复步骤1-2保活机制关键字段示例SPDPdiscoveredParticipantData: participantGuid.prefix 0x000000000000000000000001 participantGuid.entityId 0x0000c1 leaseDuration.seconds 100 userData.value FastDDSv2.103.2 端点发现SEDP这个阶段交换Writer和Reader的QoS信息。以Writer发现为例Publisher发送DiscoveredWriterDatawriterProxy.remoteWriterGuid 0x000000000000000000000001|0x000002c2 topicName HelloWorldTopic typeName HelloWorld reliability.kind RELIABLESubscriber回复ACKNACKbitmapBase 1 numBits 0 finalFlag true注意发现阶段通常持续3-5秒期间可能看到重复的HEARTBEAT和ACKNACK交换这是正常的心跳机制。4. 数据传输阶段实战分析当终端显示Publisher matched后真正的用户数据传输开始。我们以一条完整的HelloWorld消息为例发送序列Publisher发送DATA报文RTPS DATA submessage: writerId 0x000002c2 sequenceNumber 1 serializedPayload Hello World! (1)Subscriber回复ACKNACKRTPS ACKNACK submessage: readerId 0x000003c2 writerId 0x000002c2 bitmapBase 1 numBits 0 (表示成功接收)关键时序分析时间戳(ms)事件类型方向关键参数0DATAPub → Subseq1, payload(1)0.8ACKNACKSub → Puback seq11000HEARTBEATPub → Subfirst1, last11000.5ACKNACKSub → Pubexpect seq25. 高级场景与异常分析5.1 大消息分片处理当消息超过MTU时Fast DDS会进行分片传输。在Wireshark中可以看到原始DATA报文被标记为DATA_FRAG分片信息字段fragmentStartingNum 1 fragmentsInSubmessage 3 fragmentSize 14005.2 丢包重传场景人为制造网络丢包如用tc命令后观察到的恢复流程Publisher发送HEARTBEAT(lastSeq5)Subscriber发现缺失seq3回复ACKNACK: bitmapBase 3 numBits 1 bitmap 0x1 (二进制01表示缺失)Publisher重传DATA(seq3)5.3 QoS策略对通信的影响对比不同QoS设置下的报文差异QoS类型典型报文特征适用场景BEST_EFFORT无ACKNACKHEARTBEAT间隔长低延迟允许丢包RELIABLE密集的ACKNACKHEARTBEAT间隔短数据完整性要求高TRANSIENT发现阶段携带持久化数据晚加入的订阅者6. 实战技巧与性能优化经过上百次抓包测试总结出这些实用经验过滤技巧rtps rtps.payload contains Hello // 只显示含Hello的消息 rtps.flags.final 1 // 关键控制报文性能瓶颈识别ACKNACK延迟50ms → 检查网络延迟HEARTBEAT间隔异常 → 检查QoS配置DATA分片过多 → 考虑调整消息大小Wireshark插件配置 在Preferences → Protocols → RTPS中启用Deserialize user data设置Default encoding为CDR_LE附本文分析的完整pcap文件已上传至示例仓库包含以下场景正常通信流程高延迟网络模拟大消息分片传输可靠性模式下的丢包恢复