2、RDMA基础概念：InfiniBand、RoCE、iWARP协议栈对比，以及RDMA Verbs API概述
RDMA（Remote Direct Memory Access，远程直接内存访问）的核心价值在于绕过操作系统内核与CPU参与，直接在网卡与应用程序内存之间搬运数据。然而，RDMA并非单一技术，而是由多种承载于不同物理网络与传输层之上的协议族共同实现。理解InfiniBand、RoCE、iWARP三种协议栈的差异，以及统一的上层接口——Verbs API，是掌握RDMA编程与网络选型的基石。本章将从协议分层、性能特征、部署场景与编程接口四个维度展开，帮助读者建立清晰的RDMA技术坐标系。
上图展示了RDMA协议栈的整体架构。应用层通过统一的Verbs API与底层三种协议栈交互，而三种协议栈在传输层、网络层和链路层的实现差异，直接决定了它们的性能上限、部署成本与适用场景。下面逐一深入剖析。
2.1 三种协议栈的核心原理与分层对比
核心原理：RDMA的本质是让网卡（HCA或RNIC）直接访问应用程序注册的内存区域，完成数据收发、内存读写等操作，全程无需CPU介入数据拷贝。但不同协议栈在“如何保证数据可靠传输”“如何路由”“如何适配物理网络”上采用了截然不同的设计哲学。
- InfiniBand（IB）：从物理层到传输层完全为RDMA设计的原生协议。物理层使用专用IB线缆（如4x/12x链路）、IB交换机与IB网卡，链路层采用基于信用（Credit）的流控机制，保证端到端无损传输。网络层使用64位全局ID（GID）进行路由，传输层提供可靠连接（RC）、不可靠连接（UC）、可靠数据报（RD）等类型。
- RoCE（RDMA over Converged Ethernet）：将IB的传输层和网络层映射到以太网之上。RoCEv1在以太网链路层直接封装IB报文（以太网类型0x8915），要求收发双方处于同一二层网络；RoCEv2则引入UDP/IP封装（目标端口4791），实现三层路由，是目前数据中心的主流选择。RoCE依赖以太网的无损特性（PFC优先级流控、ECN显式拥塞通知）来模拟IB的无损环境。
- iWARP（Internet Wide Area RDMA Protocol）：将RDMA语义映射到TCP/IP协议栈之上。利用TCP的可靠传输、拥塞控制与乱序重排能力，实现RDMA操作。iWARP的硬件卸载复杂度较高，因为TCP状态机管理、重传缓存等都需要在网卡中实现，但其最大优势是无需特殊网络配置，可在标准以太网（有损）环境中运行。
| 对比维度 | InfiniBand | RoCE v2 | iWARP |
|---|---|---|---|
| 物理层 | IB专用线缆/交换机 | 以太网（25/100/200G） | 以太网（任意速率） |
| 网络层 | IB全局路由（GID） | IP（UDP封装） | IP（TCP封装） |
| 传输层 | IB传输协议（RC/UC/UD） | UDP + IB传输协议 | TCP / SCTP |
| 无损要求 | 天然无损（信用流控） | 需PFC/ECN配置 | 无需（TCP重传保证） |
| 典型时延 | 0.5 - 1.0 µs | 1.0 - 2.0 µs | 2.0 - 5.0 µs |
| CPU卸载 | 完全卸载 | 完全卸载 | 部分卸载（TCP处理开销） |
| 部署成本 | 最高（专用设备） | 中（需无损以太网） | 低（标准以太网） |
| 生态成熟度 | HPC/超算主流 | 云数据中心主流 | 传统企业/跨地域场景 |
判断方法：选型时首先看网络基础设施现状。如果从零搭建专用HPC集群，InfiniBand是最佳选择；如果已有大规模以太网且愿意投入网络调优（PFC/ECN），RoCEv2性价比最高；如果网络环境复杂、跨三层且无法保证无损，iWARP是唯一能“开箱即用”的RDMA方案。
2.2 实战场景：RoCEv2与iWARP在分布式存储中的选型对比
案例背景：某互联网公司计划构建一套基于RDMA的分布式块存储系统，用于支撑数据库与虚拟化场景。现有网络为25G以太网，核心交换机支持PFC和ECN，但存储集群与计算集群分布在两个机房，中间通过三层路由互联。
初始目标与约束：目标是将存储访问时延从传统TCP/IP的200µs降低至20µs以内。约束条件包括：不能更换现有以太网交换机；必须支持跨机房三层路由；运维团队对PFC死锁问题有顾虑。
分析判断过程：
- InfiniBand被排除——需要更换全部网络设备，成本过高。
- RoCEv2支持三层路由（UDP封装），但跨机房长距离链路（>2km）对PFC的依赖会导致队头阻塞风险，且两个机房的PFC域需要统一配置，运维复杂度高。
- iWARP基于TCP，天然支持跨三层路由，无需PFC/ECN配置，但时延比RoCEv2高约2-3µs，仍能满足20µs目标。
实际操作步骤：
# 在存储节点上使用iWARP网卡（如Chelsio T6）并验证
rdma link show
# 输出示例：link mlx5_0/1 state ACTIVE physical_state LINK_UP
# 使用ib_write_bw测试iWARP带宽与时延
ib_write_bw -d mlx5_0 -x 3 -F 192.168.1.10
# 结果：带宽 23.8 Gbps，时延 4.2 µs（满足要求）结果对比：最终选择iWARP方案。虽然单跳时延比RoCEv2高约2µs，但避免了PFC配置的运维负担，且跨机房链路表现稳定。上线后实测存储平均时延为18µs，达到预期目标。
复盘经验：在以太网环境中，RoCEv2的性能优势需要以无损网络为前提。如果网络规模大、跨地域或运维能力有限，iWARP的“标准TCP”特性反而成为可靠性保障。选型不能只看峰值性能，还要考虑运维复杂度和故障恢复能力。
2.3 RDMA Verbs API概述与操作流程
核心原理：Verbs API是RDMA的编程接口标准，由InfiniBand Trade Association（IBTA）定义，Linux内核的libibverbs库实现了该标准。Verbs API屏蔽了底层协议差异，应用程序通过同一套接口操作InfiniBand、RoCE或iWARP网卡。其核心对象包括：设备上下文（Context）、保护域（PD）、内存区域（MR）、队列对（QP）、完成队列（CQ）等。
关键操作流程：
- 设备初始化：
ibv_get_device_list()获取设备，ibv_open_device()打开设备，ibv_alloc_pd()分配保护域。 - 内存注册：
ibv_reg_mr()将应用缓冲区注册到网卡，获得L_Key（本地键）和R_Key（远程键），用于后续访问。 - 队列对创建：
ibv_create_qp()创建发送队列（SQ）和接收队列（RQ），指定传输类型（RC/UC/UD）。 - 连接建立：交换QP编号、GID、LID等信息（通常通过TCP带外通道），调用
ibv_modify_qp()将QP状态从RESET迁移到RTS（Ready To Send）。 - 数据收发：
ibv_post_send()提交发送请求（WR），ibv_post_recv()预置接收缓冲区，ibv_poll_cq()轮询完成队列获取操作结果。
| Verbs函数 | 功能 | 对应RDMA操作 |
|---|---|---|
ibv_post_send |
提交发送请求 | Send / Write / Read / Atomic |
ibv_post_recv |
预置接收缓冲区 | Receive |
ibv_poll_cq |
轮询完成队列 | 获取操作完成状态 |
ibv_reg_mr |
注册内存区域 | 获取L_Key/R_Key |
ibv_create_qp |
创建队列对 | 建立通信端点 |
经验提醒：Verbs API虽然统一，但不同协议栈对某些特性的支持程度不同。例如，RoCEv2不支持InfiniBand的原子操作（Atomic）在部分网卡上的硬件卸载；iWARP对IBV_QPT_UD（不可靠数据报）支持有限。编写跨协议代码时，应通过ibv_query_device()查询设备能力，避免使用不兼容的特性。
2.4 常见误区与总结复盘
误区一：认为RoCE和iWARP性能相同。实际上，RoCEv2在无损网络下时延更低（约1.5µs vs 4µs），但iWARP在拥塞网络中表现更稳定，因为TCP的拥塞控制算法比PFC/ECN更成熟。
误区二：忽略Verbs API的上下文管理。每个QP关联一个PD，PD又关联MR。如果多个线程共享同一个QP，必须使用锁或原子操作保护ibv_post_send调用，否则会导致QP状态错乱。
误区三：认为RDMA不需要CPU参与就完全零拷贝。RDMA确实避免了内核态与用户态之间的拷贝，但应用仍需将数据从应用缓冲区“放置”到注册的MR中（如果数据不在MR内）。零拷贝的前提是数据直接写入注册内存。
风险提示：RoCEv2的PFC配置不当会导致“死锁”现象——多个交换机端口互相等待缓冲区释放，网络吞吐骤降为0。建议启用PFC时同时配置ECN和DCQCN（数据中心量化拥塞通知），并设置合理的缓冲区阈值。iWARP虽然无此风险，但TCP的重传机制在极端丢包（>1%）场景下时延会急剧上升。
总结复盘：本章的核心是建立“协议栈差异”与“编程接口统一”的认知框架。InfiniBand是RDMA的“原生形态”，RoCEv2是“以太网上的IB”，iWARP是“TCP上的RDMA”。Verbs API作为统一抽象层，让上层应用无需关心底层物理网络。实际工程中，选型应综合考量性能、成本、运维复杂度与网络现状。下一阶段的学习重点应放在QP状态机、WR（Work Request）与CQ（Completion Queue）的交互机制上，这是编写高效RDMA程序的关键。