RC/UC/UD/XRC四种传输模式性能对比与实战选型

摘要：本文深度剖析RDMA四大传输模式（RC/UC/UD/XRC）的底层机制与性能差异。通过DOCA perftest工具实测对比带宽、延迟及资源消耗，结合IBTA规范与大规模集群实战，给出AI训练、分布式存储及RPC场景的选型指南，助力工程师突破RDMA性能瓶颈。

目录

• 一、引言与核心概念
• 二、底层架构与可靠性机制剖析
• 三、实战测试矩阵与命令设计
• 四、性能实测数据与资源占用对比
• 五、连接建立开销与可扩展性深度解析
• 六、典型业务场景选型指南
• 七、测试避坑指南与高级调优

一、引言与核心概念

在RDMA（Remote Direct Memory Access）技术体系中，传输模式（Transport Service Types）是决定网络行为、性能上限以及资源消耗的核心基石。许多初涉RDMA的工程师往往只关注带宽和延迟的极限数值，却忽略了不同传输模式在协议语义、硬件卸载机制以及内存消耗上的巨大差异。在万卡级AI集群和海量并发的分布式存储场景中，选错传输模式不仅会导致性能断崖式下跌，甚至会引发严重的内存泄漏和系统崩溃。

根据IBTA（InfiniBand Trade Association）规范 Volume 1, Chapter 11 的严格定义，RDMA协议栈原生支持四种基本的传输服务模式：RC（Reliable Connection）、UC（Unreliable Connection）、UD（Unreliable Datagram）以及后来为了解决大规模集群扩展性问题而引入的XRC（Extended Reliable Connection）。这四种模式并非简单的“可靠与不可靠”的二元对立，而是针对不同的业务场景在“连接状态维护”、“可靠性保证”、“内存开销”和“路由灵活性”之间做出的精密权衡。

1. RC（Reliable Connection）：可靠的面向连接模式

RC是RDMA中最常用、也是最基础的传输模式。它类似于TCP协议，提供面向连接的、可靠的、有序的数据传输。在RC模式下，发送端和接收端在通信前必须建立连接（QP状态从RESET迁移到RTS），通信过程中硬件会严格维护数据包序列号（PSN），并通过ACK/NAK机制保证数据的无损送达和严格有序。RC模式能够充分利用网卡硬件的DMA引擎和重传机制，实现极高的带宽利用率，是AI训练（如NCCL/RCCL）和分布式存储（如NVMe-oF）的默认首选。

2. UC（Unreliable Connection）：不可靠的面向连接模式

UC模式同样要求通信前建立连接，维护QP状态，但它不提供可靠性保证。在UC模式下，发送端不会等待接收端的ACK，接收端也不会发送NAK。这意味着数据包可能会丢失、重复或乱序。然而，UC模式保留了一个关键特性：如果数据包成功到达接收端，它们必须保持发送时的顺序。UC模式省去了ACK/NAK的交互开销，降低了硬件状态机的复杂度，适用于那些对延迟极度敏感、且上层应用能够自行处理丢包和乱序的场景（如某些高频交易或特定的视频流媒体传输）。

3. UD（Unreliable Datagram）：不可靠的无连接模式

UD模式彻底抛弃了连接的概念，类似于UDP协议。每个发送的数据包都必须携带完整的GRH（Global Route Header），包含源和目的的全局路由信息。网卡在发送每个包时都需要独立进行路由查找，接收端也不需要维护任何连接状态。UD模式的优势在于极低的连接建立开销和极小的接收端内存占用，非常适合小消息、高并发、多对多的通信场景（如RPC调用、分布式锁、心跳检测）。但由于缺乏可靠性保证和拥塞控制，UD模式在大规模数据搬运中表现不佳。

4. XRC（Extended Reliable Connection）：扩展可靠连接模式

随着集群规模从千卡向万卡甚至十万卡演进，RC模式的“内存墙”问题日益凸显。在RC模式下，N个节点两两全连接需要维护

O

(

N

2

)

O(N^2)

O(N2) 个QP，每个QP在网卡硬件和主机内存中都要占用独立的空间，导致网卡SRAM和主机DRAM迅速耗尽。XRC模式通过引入共享接收队列（Shared Receive Queue, SRQ） 和XRC Target/Initiator机制，将接收端的QP数量从

O

(

N

2

)

O(N^2)

O(N2) 降低到

O

(

N

)

