2. 链路层基础：物理层、链路层、网络层、传输层协议栈概览
各位同学，咱们今天聊聊InfiniBand的协议栈。很多新手一上来就被这四层架构搞晕了。我个人习惯把这四层比作一个快递系统——物理层是公路和卡车，链路层是分拣中心，网络层是导航路线，传输层是签收确认。这么一想，是不是清晰多了？
2.1 物理层：信号传输的基石
物理层，说白了就是信号怎么在线上跑。InfiniBand用的是差分信号，跟PCIe有点像。我记得刚入行那会儿，有个项目因为线缆太长导致信号衰减，折腾了两天才发现是物理层的问题。
物理层主要管三件事：
- 电气特性：电压摆幅、信号速率。InfiniBand的速率从SDR（2.5Gbps）一路飙到NDR（400Gbps），每次升级都像换了一代硬件。
- 编码方式：8B/10B编码（早期）或64B/66B编码（高速）。说白了就是保证信号里有足够的跳变，方便时钟恢复。
- 连接器与线缆：铜缆、有源光缆（AOC）、光模块。我建议你在数据中心里尽量用AOC，铜缆超过3米就容易出问题。
关键参数速查表
| 速率代 | 单通道速率 | 编码方式 | 典型应用 |
|---|---|---|---|
| SDR | 2.5 Gbps | 8B/10B | 早期HPC |
| DDR | 5 Gbps | 8B/10B | 老集群 |
| QDR | 10 Gbps | 8B/10B | 常见 |
| HDR | 25 Gbps | 64B/66B | 主流 |
| NDR | 50 Gbps | 64B/66B | 最新 |
避坑指南：我曾经在部署HDR交换机时，发现链路死活起不来。查了半天，结果是光模块的固件版本不匹配。记住，物理层的问题往往最隐蔽，先检查光功率和CRC错误计数。
2.2 链路层：可靠传输的保障
链路层是InfiniBand协议栈里最核心的一层。它负责把物理层的比特流组织成数据包，并且保证这些包能正确到达对端。你想想看，如果没有链路层，物理层传过来的信号就是一坨乱码。
链路层的关键机制：
- 数据包格式：每个包都有LRH（本地路由头），包含源和目的LID。LID就像门牌号，交换机靠它转发。
- 流控机制：基于信用的流控（Credit-Based Flow Control）。发送方必须收到接收方的信用才能发数据。这能防止接收方被淹没。
- 错误检测：CRC校验。链路层会计算VCRC（变长CRC）和ICRC（不变CRC）。
我个人习惯把链路层比作一个快递分拣中心。每个包裹（数据包）都贴了标签（LID），分拣员（交换机）根据标签把包裹送到正确的传送带上。如果包裹破损（CRC错误），就扔掉重发。
链路层数据包结构
+----------------+----------------+----------------+----------------+
| LRH (8B) | BTH (12B) | Payload | ICRC (4B) |
+----------------+----------------+----------------+----------------+
| 目的LID | 源LID | 操作码 | 包序号 | 数据内容 | 不变CRC |
+----------------+----------------+----------------+----------------+注意：链路层的信用流控是InfiniBand低延迟的关键。我曾经遇到一个性能问题，发现是信用机制配置不当，导致发送方频繁等待信用。调整后延迟直接降了30%。
2.3 网络层：全局寻址与路由
网络层在InfiniBand里相对简单，但很重要。它负责全局寻址——也就是跨子网通信。链路层的LID只在子网内有效，跨子网就得靠GID（全局标识符）。
网络层主要做两件事：
- GRH处理：全局路由头（GRH）包含128位的源和目的GID。GID其实就是IPv6地址格式，但用法不同。
- 路由决策：根据GID查找路由表，决定下一跳。InfiniBand的路由是静态的，由子网管理器（SM）计算。
嗯，这里要注意：InfiniBand的网络层不像IP网络那样有动态路由协议。所有路由都由SM集中计算，然后下发到交换机。这种设计的好处是简单、确定性强，适合HPC场景。
个人经验：我在做多子网互联时，发现GID配置错了导致跨子网通信失败。排查方法很简单——用ibroute命令查看路由表，确认GID和端口映射是否正确。
2.4 传输层：端到端的可靠服务
传输层是协议栈的顶层，负责端到端的通信服务。它提供了多种服务类型，满足不同场景的需求。说白了，传输层决定了你的数据是「丢了不管」还是「必须送到」。
传输层提供的服务类型：
- 可靠连接（RC）：一对一，保证有序、不丢、不重。适合存储和数据库。
- 可靠数据报（RD）：多对多，保证可靠但不保证顺序。适合集群通信。
- 不可靠数据报（UD）：多对多，不保证可靠。适合管理消息。
- 原始数据报（Raw）：直接访问物理层，适合特殊场景。
我建议你在实际项目中，优先用RC。虽然它消耗的资源多，但可靠性最好。UD虽然轻量，但丢包了应用层得自己处理重传，麻烦得很。
传输层关键字段（BTH）
| 字段 | 长度 | 说明 |
|---|---|---|
| OpCode | 8位 | 操作码，标识包类型（如RDMA写、读） |
| SE | 1位 | 发送完成标志 |
| M | 1位 | 迁移标志 |
| Pad | 6位 | 保留 |
| PSN | 24位 | 包序号，用于排序和重传 |
避坑指南：我曾经在调试RDMA写操作时，发现对端收不到数据。查了半天，原来是传输层的PSN没有同步。记住，RC连接建立时，两端必须协商好初始PSN，否则数据包会被丢弃。
2.5 四层协议栈的协作
这四层是怎么协同工作的？我给你举个例子：
- 应用层发起一个RDMA写请求，数据交给传输层。
- 传输层加上BTH（包含PSN和操作码），交给网络层。
- 网络层加上GRH（包含GID），交给链路层。
- 链路层加上LRH（包含LID）和ICRC，交给物理层。
- 物理层把比特流发到线缆上。
接收端反过来，一层层剥掉头部，最终把数据交给应用。整个过程硬件完成，不需要CPU干预。这就是InfiniBand低延迟的秘密。
个人习惯：我调试协议栈问题时，常用ibdump抓包。然后一层层看头部信息——先看LRH里的LID对不对，再看GRH里的GID，最后看BTH里的PSN。这样排查效率很高。
好了，协议栈概览就讲到这里。下一章我们会深入链路层的流控机制，那是InfiniBand性能调优的关键。你想想看，如果没有流控，高速网络里丢包率会高得吓人。到时候我教你如何用信用机制来避免拥塞。