企业官网建设流程全解析

搞过ROS 2、而且系统一复杂就开始排查通信问题的人，基本都会碰上一个需要把协议栈往下翻两层的时刻。明明每个节点都起来了，ros2 topic list却只显示一半；或者新节点启动半天，其他模块才慢吞吞发现它；再要么一抓包，UDP 7400端口上来来往往的组播流量非常热闹，却说不清谁在发、谁在收。ROS 2默认的中间件是Fast DDS，DDS/RTPS里的“分布式发现”机制决定了这一切。这篇文章就从Fast DDS的视角，把PDP、EDP这两个发现协议，以及它们背后真正的接收线程、事件线程讲清楚。适合两类人：一类是想把“对方怎么找到我”弄明白的ROS 2开发者，另一类是已经被发现故障折磨到想放弃、准备按图索骥排查的工程师。

1. 先弄清楚PDP和EDP在DDS里的位置

1.1 从一次完整的话题通信说起

在接触DDS之前，我们很容易被ROS 1时代养出来的惯性思维带偏：以为发布方和订阅方之间有一个“主节点”或者“名字服务”，话题关系是由调度中心撮合的。ROS 1确实有master节点，但ROS 2默认架构完全不同——它没有中心节点，底层走的是DDS，DDS的分布式发现是完全去中心化的。一个发布方和一个订阅方最终能对上话，靠的是RTPS协议栈里那套看不见的握手流程。

一套完整流程是这样。节点启动时，Fast DDS会创建一个RTPS Participant实例，这个实例携带一定数量的内置端点（builtin endpoints）。阶段一叫PDP，也就是Participant Discovery Protocol，参与者发现协议。它负责把“我这台机器上有一个参与者，我长这样”的信息广播出去，同时收集网络里其他参与者发来的同类信息。阶段二叫EDP，Endpoint Discovery Protocol，端点发现协议。它解决的是另一个问题：既然我已经知道对面有一个参与者了，那它内部有哪些Publisher、哪些Subscriber？它们分别挂在哪个话题下？QoS策略是什么？只有等EDP把这一层也交换完，实际数据才能在发布方和订阅方之间流动。

很多排查陷阱就藏在两阶段之间的衔接处。PDP做完了，只能说明“我看到你了”，并不代表话题能通。话题能不能通，取决于EDP阶段有没有匹配成功。我见过不少项目组在容器环境里排查数据不通，折腾半天发现是组播没开，PDP阶段就失败了，压根没轮到EDP说话。

1.2 PDP和EDP的分工差异

用生活化的例子帮记忆。PDP像电梯里的住户表：张三搬进来，在楼道里喊一声“我住301，叫张三，这是我的样子”，大家各自在脑子里记一笔；李四也一样。EDP像是加微信之后交换名片：你知道了对面住着一位叫张三的邻居，但还不知道张三平时干什么、能帮你什么忙，于是双方交换更细的信息：“我这边有一路摄像机图像话题”“我这边在订阅摄像机图像”。PDP管的是参与者级别的可见性，EDP管的是端点级别的匹配性。

这个分工直接决定了协议行为差异。PDP的流量是周期性的、尽力发送的，因为参与者在线状态需要持续维持，隔几秒就得重新宣告一次；EDP的流量是事件驱动的、可靠投递的，因为端点信息只会在节点启动、话题创建、QoS变化这些时刻主动产生。理解了这点，再看后面的线程模型会顺很多：前者天然需要周期事件线程兜底，后者则更依赖收包线程上的可靠回调。

2. PDP怎么发现“参与者”：SPDP组播宣告、租约与内置端点

2.1 默认实现SPDP，消息里到底装了什么

Fast DDS的PDP默认实现是SPDP，全称Simple Participant Discovery Protocol，简单参与者发现协议。它不是一个抽象理论，而是有明确定义报文格式和生产级实现的RTPS机制。在这个协议下，每个Participant内部固定维护一组用来交换PDP信息的内置端点，在DDS主题层面对应内建主题DCPSParticipant，在RTPS传输层则使用预先约定的组播地址和端口进行通告。

