UDP Transport

1.1 参与者发现流程（Discovery）#

Fast DDS 基于 RTPS 协议进行参与者发现，完全依赖 UDP 组播。流程如下：

关键要点：

为什么必须用 UDP？ 因为参与者发现需要”一对多”的组播能力——每个 Participant 需要被同一域内的所有其他 Participant 发现，而 TCP 是点对点协议，无法实现组播发现。

1.2 数据分发流程（Data Distribution）#

发现完成后，实际的数据传输走用户数据端口。一次完整的数据分发流程如下：

1.3 协议封装结构（Packet Encapsulation）#

理解一个 UDP 数据包从用户数据到物理网络的层层封装过程，有助于直观认识协议开销的来源：

以一个 100 字节用户数据 为例，各层开销如下：

关键洞察：即使对于 100 字节的小消息，协议头部开销也达到了 98 字节（约 33%）。消息越小，头部占比越高，带宽利用率越低。这也是为什么高频小消息场景下，适当合并消息（batching）可以有效提升吞吐量。

1.4 大数据分片流程（Fragmentation）#

当消息体积超过 UDP MTU（以太网通常 1500 字节，UDP 有效载荷约 1472 字节）时，RTPS 协议会在应用层进行分片，避免依赖 IP 层分片（IP 分片丢失会导致整个包丢失）：

注意：分片重组是 CPU 密集型操作。10KB 的消息需要拆成约 7 个分片，接收端需要维护重组缓冲区、检测完整性、处理乱序到达。消息越大，分片越多，CPU 开销越大。

1.5 可靠性机制（RELIABLE vs BEST_EFFORT）#

RTPS 协议在 UDP 之上提供两种可靠性 QoS：

RELIABLE 模式的代价：心跳（HEARTBEAT）和确认（ACKNACK）消息本身占用带宽和 CPU；发送端需要维护每个接收端的确认状态窗口；超时重传逻辑增加了延迟的不确定性。

2.1 内存拷贝——最核心的瓶颈#

一次完整的 UDP 数据传输，端到端涉及 4~6 次内存拷贝，这是 CPU 高占用的首要原因：

为什么拷贝这么耗 CPU？ 因为每次拷贝都需要 CPU 实际搬运数据。以 10MB 的点云为例，6 次拷贝意味着 CPU 实际搬运了 60MB 数据。频率越高、数据越大，CPU 越不堪重负。

2.2 CPU 高占用的完整归因#

一句话总结：CPU 高的根本原因是数据在多个层级之间反复拷贝，加上协议处理的计算开销。 数据量越大、频率越高，CPU 压力越大。

2.3 与 TCP / 共享内存的对比#

当传输大数据（点云、图像）且为本地进程间通信时，Shared Memory Transport 是解决 CPU 高问题的首选方案——它通过共享内存段传递 Buffer Descriptor，消除了内核态拷贝和系统调用，将拷贝次数从 46 次降低到 23 次。如需进一步降至 0 次拷贝，可结合 Data-sharing + loan API 实现 Zero-Copy。详见 Shared Memory Transport 和 Zero-Copy communication。

3.1 优点#

3.2 缺点#

3.3 适用场景#

4.1 Socket 缓冲区大小#

Socket 缓冲区是内核态为每个 UDP Socket 分配的收发缓冲区，直接影响吞吐量和抗丢包能力：

1
<!-- 示例：通过 XML 配置增大 Socket 缓冲区 -->
2
<transport_descriptor>
3
    <transport_id>my_udp_transport</transport_id>
4
    <type>UDPv4</type>
5
    <sendBufferSize>4194304</sendBufferSize>    <!-- 4 MB -->
6
    <receiveBufferSize>4194304</receiveBufferSize> <!-- 4 MB -->
7
</transport_descriptor>

1
// 示例：通过 C++ API 配置 UDP 传输
2
#include <fastdds/rtps/transport/UDPv4TransportDescriptor.h>
3
#include <fastdds/rtps/transport/shared_memory/SharedMemTransportDescriptor.h>
4

5
using namespace eprosima::fastdds::rtps;
6

7
// 1. 配置 UDP 传输
8
auto udp_transport = std::make_shared<UDPv4TransportDescriptor>();
9
udp_transport->sendBufferSize = 4 * 1024 * 1024;    // 4 MB
10
udp_transport->receiveBufferSize = 4 * 1024 * 1024;  // 4 MB
11
udp_transport->non_blocking_send = true;              // 非阻塞发送
12
udp_transport->TTL = 1;                               // 组播 TTL（1=同子网）
13

14
// 2. 注册传输（可同时注册 SHM 和 UDP）
15
DomainParticipantQos pqos;
16
pqos.transport().use_builtin_transports = false;      // 禁用默认传输
17

