3、IB网络协议：数据包格式与核心服务
各位同学，今天我们来聊聊InfiniBand网络协议的核心内容。这部分内容，说白了就是IB网络通信的“交通规则”。你只有理解了数据包怎么封装、SM怎么管理网络、SA怎么提供服务，才能真正看懂故障现象。
我个人习惯把IB协议分成两大部分来看：数据面和控制面。数据面就是数据包格式和通信服务类型，控制面就是SM和SA。咱们一个一个来拆解。
3.1 IB数据包格式
IB的数据包，其实比以太网要复杂一些。它分为两个层级：本地路由头（LRH）和全局路由头（GRH）。嗯，这里要注意，不是所有包都有GRH，只有跨子网通信时才需要。
先看一个典型的IB数据包结构：
+----------------+----------------+----------------+----------------+
| LRH (8字节) | GRH (40字节) | BTH (12字节) | Payload |
| (必须存在) | (可选，跨子网) | (基本传输头) | (0-4096字节) |
+----------------+----------------+----------------+----------------+
| ETH (4字节) | ICRC (4字节) | VCRC (4字节) | |
| (扩展传输头) | (不变CRC) | (可变CRC) | |
+----------------+----------------+----------------+----------------+我在项目中遇到过一个问题：某次集群性能突然下降，排查了半天，最后发现是LRH中的VL（虚拟通道）字段被错误配置了。你想想看，一个字节的差异，就能让整个集群的吞吐量掉一半。
关键字段解读：
- LRH：包含源LID、目的LID、VL、SL等。LID是本地标识符，类似于以太网的MAC地址，但只有16位。
- GRH：包含128位的源GID和目的GID。GID其实就是IPv6地址格式，用于跨子网路由。
- BTH：包含OpCode、目的QP号、分组序列号（PSN）。PSN是IB可靠传输的关键，乱序重传全靠它。
重要提示：IB数据包最大传输单元（MTU）是4096字节，比以太网的1500字节大得多。这意味着IB在大数据块传输时效率更高。但要注意，如果MTU配置不一致，会导致分片和重组，性能会大打折扣。
3.2 Subnet Manager (SM) 工作原理
SM是IB网络的“大脑”。没有它，所有端口都只能处于初始化状态，无法通信。SM负责发现网络拓扑、分配LID、计算路由表。
SM的工作流程，我总结为三步：
- 发现阶段：SM通过SMP（子网管理包）扫描所有交换机、HCA（主机通道适配器），构建完整的拓扑图。
- 分配阶段：为每个端口分配唯一的LID。注意，一个端口可以有多个LID，但主LID只有一个。
- 路由计算：基于拓扑和路径策略，计算所有端到端的最优路径。这里支持多路径（多路径路由，MPR）。
我曾经遇到过一个案例：某数据中心新增了4台GPU服务器，但死活连不上存储。排查后发现，SM的拓扑发现超时了——因为新加的交换机固件版本太老，响应SMP包的速度太慢。嗯，这种问题在混合厂商设备时特别常见。
避坑指南：我曾经在升级SM固件时，没有先备份当前配置。结果升级后所有LID重新分配，导致上层应用全部断连。记住：操作SM前，一定要用ibswinfo或ibnetdiscover保存当前拓扑。
3.3 Subnet Administration (SA) 服务
SA是SM的“信息中心”。它不直接管理网络，而是提供查询服务。比如，一个节点想知道“到某个LID的路径是什么”，就可以通过SA查询。
SA的核心功能：
- 路径查询：返回源到目的的最优路径，包括SL（服务等级）和VL。
- 多播管理：管理多播组的加入和离开。IB的多播比以太网复杂，需要SA维护多播树。
- 服务记录：注册和查询服务名称（比如“存储服务A”对应的LID和QP号）。
说白了，SA就是IB网络的“黄页”。你打电话问“到某某地方怎么走”，SA告诉你“走哪条路、用什么等级”。
在实际故障排查中，我经常用ibqueryerrors和saquery这两个工具。比如：
# 查询所有端口的路径信息
saquery -p
# 查询多播组信息
saquery -m如果SA响应超时，通常意味着SM负载过高或者网络中存在环路。我曾经在4000节点集群上遇到过SA查询风暴——某个应用疯狂查询路径，导致SA队列溢出，整个网络管理平面瘫痪。
3.4 通信服务类型
IB提供了四种通信服务，我按使用频率排序：
| 服务类型 | 全称 | 可靠性 | 连接方式 | 典型应用 |
|---|---|---|---|---|
| RC | 可靠连接 | 可靠 | 点对点连接 | MPI、存储协议 |
| UC | 不可靠连接 | 不可靠 | 点对点连接 | 视频流、实时数据 |
| UD | 不可靠数据报 | 不可靠 | 无连接 | 管理消息、广播 |
| RD | 可靠数据报 | 可靠 | 无连接 | 较少使用，特殊场景 |
RC（可靠连接）：这是IB最常用的服务。它建立一对一的连接，保证数据按序到达，丢失自动重传。MPI通信几乎都用RC。我建议：只要你的应用需要可靠传输，优先选RC。
UC（不可靠连接）：它也有连接，但不保证可靠性。数据丢了就丢了，不会重传。适合对延迟敏感、能容忍少量丢包的应用，比如视频监控。
UD（不可靠数据报）：无连接，类似于UDP。每个包独立发送，不需要建立连接。SM和SA之间的通信就用UD。你想想看，如果SM用RC，那SM挂了之后所有连接都断了，还怎么恢复？
RD（可靠数据报）：这个用得很少。它结合了UD的无连接特性和RC的可靠性，但实现复杂，硬件支持也不够普遍。我在实际项目中几乎没见过RD的部署。
注意：不要混淆“连接”和“可靠”。RC既有连接又可靠，UC有连接但不可靠，UD无连接且不可靠。RD无连接但可靠。选型时，先问自己三个问题：需要连接吗？需要可靠吗？延迟要求多高？
知识体系总览
下面这张图，是我自己整理的IB协议核心逻辑。你可以把它当作本章的“地图”：
这张图把本章内容分成了三大块：数据包格式、控制面（SM/SA）、通信服务。你排查故障时，就按这个顺序来：先看数据面有没有问题（比如MTU不匹配、PSN乱序），再看控制面（比如SM是否在运行、SA是否响应）。
好了，IB协议的核心内容就这些。记住：数据包格式是基础，SM/SA是大脑，通信服务是工具。下次遇到IB网络问题，先问自己：是数据面还是控制面？是RC还是UD？这样排查思路就清晰了。
一句话总结：IB网络故障，80%出在SM配置错误或通信服务类型不匹配上。剩下的20%，才是硬件问题。