默认情况下，domain ID为0时，组播地址是239.255.0.1:7400。domain ID每增加1，端口号偏移250，所以domain 1对应端口7650，domain 2对应7900。这个设计保证了不同domain的网络流量天然隔离，避免两个团队在同一个局域网里跑各自的系统时相互干扰。实际抓包时，这个端口是最重要的过滤条件。

SPDP报文里携带的关键信息包括Participant的GUID（全局唯一标识，由GUID Prefix和Entity ID组成）、RTPS协议版本、所属domain ID、租约时长leaseDuration，以及一组单播/组播Locator地址。对端收到后会在本地维护一份ParticipantProxy记录，里面保存着这个“邻居”的网络可达地址和身份信息，之后EDP的所有通信就需要用到这些地址。

2.2 宣告周期与租约，两个容易被误调的参数

Fast DDS里两个最核心的PDP参数，默认值非常朴素：discoveryPeriod宣告周期默认1秒，leaseDuration租约默认3秒。也就是说，正常情况下每个Participant每秒钟会向组播地址广播一次自己的存在；对端如果连续3秒没有再收到某个Participant的SPDP，就会认为它离开了或网络断了，主动把本地对应的ParticipantProxy记录清理掉。

这两个参数之间的关系，是排查“节点明明活着但别人就是看不到它”这类问题的核心。很多优化心切的开发者会把宣告周期往小调，比如一百毫秒，以期加快发现速度。但若只调周期、不调租约，就会出现一个诡异现象：两个节点在同一网段里，进程都好好的，却偶尔互相“失明”。原因是网络稍有抖动，3秒内没收到组播，对端就把本地记录清了，于是触发一次重新发现。我的建议是，除非有明确需求，否则不要动默认值；如果确实要调，leaseDuration至少应该是discoveryPeriod的5倍以上，否则就是自己给自己挖坑。

配置项在Fast DDS的participant attributes里，通常通过XML profiles暴露。一个简化示意如下：

<participant> <rtps> <builtin> <discovery_config> <discoveryProtocol>SIMPLE</discoveryProtocol> <leaseDuration>PT3S</leaseDuration> <leaseAnnouncement> <period> <sec>1</sec> </period> </leaseAnnouncement> </discovery_config> </builtin> </rtps> </participant>

代码里也可以通过RTPSParticipantAttributes::builtin.discovery_config.discoveryPeriod和leaseDuration直接改。但注意，跨语言的客户端类型、ROS 2的QoS设置都可能覆盖或绕过部分XML配置，改了还得验证真的生效。

2.3 租约过期引发的“假离线”和“假在线”

租约机制本身是可靠的，但人类对它的理解经常出错。默认3秒租约的意思是，对端把你的ParticipantProxy保留3秒，这3秒内只要收到任何一包SPDP，就自动续约。所以一个稳定运行的节点，它的邻居侧记录几乎不会超时。反过来，如果一个节点异常退出，因为SPDP不再继续广播，其他节点最多3秒后就会把它从参与者的列表里清掉。

在ROS 2层面做一次直观验证：打开两个终端分别运行两个节点，然后直接关掉其中一个进程，另一个机器上执行ros2 node list，你会看到消失的滞后时间略小于租约时长。如果这个滞后时间过长，就得去复查是不是把leaseDuration调得太大了。另一个反面情况是，如果你把组播禁掉了，PDP宣告完全发不出去，则会出现“自己能看到自己，但永远看不到别人”的诡异状态，因为Fast DDS默认还保留了环回接口的发现能力。

3. PDP之后紧跟着EDP：端点信息如何从“谁能收发”变成匹配结果

3.1 SEDP的两个内置主题，绕不开的四类端点

当两个Participant通过PDP互相确认存在之后，EDP开始工作。Fast DDS的EDP默认实现是SEDP，Simple Endpoint Discovery Protocol，简单端点发现协议。与PDP的尽力而为不同，SEDP基于可靠通信，因为它承载的信息量大、错过一次就要重传，绝不可能靠“下次周期再广播”来兜底。

具体到实现上，每个Participant要维护两组内置主题：DCPSPublication和DCPSSubscription。每个主题各有一个Writer和一个Reader，所以一共是四个内置端点。发Publisher信息由Publication Writer完成，订阅方侧的Publication Reader接收；发Subscriber信息则由Subscription Writer完成，由发布方侧的Subscription Reader接收。看到这些名字不用害怕，它们本质就是一些经过特殊标记的RTPS端点，伪装成普通话题走同样的收包分发通道。

