3. 以太网与TCP/IP回顾
RoCEv2（RDMA over Converged Ethernet version 2）的本质，是将RDMA的数据通路从InfiniBand的专用链路迁移到标准IP路由的以太网之上。这意味着，任何RDMA报文在进入物理线缆之前，都必须经历一次完整的“TCP/IP视角下的封装旅程”。如果对以太网帧结构、IP路由决策、UDP封装细节以及拥塞控制的基本逻辑缺乏清晰认知，后续理解RoCEv2的流控机制、ECMP负载分担、PFC死锁等问题时就会缺乏根基。本章并非简单复习网络基础，而是从RoCEv2工程落地的角度，重新审视这些经典协议中与RDMA性能强相关的关键细节。
上图展示了RoCEv2报文从应用到物理链路的完整封装路径。与传统的TCP/IP通信相比，RoCEv2最大的差异在于：传输层选择了UDP而非TCP，并且固定使用目的端口4791。这一设计并非随意为之——TCP的重传机制会引入毫秒级的时延抖动，这对于RDMA要求的微秒级时延是不可接受的。而UDP的无状态特性配合RDMA网卡硬件卸载，才能实现端到端的最低时延。但这也意味着，RoCEv2必须依赖网络自身的无损能力（如PFC）或端侧拥塞控制算法来保证可靠性，这正是本章需要重点铺垫的内容。
3.1 以太网帧结构：从MAC到VLAN的工程细节
以太网帧是RoCEv2报文在物理链路上传输的最终载体。理解帧结构不能停留在“前导码+目的MAC+源MAC+类型+数据+FCS”的层面，而需要关注与RoCEv2部署直接相关的三个细节：VLAN标签、以太类型、以及帧大小限制。
核心原理：标准帧与VLAN帧的差异
标准以太网帧（DIX v2）的Type字段位于第13-14字节，值为0x0800表示IPv4，0x86DD表示IPv6。当启用VLAN时，帧头中插入4字节的802.1Q标签，Type字段位置后移。对于RoCEv2网络，VLAN不仅仅是二层隔离手段，更是PFC（优先级流控）的载体——PFC基于802.1p优先级（位于VLAN标签的PCP字段）对特定流量进行暂停控制。因此，在RoCEv2组网中，VLAN规划必须与PFC优先级映射同步设计。
| 帧类型 | 目的MAC | 源MAC | VLAN Tag | EtherType | Payload | FCS |
|---|---|---|---|---|---|---|
| 标准帧 | 6B | 6B | 无 | 2B (0x0800) | 46-1500B | 4B |
| VLAN帧 | 6B | 6B | 4B (TPID+TCI) | 2B (0x0800) | 42-1500B | 4B |
| 巨型帧 | 6B | 6B | 4B (可选) | 2B | 最大9000B | 4B |
在RoCEv2环境中，MTU（最大传输单元）的设置直接影响RDMA性能。InfiniBand原生支持4KB MTU，而标准以太网MTU为1500B。如果RoCEv2报文超过1500B，就必须依赖IP分片——这会导致接收端重组开销，严重时延增加。因此，生产环境中的RoCEv2网络几乎无一例外地启用巨型帧（通常为9000B），确保RDMA数据包无需分片。
show interfaces gigabitethernet 1/0/1 查看MTU值，确保所有RoCEv2相关端口（包括服务器网卡、TOR交换机、Spine交换机）的MTU均设置为9000。若发现MTU不一致，需在变更窗口内统一调整，否则可能出现“黑洞”丢包。
案例拆解：VLAN与PFC优先级映射错误导致丢包
某金融数据中心部署RoCEv2存储网络，服务器网卡与TOR交换机之间出现间歇性丢包。初步排查物理链路正常，但RDMA吞吐量仅为预期的60%。通过抓包分析发现，服务器发送的RoCEv2报文携带VLAN优先级为3，而交换机PFC配置仅对优先级5的流量启用无损保障。当网络拥塞时，优先级3的流量被交换机丢弃，而RDMA协议栈无法感知丢包（UDP无重传），导致应用层超时。
解决过程：
- 检查服务器网卡驱动配置：确认RoCEv2流量映射的优先级（通常为3或5）。
- 核对交换机PFC配置：
show qos pfc priority查看各优先级是否启用PFC。 - 统一调整：将服务器RoCEv2优先级改为5，并在交换机上为优先级5启用PFC。
- 验证：使用
perftest工具重新测试带宽，恢复至线速。
复盘经验：VLAN优先级是RoCEv2无损特性的“钥匙”，必须确保端到端（服务器→TOR→Spine）的优先级映射完全一致。任何一跳的配置漂移都会导致PFC失效。
3.2 IP路由与ECMP：RoCEv2的路径选择逻辑
RoCEv2相较于RoCEv1的最大改进，就是引入了IP层路由能力。这使得RDMA流量可以跨越三层网络，不再局限于同一二层域。但IP路由的引入也带来了新的问题：如何保证多路径场景下的流量均衡？如何避免乱序？
核心原理：ECMP的哈希机制
ECMP（等价多路径）允许路由器或交换机通过哈希算法将流量分散到多条等价链路上。对于RoCEv2，哈希输入通常为五元组（源IP、目的IP、源端口、目的端口、协议）。由于RoCEv2固定使用UDP 4791端口，哈希的随机性主要依赖于源端口——这正是RoCEv2规范要求源端口随机化的原因。如果所有RoCEv2流都使用相同的源端口，ECMP哈希将把所有流量映射到同一条链路上，造成严重负载不均。
# 查看交换机ECMP哈希配置（以Cisco Nexus为例）
switch# show ip load-sharing
IP load-sharing algorithm: symmetric
IP load-sharing parameters: source-ip dest-ip source-port dest-port在RoCEv2部署中，建议将哈希参数调整为包含L4端口，并确保服务器端RoCEv2驱动启用了源端口随机化功能。Mellanox网卡可通过 mlxconfig 工具设置 ROCE_ECMP 参数。
案例拆解：ECMP哈希不均导致单链路拥塞
某AI智算中心，4台Spine交换机与8台TOR组成CLOS架构。运行分布式训练任务时，发现Spine1的上行链路利用率达95%，而Spine4仅20%。通过流量分析工具（如sFlow）采集数据，发现大量RoCEv2流的源端口集中在偶数段，导致哈希结果偏向Spine1。
优化步骤：
- 在服务器端启用RoCEv2源端口随机化：
mlxconfig -d /dev/mst/mt4123_pciconf0 set ROCE_ECMP=1 - 调整交换机哈希算法，加入源端口字段：
ip load-sharing srcip dstip srcport dstport - 验证：重新运行训练任务，观察各Spine链路利用率趋于均衡（差距小于10%）。
代价与权衡：启用源端口随机化会增加CPU开销（约2-3%），但对于现代网卡硬件卸载而言可忽略不计。若网络规模较小（如仅2台Spine），ECMP收益有限，可考虑使用静态路由绑定。
3.3 UDP封装：为什么RoCEv2选择UDP而非TCP
RoCEv2的传输层选择UDP，是经过深思熟虑的架构决策。理解这一选择背后的逻辑，有助于在排障时正确判断问题边界。
核心原理：UDP封装的三重意义
第一，UDP头部的校验和字段（可选）提供了数据完整性校验，但RoCEv2通常禁用UDP校验和以降低CPU开销，转而依赖链路层CRC（FCS）保证数据正确性。第二，UDP端口号（4791）作为多路复用标识，使接收端能够区分不同的RDMA流。第三，UDP的无连接特性使得RDMA网卡可以在硬件层面完成封装与解析，无需操作系统协议栈参与，从而实现微秒级时延。
| 对比维度 | TCP | UDP (RoCEv2) |
|---|---|---|
| 连接状态 | 有连接，需维护状态机 | 无连接，无状态 |
| 可靠性 | 确认重传 | 依赖无损网络或上层保障 |
| 时延抖动 | 重传导致毫秒级抖动 | 无重传，时延稳定 |
| 硬件卸载 | 部分卸载（TSO等） | 全硬件封装/解析 |
| 拥塞控制 | 内置（CUBIC等） | 需外部机制（DCQCN等） |
从工程角度看，UDP封装的最大代价是放弃了TCP的拥塞控制能力。TCP通过滑动窗口和拥塞窗口自适应调整发送速率，而UDP没有这些机制。因此，RoCEv2必须依赖网络层（PFC）和端侧（DCQCN、TIMELY等）的协同，才能避免拥塞崩溃。
3.4 拥塞控制基础：从TCP到RoCEv2的演进
拥塞控制是RoCEv2网络稳定运行的“最后一道防线”。与TCP的端到端拥塞控制不同，RoCEv2的拥塞控制需要网络设备（交换机）与端节点协同工作。
核心原理：三种拥塞控制机制的分工
RoCEv2网络中存在三个层次的拥塞控制：链路层PFC（优先级流控）、网络层ECN（显式拥塞通知）、传输层速率控制（DCQCN等）。PFC是“最后手段”，通过暂停帧阻止丢包；ECN是“预警机制”，在队列深度超过阈值时标记报文；速率控制是“主动调节”，根据ECN标记动态调整发送速率。
# 交换机ECN配置示例（Arista）
interface Ethernet1
qos ecn
qos ecn threshold 100000 200000上述配置表示：当队列长度超过100000字节时开始标记ECN，超过200000字节时丢弃（如果未启用PFC）。合理的阈值设置需要结合网络时延带宽积（BDP）计算，过小会导致频繁限速，过大则失去预警作用。
案例拆解：DCQCN参数调优实战
某高性能计算集群，RoCEv2网络在突发流量下出现吞吐量震荡。分析发现，DCQCN的 alpha 参数（拥塞因子）设置过高，导致发送端对ECN标记反应过度，速率骤降后恢复缓慢。
调优过程：
- 初始参数：
alpha=1.0，g=4（速率恢复因子）。 - 观察现象：吞吐量在10Gbps和40Gbps之间周期性波动。
- 调整策略：将
alpha降至0.5，g增至8，使速率调整更平滑。 - 验证结果：吞吐量稳定在38Gbps左右，波动幅度小于5%。
复盘经验：DCQCN参数没有“万能配置”，必须根据实际流量模型（突发程度、流大小分布）进行迭代调优。建议在测试环境模拟生产流量，使用 perftest 和 ethtool -S 监控ECN标记计数和速率变化。
3.5 本章总结与工程要点
以太网帧结构、IP路由、UDP封装和拥塞控制，构成了RoCEv2运行的四大基石。在后续章节中，我们将深入RoCEv2的报文格式、QP状态机、以及PFC/DCQCN的详细实现。但无论技术细节如何演进，以下工程原则始终不变：
- MTU一致性：所有RoCEv2路径上的设备必须启用相同的巨型帧MTU（通常9000B）。
- 优先级映射：VLAN PCP值必须端到端一致，且与PFC配置严格对应。
- ECMP哈希：确保源端口随机化，避免流量极化。
- 拥塞控制分层：ECN+速率控制为主，PFC兜底，避免依赖PFC处理常规拥塞。