面试的时候被问过："ROS2的topic底层是怎么传输的？"我说"用DDS"。面试官说："DDS具体怎么工作的？数据从发布到接收经过了哪些步骤？"
这个问题确实有深度。很多人用ROS2写了很多节点，发布订阅用得很溜，但底层到底发生了什么，完全不清楚。今天把DDS的通信原理掰开了讲，让你知道一条消息从发布到接收经历了什么。
发现过程：节点是怎么找到彼此的
当你启动一个ROS2节点，它做的第一件事不是通信，而是"广播"。
节点通过UDP组播（multicast）向网络发送一个SPDP（Simple Participant Discovery Protocol）包。这个包的内容包括：节点的名称、它所在的域（domain ID）、它支持哪些DDS版本、以及它发布的topic和订阅的topic列表。
网络中的其他节点收到这个SPDP包后，会回复自己的SPDP包。这样每个节点都知道了网络里有哪些参与者（participant）。
接下来是端点发现（Endpoint Discovery）。每个节点会进一步交换SEDP（Simple Endpoint Discovery Protocol）信息，详细说明自己发布的每个topic的数据类型、QoS配置等。当DDS发现一个发布者和一个订阅者的topic名称匹配、数据类型一致、QoS兼容时，就会在它们之间建立数据传输通道。
这个发现过程通常需要几秒钟。你启动一个ROS2系统后，不是立刻就能通信的，得等发现完成。在节点数量少的时候（十几个以内），发现很快。节点数量多了（上百个），发现时间会明显变长，因为每个节点都要和其他所有节点交换信息，通信量是O(n²)的。
数据传输：共享内存 vs 网络
发现完成之后，数据传输有两种路径。
如果发布者和订阅者在同一台机器上，DDS会优先使用共享内存（shared memory）。数据写到一块共享的内存区域，订阅者直接从这里读。不需要经过网络协议栈，速度非常快，延迟在微秒级别。
如果发布者和订阅者在不同机器上，数据就走网络。DDS默认用UDP传输，因为UDP比TCP快，而且DDS自己在上层实现了可靠性保证（如果你配置了RELIABLE QoS的话）。
你可以在同一台机器上验证这一点。启动一个发布者一个订阅者，用ros2 topic hz观察频率，再用netstat看网络连接。你会发现同机通信走的是共享内存，没有UDP数据包。
序列化：数据是怎么打包的
ROS2的消息在发送之前需要序列化——把内存中的数据结构转换成字节流。接收端再反序列化，把字节流还原成数据结构。
ROS2用的是CDR（Common Data Representation）序列化格式，这是DDS标准定义的。CDR是一种二进制格式，紧凑高效，但不可读。
序列化的开销有时候不能忽略。比如一个包含100万个点的点云消息，每次发布都要序列化一次。如果发布频率是10Hz，每秒就要序列化10次大数据。这个CPU开销可能比你实际的处理逻辑还大。
优化方法有几种。一是减少消息大小，比如点云先降采样再发布。二是用共享内存通信（同机情况下DDS自动使用）。三是用组件化编程（Component），把发布者和订阅者放在同一个进程里，直接传指针，完全跳过序列化。这个后面会专门讲。
QoS在底层是怎么工作的
QoS不是抽象概念，它在DDS底层有具体的实现机制。
RELIABLE模式。DDS在UDP之上实现了一套确认机制。发布者发出数据后，订阅者要回复一个ACK确认收到。如果发布者一段时间没收到ACK，就重传。这和TCP的可靠传输类似，但DDS的实现更灵活，可以针对每个topic单独配置。
BEST_EFFORT模式。发布者发了就完了，不管订阅者收没收到。没有ACK，没有重传。速度最快，但可能丢数据。适合传感器数据这种"丢了也无所谓"的场景。
TRANSIENT_LOCAL持久性。发布者会缓存最近的历史数据（历史深度可配置）。新加入的订阅者可以立刻收到最近几份数据，不用等到下一次发布。这在静态地图、传感器标定参数这种"新节点需要立刻知道当前值"的场景下很有用。
DEADLINE截止时间。发布者承诺在指定时间内至少发一次数据。如果超时没发，订阅者会收到一个deadline missed的通知。这可以用来检测传感器是否掉线。
调试DDS通信
DDS的通信是"黑盒"的，不像ROS1那样可以用rostopic echo直接看数据在流动。调试DDS通信需要一些专门的工具。
ros2 topic echo /topic_name。这个命令本质上创建了一个临时的订阅者，能看到数据内容。但如果你发现echo没有输出，不一定是发布者在发数据——可能是QoS不匹配导致连接没建立。
ros2 topic info /topic_name --verbose。可以看到这个topic的详细信息，包括发布者数量、订阅者数量、QoS配置。如果发布者数量是0但你知道明明启动了一个节点，说明发现过程出了问题。
ros2 doctor。这个命令会检查你的ROS2环境，包括DDS的发现是否正常、网络接口配置是否正确。如果节点互相发现不了，先跑一下这个命令看看问题在哪。
Domain ID的问题也值得注意。ROS2默认用domain ID 0。如果你在同一台机器上跑了两套ROS2系统（比如开发环境和测试环境），它们会互相干扰。用export ROS_DOMAIN_ID=1可以切换域，不同域的节点互相看不到。
如果你想看更底层的DDS信息，可以开启DDS的日志。以Fast DDS为例：
export FASTDDS_DEFAULT_PROFILES_FILE=/path/to/profile.xml # 在profile里配置日志级别Cyclone DDS也有类似的调试选项。设置CYCLONEDDS_URI环境变量可以传入配置，开启详细的通信日志。
面试中怎么聊
面试官问DDS通信原理，你可以说："ROS2的节点通过UDP组播自动发现彼此，发现完成后建立数据传输通道。同机通信优先用共享内存，跨机器走UDP。数据在发送前用CDR格式序列化。QoS策略在底层通过ACK确认、历史缓存、超时检测等机制实现。我遇到过节点互相发现不了的问题，通常是防火墙拦截了UDP组播包，或者多网卡环境下组播走了错误的网络接口。"
这种回答好在：有底层原理、有实际经验、有排查思路。
DDS的安全机制
ROS2基于DDS还获得了一个重要能力：通信安全。DDS-Security规范定义了认证、加密和访问控制三大安全机制。在多机器人系统中，如果你不希望未授权的节点加入通信网络，可以配置DDS的认证插件。节点启动时必须通过身份验证才能参与通信，否则会被其他节点拒绝。
# 配置DDS安全（在ROS2中通过SROS2实现） export ROS_SECURITY_STRATEGY=Enforce export ROS_SECURITY_ROOT_DIRECTORY=/path/to/keystoreSROS2是ROS2对DDS-Security的封装，提供了密钥管理、权限配置等工具。在工业部署和商用机器人中，通信安全是必须考虑的因素。面试的时候如果能提到SROS2，说明你对ROS2的理解已经超出了基础使用层面。
DDS调优的实战经验
实际项目中DDS的参数调优对系统性能影响很大。默认的DDS配置适合大多数场景，但在高频率大数据量的情况下可能需要调整。比如增大缓冲区大小避免数据丢失，调整发现协议的超时时间加快启动速度，或者配置共享内存传输减少网络开销。ROS2提供了通过XML配置文件自定义DDS参数的机制，面试时能提到这个细节会加分。
给你的建议
不需要把DDS的协议规范背下来。但理解发现过程、序列化开销、QoS的底层实现，对你调试和优化ROS2系统很有帮助。
遇到通信问题的时候，先用ros2 topic info --verbose检查QoS是否匹配。发布者和订阅者的QoS如果不兼容（比如一个RELIABLE一个BEST_EFFORT），DDS会静默地不建立连接，不会报错。这是新手最常踩的坑，也是面试中经常被问到的问题。记住：QoS兼容性检查是ROS2调试的第一步，也是最容易被忽略的一步。
上一篇：第109篇 ROS2架构设计哲学——DDS与去中心化
下一篇预告：第111篇 ROS2工作空间与colcon编译——开发流程的第一步