3.2 一个Publisher和Subscriber的完整“对上眼”过程

把完整流程放慢看。假设Participant A上创建了一个Subscriber，订阅话题/chatter；Participant B上创建了一个Publisher，发布话题/chatter。在PDP完成后，A和B已经知道彼此地址。接下来A的Subscription Writer会把一条描述Subscriber的SubscriptionData发给B；B的Publication Writer也会把一条描述Publisher的PublicationData发给A。两边各自在对方的Publication Reader和Subscription Reader上收到数据。

收到数据后，Fast DDS要做的是匹配检查。匹配条件比大多数人想象得严格：不只是话题名相同，type name也必须一致，QoS策略还要互相兼容。如果这三个条件都满足，双方就会在各自的端点上相互建立写作/阅读关联，于是数据通道正式打通。这个匹配过程对两端是对称的，某一边漏收了一条EDP消息，就会出现“我从A能看到B的话题，但B看不到A的”这种单向可见问题。

3.3 QoS不匹配是EDP层最常见的分手原因

EDP匹配失败时，表面症状和PDP失败完全不同。PDP失败时，ros2 node list里根本看不到对方节点；EDP失败时，节点列表正常，但话题列表要么缺失、要么有话题名但数据永远是空的。

我排查过一个很典型的场景：两台机器通过自研的可视化程序连接，程序里自定义了History和Reliability策略，订阅方用了Volatile的Durability，发布方却要求TransientLocal。两边的topic name完全一致，type也一致，但QoS就是不兼容。ROS 2控制台刷了一堆INCOMPATIBLE_QOS日志，话题出现却始终没有数据。这类问题不是网络问题，也不是线程问题，就是EDP层的QoS匹配规则卡住了。遇到这种症状，第一反应应该是列出两端的QoS对象，逐个字段比对，而不是去抓包看流量。

4. 谁在处理这些发现流量？接收线程和事件线程的真实分工

4.1 先破除一个误解：PDP和EDP没有专属常驻线程

很多刚接触Fast DDS源码的人容易默认“PDP一个线程，EDP一个线程，数据通信又一个线程”。真实实现不是这样。Fast DDS里，PDP和EDP的逻辑处理都寄生在几个通用机制上：收包IO线程、事件调度线程，以及内建端点上的回调。它们是协议，不是一堆独立调度的线程。理解这一点特别重要，因为它直接影响你看性能瓶颈的方向。

收包IO线程负责从UDP或TCP socket上读取到来的RTPS报文。默认配置下，一个Participant会按需创建若干个这类线程，数量和启用的传输通道有关，常见的单播、组播通道各自会有一个接收线程在跑。事件调度线程则是Fast DDS内部用于管理周期任务和超时任务的公共设施，SPDP的周期性公告、leaseDuration超时清理这类工作都由它驱动。换句话说，网络流量由IO线程吃进去，周期维护由事件线程负责，PDP和EDP的回调则分别挂在各自的Reader上，最终在IO线程的上下文里被调用。

4.2 一个UDP包从网卡到PDP/EDP回调的完整链路

这条链路值得展开讲。假设某个Participant收到一条SPDP消息，顺序是这样的。首先，UDP传输层接收线程阻塞在socket上，拿到一个数据报，交给MessageReceiver::processCDRMsg做RTPS子消息解析。接着，解析器根据子消息里的实体ID，找到对应Endpoint，也就是PDP Reader。然后调用该Reader的回调onNewCacheChangeAdded，在这个回调里完成GUID比对、ParticipantProxy创建或更新、租约续期等动作。如果这条消息触发了一个新Participant加入，回调还会在此基础上发起进一步的SEDP书籍交换，于是又有新的EDP消息进入发送队列。

这条链路的精髓在于，PDP和EDP的处理不是单独的线程在跑，而是实实在在发生在接收IO线程的调用栈里。用gdb或perf抓一个高负载进程的栈，排在前面的函数往往就是MessageReceiver::processCDRMsg和它下面挂着的Reader回调。这意味着一次发现包的解析时间如果过长，后到的其他RTPS包只能排队等着；反过来，如果发现包流量极大，最先被打爆的就是这几个接收线程。

