企业官网建设流程全解析

1. Fast DDS 到底怎么用？先搞清它不是“另一个ROS2通信层”

Fast DDS 是 eProsima 开发的开源实现，严格遵循 OMG（对象管理组织）发布的 DDS（Data Distribution Service）标准。很多人第一次接触它，是通过 ROS2——因为 ROS2 默认底层通信中间件就是 Fast DDS。但这里必须划重点：Fast DDS 本身是一个独立、完整、可脱离 ROS2 单独部署的实时发布-订阅中间件。它不依赖 ROS2，也不等同于 ROS2 的“网络模块”。把它当成“ROS2 的网卡驱动”是常见误解；更准确地说，它是 ROS2 可插拔的“通信引擎之一”，就像汽车可以换装不同品牌的发动机。

标题里问“到底怎么用”，核心痛点其实很现实：刚跑通一个 HelloWorld 示例，一加 QoS 策略就收不到数据；开了两个节点，互相“看不见”，日志里反复刷discovery failed；想传个 10MB 的图像结构体，吞吐直接掉到 2fps，CPU 却只占 15%……这些不是配置写错了，而是对 Fast DDS 的三大支柱——发现（Discovery）、传输（Transport）与服务质量（QoS）——缺乏系统性理解，导致参数之间相互打架。

比如，“电脑打开了网络发现，为什么别的用户看不着”这个热词，表面是 Windows 网络设置问题，但内核逻辑和 Fast DDS 的发现机制高度同源：都是靠周期性广播/组播“我是谁、我在哪、我能提供什么服务”来建立连接。只不过 Windows 用的是 SSDP 或 NetBIOS，而 Fast DDS 用的是 RTPS（Real-Time Publish-Subscribe）协议定义的 Participant Discovery 和 Endpoint Discovery。你配错一个builtin发现模式，或者防火墙拦了 7400 端口，效果就是“节点在线，但彼此失联”，和“局域网可见性异常”本质一致。

再比如“TLS 是安全传输层协议，用于在两个通信应用程序之间提供保密性和数据完整性”，这句描述放在 HTTPS 场景完全正确，但套到 Fast DDS 上就容易踩坑。Fast DDS 支持 TLS，但它不是简单地给 TCP 连接套一层壳；它要求证书链、密钥格式、验证策略、甚至证书有效期都必须严格匹配 RTPS 的安全模型（DDS Security spec）。我曾见过团队把 Nginx 的 PEM 证书直接丢进 Fast DDS 配置，结果握手失败，日志只报security validation failed，查了三天才发现是证书缺少 Subject Alternative Name（SAN）字段——这种细节，官方文档不会手把手教，但实操中天天遇到。

所以这篇文章不讲“如何安装 Fast DDS”，也不堆砌 API 列表。我要带你像调试一台精密仪器一样，一层层拧开它的外壳：从最底层的网络包怎么发、被谁收到（传输），到节点怎么“认出彼此”（发现），再到当带宽不足、延迟敏感、数据关键时，你该动哪个旋钮、调哪组参数（QoS）。所有内容基于 v2.14.x（当前 LTS 版本）实测，配置项全部附带真实场景下的取值依据，不是“建议设为 true”，而是“为什么此处必须设为 false”。

2. 发现机制：不是“自动连上”，而是“按规则找到对方”

2.1 发现的本质：三类消息 + 两种模式

Fast DDS 的发现过程，本质是三个角色（Participant、Publisher、Subscriber）之间交换四类 RTPS 消息：HEARTBEAT,ACKNACK,DATA,GAP。但真正决定“能不能看见对方”的，是前两类控制消息：Participant Discovery（参与者发现）和Endpoint Discovery（端点发现）。前者解决“你是谁”，后者解决“你能发什么、收什么”。

发现不是魔法，它严格依赖两种模式的组合：

• Simple Discovery（默认）：轻量级，适用于单播或小规模组播网络。它把 Participant 和 Endpoint 信息打包进一个DATA消息，通过预设的“初始 Peer List”（Initial Peers List）发送。这个列表就像通讯录，你得手动告诉本节点“隔壁那台机器 IP 是 192.168.1.102，端口是 7400”，它才会主动去“敲门”。

• Static Discovery（静态发现）：零广播、零组播，完全靠配置文件驱动。所有 Participant 和 Endpoint 的元数据（GUID、类型名、QoS 策略哈希值）都写死在 XML 文件里。启动时，每个节点加载自己的 XML，然后按文件里写的地址和 GUID，直接向目标节点发起单播连接。适合高安全、强管控环境，比如军工嵌入式设备，禁止任何动态广播行为。

