惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Cyberwarzone
Cyberwarzone
S
Secure Thoughts
L
LINUX DO - 热门话题
C
Cyber Attacks, Cyber Crime and Cyber Security
C
CERT Recently Published Vulnerability Notes
P
Privacy & Cybersecurity Law Blog
A
Arctic Wolf
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
C
Cybersecurity and Infrastructure Security Agency CISA
大猫的无限游戏
大猫的无限游戏
U
Unit 42
Recorded Future
Recorded Future
Hacker News: Ask HN
Hacker News: Ask HN
F
Full Disclosure
Spread Privacy
Spread Privacy
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
Know Your Adversary
Know Your Adversary
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
云风的 BLOG
云风的 BLOG
Stack Overflow Blog
Stack Overflow Blog
D
Darknet – Hacking Tools, Hacker News & Cyber Security
F
Fortinet All Blogs
Martin Fowler
Martin Fowler
T
Threatpost
I
InfoQ
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
Cloudbric
Cloudbric
L
LangChain Blog
N
Netflix TechBlog - Medium
The Register - Security
The Register - Security
S
Security @ Cisco Blogs
B
Blog
T
Threat Research - Cisco Blogs
T
The Blog of Author Tim Ferriss
The GitHub Blog
The GitHub Blog
D
DataBreaches.Net
Simon Willison's Weblog
Simon Willison's Weblog
P
Proofpoint News Feed
Microsoft Security Blog
Microsoft Security Blog
Blog — PlanetScale
Blog — PlanetScale
B
Blog RSS Feed
MongoDB | Blog
MongoDB | Blog
W
WeLiveSecurity
Forbes - Security
Forbes - Security
O
OpenAI News
C
Check Point Blog
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
The Last Watchdog
The Last Watchdog
H
Help Net Security
SecWiki News
SecWiki News

Peng's Blog

Vibe paper不负责指北 读《Uno:数据中心间和数据中心内拥塞控制与可靠连接的一站式解决方案》 Lenovo Legion Y9000P 在 Linux 下只有 30W:从现象、WMI 到驱动补丁 理解《From ATOP to ZCube》中的ZCube网络拓扑 集合通信原语学习 Zotero在Wayland下侧边栏无法拖动的解决办法 再读CAVER 我读的第一篇论文--NSDI_26_CAVER 在archlinux下使用万象拼音实现更智慧的中文输入法 Traefik实现单Docker容器托管多个静态网站 Pengs.top浴火重生!备案、服务器迁移与全站Docker化 严谨与温度并存:北航宋友老师程设课的学习感悟 Android Studio全流程换源指南 解决linux系统下pipewire作为音频服务器持续播放声音中断问题 在ThinkBook 16+ 2025上安装archlinux驯服记录【基本信息与触摸板修复】 「行云流水」在挂载移动硬盘时自动启动Syncthing开始同步的丝滑体验 自建图床和PicGo闹不愉快?干脆自己写个脚本,深度整合到KDE右键菜单! btrfs各压缩等级速率测试脚本,选择最适合你的压缩级别 别当冤大头,Adobe全家桶破解源头方案:修图剪辑不求人,盗版网站也得从你这儿进货! 轻松配置aria2下载器,通过systemd设置开机自启并与浏览器集成 Git Commit 规范指南
SPFC参考文献阅读《CONGA》
Micraow · 2026-06-02 · via Peng's Blog

《CONGA: Distributed Congestion-Aware Load Balancing for Datacenters》是发表于2014年的面向数据中心的负载均衡机制。

论文的核心观点是:数据中心网络负载均衡最好在网络中完成(而非像MPTCP在主机实现),并且需要全局机制解决网络不对称

论文中的下图画出了CONGA的生态位,也顺便提了一下其他分支的技术:

屏幕截图_20260602_150511

CONGA的设计过程是先写出了一些期望CONGA具有的性质:响应快,对传输层无感,可适应非对称网络,可局部部署,为叶脊拓扑优化

集中式负载均衡还是分布式负载均衡?

CONGA论文中思考了什么时候使用中心化调控,什么时候使用分布式:

  • 分布式:数据中心流量高突发,不可预测,拓扑有规则
  • 集中式:WAN上流量稳定,拓扑随意

为什么不在主机侧协议层做?

CONGA给出的理由是:协议层本身已经要兼顾吞吐,延迟,突发了,在协议上再做改动不是一个工程上很好的解决方案。

为什么需要全局拥塞感知?

CONGA认为,尤其是在处理非对称拓扑时,交换机必须要知道非本机的下游拥塞情况,否则性能可能会比ECMP还差。