4.3 周期宣告为什么必须由事件线程做

SPDP每隔一秒自动发送的动作，并不能靠接收线程“收到请求再回复”，因为组播环境下没有统一的请求源。它就是单纯按时间节拍往组播地址上喊话。Fast DDS把这些周期动作挂到Participant的事件调度器上，由事件线程按时间唤醒、执行发送动作。还有租约过期清理，本质上也依赖事件线程的定时检查。

这个分工带来的实际影响是：当你用top或perf观察发现某个进程CPU异常时，先分清CPU时间到底是花在接收线程的processCDRMsg上，还是花在事件调度上。前者说明流量压力大，比如节点多、发现风暴、或有人恶意组播；后者说明周期任务太频繁，往往和把discoveryPeriod调得过小有关。方向判断错了，后面所有调优都会白费。

5. 实际调试发现问题的三个层次，从抓包到线程视角

5.1 第一层：先抓包确认SPDP和EDP流量存在

排查发现故障，我习惯先不碰代码，先抓包。domain 0的默认场景下，一条tcpdump命令就能验证SPDP是否在发：

tcpdump -i eth0 udp port 7400 -nn

正常启动一个节点，你会看到源地址为组播地址或本机地址的周期UDP包。如果看不到任何SPDP包，问题大概率出在网络层，而不是Fast DDS配置。最常见的三个原因：组播被交换机或防火墙挡了；节点跑在容器里而容器网络没开启多播；两个节点不在同一VLAN。组播是一个很容易被忽略的先决条件，尤其在云主机和K8s环境里，默认是不支持组播的，SPDP首先就发不出去，后面一切免谈。

如果SPDP正常，但话题始终没数据，继续抓EDP流量就得靠优化过滤规则。EDP走的是可靠传输，端口通常落在单播端口范围，不像SPDP有固定的7400这么友好。一个更实用的验证办法是直接用ROS 2层的工具判断：ros2 node list能看到对方，说明PDP完成了；ros2 topic list有话题但ros2 topic echo没有数据，说明EDP匹配出了问题。

5.2 第二层：PDP“看见了”但EDP匹配不上的经典场景

假设你已经确认节点列表里能看到对方，话题列表却很安静，这时候的排查重点我前面已经提过：topic name、type name、QoS三者逐一核对。还有一种很容易被忽略的情况，就是参与者的domain ID不一致。如果两个节点分别跑在domain 0和domain 1，它们不会互相发现对方，但各自的node list里可能都看不到对方，这个问题会在PDP层先暴露出来，属于第一层就能查出。

EDP层最常见的坑反而是“话题出现为空”。比如两个节点都加载了同一个接口定义文件，但source code里的package版本不一致，生成的type identifier不完全一样，Fast DDS在type匹配时给出的结果可能是不匹配。从用户视角看，明明消息结构一模一样，为什么互相不认识？这就是因为RTPS层的type匹配非常严格。遇到这种情况，先让两端把topic type打印出来对比，别急着怀疑中间件。

5.3 第三层：线程视角下的发现风暴和CPU尖峰

到了最底层就是线程。多机多节点场景下，我见过很多“启动瞬间CPU飙满、几十秒后才回落”的报告，本质就是发现风暴。N个Participant在PDP阶段互相广播、在EDP阶段互相交换端点信息，整体通信量接近N平方量级。在一个有20个节点的系统里，一多半节点同时重启，瞬间EDP可靠消息挤满收包线程，CPU自然就上去了。

用perf top或者直接开一个gdb attach之后看线程栈，基本都能看到收包线程密集执行MessageReceiver::processCDRMsg。这种情况下，修改单个参数意义不大，真正的优化手段是下面要讲的Discovery Server模式，或者拆分domain、控制同一个domain下的Participant数量。从线程角度看，发现问题不是“某个线程坏了”，而是“所有发现处理都堆在那几个收包线程上”。所以调优的思路永远是减少流量、分散负载，而不是增加线程数。

6. 大系统下的发现优化：从周期参数到Discovery Server

