DDS通信支持UDP与TCP-平芜编程栈

DDS消息中间件在通信时，既支持TCP也支持UDP，具体采用哪种传输协议取决于多种因素，包括应用场景、QoS（服务质量）配置以及底层DDS实现的具体设计。这两种协议各有其适用场景，DDS通过其灵活的架构和丰富的QoS策略来适配不同的需求。

1. DDS支持的传输协议

根据FastDDS等主流实现的特性，DDS的通道层支持多种传输协议。主要包含：

传输协议	描述	典型应用场景
UDP	无连接、尽力而为的传输协议，具有低延迟、低开销的特点。	对实时性要求高、允许少量数据丢失的场景，如传感器数据流、视频流。
TCP	面向连接、可靠的传输协议，保证数据顺序和可达性，但延迟和开销相对较高。	要求数据可靠、完整传输的场景，如关键控制指令、配置信息同步。
SHM (共享内存)	在同一台主机内的进程间进行通信，速度极快，零拷贝。	同一节点上不同进程或线程间的高性能数据交换。
TCPv4/TCPv6, UDPv4/UDPv6	分别对应IPv4和IPv6网络环境下的TCP和UDP协议。	跨网络通信，适应不同的网络基础设施。

DDS的设计允许在同一应用甚至同一数据流中，根据不同的数据主题（Topic）或服务质量要求，混合使用这些传输方式。

2. 协议选择的决定因素

选择UDP还是TCP，主要由以下几个核心因素决定：

2.1 QoS策略配置

QoS策略是DDS的核心，直接决定了通信的行为和底层传输协议的选择。

可靠性要求 (ReliabilityQosPolicy)

BEST_EFFORT_RELIABILITY_QOS(尽力而为): 此策略不保证数据一定送达，通常与UDP协议配对使用，以追求最低的延迟和最高的吞吐量。
RELIABLE_RELIABILITY_QOS(可靠传输): 此策略保证数据可靠、有序地送达订阅者。它通常基于TCP协议实现，因为TCP本身提供了重传、确认和排序机制。值得注意的是，一些DDS实现（如FastDDS）也能在UDP之上通过应用层协议（如RTPS）实现可靠传输，但这通常会增加复杂性和开销。

DataWriter和DataReader的QoS必须兼容才能建立连接，兼容性如下表所示：

DataWriter 可靠性策略	DataReader 可靠性策略	是否兼容
`BEST_EFFORT_RELIABILITY_QOS`	`BEST_EFFORT_RELIABILITY_QOS`	是
`BEST_EFFORT_RELIABILITY_QOS`	`RELIABLE_RELIABILITY_QOS`	否
`RELIABLE_RELIABILITY_QOS`	`BEST_EFFORT_RELIABILITY_QOS`	是
`RELIABLE_RELIABILITY_QOS`	`RELIABLE_RELIABILITY_QOS`	是

实时性要求
- 对于需要极低延迟的硬实时系统（如机器人关节控制、飞行器姿态调整），通常优先选择UDP，并配合BEST_EFFORT可靠性策略，避免TCP重传机制引入的不确定延迟。
- 对于软实时系统或对延迟有要求但更注重数据完整性的场景，可以使用基于TCP的可靠传输，并通过优化缓冲区、调整心跳间隔等QoS参数来平衡延迟和可靠性。

2.2 网络环境与通信范围

本地通信 (同一主机): 即使配置为使用TCP或UDP，数据包也会通过操作系统的回环接口（Loopback）进行传输，不经过物理网卡，速度非常快。此时，选择TCP或UDP的性能差异远小于网络传输。更优的选择是SHM（共享内存），它能完全绕过网络协议栈，实现最高效的进程间通信。
广域网/不稳定网络: 在丢包率高、延迟大的网络中，TCP的拥塞控制和重传机制可能导致性能急剧下降。此时，采用基于UDP的定制可靠传输协议（如DDS自身的RTPS over UDP），有时能通过更激进的策略获得更好的表现，但这需要仔细调优。

2.3 DDS实现与RTPS协议

