3. 可靠连接（RC）核心概念：RC的定义、特点、适用场景
3.1 RC的定义与协议语义
可靠连接（Reliable Connection，RC）是RDMA中最常用、功能最完整的传输服务类型。它基于面向连接的通信模型，在通信双方之间建立一条独立的、有序的、可靠的逻辑通道。RC在硬件层面实现了InfiniBand规范中定义的可靠传输语义，其核心特征可以概括为：一对一的连接关系、报文级确认与重传、严格保序交付、以及端到端的流控机制。
从协议栈角度看，RC服务由InfiniBand传输层（Transport Layer）实现，每个QP（Queue Pair）在建立时即被配置为RC类型。发送端发出的每个WQE（Work Queue Element）会被分割为一个或多个数据包，每个数据包都携带PSN（Packet Sequence Number），接收端通过PSN检测丢包、乱序和重复包，并通过ACK/NAK响应通知发送端。发送端在收到NAK或超时未收到ACK时，会从重传缓冲区中取出原始数据重新发送。
RC的关键协议要素：
- QP连接：一个RC QP只能与对端唯一一个RC QP建立连接，形成点对点通道。
- PSN机制：每个数据包携带递增的序列号，用于检测丢包、乱序和重复。
- ACK/NAK响应：接收端对每个（或批量）数据包返回确认，NAK携带错误码。
- 重传机制：发送端维护重传缓冲区，超时或收到NAK后按PSN重传。
- 有序交付：接收端严格按照PSN顺序将数据写入内存，保证消息边界完整。
3.2 RC的核心特点
RC服务的本质是将传统TCP/IP协议栈中由软件完成的可靠性保障，下沉到RDMA网卡硬件中实现。这种硬件卸载带来了几个显著特点：
- 极高的带宽利用率：由于可靠性逻辑由硬件处理，CPU无需参与数据包确认、重传和排序操作，从而将宝贵的CPU资源留给应用程序。在InfiniBand HDR（200Gb/s）速率下，RC连接可以轻松打满链路带宽。
- 极低的延迟：RC的确认和重传机制在硬件中完成，端到端延迟可低至1微秒级别。相比TCP/IP的软件协议栈（通常数十微秒），RC延迟降低了1~2个数量级。
- 严格的消息有序性：RC保证同一QP上的消息严格按照发送顺序被接收端处理。这种有序性对于许多并行计算算法（如MPI_Allreduce中的规约操作）至关重要。
- 完整的RDMA操作支持：RC是唯一支持全部四种RDMA操作（RDMA Send/Recv、RDMA Read、RDMA Write、Atomic）的传输服务。这使得RC能够灵活适配不同的应用模式。
- 内存开销较大：每个RC QP需要维护连接状态、重传缓冲区、接收端重组缓冲区等资源。当连接数量达到数千甚至数万时，网卡内存和CPU开销会显著增加。
RC与TCP的类比：如果读者熟悉TCP协议，可以将RC理解为“硬件化的TCP”。两者都提供可靠、有序、面向连接的传输，但RC将TCP/IP协议栈中软件实现的拥塞控制、确认重传、流量控制等功能全部卸载到网卡硬件中，并且省去了IP路由和操作系统协议栈的开销，因此性能远超TCP。
3.3 RC的适用场景
RC服务在以下典型场景中发挥着不可替代的作用：
| 应用领域 | 典型应用 | 为什么选择RC |
|---|---|---|
| 高性能计算（HPC） | MPI并行计算、科学仿真 | 需要极低延迟和零丢包，RC的硬件可靠性和保序性保证大规模集群中通信的确定性 |
| 分布式存储 | NVMe-oF、Ceph、Lustre | 存储协议要求数据不丢失、不乱序，RC的RDMA Write/Read操作可减少数据拷贝，提升IOPS |
| 人工智能/深度学习 | 分布式训练（NCCL、Horovod） | AllReduce等集合通信需要可靠、有序的数据交换，RC可提供微秒级同步延迟 |
| 数据库与缓存 | 分布式数据库、Redis Cluster | 关键事务日志需要持久化传输，RC保证数据不丢失且顺序一致 |
| 金融交易系统 | 高频交易、行情分发 | 纳秒级延迟差异即影响交易结果，RC的低延迟和确定性至关重要 |
3.4 RC的局限性：连接扩展性瓶颈
尽管RC性能卓越，但它并非银弹。RC最突出的局限在于连接扩展性问题。由于RC是一对一连接，当集群规模扩大时，每个节点需要与其他所有节点建立独立的RC QP。假设集群中有N个节点，每个节点需要建立N-1个QP，整个集群的QP总数达到N×(N-1)/2。当N=1000时，每个节点需要维护999个QP，每个QP需要消耗网卡内存用于维护状态和缓冲区，这对网卡资源是巨大的压力。
以实际数据为例，一个中等规格的RDMA网卡（如Mellanox ConnectX-6）可支持的QP数量约为10万级，但每个QP需要约数KB的上下文内存。当节点上运行多个进程（如MPI进程数=核心数）时，QP数量会成倍增长，最终可能耗尽网卡资源。
误区提醒：初学者常误以为“RC连接数越多越好”，实际上RC QP数量增加会带来以下代价：
- 网卡内存消耗线性增长，可能导致QP创建失败。
- CPU中断处理开销增加（虽然远小于TCP，但并非为零）。
- 连接建立时间随QP数量增加而延长。
- 当连接数超过网卡处理能力时，吞吐量反而下降。
因此，在大规模集群中，通常需要结合其他传输类型（如动态连接DC、不可靠连接UD）来缓解扩展性问题。
3.5 案例复盘：RC在分布式训练中的实践
以NVIDIA NCCL（NVIDIA Collective Communications Library）为例，观察RC的实际应用。在8节点DGX A100服务器组成的集群中，每台服务器有8张A100 GPU，通过8张HDR InfiniBand网卡互联。NCCL在初始化时会为每对GPU之间建立RC连接，用于执行AllReduce等集合通信操作。
在训练过程中，每个GPU需要将梯度数据通过RC连接发送给其他GPU。RC的RDMA Write操作允许GPU数据直接从显存写入远端显存，无需经过CPU和内存拷贝。同时，RC的硬件确认机制保证了梯度数据在传输过程中不丢失、不重复，确保AllReduce结果的正确性。
实际测试表明，在512张A100 GPU的集群上进行BERT大模型训练，使用RC连接的通信耗时仅占整体训练耗时的5%~8%，而如果改用软件模拟的可靠传输，通信耗时占比将超过30%。这充分体现了RC硬件卸载带来的性能优势。
然而，当集群规模扩展到数千张GPU时，NCCL会采用层级式通信策略：节点内部使用NVLink（不经过RDMA），节点间使用RC连接。同时，NCCL会复用QP（一个QP承载多对通信关系），以减少QP数量。这种设计正是为了规避RC连接扩展性的瓶颈。
本节要点回顾：
- RC是RDMA中最可靠、功能最完整的传输服务，基于一对一连接实现硬件级可靠传输。
- RC通过PSN、ACK/NAK、重传机制保证数据不丢失、不重复、严格有序。
- RC支持全部RDMA操作（Send/Recv、Read、Write、Atomic），适用于HPC、存储、AI等场景。
- RC的主要局限是连接扩展性，大规模集群中需结合DC或UD服务使用。