提示：很多初学者以为“开了发现就自动互联”，结果在 Docker 容器或 Kubernetes Pod 里死活连不上。根本原因是 Simple Discovery 默认用组播（239.255.0.1:7400），而容器网络通常禁用组播。此时必须显式配置 Initial Peers List，把其他节点的 IP:Port 写进去，强制走单播。

2.2 关键配置项详解：从builtin到initialPeersList

发现行为由DomainParticipantQos中的builtin子模块控制。核心参数如下：

举个真实案例：某 AGV 调度系统有 5 台工控机，每台运行一个 Fast DDS Participant。网络是千兆交换机直连，无 VLAN。最初用默认组播，测试时一切正常；上线后某天突然 2 台机器失联。抓包发现交换机某端口因流量突增触发了 IGMP Snooping 限速，组播包被丢弃。解决方案不是换协议，而是将initial_peers_list显式设为所有 5 台机器的 IP:7400，强制走单播。这样既绕过组播依赖，又保持了 Simple Discovery 的灵活性。

注意：initial_peers_list中的地址，必须是目标节点实际监听的地址。Fast DDS 默认监听0.0.0.0（所有接口），但如果你在TransportDescriptor里绑定了特定网卡（如enp0s31f6），那么initial_peers_list就必须填该网卡的 IP，而不是127.0.0.1或localhost。我踩过的坑：在双网卡笔记本上开发，initial_peers_list写127.0.0.1，结果另一台机器连过来，数据全发到回环口，本地收不到。

2.3 发现失败排查：三步定位法

当ros2 node list看不到节点，或自定义程序wait_for_subscriptions()卡住，按此顺序排查：

1. 确认网络连通性：

   # 检查目标节点 7400 端口是否开放（注意：Fast DDS 默认用 UDP） nc -zuv 192.168.1.102 7400 # 或更直接：用 tcpdump 抓 RTPS 包 sudo tcpdump -i any -n port 7400

   如果nc不通，说明防火墙或网络策略拦截；如果tcpdump完全没包，说明本节点根本没发发现请求——检查initial_peers_list是否为空或格式错误。

2. 检查 Participant GUID 是否冲突：
   Fast DDS 要求每个 Participant 有唯一 GUID。若多个进程用相同 XML 配置启动（尤其在 Docker 中未指定domain_id），GUID 可能重复，导致发现消息被静默丢弃。验证方法：启动时加-v参数，看日志中GUIDPREFIX是否各不相同。

3. 验证 Topic 名称与类型是否严格一致：
   Publisher和Subscriber的 Topic 名称（如/sensor/camera）、数据类型（如sensor_msgs::msg::Image_）必须字节级完全相同。ROS2 中常因.idl文件生成路径不同、CMakeLists.txt 中rosidl_generate_interfaces()调用顺序差异，导致同一类型在不同节点编译出不同哈希值。此时发现成功（Participant 可见），但 Endpoint 发现失败，日志会显示Type not matched。解决方案：统一使用rosidl_typesupport_introspection_cpp，并在 CMake 中强制指定类型支持包。

3. 传输层：UDP 是默认，但不是唯一，更不是最优

3.1 传输的本质：不只是“发包”，而是“选路+保活+适配”

Fast DDS 的传输层（Transport Layer）负责把序列化后的数据，从发送方内存，可靠/不可靠地送达接收方内存。它不关心数据是什么（那是序列化层的事），只关心“怎么送、送几次、超时多久、走哪条路”。默认使用UDPv4TransportDescriptor，但这只是起点。真正的传输能力，取决于你如何组合以下三类传输描述符：

• 基础传输（Base Transport）：UDPv4,UDPv6,TCPv4,TCPv6,SHM（Shared Memory，本机进程间最快）。
• 安全传输（Secure Transport）：TLS（基于 OpenSSL）、DTLS（UDP 上的 TLS）。
• 自定义传输（Custom Transport）：通过继承TransportInterface实现私有协议，如对接 CAN FD、TSN（时间敏感网络）。