6.1 discoveryPeriod和leaseDuration的取舍逻辑

这两个参数在小型实验里几乎感觉不到差别，但在大系统里它们决定了发现速度与网络压力的平衡。用一个简单关系来说明：discoveryPeriod越短，新节点加入后被其他人发现的时间就越短，但单位时间内的组播包数量也线性增长；leaseDuration越长，临时掉线节点在邻居列表里残留的时间就越长，容易出现“明明进程挂了，列表里还能看到它”的尴尬。

我个人的经验是，如果节点少于10个，默认参数就是最优解，不用动。如果节点多且启动频繁，可以把discoveryPeriod压到500ms左右，同时把leaseDuration设为2秒或3秒，保证租约仍然远大于周期。反过来，如果网络带宽紧张，把周期拉到2秒甚至3秒，leaseDuration至少要在5到6秒以上。调参数时不能只改一个，必须成对改，这个我在前面已经踩过坑。

6.2 组播不可用的环境：单播模式的价值与代价

Fast DDS允许把PDP调整为只使用单播，它不再依赖组播地址，而是通过已知的单播locator列表互相发现。这种方式在某些云网络里很实用，因为云厂商的VPC通常不转发组播。但代价是配置量变大，你必须把所有Participant的单播地址和端口都写清楚，而且每增加一个节点都要更新配置。除非环境强制要求，否则一般不建议自己写死单播列表，太脆弱。

相对更优雅的方案是后面这招：Discovery Server。它可以被理解成一个“会合点”，把发现流量从组播泛洪改成单播注册，特别适合跨网段、跨VLAN、或者组播已被禁用的容器环境。它改动的是PDP协议的模式，而不是把组播简单换成单播列表。

6.3 Discovery Server：把PDP从广播社交变成单播会合

Fast DDS的Discovery Server模式在ROS 2里通过环境变量或XML配置即可使用。每个Participant扮演两种角色：声明为CLIENT的节点不再发组播SPDP，而是定期向已知的SERVER地址注册并请求其他Client的信息；声明为SERVER的节点维护一个参与者目录，单独为每个Client转发目录变化。这样，本来要发到整个局域网的组播PDP流量，变成了每个Client和Server之间的一对一单播流量，发现收敛时间也不随节点数平方爆炸。

设置方式在ros 2中非常直观：

export ROS_DISCOVERY_SERVER="192.168.1.100:11811"

XML配置则是在participant的<discovery_config>里把discoveryProtocol改成CLIENT或SERVER，再填上discoveryServersList。需要特别提醒：Discovery Server运行后，Client之间虽然不需要组播也能互相发现，但EDP的端点信息交换仍然会发生在两端之间，所以网络层仍然要保证它们能单播互通。另外，SERVER是单点，生产环境最好再考虑备用SERVER的同步，否则SERVER挂掉，新的Client就进不了这个分布式系统。

6.4 优化之前先想清楚瓶颈在哪

优化工具永远只是工具，真正重要的还是定位瓶颈。如果问题出现在“新节点加入后别人发现它太慢”，优先调短discoveryPeriod；如果问题出现在“局域网的CPU尖峰和组播风暴”，优先上Discovery Server或拆domain；如果问题出现在“掉线节点残留在列表里太久”，优先调短leaseDuration。把故障现象和协议阶段对应上，就不会像无头苍蝇一样乱试参数。每改一次配置，都要重新验证PDP和EDP两个层次的表现，最简单的方法仍然是ros2 node list配合ros2 topic echo。

结尾

最后分享一个我自己的排查习惯。遇到任何“发现类”问题，我第一反应不是去改参数，而是先抓包，确认SPDP到底在不在发、EDP到底有没有交换，先判断是卡在PDP还是EDP这一层。绝大多数情况下，默认参数是够用的，真正害我的反而是一次手滑把discoveryPeriod调到了100毫秒，结果局域网里瞬间全是RTPS广播，所有节点的CPU都被顶了上去，节点之间反而因为发现风暴丢失了消息。那一次教训让我彻底明白，Fast DDS的发现机制本质上就是收包线程加事件线程的协同产物，调任何参数之前，想清楚它会让哪个线程多干活、会让哪段链路变快或变慢，比什么都重要。