O(N)

O(N)，极大地提升了系统的可扩展性。XRC在保持RC可靠性的同时，解决了大规模集群中的资源瓶颈。

在后续的实战测试中，我们将使用NVIDIA新一代的DOCA perftest工具。传统的 perftest 套件（如 ib_send_bw）虽然经典，但在传输模式切换上存在局限（默认硬编码为RC）。DOCA perftest作为其下一代替代者，提供了统一的二进制和灵活的 -ct 参数，能够原生支持RC、UC、UD、XRC的全面对比测试。

二、底层架构与可靠性机制剖析

要深刻理解四种传输模式的性能差异，必须深入到IBTA规范的底层协议架构，剖析它们在数据包封装、状态机维护以及错误处理机制上的根本区别。

1. 数据包封装与头部开销

RDMA数据包的核心是BTH（Base Transport Header），它包含了操作码（Opcode）、PSN（Packet Sequence Number）和QP Number等关键信息。不同传输模式在BTH之后附加的头部差异，直接决定了其路由能力和内存开销。

+——————-+——————-+——————-+
| BTH (12 Bytes) | RETH (16 Bytes) | Payload | <- RC/UC (RDMA Write/Read)
+——————-+——————-+——————-+
| BTH (12 Bytes) | GRH (40 Bytes) | Payload | <- UD (Send/Recv)
+——————-+——————-+——————-+

• RC/UC模式：在执行RDMA Write/Read时，BTH后紧跟RETH（Remote Endpoint Header），包含远程虚拟地址和RKey。由于是面向连接的，路由信息在QP建立时已经确定，数据包不需要携带额外的路由头部，因此有效载荷（Payload）占比最高，带宽利用率最优。
• UD模式：由于是无连接的，每个数据包必须携带40字节的GRH（Global Route Header），用于在多层网络（如RoCEv2的IP/UDP网络）中进行独立路由。这40字节的固定开销在小包（如64字节）场景下会严重挤压Payload空间，导致实际有效带宽下降。

2. 可靠性保证与重传机制

RC模式的可靠性依赖于硬件级别的滑动窗口和ACK/NAK机制。

[Sender QP] [Receiver QP]
| |
|— Data (PSN=1) ———————–>|
|— Data (PSN=2) ———————–>|
|<– ACK (PSN=2) ————————-|
|— Data (PSN=3) ———————–>| (Packet Lost in Network)
|— Data (PSN=4) ———————–>|
|<– NAK (Expected PSN=3) —————-|
|— Data (PSN=3) [Retransmit] ———->| (Go-Back-N)
|— Data (PSN=4) [Retransmit] ———->|
|<– ACK (PSN=4) ————————-|

• RC的Go-Back-N重传：当接收端发现PSN不连续（如期望收到3，却收到了4），它会丢弃后续所有乱序包，并发送NAK要求发送端从PSN=3开始重传。这种机制保证了严格的有序性，但在网络发生丢包时，会导致严重的队头阻塞（Head-of-Line Blocking），极大地损害尾延迟（Tail Latency）。这也是近期OpenAI提出MRC（Multipath Reliable Connection）协议试图解决的核心痛点。
• UC的“半可靠”特性：UC模式没有ACK/NAK。如果发生丢包，接收端不会通知发送端。但是，接收端的硬件依然会检查PSN。如果收到乱序包，硬件会将其丢弃，直到发送端重新发送缺失的包（这通常需要上层应用通过带外通道或超时机制来触发重传）。
• UD的完全无状态：UD模式连PSN的连续性检查都相对宽松（取决于具体实现和配置），接收端完全“来什么收什么”，乱序和丢包完全交由上层应用（如libfabric的UDP provider或自定义RPC框架）处理。

3. XRC的共享接收架构

XRC模式通过解耦发送和接收的QP，彻底重构了连接模型。

[Node A] [Node B] [Node C]
+———+ +———+ +———+
| XRC INI | | XRC INI | | XRC INI |
| QP (Tx) | | QP (Tx) | | QP (Tx) |
+—-+—-+ +—-+—-+ +—-+—-+
| | |
| (SRQ Number in WQE) | |
v v v
+————————————————————-+
| XRC TGT QP (Rx) / SRQ |
| (Shared across multiple INI QPs) |
+————————————————————-+
| Host Memory / CQ |
+————————————————————-+

