4. 不可靠连接（UC）核心概念：UC的定义、特点、适用场景
4.1 什么是不可靠连接（UC）
在RDMA协议体系中，不可靠连接（Unreliable Connection，简称UC）是一种面向连接的通信服务类型。与可靠连接（RC）不同，UC在数据传输过程中不提供丢包重传、报文排序、确认应答（ACK）等可靠性保障机制。它虽然建立了端到端的连接关系，但发送端发出数据后，并不等待接收端的确认，也不维护重传队列。换句话说，UC是“有连接、无可靠”的折中方案。
从队列对（QP）的类型来看，UC的QP状态机与RC类似，包含Reset、Init、RTR、RTS等状态，但在数据传输语义上，UC只支持Send/Receive（双边操作），不支持RDMA Read/Write（单边操作）。这意味着接收端必须预先提交接收请求（WR），否则发送端的数据将被丢弃。UC的MTU（最大传输单元）通常为256、512、1024或2048字节，与RC一致。
核心定义速记：UC = 面向连接 + 尽力而为交付 + 无重传 + 无ACK + 仅双边操作。它介于RC（可靠连接）与UD（不可靠数据报）之间：比UD多了连接上下文，比RC少了可靠性开销。
4.2 UC的核心特点分析
UC的特点可以从性能收益与功能限制两个维度来理解。在性能方面，UC省去了发送端对每个报文的ACK等待、重传定时器管理、接收端序号检查与重复报文处理等逻辑，因此CPU卸载更彻底，端到端延迟更低，带宽利用率更高。在功能方面，UC的局限性也非常明显：
- 无报文确认：发送端无法得知报文是否真正到达接收端，只能通过上层协议或应用逻辑来判断。
- 无乱序处理：如果网络发生乱序，UC不会对报文进行重排，接收端可能直接丢弃乱序到达的报文。
- 无流控机制：UC不提供端到端的信用量（Credit）管理，发送速率完全由上层应用或拥塞控制算法决定。
- 错误检测有限：UC仅依赖链路层的CRC（循环冗余校验）来检测传输错误，一旦发现错误即丢弃报文，不进行恢复。
- 接收端必须预置缓冲区：如果接收端没有提前提交Receive WR，到达的报文会被静默丢弃，发送端对此一无所知。
| 对比维度 | UC（不可靠连接） | RC（可靠连接） |
|---|---|---|
| 确认机制 | 无ACK | 逐包ACK |
| 丢包重传 | 不支持 | 支持 |
| 报文排序 | 不保证 | 保证 |
| QP上下文开销 | 较低 | 较高（需维护重传队列） |
| 支持操作类型 | 仅Send/Recv | Send/Recv + RDMA Read/Write |
| 典型延迟 | 更低 | 略高 |
4.3 UC的适用场景与典型案例
UC并非“低配版”RC，而是针对特定需求设计的通信模式。它的核心价值在于在可容忍少量丢包的应用中，换取极致的低延迟和低CPU开销。以下是UC最典型的几类应用场景：
4.3.1 高频交易与金融行情分发
在证券交易系统中，行情数据（如股票报价、订单簿更新）以极高的频率产生。这类数据具有时效性强、可容忍偶发丢失的特点——如果某一条行情报文丢失，下一条更新的行情很快就会到来，应用层无需重传旧数据。使用UC可以避免RC中ACK和重传带来的额外延迟，让行情数据以最快的速度从交易所网关送达交易策略引擎。
// 伪代码示例：UC发送行情快照
struct ibv_qp *uc_qp = create_uc_qp(pd, cq);
struct ibv_sge sge = { .addr = (uint64_t)market_data,
.length = sizeof(struct market_snapshot),
.lkey = mr->lkey };
struct ibv_send_wr wr = {
.opcode = IBV_WR_SEND,
.send_flags = IBV_SEND_SIGNALED,
.sg_list = &sge,
.num_sge = 1
};
ibv_post_send(uc_qp, &wr, &bad_wr);
// 无需等待完成事件，立即发送下一条4.3.2 高性能计算中的周期性同步数据
在分布式机器学习或科学计算中，计算节点之间需要周期性交换中间结果（如梯度向量、状态快照）。这些数据在每一轮迭代中都会重新生成，即使某一轮的报文丢失，下一轮的数据也会覆盖旧值。UC在此场景下可以显著降低同步开销，提升整体计算吞吐量。
4.3.3 实时音视频传输
在RDMA加速的实时音视频系统中，音视频帧数据对延迟极其敏感，但对个别帧的丢失并不致命（解码器可以通过前后帧插值恢复）。UC避免了重传导致的延迟抖动，保证媒体流的平滑传输。
选型判断准则：如果应用满足以下条件，可优先考虑UC——① 数据具有周期性或可刷新性；② 应用层能容忍小概率丢包（通常<0.1%）；③ 对延迟极度敏感，无法等待重传；④ 不需要RDMA Read/Write单边操作。
4.4 常见误区与复盘
在实际使用UC时，工程师常陷入以下几个误区，值得特别警惕：
误区一：将UC当作“RC的降级版”使用。有些开发者为了追求低延迟，将原本基于RC的应用直接切换为UC，却没有修改上层协议。当网络出现拥塞丢包时，应用层因为没有重传机制而出现数据空洞，导致业务逻辑错误。正确的做法是：在应用层设计序列号检测与补偿机制，或者仅在确认数据可容忍丢失的前提下使用UC。
误区二：忽略接收端Receive WR的预置。UC的接收端必须提前调用ibv_post_recv提交缓冲区。如果接收端处理速度跟不上发送端，或者忘记预置足够的WR，报文会被网卡直接丢弃。这种丢包是“静默”的——发送端完全感知不到。建议在接收端维护一个WR池，通过完成队列（CQ）事件及时补充新的Receive WR。
误区三：认为UC不需要连接管理。虽然UC不提供数据可靠性，但它仍然是面向连接的。QP的状态转换（Reset→Init→RTR→RTS）必须正确完成，连接双方需要交换QP编号（QPN）、LID等参数。如果连接建立过程出错，后续所有数据都将无法传输。因此，UC的连接管理开销与RC相同，省去的只是数据面的可靠性逻辑。
复盘一个真实案例：某分布式存储团队最初使用RC进行数据节点间的元数据同步，发现CPU占用率高达15%。他们分析后认为元数据更新具有幂等性（每次更新携带完整版本号），于是改用UC传输。修改后CPU占用率降至3%，端到端延迟降低约40%。但他们在测试中发现，当网络出现微突发拥塞时，丢包率会短暂超过1%，导致部分元数据版本跳跃。最终他们增加了应用层的定期全量同步机制（每100ms一次），在保持低延迟的同时，将数据不一致窗口控制在可接受范围内。这个案例说明：UC的适用需要系统性的架构设计，而非简单的协议替换。