很多人以为“UDP 快所以选 UDP”，这是片面的。UDP 确实无连接、低开销，但它的“快”是有前提的：网络质量好、丢包率 < 0.1%、单跳延迟 < 1ms。一旦跨交换机、经无线 AP、或在车载 ECU 的 CAN 网关后，UDP 丢包率可能飙升至 5%，此时重传机制缺失，数据就真丢了。而 TCP 虽有连接建立、拥塞控制开销，但在高丢包环境下，其 ARQ（自动重传请求）机制反而保障了最终送达。

3.2 UDP 传输深度调优：从sendBufferSize到maxMessageSize

UDP 传输看似简单，但几个关键参数直接影响吞吐与稳定性：

• sendBufferSize/receiveBufferSize：操作系统 socket 缓冲区大小（单位：字节）。默认 64KB，但千兆网卡满速传输时，建议设为2 * 1024 * 1024（2MB）。原因：Linux 内核中，UDP 缓冲区过小会导致send()系统调用阻塞，即使应用层认为“发出去了”，实际数据卡在内核队列。实测：某雷达点云流（单帧 8MB），sendBufferSize=64KB时吞吐仅 120MB/s；设为 2MB 后，稳定达 940MB/s（接近千兆线速）。

• maxMessageSize：单个 RTPS 消息最大尺寸（单位：字节）。默认 65500，但受 MTU（Maximum Transmission Unit）限制。以太网标准 MTU 是 1500 字节，减去 IP 头（20B）和 UDP 头（8B），实际有效载荷约 1472B。Fast DDS 为避免分片，会将大消息拆成多个 Fragment。maxMessageSize设得太小（如 1000），会导致一个 1MB 图像被切成 1000+ 个 Fragment，每个 Fragment 都要带 RTPS Header（至少 24B），头部开销暴涨 2.4%。我们推荐设为65000（接近理论最大值），并确保网络路径支持 Jumbo Frame（MTU=9000）。

• ttl（Time-To-Live）：IP 包生存时间。默认 1，即只允许在同一子网内传输。若需跨路由器（如办公网到产线网），必须设为>1（如 64）。但注意：ttl=64并不意味能跨 64 跳，而是每经过一个路由器，值减 1，为 0 时丢包。生产环境建议设为32，平衡可达性与安全性。

<!-- 示例：高性能 UDP 传输配置 --> <transport_descriptors> <transport_descriptor> <transport_id>udp_high_perf</transport_id> <type>UDPv4</type> <send_socket_buffer_size>2097152</send_socket_buffer_size> <receive_socket_buffer_size>2097152</receive_socket_buffer_size> <max_message_size>65000</max_message_size> <ttl>32</ttl> </transport_descriptor> </transport_descriptors>

3.3 TCP 与 SHM：何时该放弃 UDP？

• TCP 适用场景：

  • 跨广域网（WAN）通信，如总部与工厂远程监控；
  • 对可靠性要求极高，且能接受 50~200ms 级延迟，如 PLC 控制指令下发；
  • 网络存在 NAT 或防火墙，UDP 端口难穿透（TCP 可走 443 端口伪装 HTTPS）。
    配置要点：关闭 Nagle 算法（nagle_disabled=true），避免小包合并引入延迟；增大keep_alive_interval（如 30s），防止空闲连接被中间设备断开。

• SHM（共享内存）适用场景：

  • 同一物理机上的多进程通信，如 ROS2 中rviz2与robot_state_publisher；
  • 对延迟极度敏感（< 10μs），如实时运动控制闭环。
    配置要点：shared_mem_transport必须在DomainParticipantQos中显式启用；segment_size（共享内存段大小）建议设为100 * 1024 * 1024（100MB），避免频繁重分配。

实操心得：某客户做无人机集群仿真，100 个 UAV 节点全跑在同一台服务器。最初用 UDP，CPU 占用 85%，延迟抖动大。切换为 SHM 后，CPU 降至 22%，平均延迟从 180μs 降到 3.2μs。关键不是“换协议”，而是识别出通信发生在同一物理内存空间，SHM 是唯一合理选择。盲目追求“通用性”而不用 SHM，是性能浪费。

4. QoS 配置：不是调参，而是为数据“买保险”

4.1 QoS 的本质：一份数据传输的“服务契约”

QoS（Quality of Service）不是性能开关，而是 Publisher 和 Subscriber 之间协商的一份“服务契约”。它定义了：数据是否必须送达（Reliability）、能容忍多长延迟（Deadline）、是否允许旧数据覆盖新数据（Liveliness）、以及当网络拥塞时，谁的数据该被丢弃（Destination Order）。所有 QoS 策略必须成对配置：Publisher 设RELIABLE，Subscriber 也必须设RELIABLE，否则发现阶段就会拒绝匹配。

