第2章拥塞控制基础

2、拥塞控制基础：网络拥塞的定义与成因

聊拥塞控制之前，咱们得先搞清楚一个根本问题：到底什么是网络拥塞？

说白了，就是网络里数据太多，路不够宽了。你想想看，一条高速公路，设计时速120，结果一下子涌进来10倍的车，那肯定堵死。网络也是这个道理。

我当年刚接触RDMA时，总觉得InfiniBand和RoCE都是高速网络，应该不会堵吧？结果第一次部署RoCE v2集群，跑AllReduce训练任务，延迟直接从5微秒飙到200微秒。嗯，那会儿我才真正意识到——拥塞这东西，跟带宽大小没关系，跟流量是否匹配网络容量有关系。

网络拥塞的成因，我习惯归纳为三点：

流量突发（Burst）：多个发送端同时发数据，瞬间超过链路容量。比如Incast场景，40个节点同时回数据给一个聚合节点，交换机缓存瞬间被打满。
资源竞争（Contention）：多个流争抢同一个出口端口。这在多打一（Many-to-One）的通信模式里特别常见，比如参数服务器架构。
缓冲区不足（Buffer Bloat的反面）：交换机或网卡的缓存太小，无法吸收突发流量。RoCE v2依赖PFC流控，但PFC本身也会引发拥塞扩散——这个坑我后面会细讲。

核心观点：拥塞不是带宽不够，而是瞬时流量 > 瞬时服务能力。哪怕你有100Gbps的链路，只要100个节点同时发1ms的突发，照样拥塞。

拥塞控制到底要控什么？我个人的理解是三个维度：

目标	定义	我踩过的坑
吞吐（Throughput）	单位时间内成功传输的数据量	曾经为了追求极限吞吐，把拥塞窗口开得太大，结果导致大量丢包重传，吞吐反而下降——这叫拥塞崩溃
延迟（Latency）	数据从发送到接收的时间	RoCE场景下，延迟从5μs飙到100μs，训练效率直接腰斩。延迟比吞吐更敏感
公平性（Fairness）	多个流之间如何分配带宽	我记得有一次排查问题，发现一个流占了90%带宽，其他流饿死了。后来发现是ECN标记策略有问题

这三个目标其实是互相制约的。你追求高吞吐，就可能牺牲延迟；你追求低延迟，又可能降低链路利用率。好的拥塞控制算法，就是在三者之间找平衡点。

避坑指南：我曾经在调优RoCE v2时，只盯着吞吐看，结果延迟爆炸。后来学乖了——延迟抖动（Jitter）比平均延迟更重要。对于分布式训练，尾延迟（99分位延迟）才是真正的杀手。

拥塞控制的实现方式，大致分两类。我画了一张图帮你理解：

端到端控制，说白了就是靠两端自己猜。发送端通过观察丢包、延迟变化、ACK到达速率等信号，推断网络是否拥塞，然后调整发送速率。

典型的例子就是TCP Reno。它靠丢包来判断拥塞——丢包了，说明网络堵了，赶紧降速。但这里有个问题：丢包本身就是一种损失。等你发现丢包时，数据已经丢了，重传成本已经产生了。

注意：在RoCE场景下，端到端控制有个致命缺陷——延迟太大。RoCE的RTT通常在10μs级别，但端到端控制需要多个RTT才能收敛。对于微突发流量，等你发现拥塞时，交换机缓存已经爆了。

网络辅助控制就不一样了。交换机作为中间节点，能实时感知队列长度、端口利用率。它主动给发送端发信号——「兄弟，我这边快扛不住了，你悠着点」。

RoCE v2里用的DCQCN（Data Center Quantized Congestion Notification）就是典型。交换机检测到队列超过阈值，就给发送端发CNP（Congestion Notification Packet）报文。发送端收到CNP后，立即降速。

我当年调DCQCN参数时，踩过一个坑：CNP的生成频率太高。交换机每微秒都在发CNP，结果发送端频繁降速，吞吐直接掉到60%。后来把CNP的采样间隔从1μs调到10μs，吞吐就稳住了。

个人经验：网络辅助控制虽然好，但不要过度依赖交换机反馈。我建议把端到端和网络辅助结合起来——交换机做粗粒度拥塞检测，端节点做细粒度速率调整。DCQCN就是这么干的。

嗯，到这里你应该对拥塞控制的基础有了清晰的认识。说白了，拥塞控制就是在吞吐、延迟、公平性之间做权衡。而端到端和网络辅助两种方式，各有优劣。RoCE网络之所以选择网络辅助控制，是因为数据中心场景对延迟极度敏感，等不起端到端的慢收敛。

下一节我们会深入DCQCN的具体实现，看看交换机到底怎么发CNP，发送端又怎么响应。不过那是后话了，先把基础打牢。

公众号:蓝海资料掘金营，微信deep3321