目录
- 导语
- [一、3.6.1 拥塞原因与代价](#一、3.6.1 拥塞原因与代价)
- [二、3.6.2 拥塞控制方法](#二、3.6.2 拥塞控制方法)
- 本节核心总结（必看）
- 结语
导语
大家好呀～上一节3.5我们全面学习了TCP，知道了TCP通过序号、确认、重传、滑动窗口等机制实现了可靠数据传输，还通过接收窗口实现了流量控制。但是，TCP还有一个更宏大的挑战------拥塞控制（Congestion Control）。
什么是拥塞？通俗类比：就像城市的交通------如果路上的车太多，超过了道路的承载能力，就会堵车，大家都走不动。网络中的拥塞也是一样：当太多发送方同时以太高的速率发送数据时，路由器的缓冲区会被填满，数据包开始排队、延迟增加，甚至被丢弃。
你可能会问：3.5节不是已经有流量控制了吗？流量控制和拥塞控制有什么区别？记住这个关键区别：流量控制是端到端的问题 ------发送方太快，接收方处理不过来；拥塞控制是网络中的问题------发送方太快，中间路由器处理不过来。一个是"收件人拿不动"，一个是"快递中转站爆仓"，完全是两码事。
这一节我们先不深入TCP具体的拥塞控制算法（那是3.7节的内容），而是从原理层面理解：拥塞到底是怎么发生的？它有什么代价？拥塞控制有哪些基本方法？准备好了吗？让我们开始～
一、3.6.1 拥塞原因与代价
教材通过三个逐步复杂的场景来分析拥塞的原因和代价。每个场景都比上一个更接近真实网络，我们一个个来看。
场景一：两个发送方，一个路由器，无限大缓冲区
场景设定 ：有两个发送方（A和B），它们的数据都要经过同一个路由器R，然后分别到达各自的接收方。路由器的输出链路容量是R。假设路由器的缓冲区是无限大的------永远不会丢包，只是排队。
我们来分析这个场景的性能。假设每个发送方的发送速率是λ_in（单位：数据包/秒）。那么路由器的输入速率就是2λ_in，输出速率是R。
当2λ_in < R时：输入速率小于输出能力，数据包到了路由器立刻就能发出去，几乎没有排队延迟。每个发送方的吞吐量（实际成功交付的速率）就是λ_in，一切正常。
当2λ_in接近R时：输入速率接近输出能力，路由器开始出现排队。数据包需要在缓冲区里等一会儿才能被发送，延迟开始增加。但因为缓冲区无限大，不会丢包，所以吞吐量还是λ_in------只是延迟变大了。
当2λ_in > R时：输入速率超过了输出能力，路由器的队列会越来越长，延迟趋向于无穷大。虽然吞吐量还是R/2（每个发送方分到一半），但每个包要等超级久才能到------这就像堵车了，虽然车最终都能过去，但每辆车都要堵几个小时。
场景一的代价 ：拥塞的第一个代价是排队延迟增加。虽然没有丢包，但数据包在路由器缓冲区里排队等待的时间越来越长，端到端延迟急剧上升。这就像高速公路上车多了，虽然不会追尾（不丢包），但大家都在龟速爬行。
场景二：两个发送方，一个路由器，有限缓冲区，会重传
场景设定 ：和场景一类似，但路由器的缓冲区是有限的------满了之后新来的包会被丢弃。发送方使用可靠传输（超时重传），丢了的包会重传。
这个场景更接近真实网络。我们来分析性能：
当发送速率较低时，和场景一一样，没有拥塞，吞吐量等于发送速率。
当发送速率增加到一定程度，路由器缓冲区开始排队，偶尔会有包因为缓冲区满而被丢弃。发送方发现超时后，会重传这些包。
这里出现了一个关键问题：重传会加剧拥塞！本来网络就已经堵了，发送方还在重传丢了的包，相当于往已经爆满的中转站再塞更多包裹，导致更多的包被丢弃，然后更多重传......形成恶性循环。
更糟糕的是，发送方无法区分一个包是真的丢了，还是只是延迟比较大。如果包只是排队久了一点，发送方等不及就重传了，那么原始包和重传包都会到达接收方，接收方会丢弃重复的包------这就造成了不必要的重传，白白浪费了带宽。
场景二的代价：
- 丢包：缓冲区满了之后，新来的包被丢弃。
- 重传浪费：发送方重传丢失的包，进一步加剧拥塞。
- 不必要的重传：因为超时时间设得不合理，把延迟大的包当成丢了来重传，浪费带宽。
教材中有一个经典的图：随着发送速率增加，吞吐量先线性增长，然后达到一个峰值，之后反而下降！为什么会下降？因为当发送速率太高时，大量的包被丢弃和重传，实际成功交付的数据包反而减少了------很多带宽被重传的包浪费了。这就是拥塞的"反噬效应"：越使劲发，实际收到的越少。
场景三：四个发送方，多跳路径，有限缓冲区
场景设定：四个发送方，数据经过多个路由器（多跳路径），每个路由器缓冲区有限。发送方使用可靠传输和超时重传。
这个场景最接近真实网络。除了场景一和场景二的问题外，还出现了新的拥塞代价：
代价一：多跳浪费。一个数据包可能已经经过了好几跳路由器，在最后一跳因为缓冲区满被丢弃了。那么前面几跳为传输这个包所消耗的带宽和路由器处理能力全部白费了！这就像你快递已经到了你们城市的分拣中心，结果在派送的时候丢了------前面从发货到分拣中心的运输全部白忙活了。
代价二：不公平性。在多跳网络中，不同的流可能经过不同数量的拥塞路由器。经过更多拥塞路由器的流，更容易丢包，从而降低发送速率；而经过较少拥塞路由器的流，可能占据更多带宽。这导致了带宽分配的不公平------不是按需求分配，而是按"谁的路径更顺"分配。
代价三：拥塞扩散。一个路由器的拥塞可能导致上游路由器的缓冲区也被填满（因为下游发不出去，上游的包只能在自己的缓冲区里等着），拥塞像多米诺骨牌一样向四周扩散。
三个场景的总结
让我们把三个场景的拥塞代价汇总一下：
| 场景 | 缓冲区 | 主要代价 |
|---|---|---|
| 场景一 | 无限大 | 排队延迟增加 |
| 场景二 | 有限，会重传 | 丢包 + 重传浪费 + 不必要重传 |
| 场景三 | 有限，多跳 | 多跳浪费 + 不公平性 + 拥塞扩散 |
从这三个场景可以看出，拥塞的代价是巨大的：延迟增加、吞吐量下降、带宽浪费、不公平。所以，我们需要拥塞控制机制来避免或缓解拥塞。
二、3.6.2 拥塞控制方法
既然拥塞有这么多危害，那怎么控制呢？教材把拥塞控制方法分为两大类：端到端拥塞控制（End-to-End Congestion Control）和网络辅助的拥塞控制（Network-Assisted Congestion Control）。
1. 端到端拥塞控制
端到端拥塞控制的核心思想：网络层不提供任何明确的拥塞反馈，运输层（主要是TCP）通过自己观察网络行为来推断是否发生了拥塞，然后采取相应的措施。
TCP怎么推断拥塞呢？主要通过两个信号：
- 丢包：如果出现了超时或收到3个重复ACK，说明可能有包丢了，而丢包通常是由路由器缓冲区溢出导致的------这就是拥塞的信号。
- 延迟增加：如果RTT（往返时间）开始增大，说明数据包在路由器里排队的时间变长了------这也是拥塞的早期信号。
当TCP推断出拥塞时，它会怎么做？降低发送速率 ！具体来说，就是减小拥塞窗口（Congestion Window，cwnd）的大小。拥塞窗口是TCP发送方维护的一个变量，它和接收窗口一起决定了发送方的实际发送速率：实际窗口 = min(cwnd, rwnd)。
端到端拥塞控制的优点：
- 不需要网络层支持：路由器不需要做任何特殊处理，只要正常转发和丢包就行。这也是为什么TCP能在因特网上广泛部署的原因------不需要升级所有路由器。
- 部署简单：只需要在端系统（发送方和接收方）上实现，中间网络不用改。
端到端拥塞控制的缺点：
- 反应慢：发送方只能通过丢包或延迟来"猜测"拥塞，等发现拥塞时，拥塞可能已经很严重了。
- 不够精确：丢包不一定都是拥塞导致的（也可能是链路噪声），延迟增加也不一定意味着拥塞。
TCP的经典拥塞控制（慢启动、拥塞避免、快速恢复）就是端到端拥塞控制的典型代表，我们会在3.7节详细学习。
2. 网络辅助的拥塞控制
网络辅助的拥塞控制的核心思想：路由器参与拥塞控制，主动向发送方提供拥塞状态的反馈。
网络辅助的拥塞控制有两种主要的反馈方式：
方式一：路由器直接给发送方发反馈
当路由器检测到拥塞时，直接给发送方发送一个特殊的控制报文（比如ICMP源抑制报文），告诉发送方"我这里堵了，你慢点发"。这种方式比较直接，但在实际中很少使用------因为路由器本身就很忙，还要额外发控制报文，而且ICMP报文可能被防火墙过滤。
方式二：路由器在数据包中标记拥塞信息
这是更常见的方式。路由器在转发数据包时，在数据包的某个字段中标记一个"拥塞位"，接收方收到这个被标记的包后，在回给发送方的ACK中也带上拥塞标记，发送方看到后就知道网络拥塞了，于是降低速率。
这种方式的典型代表就是显式拥塞通告（Explicit Congestion Notification，ECN）。ECN使用IP首部中的两个位来标记：
- 00：不支持ECN
- 01或10：支持ECN，但未发生拥塞
- 11：发生了拥塞（CE，Congestion Experienced）
当路由器拥塞时，它把经过的数据包的ECN位标记为11。接收方收到后，在TCP首部中设置ECE（ECN-Echo）标志位，通过ACK告诉发送方。发送方收到ECE后，就像收到丢包信号一样降低发送速率。
网络辅助拥塞控制的优点：
- 反应快：路由器一检测到拥塞就立刻标记，发送方可以在丢包发生之前就开始降速，避免了丢包带来的性能损失。
- 更精确：路由器最清楚自己的队列状态，它的反馈比端系统的猜测更准确。
网络辅助拥塞控制的缺点：
- 需要网络层支持：所有经过的路由器都必须支持ECN标记，否则端到端的ECN就无法工作。这在异构网络中部署比较困难。
- 部署成本高：需要升级路由器固件，运营商可能不愿意做。
不过，随着数据中心网络和5G网络的发展，网络辅助的拥塞控制越来越受到重视。比如数据中心中使用的**DCTCP（Data Center TCP）**就严重依赖ECN来实现低延迟和高吞吐。
3. 两种方法的对比
| 对比项 | 端到端拥塞控制 | 网络辅助拥塞控制 |
|---|---|---|
| 拥塞感知 | 通过丢包/延迟推断 | 路由器直接反馈 |
| 反应速度 | 慢（丢包后才知道） | 快（拥塞初期就知道） |
| 网络层支持 | 不需要 | 需要（ECN等） |
| 部署难度 | 低（只改端系统） | 高（需要改路由器） |
| 典型代表 | TCP Reno/CUBIC | ECN、DCTCP、ATM ABR |
| 准确性 | 较低（丢包≠拥塞） | 较高（路由器直接感知） |
在实际的因特网中，这两种方法是共存的。TCP默认使用端到端拥塞控制（通过丢包检测），同时也支持ECN（如果两端和中间路由器都支持的话）。3.7节我们会看到，TCP的拥塞控制算法主要是端到端的，但也融入了网络辅助的思想。
本节核心总结（必看）
这一节我们从原理层面理解了拥塞控制。核心要点如下：
一、拥塞的原因
- 太多发送方同时以太高速率发送数据
- 路由器缓冲区被填满，数据包排队、延迟增加、甚至丢弃
- 重传机制会加剧拥塞，形成恶性循环
二、拥塞的代价（三个场景）
- 场景一（无限缓冲区）：排队延迟增加，吞吐量不变但延迟趋向无穷
- 场景二（有限缓冲区+重传）：丢包 + 重传浪费 + 不必要重传，吞吐量可能随发送速率增加而下降
- 场景三（多跳+有限缓冲区）：多跳带宽浪费 + 不公平性 + 拥塞扩散
三、拥塞控制的两大类方法
- 端到端拥塞控制：TCP通过丢包/延迟推断拥塞，自己降速。不需要网络支持，部署简单，但反应慢。
- 网络辅助拥塞控制：路由器通过ECN等机制主动反馈拥塞状态。反应快、精确，但需要网络支持，部署成本高。
关键概念清单
- 拥塞（Congestion）：网络中数据包过多导致性能下降的现象
- 吞吐量（Throughput）：实际成功交付的数据速率
- 排队延迟（Queuing Delay）：数据包在路由器缓冲区等待的时间
- 重传（Retransmission）：丢失的数据包被重新发送
- 端到端拥塞控制（End-to-End Congestion Control）：端系统自己推断和应对拥塞
- 网络辅助拥塞控制（Network-Assisted Congestion Control）：路由器参与反馈拥塞状态
- 显式拥塞通告（ECN）：在IP首部标记拥塞信息的机制
- 拥塞窗口（cwnd）：发送方因拥塞控制而限制的窗口大小
结语
这一节我们理解了拥塞的本质和危害，以及拥塞控制的两大类方法。拥塞是网络的"癌症"------它不会直接让网络崩溃，但会让性能急剧下降，让所有人都受害。而拥塞控制就是网络的"交通管制"------通过合理调节每个发送方的速率，让网络保持在高效运行的状态。
理解了这些原理之后，下一节3.7我们将深入学习TCP具体的拥塞控制算法------慢启动（Slow Start）、拥塞避免（Congestion Avoidance）、快速恢复（Fast Recovery），也就是著名的TCP拥塞控制四阶段（加上快速重传）。这部分是TCP的灵魂，也是面试和考试的绝对重点，让我们带着这一节的原理基础，去看看TCP是怎么把这些思想落地的吧！
如果你觉得这篇笔记对你有帮助，欢迎点赞收藏～有问题也欢迎留言讨论，我们一起进步！