---
格式版本: 2
标题: "【读懂UB无损传输】C-AQM、FECN与链路层重传——近似零队列是怎么做到的-CSDN博客"
原文链接: "https://blog.csdn.net/weixin_49775784/article/details/163505688?ops_request_misc=&request_id=&biz_id=102&utm_term=UB&utm_medium=distribute.pc_search_result.none-task-blog-2~all~sobaiduweb~default-3-163505688.142^v102^pc_search_result_base7"
发布日期: "2026-08-11"
发布时间校准状态: "found"
发布时间需复核: "否"
发布时间来源: "rule:local:strict_original_body"
发布时间证据: "于 2026-08-11 11:00:01 发布"
发布时间校准原因: "规则确认唯一严格发布时间，来源 local:strict_original_body"
发布时间校准置信度: "high"
发布时间候选数量: 11
发布时间严格候选数量: 1
发布时间原页读取状态: "source template page reused from URL open"
发布时间未找到原因: ""
发布时间校准时间: "2026-08-12T06:15:47+08:00"
发布时间仲裁状态: "skipped"
发布时间仲裁尝试次数: 0
发布时间仲裁耗时毫秒: 0
发现时间: "2026-08-12T06:14:51+08:00"
入库时间: "2026-08-11T22:15:47.551Z"
来源平台: "CSDN 搜索"
搜索渠道: "source_template"
搜索词: "https://so.csdn.net/so/search?urw=&q=UB"
匹配关键词:
  - "UB"
  - "超节点"
  - "光"
  - "内存"
  - "交付"
  - "时延"
  - "带宽"
  - "吞吐"
  - "AI"
相关厂家:
  - "字节"
相关专家:
  []
内容类型: "网页"
抓取工具: "CDP Render"
清洗工具: "CDP Text + Defuddle/Readability 正文提取"
原始附件:
  []
AI优质: "是"
AI打分: 80
AI分档: "高置信优质"
AI质检状态: "通过"
AI打分理由: "直接讨论UB无损传输机制（C-AQM/FECN/LLR），与超节点/机柜级AI系统的高速互连强相关；技术细节深入，基于公开规范，但来源为个人博客，权威性一般；无商业部署信号。"
AI质检模型: "ali-deepseek-v4-flash"
AI质检时间: "2026-08-12T06:15:54+08:00"
AI主题相关性: 20
AI来源权威性: 10
AI新颖性: 15
AI技术细节: 20
AI商业部署信号: 5
AI完整性: 10
采集批次: "2026年8月12日2点04分20秒"
采集批次ID: "20260812-020420-289"
去重键: "https://blog.csdn.net/weixin_49775784/article/details/163505688?biz_id=102&ops_request_misc=&request_id="
---

作者：陈东坡 （方宜万强）