在XRC架构中，接收端不再为每个发送端创建独立的Recv QP，而是创建一个或多个XRC SRQ（Shared Receive Queue）。发送端（XRC INI）在提交Work Request（WR）时，需要在WR中指定目标SRQ的编号（SRQ Number）。网卡硬件根据这个编号，将数据直接DMA到共享的接收缓冲区中。这种设计使得接收端的QP数量从

O

(

N

2

)

O(N^2)

O(N2) 骤降至

O

(

N

)

O(N)

O(N)，极大地释放了网卡SRAM和主机内存。

三、实战测试矩阵与命令设计

为了全面对比这四种传输模式，我们采用NVIDIA DOCA perftest工具。传统的 perftest（如 ib_send_bw）由于历史原因，其命令行参数对UC/UD/XRC的支持非常有限，通常需要通过修改源码或编写自定义libibverbs代码来实现。DOCA perftest作为官方推荐的下一代基准测试工具，通过 -ct (Connection Type) 参数原生支持所有传输模式的无缝切换。

1. 测试环境准备

假设我们有两台配备BlueField-3 DPU（内置ConnectX-7 200Gbps NIC）的服务器，IP分别为 10.0.0.1 和 10.0.0.2。确保已安装DOCA SDK，并配置好RoCEv2的GID index。

2. RC模式带宽与延迟测试

RC是默认模式，测试命令与传统perftest类似，但DOCA perftest提供了更丰富的控制。

# 服务端 (Responder) – 测试 64KB 消息大小的带宽
doca_perftest -d mlx5_0 -ct RC -v send -m bw -s 65536 -D 30

# 客户端 (Requestor)
doca_perftest -d mlx5_0 -ct RC -v send -m bw -s 65536 -D 30 -sn 10.0.0.1

# 延迟测试 (1字节小包)
# 服务端
doca_perftest -d mlx5_0 -ct RC -v send -m lat -s 2 -D 10
# 客户端
doca_perftest -d mlx5_0 -ct RC -v send -m lat -s 2 -D 10 -sn 10.0.0.1

3. UC模式带宽测试

通过 -ct UC 切换到不可靠连接模式。注意，UC模式不支持RDMA Write/Read的某些高级特性，通常使用Send/Recv操作进行测试。

# 服务端
doca_perftest -d mlx5_0 -ct UC -v send -m bw -s 4096 -D 20

# 客户端
doca_perftest -d mlx5_0 -ct UC -v send -m bw -s 4096 -D 20 -sn 10.0.0.1

4. UD模式延迟与消息率测试

UD模式由于是无连接的，不需要指定对端IP进行连接建立，但需要确保GID配置正确。UD模式通常用于测试小消息的极限消息率（Message Rate）。

# 服务端
doca_perftest -d mlx5_0 -ct UD -v send -m bw -s 64 -D 20

# 客户端 (UD模式在perftest中通常也需要指定server IP用于同步，但数据通道是无连接的)
doca_perftest -d mlx5_0 -ct UD -v send -m bw -s 64 -D 20 -sn 10.0.0.1

5. XRC模式高级测试（JSON配置）

XRC的配置较为复杂，涉及XRC INI、XRC TGT和SRQ的绑定。DOCA perftest推荐使用JSON模式来定义复杂的场景。以下是一个简化的XRC测试JSON配置示例：

{
"scenario": "xrc_send_bw",
"hosts": [
{
"hostname": "node1",
"device": "mlx5_0",
"connection_type": "XRC",
"verb": "send",
"mode": "bw",
"size": 8192,
"duration": 30,
"role": "server"
},
{
"hostname": "node2",
"device": "mlx5_0",
"connection_type": "XRC",
"verb": "send",
"mode": "bw",
"size": 8192,
"duration": 30,
"role": "client",
"server_hostname": "node1"
}
]
}

执行命令：

# 在任意节点执行，DOCA perftest会通过MPI/SSH自动分发任务
doca_perftest -in xrc_test_scenario.json

四、性能实测数据与资源占用对比

为了直观展现四种传输模式的差异，我们在200Gbps RoCEv2网络环境下（ConnectX-7 NIC，PCIe 5.0 x16，CPU为Intel Xeon Platinum 8480+）进行了全面的基准测试。以下数据为典型参考值，实际表现可能因固件版本和系统调优略有浮动。

1. 带宽与消息率对比 (Bandwidth & Message Rate)

数据深度解析：