下游路径的拥塞情况必须对上游交换机的调度产生影响!

为什么一定需要Overlay网络

CONGA依赖于Overlay网络,Overlay网络主要是想实现大二层网络。论文中使用的例子是VXLAN. 这让我思考为什么不能直接使用Underlay网络。Underlay网络的话,IP头可供夹带信息的空间较少确实是一个问题。但这不是最重要的。

VXLAN的基础讲解我阅读了这篇知乎文章以及华为的文档 华为的文档更详细一点。

通过Overlay将整个网络变成大二层的好处是可以知道在物理上一条流是从哪个leaf到哪个leaf的,这个信息可以用于实际记录路径的拥塞情况,是端到端的感知。而IP协议对于不在同一网段的设备,只知道下一跳发送给谁。这样的话即使记录路径情况,也只能知道从IP-src到IP-dst的总体拥塞情况,无法分辨路径,也不存在多路径负载均衡了。

我一开始疑惑Leaf到Leaf也还不是路径啊,中间还隔着Spine呢,后面具体设计解答了。CONGA的VXLAN封装会在包头添加LBTag的四位标签,指示该流从本地的哪个端口发出。

为什么以Flowlet为分流单位

CONGA认为当两批突发包的间隔大于路径延迟差异,就能将第二批流量转移到新路径而不会引发乱序。

为了在数据中心网络中划分flowlet的大小,研究人员镜像了150GB的流量,按照100微秒,500微秒,250毫秒的gap尝试划分了flowlet.因为很少有超过250ms的gap,所以250毫秒的组基本相当于没有划分flowlet,直接是整条流。

实验结果表明500微秒组能让大部分的flow(let)大小减少两个数量级,并且乱序风险小

总体设计

传递拥塞信息

包经过Leaf-src,检查本地Flowlet表(用于转发已决策的流),如果是新流,则进行负载均衡,检查本地Congestion-to-Leaf表检查到Leaf-dst的路径的拥塞情况。包发出时打上了LBTag的标签,指示是从本地哪个端口出去的(指示了走了哪个Spine)。沿途的交换机会修改包头的CE标签指示拥塞的严重程度。

到达目的Leaf后,Leaf-dst会维护Congestion-from-Leaf表。并在向Leaf-src发送包的时候在包头附加FB_LBTag和FB_Metric,随后Leaf-src将收到的Metric写入Congestion-to-Leaf

另外,由于CONGA的Leaf-dst不是立即发回,所以等到有回到src的可供夹带信息的数据包时,拥塞情况可能已经改变,CONGA设计了一个过期机制,将拥塞情况逐渐递减到0, 但是如果链路真的拥塞了,它会被一直刷新。我认为这是合理的,在其他负载均衡机制上也见到过。

拥塞情况如何量化

CONGA使用Discounting Rate Estimator (DRE) 来量化流量积压,有点类似于EWMA。都是为了平滑流量变化,防止反应过激,但是如果拥塞确实上升了需要有所体现。

CONGA论文里说与EWMA相比,DRE有两个关键优势(i)它只需一个寄存器即可实现(而EWMA需要两个寄存器);和(ii)DRE对流量突发的反应更快(因为增量在数据包到达时立即发生)

EWMA算法我第一次接触是在Uno: A One-Stop Solution for Inter- and Intra-Data Center Congestion Control and Reliable Connectivity

这两个算法我打算后面再写一篇文章梳理一下。

负载均衡逻辑

Load balancing decisions are made on the first packet of each flowlet (other packets use the port cached in the Flowlet Table). For a new flowlet, we pick the uplink port that minimizes the maximum of the local metric (from the local DREs) and the remote metric (from the Congestion-To-Leaf Table). If multiple uplinks are equally good, one is chosen at random with preference given to the port cached in the (invalid) entry in the Flowlet Table; i.e., a flow only moves if there is a strictly better uplink than the one its last flowlet took.

简而言之,选择一条路径,在这条路径上本地出向压力与链路压力都不大。如果多条一样好的话,则优先选择之前走过的(上一条flowlet的路径,已经因为超时而invalid)。

讨论

有一些从数学的博弈论角度出发的分析被我跳过了,直接看到分析部分。

作为一种负载均衡机制,CONGA可以自适应网络流量和拓扑,因此在部分机器上进行部署是可行的,也有一定收益。

CONGA也指出了面对大型的拓扑可能存在不能重新利用路径的问题。因为当前的设计仅面向双层的Spine-Leaf网络。对于链路状况的反馈是叶对叶的,在两层的条件下,叶交换机的出端口即对应特定的脊,但是多层之后情况会变得复杂。