RoCE基础：RoCEv1/v2协议原理、帧格式、与InfiniBand和TCP/IP的对比
核心原理：从InfiniBand到以太网的“借道”方案
RoCE（RDMA over Converged Ethernet）的核心思想，是把InfiniBand（IB）网络中成熟的RDMA传输语义——包括队列对（QP）、完成队列（CQ）、可靠连接（RC）等——原封不动地搬到以太网物理链路上来。它并不重新发明一套传输协议，而是让IB的报文头直接“骑”在以太网帧上，从而让原本为IB设计的RDMA软件栈（如libibverbs、Mellanox OFED）无需修改即可运行在以太网交换机组成的网络中。
RoCEv1与RoCEv2的关键差异在于“承载位置”：
- RoCEv1：IB全局路由头（IB GRH）直接封装在以太网II帧的EtherType字段（0x8915）之后，没有IP层。它要求收发双方处于同一个二层广播域（VLAN），无法跨子网路由。
- RoCEv2：在IB GRH之前插入UDP头（目的端口4791）和IPv4/IPv6头，EtherType变为0x0800（IPv4）。这使得RoCE报文可以被传统IP路由器转发，实现了三层可路由。
关键认知：RoCEv2本质上是“IB语义 + UDP封装 + 以太网承载”。UDP端口4791并非用于传输用户数据，而是作为协议多路复用标识，让交换机/网卡能识别这是RoCE流量并应用对应的流控与拥塞控制策略。
帧格式细节：RoCEv2报文逐字段拆解
以RoCEv2为例，一个完整的发送报文在网卡内部按以下顺序组装（以IPv4为例）：
以太网头: 目的MAC(6B) | 源MAC(6B) | EtherType=0x0800(2B)
IP头: 版本/IHL | DSCP | 总长度 | 标识 | 标志/片偏移 | TTL | 协议=17(UDP) | 头校验和 | 源IP(4B) | 目的IP(4B)
UDP头: 源端口(由QP号哈希生成) | 目的端口=4791(2B) | UDP长度(2B) | UDP校验和(2B)
IB GRH: IP版本=6 | 流量等级 | Payload长度 | 下一头=0x1B | 跳限 | 源GID(16B) | 目的GID(16B)
IB BTH: 操作码(Opcode) | 目的QP号(24bit) | 报文序号PSN(24bit) | 分区键P_Key(16bit)
IB扩展头: 可选（如原子操作、XRC等）
Payload: 用户数据（通常为4KB~8KB，受MTU限制）
ICRC: 4字节不变CRC，覆盖IB头+Payload
FCS: 以太网CRC，由MAC层硬件生成
实操提示：抓包时若看到UDP目的端口为4791，即可判定为RoCEv2流量。源端口并非固定值，而是由QP号（Queue Pair Number）经哈希生成，用于在ECMP（等价多路径）场景下让不同QP的流量散列到不同物理链路上。
三协议对比：RoCE、InfiniBand与TCP/IP
| 维度 | InfiniBand | RoCEv2 | TCP/IP |
|---|---|---|---|
| 物理层 | IB专用线缆/交换机 | 标准以太网（25/100/400G） | 标准以太网 |
| 网络层 | IB本地路由（LID/GID） | IP路由（可跨三层） | IP路由 |
| 传输层 | IB传输（RC/UC/UD） | IB传输（RC/UC/UD） | TCP（可靠字节流） |
| 数据搬运方式 | RDMA（内核旁路） | RDMA（内核旁路） | send/recv（内核参与） |
| 端到端延迟 | ~0.7µs | ~1.2µs（同DC内） | ~10µs+（软件开销） |
| CPU卸载 | 完全卸载 | 完全卸载 | 依赖TSO/LRO等部分卸载 |
| 拥塞控制 | IB CC（基于FECN/BECN） | DCQCN / 自适应路由 | TCP拥塞控制（CUBIC/BBR） |
| 流控机制 | 链路级流控（信用机制） | 以太网PFC（优先级流控） | 滑动窗口（端到端） |
| 部署成本 | 高（专用硬件） | 中（复用以太网） | 低（无处不在） |
典型场景与选型逻辑
在数据中心里，RoCEv2最常见的部署场景是存储网络（NVMe-oF）和高性能计算（HPC）中的消息传递接口（MPI）通信。以NVMe-oF为例，主机端通过RoCEv2网卡发起RDMA Read/Write操作，将远端NVMe SSD中的数据直接搬入本地内存，绕过了SCSI协议栈和内核网络栈，单盘读延迟可从TCP/IP方案的~100µs降至~20µs。
选型时通常遵循以下判断路径：
- 是否需要跨三层通信？ 是→RoCEv2；仅二层→RoCEv1或RoCEv2均可。
- 交换机是否支持PFC和ECN？ 是→可部署无损RoCE；否→需考虑RoCE性能下降风险。
- CPU资源是否紧张？ 是→RoCE（内核旁路）；否→TCP/IP可能更简单。
- 生态兼容性要求？ 需要与现有IP网络统一管理→RoCEv2；可接受独立网络→IB。
误区与复盘：RoCE部署中的常见陷阱
误区一：RoCEv2“有IP头”就等于可以像TCP一样随意路由。
实际上RoCEv2依赖无损网络（PFC）或ECN标记来避免丢包。若中间路由器缓存不足或未启用ECN，一旦发生拥塞丢包，RoCE的可靠连接（RC）会触发重传，但重传超时（TO）通常以毫秒计，远高于TCP的微秒级快速重传，性能会断崖式下跌。
实际上RoCEv2依赖无损网络（PFC）或ECN标记来避免丢包。若中间路由器缓存不足或未启用ECN，一旦发生拥塞丢包，RoCE的可靠连接（RC）会触发重传，但重传超时（TO）通常以毫秒计，远高于TCP的微秒级快速重传，性能会断崖式下跌。
误区二：RoCEv1和RoCEv2可以混用。
两者EtherType不同，且RoCEv1无法通过IP路由。若同一VLAN内混有RoCEv1和RoCEv2设备，RoCEv1流量会被RoCEv2网卡当作未知EtherType丢弃，反之亦然。实际部署中必须统一协议版本。
两者EtherType不同，且RoCEv1无法通过IP路由。若同一VLAN内混有RoCEv1和RoCEv2设备，RoCEv1流量会被RoCEv2网卡当作未知EtherType丢弃，反之亦然。实际部署中必须统一协议版本。
复盘建议：在规划RoCE网络时，先用ibstat或rdma link show确认网卡当前模式（RoCEv1/v2），再用tcpdump -i eth0 udp port 4791抓包验证实际报文格式。若发现抓不到RoCE流量，优先检查网卡驱动是否加载了rdma_rxe或厂商专用驱动模块，以及交换机端口是否启用了PFC（优先级流控）和ECN（显式拥塞通知）。