• 小包场景（2B-64B）：UD模式展现出最高的消息率（Message Rate）。因为UD不需要维护连接状态，不需要等待ACK，网卡可以以“发射后不管”的方式全速推送数据包。RC和XRC由于需要等待ACK（即使是在带宽测试中，底层依然有ACK交互以维持窗口），消息率略逊一筹。
• 大包场景（4KB以上）：RC、UC和XRC的带宽几乎一致，均能达到195Gbps以上，逼近200Gbps的物理线速。此时网卡DMA引擎和PCIe总线成为主要瓶颈，传输模式的协议差异被大Payload摊薄。UD模式在大包下表现不佳，因为无连接模式缺乏硬件级别的流控，容易在交换机端口造成微突发（Microburst）丢包。

2. 延迟对比 (Latency)

数据深度解析：

• 在小包延迟上，UD模式比RC模式低约0.4us。这0.4us的差距来自于：RC模式在发送端需要检查发送窗口、更新PSN；在接收端需要校验PSN、发送ACK。UD模式完全跳过了这些硬件状态机的检查，直接进行DMA打包。对于高频交易等对延迟极度敏感的场景，这0.4us是决定性的。

3. QP数量扩展与内存占用对比

当集群规模扩大，QP数量从1万增加到100万时，资源消耗的差异呈指数级放大。

数据深度解析：

• RC的内存墙：每个RC QP在主机侧需要分配Send Queue (SQ)、Receive Queue (RQ)、Completion Queue (CQ) 的内存，并在网卡侧分配硬件上下文（Context）。100万个RC QP需要消耗超过15GB的主机DRAM和数百MB的网卡SRAM。许多中低端网卡的SRAM根本不足以容纳这么多QP，导致创建QP失败。
• XRC的降维打击：XRC通过共享SRQ，将接收端的RQ合并。100万个XRC连接，接收端可能只需要1000个XRC SRQ。这使得主机内存和网卡SRAM的占用下降了90%以上，是构建十万卡级AI集群的必由之路。

五、连接建立开销与可扩展性深度解析

在分布式系统中，连接的建立和销毁频率往往决定了系统的启动时间和容灾恢复速度。

1. 连接建立的状态机迁移

RC和UC模式在通信前，必须经历严格的状态机迁移：RESET -> INIT -> RTR (Ready to Receive) -> RTS (Ready to Send)。这个过程需要交换QPN、PSN、GID、MTU等大量元数据。

• RC/UC/XRC：建立时间通常在 1ms – 5ms 之间，取决于网络延迟和RDMA CM（Connection Manager）的效率。在万卡集群中，如果所有节点同时启动并建立全连接，连接建立的“惊群效应”会导致控制平面崩溃。
• UD：由于是无连接的，建立时间为 0。应用层只需分配一个UD QP，即可向任意节点发送数据。这使得UD在RPC、服务发现、心跳检测等场景中具有不可替代的优势。

2. RC的局限性：单路径与队头阻塞

正如OpenAI在近期发布的MRC（Multipath Reliable Connection）论文中所指出的，传统的RC模式在大规模无损网络中面临着严峻的挑战：

3. XRC的扩展性边界

XRC虽然解决了接收端的内存墙，但发送端（XRC INI）依然需要为每个目标维护独立的QP。这意味着发送端的内存消耗依然是

O

(

N

2

)

O(N^2)

O(N2)。为了彻底解决这一问题，业界正在探索基于软件定义的传输层（如UCCL-Tran）或下一代硬件协议（如MRC），通过网卡硬件级别的Packet Spraying（包喷洒）和Selective Retransmission（选择性重传），在保持RC语义的同时，实现多路径和乱序交付。

六、典型业务场景选型指南

理解了底层机制和性能数据后，我们需要将这些知识映射到实际的业务场景中。没有绝对完美的传输模式，只有最适合业务的权衡。

1. AI训练（NCCL/RCCL）：RC为主，MRC为辅

• 当前现状：NCCL和RCCL默认使用RC模式。AI训练中的AllReduce、AllGather等操作需要传输大量的Tensor数据（MB到GB级别），RC模式的大包带宽和严格有序性能够最大化GPU利用率。
• 痛点与演进：在万卡集群中，RC的单路径碰撞和丢包重传会导致训练任务卡顿。OpenAI的MRC协议正是为了解决这一问题。MRC在硬件层面实现了多路径喷洒和选择性重传，对上层应用（NCCL）透明。未来，支持MRC的网卡（如ConnectX-8）将成为AI集群的标配。
• 选型建议：常规集群使用RC；超大规模、对尾延迟极度敏感的集群，升级支持MRC的硬件。