18
TransportDescriptorList transports;
19
transports.push_back(udp_transport);
20

21
// 如果需要本地高性能传输，同时注册 SHM
22
auto shm_transport = std::make_shared<SharedMemTransportDescriptor>();
23
transports.push_back(shm_transport);
24

25
pqos.transport().user_transports = transports;
26

27
// 3. 创建 Participant
28
DomainParticipant* participant =
29
    DomainParticipantFactory::get_instance()->create_participant(0, pqos);

注意：Linux 系统有全局上限 net.core.rmem_max / net.core.wmem_max，需要先通过 sysctl 调大，否则设置不生效。

4.2 分片大小（maxMessageSize）#

• 小消息高频场景：保持默认即可，无需调整
• 大数据场景：适当增大 maxMessageSize 可以减少分片数量，降低接收端重组开销；但要权衡 MTU 限制和网络丢包概率

4.3 非阻塞模式（non_blocking_send）#

• 开启后：发送操作变为非阻塞，消息可能被丢弃但不会阻塞应用线程，适合对延迟敏感但允许少量丢失的场景
• 关闭时：发送操作会阻塞直到数据写入内核缓冲区，保证不丢但可能影响应用实时性

4.4 组播 TTL（TTL）#

4.5 操作系统级内核参数调优#

除了 Fast DDS 自身的参数，操作系统层面的内核参数同样对 UDP 性能有显著影响：

1
# 临时生效（重启后失效）
2
sudo sysctl -w net.core.rmem_max=16777216
3
sudo sysctl -w net.core.wmem_max=16777216
4
sudo sysctl -w net.core.netdev_max_backlog=10000
5
sudo sysctl -w net.core.netdev_budget=600
6

7
# 永久生效（写入配置文件）
8
echo "net.core.rmem_max=16777216" >> /etc/sysctl.conf
9
echo "net.core.wmem_max=16777216" >> /etc/sysctl.conf
10
echo "net.core.netdev_max_backlog=10000" >> /etc/sysctl.conf
11
echo "net.core.netdev_budget=600" >> /etc/sysctl.conf
12
sudo sysctl -p

经验法则：先调操作系统参数，再调 Fast DDS 参数。如果 rmem_max 没有调大，即使在 Fast DDS 中配置了 receiveBufferSize=4MB，实际生效的仍然是系统默认值。

4.6 带宽估算公式速查#

在规划 UDP 传输参数前，先估算实际带宽需求：

1
单主题带宽 = 消息大小 × 频率 × (1 + 协议头部开销比)

速算示例：

经验法则：千兆以太网理论带宽 1000 Mbps，实际可用约 700~800 Mbps。当估算带宽超过物理链路的 70% 时，应考虑压缩数据、降低频率或升级网络。

4.7 调优速查表#

5.1 参与者发现失败#

现象：两个 Participant 运行在同一网络，但互相发现不了。

排查步骤：

5.2 高吞吐场景丢包#

现象：发送端正常发送，但接收端数据不完整，帧率低于预期。

5.3 CPU 占用过高#

现象：UDP 传输时 CPU 占用率持续偏高，影响系统其他任务。

5.4 性能监控与诊断命令速查#

快速诊断流程：先用 netstat -su 看有没有丢包 → 用 iperf3 -u 测实际带宽 → 用 tcpdump 抓包确认包率 → 用 sar 监控是否带宽饱和。

场景描述#

• 数据：128 线激光雷达点云，每帧约 2 MB
• 频率：10 Hz（每 100ms 一帧）
• 通信方式：两台工控机之间通过千兆以太网传输
• 初始问题：帧率只能达到 3~4 Hz，CPU 占用 60%+

第一步：定位瓶颈#

根据本文第 2 章的分析，2 MB 的消息通过 UDP 传输时：

1
2 MB 消息 → RTPS 分片 → 约 1430 个 UDP 包（每包 ~1400 字节）
2
每帧 1430 个包 × 10 Hz = 14300 包/秒

• 内存拷贝：6 次 × 2 MB = 12 MB/帧，10 Hz 时 CPU 搬运 120 MB/s
• 分片重组：每帧 1430 个分片，接收端重组开销巨大
• 系统调用：至少 14300 次 sendto() + 14300 次 recvfrom() = 28600 次/秒

第二步：逐步优化#

第三步：评估是否足够#

经过上述优化后，帧率提升到了 7~8 Hz，CPU 降到 35%。但仍然达不到 10 Hz 的目标。

根本原因：2 MB 的消息通过 UDP 传输，6 次内存拷贝是不可避免的，这是架构层面的限制。

第四步：架构级优化#

关键教训：UDP 传输大数据时，参数调优只能缓解症状，不能根治问题。当数据量超过一定阈值，必须从架构层面解决——要么改用共享内存，要么减小数据量。