RDMA 与 RoCE

枫桥2026/6/30大约 8 分钟

RDMA 与 RoCE

一个分布式数据库为什么"网络不够快"

某互联网公司的分布式 KV 存储，2020 年扩容到 1000 节点后遇到瓶颈：

单次 GET 请求端到端延迟 200 微秒
其中网络收发包占 180 微秒（TCP 协议栈 + 内核拷贝）
真正访问内存只占 20 微秒

TCP 协议栈成了瓶颈。每次收包都要经过"网卡 → 内核协议栈 → 用户态 socket → 应用 buffer"，3-4 次内存拷贝，2 次上下文切换。100 Gbps 网卡下，CPU 都耗在网络协议栈上，业务吞吐上不去。

解决方案：RDMA（Remote Direct Memory Access，远程直接内存访问）。

RDMA 让一台机器直接读写另一台机器的内存，绕过操作系统内核和 CPU。网卡（RNIC）自己处理协议，CPU 完全不参与。延迟从 200 微秒降到 10 微秒，吞吐从 50 Gbps 提到 90 Gbps。

这一章讲 RDMA 的原理、三种主流实现（InfiniBand、iWARP、RoCE）、RoCE 怎么在以太网上跑 RDMA、部署的真实坑。

问题一：TCP/IP 网络栈的瓶颈在哪

传统 TCP/IP 收发包流程：

应用 buffer ──read()──> 用户态 socket buffer
                              ↓
                         内核态 socket buffer
                              ↓
                         内核 TCP/IP 协议栈（处理头部）
                              ↓
                         网卡驱动 ring buffer
                              ↓
                         网卡 DMA 到物理线缆

一次收包 3-4 次内存拷贝：

网卡 DMA 到 ring buffer（第一次拷贝）
内核协议栈处理后从 ring buffer 复制到 socket buffer（第二次拷贝）
socket buffer 复制到应用 buffer（第三次拷贝）

2 次上下文切换（用户态 ↔ 内核态）。

CPU 负担重：处理 100 Gbps 流量需要 4-8 个 CPU 核心专门跑协议栈。

延迟高：每次上下文切换 1-5 微秒，3 次内存拷贝 5-10 微秒，加上协议栈处理 5-10 微秒。网络延迟 30-50 微秒起步。

问题二：RDMA 怎么"绕开"内核

RDMA 的核心思想：让网卡直接读写远程机器的内存，不经过 CPU。

机器 A                                              机器 B
[应用 buffer]                                       [应用 buffer]
    ↓                                                  ↑
[RNIC 网卡] ──网络（RDMA 协议）──> [RNIC 网卡] ──DMA──> 内存
    ↑                                                  ↑
[CPU 完全不参与]                              [CPU 完全不参与]

RDMA 收发包流程：

应用注册内存区域（MR）给 RNIC——告诉网卡"这段内存你可以直接访问"
应用通过 Verbs API（类似 ibv_post_send）提交"读/写/发送"请求
RNIC 自己组包（RDMA 协议头），DMA 到网卡，发送到网络
对端 RNIC 收到包，直接 DMA 到目标应用 buffer
CPU 完全不参与数据传输，只处理控制平面（连接建立、注册内存等）

RDMA 的核心收益：

零拷贝：数据从 A 网卡到 B 内存，没有中间拷贝
CPU 卸载：CPU 不参与数据传输，省下 4-8 个核心
微秒级延迟：端到端 1-10 微秒，比 TCP 100+ 微秒快一个数量级
高带宽：单端口 100 Gbps / 200 Gbps / 400 Gbps

问题三：RDMA 的三种实现方式

RDMA 不是一个协议，是一类技术。主流有三种实现：

InfiniBand（IB）

1999 年由 InfiniBand Trade Association 推出。专用网络架构——从物理层到传输层都是专门设计。

物理层：专用 IB 交换机、IB HCA（Host Channel Adapter）
链路层：16× 链路聚合，单链路 100 Gbps
传输层：RC（Reliable Connection）、UC、UD 等多种传输服务
特点：性能最优（延迟 1-2 微秒），但完全独立的网络——交换机、网卡、线缆都要单独买。无法和以太网互通。

iWARP（Internet Wide Area RDMA Protocol）

在 TCP 之上跑 RDMA。由 IETF 标准化（RFC 5040、RFC 5041、6581）。

物理层：标准以太网
链路层：标准以太网
传输层：TCP（MPA/DDP/RDS 三层协议栈）
特点：可以跑在普通以太网上，但TCP 协议栈开销还是存在——延迟 5-10 微秒，比 InfiniBand 慢。
现状：逐渐被 RoCE 取代。

RoCE（RDMA over Converged Ethernet）

在 以太网 + UDP 上跑 RDMA。由 IBTA（InfiniBand Trade Association）标准化。

RoCE v1：基于以太网链路层，不能跨三层路由
RoCE v2（RFC 7166）：基于 UDP 4791 端口，可以跨三层路由
特点：延迟 3-5 微秒（接近 InfiniBand），可以跑在标准以太网上——这是 RoCE 爆发的关键

对比表：

特性	InfiniBand	iWARP	RoCE v2
物理层	专用 IB	标准以太网	标准以太网
延迟	1-2 微秒	5-10 微秒	3-5 微秒
跨三层	不需要	是	是（UDP）
兼容传统网络	否	是	是
成本	高（专用设备）	中	低（标准网卡）
应用场景	HPC、超算	中小型数据中心	大型数据中心主流