Fast DDS 定义了 23 种 QoS 策略，但日常开发中，90% 的问题集中在以下 5 种：

4.2 Reliability 与 History 的黄金组合：解决“为什么收不到最新数据”

这是最高频问题：“我发了 100 条，Subscriber 只收到第 1 条和第 100 条”。根源在于Reliability和History的错配。

• Reliability=RELIABLE+History=KEEP_LAST, depth=1：Publisher 会确保每条消息送达，但只保留最新 1 条。若 Subscriber 启动晚了，它只能收到最后那条，前面 99 条永远丢失。这是“保送达，不保历史”。

• Reliability=RELIABLE+History=KEEP_LAST, depth=100：Publisher 缓存最近 100 条，Subscriber 启动后，会收到这 100 条（按序）。这是“保送达 + 保近期历史”。

• Reliability=BEST_EFFORT+History=KEEP_LAST, depth=100：Publisher 不保证送达，但缓存 100 条。Subscriber 可能收到乱序、重复、缺失的数据。这是“尽力而为 + 有缓冲”。

实操技巧：某激光 SLAM 系统，/scanTopic 频率 10Hz。我们配置Reliability=RELIABLE+History=KEEP_LAST, depth=5。理由：SLAM 算法只需最近 500ms 的扫描数据（5 条），depth=5刚好覆盖，内存占用可控；RELIABLE保证关键帧不丢，避免建图断裂。若设depth=100，内存多占 20MB，毫无必要。

4.3 Deadline 与 Liveliness：让系统“自我诊断”

Deadline和Liveliness是系统健康度的“心跳监测器”。

• Deadline：Publisher 承诺“每 X 时间发一次数据”。Subscriber 监测到连续 N 次未收到，触发回调。这不是延迟报警，而是数据流中断预警。例如，IMU 驱动应每 1ms 发一次，设period=2ms，若 2ms 内没收到，说明驱动卡死或硬件故障。

• Liveliness：Publisher 承诺“我活着，且能发数据”。它会周期性发HEARTBEAT。Subscriber 监测到lease_duration（租约时长）内无心跳，触发on_liveliness_changed。这比Deadline更底层，检测的是 Publisher 进程是否崩溃。

配置示例：

// Publisher QoS publisher_qos.endpoint().history_kind = eprosima::fastdds::dds::KEEP_LAST_HISTORY_QOS; publisher_qos.endpoint().history_depth = 10; publisher_qos.endpoint().reliability().kind = eprosima::fastdds::dds::RELIABLE_RELIABILITY_QOS; publisher_qos.endpoint().deadline().period = eprosima::fastrtps::Duration_t(0, 2000000); // 2ms publisher_qos.endpoint().liveliness().kind = eprosima::fastdds::dds::AUTOMATIC_LIVELINESS_QOS; publisher_qos.endpoint().liveliness().lease_duration = eprosima::fastrtps::Duration_t(1, 0); // 1s

注意：Deadline.period和Liveliness.lease_duration的单位是秒.纳秒（Duration_t(sec, nanosec)）。0, 2000000表示 2ms，不是0.002。写错单位是新手最常犯的错误，导致 deadline 永远不触发。

5. 实战配置全流程：从零开始搭建一个可靠图像传输系统

5.1 需求分析：明确“可靠”的定义

假设我们要构建一个工业相机图像采集系统：

• 相机：GigE Vision，输出1920x1080@30fps的RGB8图像；
• 传输：千兆以太网，单跳交换机，无无线段；
• 可靠性要求：允许单帧丢失，但不允许花屏、撕裂；延迟 ≤ 100ms；CPU 占用 < 40%；
• 部署：一台工控机（Camera Node）采集，一台服务器（Viewer Node）显示与存储。

这意味着：

• Reliability选BEST_EFFORT（视频流天然容错）；
• History选KEEP_LAST, depth=3（缓存 3 帧，防短暂抖动）；
• Transport必须用UDPv4，且sendBufferSize调大；
• Deadline设为33ms（30fps 周期），超时即告警；
• ResourceLimits必须限制，防内存爆炸。

5.2 XML 配置文件编写：可复用的模板

创建image_transport_profile.xml：

