RDMA基础：InfiniBand、RoCE、iWARP等协议栈对比，以及连接模式在其中的角色
核心原理：三种RDMA协议栈的诞生背景与定位
RDMA（Remote Direct Memory Access）的核心思想是让网卡（RNIC）直接读写远端内存，绕过操作系统内核与CPU。但“如何把RDMA能力落到物理网络上”却有三条不同的技术路线，分别对应三种协议栈：InfiniBand（IB）、RoCE（RDMA over Converged Ethernet）和iWARP（Internet Wide Area RDMA Protocol）。它们最大的区别在于传输层和网络层的承载方式，而这直接决定了连接模式（可靠连接RC、不可靠连接UC、不可靠数据报UD）的可用性与实现成本。
关键认知：连接模式并非协议栈的“可选附件”，而是协议栈设计时就必须确定的传输语义。IB原生定义了RC/UC/UD三种模式；RoCEv1/v2借用了IB的传输层，因此同样支持这三种模式；而iWARP基于TCP，只能实现可靠连接（RC），无法提供UC和UD。
下图展示了三种协议栈在OSI模型中的分层差异，以及连接模式所处的位置：
方法流程：如何根据网络环境选择协议栈与连接模式
在实际部署中，选择哪种协议栈并非纯技术偏好，而是受现有网络设施、性能目标、成本预算三者的共同约束。以下是典型的选择流程：
- 判断是否允许部署专用网络：如果从零开始建设数据中心内部网络，且追求最低延迟和最高可靠性，优先选择InfiniBand，并使用RC模式承载存储和HPC应用。
- 若必须复用已有以太网：则进入下一步——检查交换机是否支持无损以太网（PFC、ECN）。若支持，选择RoCEv2，并根据应用容忍度选择RC（默认）或UC（追求更低CPU开销）。
- 若跨越三层路由或Internet：只能选择iWARP，因为它基于标准TCP，天然可路由。此时连接模式只有RC一种，无需纠结。
- 确定QP类型：在IB/RoCE环境中，若消息长度小且需要多对多通信，可考虑UD；若需要高吞吐且消息可靠，选RC；若希望减少ACK开销且能容忍少量丢包重传，选UC。
实操建议：在RoCEv2环境中，绝大多数生产系统（如NVMe-oF、分布式存储）默认使用RC模式。UC模式虽然减少了确认包数量，但要求上层协议自行处理丢包，实际收益有限，除非你非常清楚自己在做什么，否则不建议在生产环境使用UC。
案例/场景：三种协议栈的典型应用对比
| 场景 | 推荐协议栈 | 连接模式 | 原因 |
|---|---|---|---|
| HPC集群（MPI并行计算） | InfiniBand | RC / UD混合 | IB原生低延迟，RC用于点对点大消息，UD用于集合通信广播 |
| 数据中心存储网络（NVMe-oF） | RoCEv2 | RC | 复用以太网，RC保证存储数据不丢失，PFC提供无损通道 |
| 跨数据中心异步复制 | iWARP | RC（唯一） | TCP可跨三层路由，无需专用无损网络 |
| 低CPU开销的分布式缓存 | RoCEv2 | UC | 减少ACK处理，CPU占用更低，但需上层自行处理丢包 |
以NVMe-oF（NVMe over Fabric）为例：存储网络对数据完整性要求极高，因此必须使用RC模式。RoCEv2通过PFC（优先级流控）保证以太网不丢包，配合RC的端到端重传机制，形成双重保障。而如果使用iWARP，虽然也能保证可靠，但TCP的拥塞控制和ACK机制会带来额外的延迟和CPU开销，在存储场景中通常不如RoCEv2+RC高效。
误区/复盘：关于协议栈与连接模式的常见误解
误区一：“RoCE和iWARP只是封装不同，性能差不多。”
事实：RoCEv2绕过TCP，直接使用UDP封装IB传输层，延迟通常在1-3微秒；iWARP走完整TCP协议栈，延迟在5-10微秒甚至更高。两者在CPU占用和延迟上有显著差异。
误区二：“UC模式比RC模式快，所以应该优先用UC。”
事实：UC确实省去了ACK和重传逻辑，但代价是丢包后上层必须自己处理。在无损以太网（PFC）下，UC的丢包率极低，此时UC可能略快；但一旦发生拥塞导致丢包，UC的恢复成本远高于RC。绝大多数场景下，RC的可靠性收益大于其额外的ACK开销。
误区三：“iWARP支持UD模式，因为UDP比TCP快。”
事实：iWARP的传输层是TCP，不是UDP。它只支持RC一种QP类型。如果你需要UD模式，只能选择IB或RoCE。
复盘总结：选择协议栈的本质是选择“传输层由谁实现”。IB自己实现了传输层，所以能自由定义RC/UC/UD；RoCE借用了IB的传输层，因此继承了全部三种模式；iWARP把传输层交给了TCP，因此只能提供RC。理解这一点，你就不会再混淆三者的能力边界。
最后，无论选择哪种协议栈，连接模式的配置都发生在QP（Queue Pair）创建阶段。在Verbs API中，通过设置 struct ibv_qp_init_attr 的 qp_type 字段来指定：
struct ibv_qp_init_attr attr = {
.qp_type = IBV_QPT_RC, // 可选：IBV_QPT_RC / IBV_QPT_UC / IBV_QPT_UD
.send_cq = cq,
.recv_cq = cq,
.cap = {
.max_send_wr = 128,
.max_recv_wr = 128,
}
};
ibv_create_qp(pd, &attr);在iWARP网卡上，如果尝试将 qp_type 设置为 IBV_QPT_UC 或 IBV_QPT_UD，驱动会返回错误，因为iWARP硬件根本不支持这两种模式。这也是验证协议栈能力边界最直接的方法。