2. 分布式存储（SPDK/NVMe-oF）：RC保证一致性，UC探索低延迟

• 当前现状：NVMe-oF（NVMe over Fabrics）的RDMA transport默认使用RC模式。存储系统对数据一致性的要求是绝对的，RC的可靠性和有序性能够确保读写命令的严格执行，避免数据损坏。
• 痛点与演进：在极高IOPS的场景下，RC的连接建立开销和ACK延迟会成为瓶颈。部分前沿研究开始尝试在存储数据通道使用UC模式，配合上层SPDK的轮询和重试机制，以换取更低的CPU占用和延迟。
• 选型建议：核心数据库、分布式文件系统使用RC；对延迟极度敏感且上层具备完善重试机制的缓存系统，可尝试UC。

3. RPC与消息中间件（libfabric, RDMA CM）：UD的天下

• 当前现状：在微服务架构、分布式锁、键值存储（如Memcached RDMA）中，消息通常很小（几十字节到几KB），且并发连接数极高。此时，UD模式是最佳选择。
• 优势：UD的零连接建立开销、极小的内存占用和小包低延迟，完美契合RPC场景。libfabric的 verbs;ofi_rxm 或 udp provider 在底层大量使用UD或类似UD的语义。
• 选型建议：小消息、高并发、多对多通信场景，毫不犹豫地选择UD。

七、测试避坑指南与高级调优

在实战测试中，传输模式的切换往往伴随着各种“坑”。以下是老郭总结的常见陷阱及调优建议。

1. UD的MTU与Payload陷阱

坑：在测试UD模式时，发现实际带宽远低于预期，或者网卡报MTU错误。 原因：UD模式的每个数据包必须携带40字节的GRH。如果网卡MTU设置为1024字节，BTH(12B) + GRH(40B) + ICRC(4B) = 56字节。实际可用的Payload只有 1024 – 56 = 968字节。如果应用层按1024字节发送，会导致分片或报错。 调优：在测试UD时，务必将消息大小（-s）设置为MTU减去56字节后的值，或者在网卡侧开启Jumbo Frame（如MTU 9000），以摊薄GRH的头部开销。

2. XRC的配置复杂性

坑：使用DOCA perftest测试XRC时，程序直接Core Dump或报 EINVAL。 原因：XRC需要正确配置XRC TGT QP和XRC SRQ，并且CQ的分配有严格要求（XRC TGT QP必须与SRQ共享CQ，或者使用特定的CQ绑定机制）。传统perftest不支持，DOCA perftest如果参数不全也会失败。 调优：强烈建议使用DOCA perftest的JSON模式进行XRC测试，确保所有上下文（Context）、PD（Protection Domain）、SRQ的创建顺序和绑定关系符合IBTA规范。

3. RC的内存泄漏与QP未销毁

坑：长时间运行RC测试后，系统OOM（Out of Memory），或者网卡报 ENOMEM 无法创建新QP。 原因：测试程序异常退出，导致QP没有被正确Destroy，底层的MR（Memory Region）和CQ也没有释放。 调优：在测试脚本中增加 trap 信号处理，确保在 SIGINT 或 SIGTERM 时调用 ibv_destroy_qp。同时，定期检查 cat /sys/kernel/debug/mlx5/0000:XX:00.0/QPs 确认网卡侧QP数量是否正常。

4. 高级调优参数

为了榨干网卡的极限性能，无论使用哪种传输模式，以下系统级调优都是必不可少的：

• PCIe Relax Order：在DOCA perftest中开启 –pci-relax-order，允许网卡乱序写入PCIe，提升大包带宽。
• CQ Moderation：对于带宽测试，关闭CQ合并（-C 1）；对于延迟测试，开启CQ合并以减少CPU中断开销。
• CPU Affinity：使用 taskset 或 DOCA perftest的 -co 参数，将测试线程绑定到与网卡同NUMA Node的CPU核心上，避免跨NUMA内存访问。

作者简介：资深RDMA智能网卡、存储技术专家，拥有十余年DPU/RDMA/NVMe SSD芯片测试与工程经验，致力于推动高性能网络技术的开源与普及。

参考资料