DDS标准定义了应用层的API和语义，而实际的网络互通性由RTPS（Real-Time Publish-Subscribe）协议保障。RTPS是DDS的Wire Protocol，它可以在TCP或UDP上运行。

RTPS over UDP: 这是最常见的配置，尤其在对实时性要求高的领域（如ROS 2默认使用Fast DDS的UDP传输）。RTPS协议在UDP之上实现了发现、心跳、确认等机制，可以在需要时提供应用层的可靠性。
RTPS over TCP: 当需要穿越防火墙（TCP端口更易配置）或与仅支持TCP的遗留系统集成时，会使用此方式。它利用TCP的流特性，简化了RTPS的部分设计。

3. 配置示例与代码片段

以下是一个简化的FastDDS QoS配置示例，展示了如何为DataWriter设置传输协议和可靠性策略。

// 示例：创建一个使用UDP且为尽力而为可靠性的Publisher #include <fastdds/dds/domain/DomainParticipant.hpp> #include <fastdds/dds/publisher/Publisher.hpp> #include <fastdds/dds/publisher/DataWriter.hpp> #include <fastdds/dds/publisher/qos/DataWriterQos.hpp> #include <fastdds/rtps/transport/UDPv4TransportDescriptor.h> // 创建Participant和Publisher的代码省略... // 1. 创建DataWriter的QoS对象 eprosima::fastdds::dds::DataWriterQos writer_qos; // 2. 配置可靠性策略为“尽力而为”（通常隐式选择UDP） writer_qos.reliability().kind = eprosima::fastdds::dds::BEST_EFFORT_RELIABILITY_QOS; // 3. （可选）显式指定UDP传输并配置其参数 auto udp_transport = std::make_shared<eprosima::fastdds::rtps::UDPv4TransportDescriptor>(); udp_transport->sendBufferSize = 65536; // 设置发送缓冲区大小 udp_transport->receiveBufferSize = 65536; // 设置接收缓冲区大小 // 获取Participant的属性并添加自定义传输 eprosima::fastdds::dds::DomainParticipantQos participant_qos; // ... 初始化participant_qos ... participant_qos.transport().user_transports.push_back(udp_transport); // 4. 使用配置好的QoS创建DataWriter eprosima::fastdds::dds::DataWriter* writer = publisher->create_datawriter(topic, writer_qos);

注释：此代码片段展示了在FastDDS中配置QoS的基本方法。通过设置reliability().kind来选择可靠性策略，这间接影响了底层传输协议的选择。也可以显式创建并配置UDP传输描述符，以实现更精细的控制。

4. 总结与最佳实践建议

场景特征	推荐传输协议	关键QoS配置	理由
高频传感器数据（如激光雷达点云）	UDP	`BEST_EFFORT_RELIABILITY`, 调整`HistoryQosPolicy`的 depth	容忍偶发丢帧，追求最低延迟和最高吞吐量。
关键控制指令（如紧急停止命令）	TCP(或可靠的RTPS over UDP)	`RELIABLE_RELIABILITY`,`DEADLINE_QOS`	必须保证指令100%可靠送达，并可能要求定期心跳确认。
同一主机内进程通信	SHM (共享内存)	使用SHM传输描述符	零拷贝，性能远超基于套接字的TCP/UDP 。
跨复杂网络（如4G/5G车联网）	TCP或定制UDP	`LIVELINESS_QOS`(设置租约期限),`RESOURCE_LIMITS_QOS`	TCP更易穿透网络设备；若用UDP，需加强应用层心跳和重传逻辑以应对网络抖动。

核心结论：DDS消息中间件不强制使用单一的TCP或UDP。它是一个高度可配置的系统，允许开发者根据数据的重要性、实时性要求和网络条件，通过QoS策略为每个数据主题（Topic）选择最合适的传输方式。在实际工程中，通常会在同一个DDS域（Domain）内混合使用多种传输协议，以满足不同子系统或数据流的差异化需求。设计时应首先明确数据的可靠性和实时性等级，再据此选择对应的QoS策略，而底层传输协议（TCP/UDP）往往是该策略选择的自然结果。