结论：2020 年以后新建数据中心，RoCE v2 是绝对主流——保留 InfiniBand 的低延迟，丢掉 IB 的封闭性。

问题四：RoCE 怎么"在以太网上跑 RDMA"

RoCE v2 用 UDP 4791 端口封装 IB 传输协议：

┌─────────────────────────────────────┐
│  外层 IP 头（源/目的 IP）            │
├─────────────────────────────────────┤
│  UDP 头（端口 4791）                │
├─────────────────────────────────────┤
│  BTH（Base Transport Header，IB 协议）│
├─────────────────────────────────────┤
│  RDMA 数据（或 RDMA 操作描述）        │
├─────────────────────────────────────┤
│  有效载荷                           │
└─────────────────────────────────────┘

关键设计：

用 UDP 而非 TCP——避免 TCP 的拥塞控制和重传（RDMA 自己有可靠传输机制）
IB 传输层提供可靠连接（RC）——丢包重传、流量控制、拥塞控制都在 IB 层实现
但底层用无损以太网（lossless Ethernet）保证不丢包

无损以太网是什么？传统以太网是"尽力而为"——拥塞就丢包。但 RoCE 假设网络不丢包，靠 PFC（Priority Flow Control） 机制在交换机层面实现不丢包。

PFC 工作原理：

网卡发包前看优先级（RoCE 用优先级 3）
交换机队列拥塞时，向上游发 PAUSE 帧
上游网卡收到 PAUSE 帧，暂停发包，直到收到 RESUME
逐跳反压直到源头，从根本上不丢包

代价：PFC 反压会导致头阻（head-of-line blocking）——一条链路拥塞，所有流量都暂停，包括不相关的流量。RoCE 网络设计要严格规划带宽，避免拥塞。

问题五：RoCE 的真实部署场景

场景 1：分布式存储（Ceph、MinIO）

存储节点之间复制数据（3 副本）需要高吞吐低延迟。RoCE 让 100 Gbps 网络下单次复制 4 KB 数据延迟 <10 微秒。

[存储节点 A] ──RoCE──> [存储节点 B] ──RoCE──> [存储节点 C]
   写数据             副本同步            副本同步

场景 2：AI 训练集群

大模型训练（GPT、LLaMA）参数 100B+，AllReduce 梯度同步是性能瓶颈。GPU 节点之间用 RoCE 同步梯度，比 TCP 同步快 5-10 倍。

[GPU 0] ─┐
[GPU 1] ─┤
[GPU 2] ─┼─> [RoCE 交换机] ─> AllReduce
[GPU 3] ─┤
[GPU 4] ─┘

NVIDIA DGX、NCCL 库默认支持 RoCE。

场景 3：金融高频交易

订单从 A 交易所到 B 交易所，延迟 1 微秒差就是 1 万美元。RoCE 让跨机房订单延迟 <10 微秒。HFT 公司基本全用 RoCE 或 InfiniBand。

场景 4：内存数据库

Redis、Memcached 集群节点之间复制会话，跨节点访问 1 微秒 vs 100 微秒，吞吐差 100 倍。

问题六：RoCE 部署的真实坑

RoCE 看着美好，部署全是坑。三个最常遇到的：

坑 1：PFC 风暴

某交换机一个端口拥塞发 PAUSE，反压传到所有上游。最后所有 RoCE 流量都暂停，业务中断。

解决：用 ECN（Explicit Congestion Notification） 替代或配合 PFC。交换机检测拥塞，在 IP 头打 ECN 标记，让发送方降速。比 PFC 反压更精确。

坑 2：MTU 不一致

RoCE 包默认 MTU 9000（jumbo frame）。如果链路某段 MTU 1500，包被丢弃，RoCE 直接断流（不是降速）。

解决：端到端统一 MTU 9000，用 ip link show 检查每段链路。

坑 3：PFC 死锁

4 台交换机两两互联，A 拥塞反压 B，B 反压 C，C 反压 D，D 又反压 A——死锁。所有 RoCE 流量卡死。

解决：交换机支持 PFC deadlock detection（8 秒超时自动恢复）。或者设计无环拓扑（Spine-Leaf）。

思考题

RoCE 假设网络"无损"。如果交换机不支持 PFC，RoCE 包丢失会怎么样？IB 协议层有重传，但重传会导致什么后果？延迟波动还是连接断？
某 AI 训练集群 100 Gbps RoCE，但 AllReduce 吞吐只有 30 Gbps。瓶颈可能在哪些地方？网卡配置？交换机？CPU？内存带宽？
某金融公司用 RoCE 跨机房做订单同步，机房 A 到机房 B 延迟 50 微秒（光速决定）。能不能用 RoCE 把延迟压到 10 微秒？瓶颈在哪？
RoCE 跑在 UDP 4791 端口。普通 TCP 业务（如 Web）和 RoCE 业务混跑在同一台交换机上。普通 TCP 业务突发拥塞，触发 PFC 反压，会影响 RoCE 业务吗？怎么避免？
你负责的分布式存储系统，业务从 TCP 迁移到 RoCE。CPU 占用从 60% 降到 10%，延迟从 200 微秒降到 15 微秒。但上线后发现某些小包场景（4 KB 读写）性能反而变差。分析可能原因。
RoCE v2 用 UDP，但 UDP 本身不可靠，IB 协议层有可靠传输。如果数据中心链路丢包率 0.1%（普通以太网典型值），RoCE 重传开销会消耗多少带宽？相比 TCP 拥塞控制（遇到丢包就降速），RoCE 处理丢包的方式更激进还是更保守？