<?xml version="1.0" encoding="UTF-8"?> <profiles xmlns="http://www.eprosima.com/XMLSchemas/fastRTPSProfile"> <transport_descriptors> <transport_descriptor> <transport_id>udp_image</transport_id> <type>UDPv4</type> <send_socket_buffer_size>4194304</send_socket_buffer_size> <!-- 4MB --> <receive_socket_buffer_size>4194304</receive_socket_buffer_size> <max_message_size>65000</max_message_size> <ttl>1</ttl> </transport_descriptor> </transport_descriptors> <participant profile_name="image_participant" is_default_profile="true"> <rtps> <name>ImageTransportParticipant</name> <builtin> <discovery_config> <use_SIMPLE_EndpointDiscoveryProtocol>true</use_SIMPLE_EndpointDiscoveryProtocol> <m_simpleEDP> <use_PublicationReaderANDSubscriptionWriter>true</use_PublicationReaderANDSubscriptionWriter> </m_simpleEDP> <initialPeersList> <locator> <udpv4> <address>192.168.1.101</address> <!-- Viewer IP --> <port>7400</port> </udpv4> </locator> <locator> <udpv4> <address>192.168.1.102</address> <!-- Camera IP --> <port>7400</port> </udpv4> </locator> </initialPeersList> </discovery_config> </builtin> <userTransports> <transport_id>udp_image</transport_id> </userTransports> <useBuiltinTransports>false</useBuiltinTransports> </rtps> </participant> <publisher profile_name="image_publisher"> <qos> <endpoint> <history_kind>KEEP_LAST_HISTORY_QOS</history_kind> <history_depth>3</history_depth> <reliability_kind>BEST_EFFORT_RELIABILITY_QOS</reliability_kind> <resource_limits> <max_samples>1000</max_samples> <max_instances>1</max_instances> <max_samples_per_instance>1000</max_samples_per_instance> </resource_limits> <deadline> <period> <sec>0</sec> <nanosec>33000000</nanosec> <!-- 33ms --> </period> </deadline> </endpoint> </qos> </publisher> <subscriber profile_name="image_subscriber"> <qos> <endpoint> <history_kind>KEEP_LAST_HISTORY_QOS</history_kind> <history_depth>3</history_depth> <reliability_kind>BEST_EFFORT_RELIABILITY_QOS</reliability_kind> <resource_limits> <max_samples>1000</max_samples> <max_instances>1</max_instances> <max_samples_per_instance>1000</max_samples_per_instance> </resource_limits> <deadline> <period> <sec>0</sec> <nanosec>33000000</nanosec> </period> </deadline> </endpoint> </qos> </subscriber> </profiles>

5.3 C++ 代码集成：加载配置并创建实体

#include <fastdds/dds/domain/DomainParticipantFactory.hpp> #include <fastdds/dds/publisher/Publisher.hpp> #include <fastdds/dds/subscriber/Subscriber.hpp> #include <fastdds/dds/domain/DomainParticipant.hpp> #include <fastdds/dds/publisher/DataWriter.hpp> #include <fastdds/dds/subscriber/DataReader.hpp> #include <fastdds/dds/topic/Topic.hpp> #include <fastdds/dds/topic/TypeSupport.hpp> #include <fastdds/rtps/attributes/PropertyPolicy.h> #include <fastdds/dds/log/Log.hpp> // 假设已定义 ImageTypeSupport（IDL 生成） using namespace eprosima::fastdds::dds; int main(int argc, char** argv) { // 1. 禁用默认日志，避免干扰 eprosima::fastdds::dds::Log::SetVerbosity(eprosima::fastdds::dds::Log::Warning); // 2. 创建 DomainParticipant，加载 XML 配置 DomainParticipantQos pqos; DomainParticipantFactory::get_instance()->load_profiles(); DomainParticipantFactory::get_instance()->get_default_participant_qos(pqos); // 加载名为 "image_participant" 的 profile DomainParticipantFactory::get_instance()->get_participant_qos_from_profile( "image_participant", pqos); DomainParticipant* participant = DomainParticipantFactory::get_instance()-> create_participant(0, pqos); if (!participant) { std::cerr << "Failed to create participant" << std::endl; return -1; } // 3. 注册类型 ImageTypeSupport type_support; type_support.register_type(participant); // 4. 创建 Topic Topic* topic = participant->create_topic( "camera/image_raw", "Image", TOPIC_QOS_DEFAULT); if (!topic) { std::cerr << "Failed to create topic" << std::endl; return -1; } // 5. 创建 Publisher（使用 "image_publisher" profile） PublisherQos pub_qos; DomainParticipantFactory::get_instance()->get_publisher_qos_from_profile( "image_publisher", pub_qos); Publisher* publisher = participant->create_publisher(pub_qos); // 6. 创建 DataWriter DataWriterQos dw_qos; DomainParticipantFactory::get_instance()->get_datawriter_qos_from_profile( "image_publisher", dw_qos); DataWriter* writer = publisher->create_datawriter(topic, dw_qos); // 7. 创建 Subscriber（使用 "image_subscriber" profile） SubscriberQos sub_qos; DomainParticipantFactory::get_instance()->get_subscriber_qos_from_profile( "image_subscriber", sub_qos); Subscriber* subscriber = participant->create_subscriber(sub_qos); // 8. 创建 DataReader DataReaderQos dr_qos; DomainParticipantFactory::get_instance()->get_datareader_qos_from_profile( "image_subscriber", dr_qos); DataReader* reader = subscriber->create_datareader(topic, dr_qos); // 9. 启动传输（此处省略具体 send/receive 循环） // ... // 10. 清理 participant->delete_contained_entities(); DomainParticipantFactory::get_instance()->delete_participant(participant); return 0; }