> *导语：在 [Agentic AI时代的吞吐狂魔——UB交换机+SuperPoD的去孤岛实践](https://blog.csdn.net/weixin_49775784/article/details/162769306?spm=1001.2014.3001.5502 "Agentic AI时代的吞吐狂魔——UB交换机+SuperPoD的去孤岛实践") 一文的3.2节，我们用近似零队列一句话带过了UB无损传输的效果。但这句话背后，其实站着一整套精心设计的机制：拥塞控制（C-AQM）、拥塞感知（FECN/FECN\_RTT）与可靠重传（LLR）。本文从拥塞到底是发生的讲起，说清楚它们各自解决什么问题、彼此如何配合。文中关键机制均对照《UB Base Specification 2.0.1》公开规范，力求准确。*

## 一、先看懂问题：拥塞、排队与长尾时延从哪来

要理解无损传输的价值，得先回答一个更基础的问题：网络里的时延到底花在了哪儿？对一个小数据包来说，它从发送端到接收端，时间大致由三部分组成——在链路上飞的传播时延、在网卡/交换机里被处理的转发时延，以及最容易被忽视的：排队时延。

#### 1.1 数据在交换机里是怎么排队的

交换机的每个出端口，都有一块有限的缓存（Buffer）。当同一时刻涌向这个端口的流量，超过了它对外发送的带宽，多出来的数据包就只能先进缓存里排队，等前面的包发完再轮到自己。这在网络里是再正常不过的机制——问题在于，AI的碎包暴雨会把这个机制推向极端。

设想一次MoE的All-to-All：成百上千张卡几乎在同一瞬间，把大量小包发向同一批目标端口。这就是典型的多入单出（incast）——短时间内入流量远大于出带宽，队列会以肉眼可见的速度堆高。

#### 1.2 为什么碎包暴雨最怕抖动

队列一旦堆起来，排队时延就会随队列水位近似线性地上升。当缓存被灌满时，时延被拉到最长——这种现象有个形象的名字叫Bufferbloat（缓冲区膨胀）。更麻烦的是，集合通信有很强的木桶效应：一轮All-to-All必须等最慢的那个小包到齐才能进入下一步，只要有一个包被卡在某个深队列的队尾，整张卡、乃至整个集群都在陪它等。

所以对碎包负载而言，真正的敌人不只是平均时延高，而是长尾时延（p99/p999抖动）。无损传输要做的，正是从根上把队列水位摁在很低的位置，让每个小包都随到随走。这就引出了本文的三个主角：拥塞控制、拥塞感知与链路重传。

![](https://i-blog.csdnimg.cn/direct/8e54cb049ccf41bba84472be337ad0ba.png)

图1 拥塞死怎么来的：队列堆积与长尾时延

## 二、传统答案：DCQCN的先拥塞、再降速

在理解UB的做法之前，先看看目前RoCEv2（RDMA over Converged Ethernet）以太网上最主流的拥塞控制方案DCQCN（Data Center Quantized Congestion Notification）。它由微软等在2015年SIGCOMM提出，今天几乎是数据中心RDMA的事实标准。把它讲清楚，UB的改进才有参照。

#### 2.1 三个角色+两根支柱

DCQCN把一次拥塞控制拆给三个角色来完成：

- **CP（Congestion Point，拥塞点）：** 就是中间的交换机。它负责发现拥塞。
- **NP（Notification Point，通知点）：** 接收端网卡。它负责把我这条流遇到拥塞了这个消息通知回源头。
- **RP（Reaction Point，反应点）：** 发送端网卡。它负责收到通知后降速。

支撑这套流程的是两根支柱：ECN与PFC。ECN（显式拥塞通知）让交换机可以在数据包上盖个戳表示拥塞；PFC（基于优先级的流控）则是一种逐跳的暂停机制——当某台交换机的入口缓存快满时，它会向上游发一个PAUSE帧，让上游先别发了。PFC是保证不丢包的最后托底，但也正是它埋下了后面要讲的隐患。

#### 2.2 一次完整的反应闭环

把这几个角色串起来，DCQCN的一次拥塞响应是这样走的：

1. **发送：** RP按当前速率把数据发向CP（交换机）。
2. **标记：** 当CP的出端口队列超过预设的ECN阈值时，它给正在转发的数据包打上ECN拥塞标记。注意：队列必须先堆到阈值以上，才会触发标记——这是先拥塞。
3. **回传：** 被标记的数据继续走到NP（接收端）；NP发现标记后，生成一个专门的CNP（拥塞通知包）反向发回RP。为控制开销，一条流最快也要每隔约50微秒才发一个CNP。
4. **降速：** RP收到CNP，才按一定比例调低发送速率，之后再缓慢试探性恢复——这是再降速。

![](https://i-blog.csdnimg.cn/direct/195e19dd98da43c68cb61e5709a0e192.png)

图2 传统DCQCN：先拥塞、再降速（反应式闭环）

#### 2.3 为什么说它被动：三个结构性痛点

DCQCN是一套设计精良、久经考验的方案，但它的事后反应范式，在碎包暴雨下会暴露三个结构性的短板：

- **反应滞后一个RTT。** 从交换机发现拥塞到发送端真正降速，中间要经过：数据走到接收端+CNP绕回发送端，这至少是一个完整的往返时延（RTT）。在这段时间里，拥塞并不会停下，队列仍在继续堆——等药到了，病可能已经加重了。
- **PFC的连锁反应。** 在ECN尚未把速率压下来之前，为了不丢包，PFC会被触发。而PFC的逐跳暂停是会传染的：一个端口的拥塞暂停会向上游反压，可能引发队头阻塞（HoL Blocking）、拥塞扩散，极端情况下甚至造成死锁，让整条路径瘫痪。
- **参数极难调。** 要让DCQCN正常工作，ECN的标记阈值必须设得比PFC的触发阈值更低（好让ECN有机会先于PFC起效）；这个阈值又和缓存大小、流量模型、链路速率强相关。现网里，这套参数的调优是出了名的玄学。

> *一句话概括DCQCN的困境：它是一套事后救火的机制——必须先让拥塞真实发生、让队列真实堆起来，才能启动那条绕一圈才生效的反馈回路。对偶发的大流，这没问题；但对每秒百万次、要求百纳秒级完成的碎包小交互，慢一个RTT和长尾抖动就是致命的。*

## 三、UB的答案：C-AQM的先授予、再发送

UB换了一个根本性的思路：与其等拥塞发生后再被动降速，不如在发送之前就主动问一问网络现在能不能多发、能多发多少，拿到授权再发。这就是C-AQM的核心——从事后反应转向事前供给。

#### 3.1 C-AQM到底是什么

C-AQM的全称是Confined Active Queue Management（可约束的主动队列管理）。

主动队列管理（AQM）是网络领域的一类经典技术，思想是不等队列满就提前干预；而UB的Confined体现在：它把发送方的发送量约束在网络当前可服务的能力之内，从源头上不让队列涨起来。

#### 3.2 C位、I位、Hint

C-AQM的精髓，藏在数据包携带的三个小字段里（规范5.3.5.3与6.6.1.3节）。

- **C位（Congestion，拥塞位）：** 发送端发包时把C位清零；数据包途经的UB Switch一旦发生拥塞，就把这一位置1。它是路上有没有堵的最简信号。
- **I位（Increase，增窗请求位）：** 发送端若想提高发送量，就把I位置1，表示我想多发一点。这是一次主动的申请。
- **Hint（增量提示）：** 配合I位，发送端在Hint域里填上期望增加多少。而交换机若判断这次增量申请可能引发拥塞，就把I位改回0（否决），并可把本节点当前的拥塞程度回填进Hint。

于是一次完整的C-AQM闭环是这样的（对照图3）：①发送端每发一个数据包，就顺带携带一次申请（C=0、I=1、Hint=期望增窗量）；交换机作为路况裁判实时裁决——不拥塞就放行申请，拥塞则置C=1、要增窗但会致堵就把I置0；②这些C/I/Hint结果，由接收端通过应答包（TPACK-CC/TPNAK-CC等）带回发送端；③发送端依据规范的窗口调整规则，相应地增大或减小自己的拥塞窗口cw。

![](https://i-blog.csdnimg.cn/direct/d8ea598f85a14bd3a72b1fda71953fb7.png)

图3 UB的C-AQM：先授予、再发送（主动式闭环）

Confined Active Queue Management ——发送速率与网络可服务能力精准匹配

#### 3.3 为什么这样就能近似零队列

关键差别在于时机。DCQCN是在拥塞已经发生、队列已经堆起之后才去降速；C-AQM则是在增大发送量之前，就先让沿途交换机审批了一遍。发送方拿到授权才增窗，意味着发送速率被持续地约束在网络可服务能力附近——数据包到了交换机基本无需排队即可转发，队列水位因此长期维持在接近零的水平。Bufferbloat带来的长尾时延，从源头上就被抑制了。

把两种范式对比：

![](https://i-blog.csdnimg.cn/direct/4ab725f3f87347d9aee812e6a6ad8efb.png)

## 四、C-AQM的眼睛：FECN与FECN\_RTT

主动授予要授得准，前提是交换机和端侧能看清路况。这双眼睛，就是FECN与FECN\_RTT。

#### 4.1 FECN：把最拥塞点的状态顺流带到目的端

FECN的全称是Forward Explicit Congestion Notification（前向显式拥塞通知）。前向是理解它的钥匙：拥塞信号不是单独往回发，而是顺流跟着数据包一起，向前送到目的端，再由目的端汇总反馈。这与传统后向通知（把信号逆流送回源头）形成对照。

- **2 bit表达拥塞程度：** FECN域段宽2比特——00表示不可标记，一直到11表示重度拥塞，把有多堵量化成四档。
- **取最大重标记：** 数据包经过每一台交换机时，若本节点的拥塞程度高于包上已有的标记，就重新标记为更高值；否则不动。这样一路走下来，目的端收到的，正是整条路径上最拥塞位置的状态。
- **拥塞扩散检测（可选）：** 逐级反压可能让拥塞状态沿路扩散，使得某台交换机明明是受害者却也显得很堵。开启该功能后，只有真正的拥塞源头端口才打标，避免误伤，让归因更准。
- **与IP ECN互通：** 对于依赖IP ECN的协议栈，规范要求在UB链路收发时完成IP头ECN与CCI域段FECN之间的相互拷贝转换，保证生态兼容。

**4.2 FECN\_RTT：给拥塞信号配一块秒表**

光知道堵不堵还不够，要把授予算准，还得知道这条路来回要多久。FECN\_RTT就是在FECN的基础上，额外附带一个时间戳（Timestamp）：发送端UB Controller在发包时写入时间戳T0，沿途的UB Switch不需要理会、原样透传；接收端再把这个T0通过CNP原样带回发送端。发送端用现在的时刻减去T0，就精确测得了这条路径的往返时延RTT。

有了实时RTT，闭环才能算得准：发送速率乘以RTT，就是在途数据量（在网络里飞着、尚未被确认的量）。C-AQM正是靠它，把窗口/速率精确匹配到不多不少、恰好填满管道又不排队的水平。FECN回答堵不堵、有多堵，FECN\_RTT回答路有多长，两者一起喂给主动授予的决策。

![](https://i-blog.csdnimg.cn/direct/34cfdb15924d42ab83ac226e51beb2a5.png)

图4 C-AQM的眼睛：FECN感知拥塞成都+FECN\_RTT测量晚饭时延

## 五、最后一道防线：链路层重传（LLR）

把队列摁到近似零、又能看清路况之后，还剩最后一个问题：物理链路偶尔会出现瞬时误码，数据包被传坏了怎么办？如果处理不好，一次小小的比特翻转，也可能拖垮小包传输的确定性。UB的答案是一套分层的重传体系，其中最贴近硬件的一层，就是链路层重传（LLR，Link-Level Retry）。

#### 5.1 UB的三级重传体系

UB规范在高可用设计上，安排了层层设防的多级容错，遇到不同层面的问题由不同层就近处理：

- **物理层：** 链路出现故障时可降速或降lane（减少并行通道数）运行，故障恢复后再升速/升lane，尽量不中断。
- **链路层点到点重传（LLR）：** 相邻两个端口之间，一旦收到出错的数据就地重传，是本文的重点。
- **网络层多路径：** 同一对端点之间存在多条路径，可逐包/逐流地分摊流量、绕开故障或热点链路。
- **传输层端到端重传：** 作为兜底，端到端地保证整条连接的可靠交付，支持GoBackN与选择性重传两种模式。

#### 5.2 LLR是怎么工作的：Retry Buffer+GoBackN

链路层的数据以Flit（20字节的传输单元）为单位收发。LLR的机制，规范4.7.3节讲得很具体：

- **发送端备份：** 发送端把已发出、但还没被确认的Flit，暂存在一块叫Retry Buffer的缓存里，随时准备重发。
- **接收端触发：** 接收端对收到的数据做CRC校验与FEC解码；一旦CRC校验出错或FEC解码失败，就由接收端发起重传请求（由重传请求状态机管理）。
- **GoBackN回退：** 发送端响应请求，采用GoBackN（回退N）机制——从出错的那个Flit开始，把它以及Retry Buffer中它之后的所有Flit重新发一遍（由重传应答状态机管理）。

这套流程的精髓是就近二字：误码在哪一跳发生，就在哪一跳、由该跳的收发两端本地解决，根本不惊动整条路径的其他环节。

![](https://i-blog.csdnimg.cn/direct/cf3f46af4c164b06b456018a57615561.png)

图5 链路层就近重传vs传输层端到端重传：LLR只在出错的一跳本地补发

#### 5.3 为什么就近重传对小包确定性至关重要

对比一下就明白LLR的价值。如果只有传输层的端到端重传，那么中间任意一跳出一次错，都要等整条连接的往返超时，再从源头把数据重发一遍——这一来一回的代价，对时延极其敏感的碎包来说是灾难性的，而且会引入很大的时延抖动。而LLR把纠错下沉到出错的那一跳本地完成，恢复极快、影响范围极小，上层几乎无感。正是这种逐跳的确定性，托住了UB在高并发碎包下依然稳定的低时延。

#### 5.4 顺带一提：死锁与逐级反压——无损网络的另一面

无损也有它的阴影面，UB链路层用信用流控保证不丢包：发送方只有在确认对端有缓存余量（信用）时才发送。但这种逐级反压若形成环路，就可能导致死锁——一个典型场景是：节点D处理不过来，反压Switch4，Switch4反压Switch3……最终首尾相连、形成缓存的循环依赖，整条路径上的包都动不了。

这也正是前面FECN拥塞扩散检测、以及网络层多路径存在的深层理由：无损网络必须同时配备一整套拥塞管理与死锁规避手段，才能把不丢包的好处稳稳拿到手。这也解释了为什么C-AQM、FECN、LLR、多路径不是彼此孤立的功能，而是一个互相支撑的整体。

## 六、合成一张图：主动授予+多路径+链路重传

现在，我们可以把主动授予+多路径+链路重传的组合真正看懂了。这三招各管一段、彼此补位，共同把一条数据通路打磨成无损、低时延、确定性的样子：

1. **主动授予（C-AQM）：** 在源头按需供给，让发送速率始终贴着网络可服务能力，事前就不让队列淤积——解决拥塞。
2. **多路径路由：** 把暴雨般的流量逐包/逐流摊到多条链路上，既避开热点，又维持整体有序——解决热点与拥塞扩散。
3. **链路层重传（LLR）：** 对瞬时误码就近、快速地本地补发，不惊动整条路径——解决可靠性。

![](https://i-blog.csdnimg.cn/direct/2f8d765e4df7409dbb02ea3ae6b5a68f.png)

图6 组合拳：主动授予+多路怪+链路重传=无损低延迟数据通路

三者叠加的净结果，正是UB敢在每秒百万次小包并发下，仍把队列水位与长尾时延同时摁住的底气所在——也就是官方口径里百纳秒级同步内存语义时延、近似零队列这类说法真正的工程支撑。

## 七、小结

UB的近似零队列是三层机制协作的结果：UB的近似零队列不是一句口号，而是三层机制协作的结果。C-AQM用先授予、再发送的主动范式，替代了DCQCN先拥塞、再降速的被动反应，从时机上就把队列摁在了源头；FECN与FECN\_RTT分别提供有多堵和路多长两个关键输入，让授予算得准；LLR则以逐跳就近重传，托住了小包传输的确定性。理解了这三者，也就理解了为什么UB能把机箱内总线那种随到随走的确定性，延伸到整个超节点的尺度。