5.4 性能压测与调优：用真实数据说话

编译后，用stress-ng模拟 CPU 负载，iperf3占用网络带宽，进行三轮测试：

结论：4MB 缓冲 + depth=3 是最佳平衡点。再往上，延迟收益递减，内存压力陡增。这印证了开头的观点：QoS 不是调参，而是根据物理约束（网卡、内存、CPU）做的工程权衡。

6. 常见问题与独家避坑指南

6.1 “QoS 不兼容”错误：23 种策略的匹配逻辑

错误日志：WARNING: Incompatible QoS policies detected。这不是配置错误，而是 Publisher 和 Subscriber 的 QoS 策略存在强制不兼容项。Fast DDS 将 23 种策略分为三类：

• 强制兼容（Mandatory）：Reliability,Durability,History,ResourceLimits。只要有一项不匹配，发现失败，节点不可见。
• 可选兼容（Optional）：Deadline,Liveliness,Ownership。不匹配会触发警告，但连接仍建立，数据可收发。
• 忽略兼容（Ignored）：User Data,Topic Data,Group Data。完全不影响发现。

排查步骤：

1. 用dds::core::policy::CompatibilityQosPolicy获取不兼容详情；
2. 重点检查Reliability和History是否完全一致（包括depth值）；
3. 若用 ROS2，检查rmw_fastrtps_cpp的rmw_qos_profile_sensor_data等预设 Profile，它们对History.depth有默认值（通常是 1），而你的自定义 Publisher 可能设为 10，导致不匹配。

6.2 “内存泄漏”幻觉：Fragment 缓存未释放

现象：程序运行数小时后，RSS 内存持续上涨，valgrind无泄漏报告。根源是RELIABLE模式下，Publisher 为每个 Subscriber 维护一个Fragment缓存队列，用于重传。若 Subscriber 频繁启停（如调试时 Ctrl+C），Publisher 不会立即清理对应队列，直到heartbeat_response_delay超时（默认 10s）。解决方案：

• 在 Subscriber 正常退出前，调用subscriber->delete_contained_entities()；
• 或在 Publisher QoS 中，缩短reliability().max_blocking_time（如设为0, 100000000即 100ms），加速超时清理。

6.3 Docker 部署：网络模式与端口映射陷阱

在 Docker 中运行 Fast DDS，必须避开两个坑：

• 网络模式：--network=host最简单，但丧失隔离性；--network=bridge需手动映射7400端口，且initial_peers_list必须填宿主机 IP（非172.17.0.2）；
• UDP 分片：Docker bridge 网络的 MTU 通常是 1500，但容器内应用看到的 MTU 可能是 65535（虚拟设备）。这导致maxMessageSize=65000的包在容器内被内核分片，而 Fast DDS 的 Fragment 重组逻辑无法处理 IP 层分片。解决方案：启动容器时加--mtu=1500，或在transport_descriptor中显式设maxMessageSize=1400。

6.4 跨平台调试：Windows 与 Linux 的行为差异

• Windows：sendBufferSize设置上限受netsh int ipv4 set dynamicport影响，默认动态端口范围小，可能导致bind()失败。需扩大范围：`netsh int ipv4 set dynamic