TCP拥塞控制核心算法与窗口变化详解

TCP拥塞控制这块我在复习计算机网络时总觉得它比三次握手难啃。三次握手好歹是固定流程背下来就能应付考试拥塞控制却是一堆算法、窗口、阈值的博弈而且教材里讲的版本还不一样看谢希仁、看自顶向下、看王道细节各有出入越看越晕。后来反复推演了几遍又抓包看了实际数据才慢慢理顺。这篇就按我的理解把拥塞控制的来龙去脉、四种算法、窗口变化过程以及复习时容易踩的坑重新梳理一遍。不管是期末复习、考研408还是面试前突击都可以参考这个思路。我尽量用大白话把原理讲透再贴一些实际排查经验。1. 为什么TCP非要做拥塞控制1.1 拥塞的根源链路资源不是无限大的先说一个被我以前忽略的本质问题拥塞不是某一台主机出了问题而是整个网络路径上的某个环节过载了。路由器或者交换机的处理能力是有限的交换机背板带宽有限链路带宽有限当多条TCP连接同时往同一个出口挤数据时路由器里的缓存队列会堆满之后到达的数据包就只能被丢弃。这就是丢包的根源之一。丢包带来的连锁反应非常可怕。如果TCP没有拥塞控制机制发送方一股脑往网络里灌数据丢包之后只能靠超时重传重传的数据又继续加剧拥塞造成更多丢包最终形成“拥塞崩溃”。这不是理论推演早期互联网还真遇到过类似问题后来才引入了拥塞控制相关的机制。所以拥塞控制的本质任务是发送方主动探测网络的可用容量限制自己往网络里发送的速率让整条链路保持在一个“能吞得下”的水平。1.2 流量控制和拥塞控制别搞混了这俩名字太像考试和面试都爱混着问。我用最简单的方式区分流量控制Flow Control管的是发送方和接收方之间的事。接收方处理不过来就在TCP首部的窗口字段里告诉发送方“你慢点发”窗口大小由接收方的缓存空闲程度决定。这属于点对点的“上下游协调”解决的是“接收方吃不吃得下”的问题。拥塞控制Congestion Control管的是发送方和整个网络之间的事。网络中间的路由器拥塞了TCP无法直接感知只能通过丢包或延迟变化来推断网络状态从而主动调整发送速率。这属于“全网协作”解决的是“中间链路受不受得了”的问题。可以把流量控制理解成你家楼下的快递柜满了快递小哥不再塞件而拥塞控制是整条送货路线上的分拣中心爆仓了快递公司主动限制发货数量。两种场景的应对完全不在一个层级。1.3 拥塞控制的核心设计目标效率与公平拥塞控制背后有两个设计目标很多人复习时没意识到但理解了这两个目标后面算法就好懂了。第一个是效率。网络链路空闲时要把利用率拉上去链路拥塞时要快速降速拥塞缓解后再慢慢提速。整个过程其实就是一条“增大——探测——降速——再增大”的曲线。第二个是公平性。如果同一条瓶颈链路上有多条TCP连接不能因为某条连接先启动就把带宽全占满。TCP用“加性增”的机制让各连接在稳态时近似公平地分享带宽。这个“公平”不是绝对的数学公平而是大致按比例分配实际效果非常符合直觉。2. 拥塞控制的四种算法拆解TCP拥塞控制的完整方案由四个算法组合而成分别是慢启动、拥塞避免、快重传、快恢复。这一套组合拳从1988年提出后不断演进目前主流版本都基于RFC 5681的框架。先记住两个核心参数cwnd拥塞窗口发送方自己维护的状态变量单位是MSS最大报文段长度。发送窗口大概等于min(cwnd, rwnd)。ssthresh慢启动阈值它是慢启动和拥塞避免之间的“分界线”。2.1 慢启动先小步试探再指数爬坡慢启动这个名字特别容易误导初学者。第一个误区是觉得“慢启动”就是慢慢发其实不然它的增长方式非常激进。连接刚建立时cwnd初始值很小。早期TCP实现把初始拥塞窗口设为1个MSS最新RFC 6928建议把初始窗口提高到10个MSS大约14KB左右实际Linux系统也按10个MSS左右设置。因为TCP不知道网络能承受多大流量只能从一个较小的值开始探测这叫“小步试探”。启动之后每收到一个ACKcwnd就增加1个MSS。不要小看这个“每ACK加1”它是等比增长的第一次发送1段收到1个ACK后cwnd变成2下一轮发2段收到2个ACK后cwnd变成4再下一轮发4段收到4个ACK后cwnd变成8。所以虽然名字叫“慢启动”实际窗口大小是指数增长的。如果网络通畅几个RTT内就能把窗口顶上来。为什么叫“慢”呢它是相对于TCP早期那种一上来就灌满整个接收窗口的方案而言的。慢在“初始”不在“过程”。慢启动什么时候结束有三个退出条件发生超时重传说明网络扛不住了ssthresh降到当前cwnd的一半cwnd重置为初始值重新开始慢启动。cwnd达到ssthresh说明按指数增长的方式已经不太合适了转入拥塞避免阶段。收到3个重复ACK触发快重传机制进入快速恢复流程。2.2 拥塞避免从指数改成线性拥塞避免阶段做的事情很简单把窗口的增长方式从“每收到ACK加1MSS”改成“每个RTT加1MSS”。需要特别说明的是拥塞避免的“避免”不是说不发生拥塞而是在接近网络容量上限后不能再莽撞地加倍增长要用线性增长探路。因为指数增长在链路还很空闲时效率很高但一旦逼近拥塞点加倍试探代价太大极容易直接把网络打爆。线性增长每次只增加1个MSS相当于缓慢探头稳扎稳打。理想情况下cwnd会沿着一条线性斜坡持续上升直到碰到拥塞点。拥塞信号有两个来源超时重传这个信号很严重说明不仅是丢包可能连ACK都丢了网络状态比较糟糕。处理方式是ssthresh cwnd / 2cwnd 初始值重新进入慢启动。收到3个重复ACK这个信号相对轻一些说明网络还能把数据送回来只是某个段丢了但后续的数据都到达了接收方。处理方式是进入快重传和快恢复。2.3 快重传与快恢复把丢包的损失控制到最小先理解什么是重复ACK。假设发送方发出去1、2、3、4、5五个报文段其中段3丢了。接收方收到段2之后按序期待段3但收到的却是段4TCP不能乱序交付只能再次确认“我等的还是段3”。于是段4到达后接收方会再发一次ACK3。之后段5到达接收方又会继续发ACK3。连续收到3个重复ACK算上第一次发出的那个一共4个ACK都是确认序号3发送方就能断定段3丢了。为什么需要快重传因为如果傻等超时往往要等一个RTO重传超时时间这个时间可能比正常RTT长很多。而重复ACK已经明确指认了哪个段丢了立刻重传它效率更高。快重传的触发条件就是连续收到3个重复ACK收到后立即重传丢失的报文段不必等超时。为什么是3个重复ACK而不是2个这是TCP设计里的一个很巧妙的折中。因为乱序也会导致重复ACK。比如段2先到了段3和段4还在路上接收方收到段2后发了一个ACK3接着段4先于段3到达接收方又会发一个ACK3。这种情况下收到少量重复ACK说明可能是乱序而不是丢包。如果收到3个重复ACK大概率是真的丢了。这个阈值是经验和工程权衡的结果不是严格的数学推导。快恢复是配合快重传用的。收到3个重复ACK后发送方会把cwnd减半ssthresh也设为减半后的值然后cwnd从减半后的值开始执行拥塞避免的线性增长。注意这个版本和早期版本不一样早期Tahoe版本遇到重复ACK也会把cwnd降到1重新慢启动后来Reno版本引入了快恢复才改为减半而非归零。现在考试和实际系统里一般以Reno和之后版本为准。2.4 四种算法的关系与触发条件汇总学到这里很多人会混淆四种算法之间的关系。其实它们的组合规则很清楚算法触发条件窗口变化对ssthresh的影响慢启动连接刚建立 / 超时重传后每收到ACKcwnd加1MSS指数增长超时时ssthresh cwnd / 2拥塞避免cwnd ssthresh每个RTTcwnd加1MSS线性增长不变快重传收到3个重复ACK立即重传丢失段cwnd临时减半再恢复不直接改ssthresh快恢复快重传之后cwnd ssthresh后的值继续线性增长ssthresh cwnd / 2这张表对期末简答题特别管用考试基本就是考这些触发条件和窗口变化。3. 拥塞窗口变化过程推演3.1 一次完整连接的窗口演变全过程光记算法不推演考场上一遇复杂题还是容易卡住。我平时复习时最喜欢画图但这里只能用文字描述。假设这样一组参数cwnd初始为1MSSssthresh初始为16MSS不考虑接收窗口限制。阶段一慢启动第1个RTT发送1个MSS收到ACK后cwnd2。第2个RTT发送2个MSS收到全部ACK后cwnd4。第3个RTT发送4个MSS收到全部ACK后cwnd8。第4个RTT发送8个MSS收到全部ACK后cwnd16。这时候cwnd已经从1涨到16正好碰到ssthresh进入拥塞避免。阶段二拥塞避免第5个RTT发送16个MSS收到全部ACK后cwnd17。第6个RTT发送17个MSS收到全部ACK后cwnd18。第7个RTT发送18个MSS收到全部ACK后cwnd19。第8个RTT发送19个MSS收到全部ACK后cwnd20。到这里网络一直很畅通cwnd线性爬坡。阶段三拥塞发生了假设第9个RTT发送20个MSS中间某些报文段丢失发送方收到3个重复ACK触发快重传和快恢复。处理过程是ssthresh更新为20 / 2 10cwnd调整为10然后进入拥塞避免阶段继续线性增长。如果后续没有再次拥塞cwnd会从10开始继续每个RTT加1MSS。但假设在第10个RTT之后发生的是超时重传处理就完全不同了ssthresh仍然减半为10但cwnd直接重置为1重新执行慢启动到新的ssthresh再转拥塞避免。这种推演的熟练度直接决定期末大题能不能得分。我建议用纸笔亲自画一遍比看任何网课都有效。3.2 教材里没细说的“约等于”细节复习时如果只看谢希仁教材有几个细节容易引发困惑实际工程实现又有差异第一初始窗口已经从1MSS变成了10MSS。考试题里如果明确说“初始为1MSS”按1算如果不提最新的Linux实现初始窗口约10段RFC 6928。408考试一般会给出参数不会让你猜。第二cwnd的单位是MSS不是字节。虽然它代表拥塞窗口但在实际发送时发送窗口 min(cwnd, rwnd)二者取小。考试计算题如果给了接收窗口一定别忘了比较。第三ACK的累积确认会让cwnd增长比理论值更快一些。比如慢启动阶段发送了2个MSS收到一个累积ACK确认了第2个段cwnd加1变成3但如果这两个MSS的ACK分别到达那么cwnd会加2变成4。教材通常按后一种理想情况计算实际情况可能略慢或略快。这个细节考试一般不追究但做实验抓包时会发现数字对不上不必太焦虑。第四快恢复过程中还有“暂缓增长”的细节。Reno版本进入快恢复后收到重复ACK时cwnd要临时增加1MSS收到新数据的ACK后再退出恢复状态。如果题目出得很细会把临时增加的部分也算进去。大多数期末题不会考到这一步但408真题偶尔会玩。4. 期末复习和实战排查中的高频问题4.1 期末/考研考点速记清单这节写给马上考试的朋友。挑了几个最常见的考点也是我以前反复记混的地方慢启动和拥塞避免的分界线是什么是cwnd与ssthresh的大小关系cwnd ssthresh时慢启动cwnd ssthresh时拥塞避免。发生超时重传后怎么处理ssthresh cwnd / 2cwnd重置为初始值1MSS或按题目给定值重新慢启动。收到3个重复ACK后怎么处理快重传进入快恢复ssthresh cwnd / 2cwnd ssthresh进入拥塞避免。为什么慢启动是“慢”的相对于最初未加限制直接灌满窗口的方案它初始值小需要逐渐探测。实际增长速率并不慢。另外还有一些高频面试追问比如“TCP怎么知道网络拥塞了” TCP本身不能直接感知路由器的拥塞状态它只能靠间接信号超时重传和重复ACK。超时往往意味着网络严重拥塞或链路中断重复ACK说明局部丢包但后续报文还在走程度相对较轻。还有一类比较新的考点公平性与TCP的Reno/BBR等算法对比。考试一般只要求传统Reno面试如果聊得深可以提一句“BBR通过测量瓶颈带宽和往返时延来规避丢包信号和传统基于丢包的算法思路不同”。作为了解即可别把BBR和Reno混在一起答题。4.2 实际抓包怎么看拥塞控制现象学习阶段光看书容易“纸上弹道”。如果环境允许可以用Wireshark或tcpdump抓包观察。做法很简单下载一个大文件同时抓包然后看TCP流的时序图。具体步骤# 抓取某个端口上的TCP流量 sudo tcpdump -i eth0 -w tcp_congestion.pcap tcp port 80下载完成后用Wireshark打开pcap文件在Statistics菜单里选“TCP Stream Graph” → “Time-Sequence GraphStevens”就能看到窗口随时间变化的曲线。正常情况下能看到明显的“慢启动指数抬升——线性爬坡——下跌”的锯齿状曲线。我实测过的现象是在丢包率比较低的内网环境曲线几乎是一条平滑的线性上升很难看到指数段因为初始窗口10MSS起步几十个RTT就到了ssthresh整个慢启动过程转瞬即逝。在弱网环境比如加了丢包模拟的网络里锯齿会非常明显每到一个尖峰就下跌循环往复。这个观察特别有助于理解“加性增、乘性减”的曲线形态。4.3 常见APP层TCP报错和拥塞控制的关系热搜词里出现了很多TCP相关的报错比如“curl: (35) TCP connection reset by peer”、“bind: address already in use”之类。这些大多数和拥塞控制没有直接关系但作为TCP学习者区分“链路拥塞”和“应用层错误”很重要。TCP connection reset by peer一般是对端应用程序把连接关掉了发送方收到RST。可能是对端进程崩溃、对端主动拒绝服务或者防火墙发送了RST不是拥塞控制触发的现象。bind: address already in use本地端口被占用TCP服务端起不来。这是因为TIME_WAIT或LISTEN状态占用了端口。解决办法是换端口或者设置SO_REUSEADDR选项。这属于Socket编程细节跟拥塞控制无关但非常常见顺手记录一下。网络下载慢、网页卡顿才可能和拥塞控制有关但也可能是应用层并发连接数不够、DNS解析慢、服务端处理慢等因素。排障时要先从端到端分层排查别一言不合就怪TCP拥塞控制。还有一个在Socket编程里常被问到的“TCP粘包问题”这里也顺带说清楚粘包是应用层消息边界问题TCP是字节流协议本身没有消息边界概念。拥塞控制影响的是“什么时候把数据发出去”粘包影响的是“收到数据后怎么切分业务消息”两者根本不在一个层面。如果你处理粘包只能想到sleep或强制flush那说明还没理解TCP的流式传输本质。正确做法是在应用层定义消息长度字段或者使用分隔符协议。这一块经常在简历项目中被追问值得单独深入。4.4 学习顺序推荐最后聊聊怎么学这块效率最高。我的个人建议先看谢希仁《计算机网络》中运输层的前半部分把三次握手、四次挥手、TCP报文段结构弄清楚然后把拥塞控制章节从头到尾读一遍不需要立刻背先理解来龙去脉再看一遍自顶向下那本教材里对应的章节重点看它的时序图之后开始画图从初始cwnd1画到自己设定的ssthresh推到拥塞发生画完整条线最后抓包验证一次这一步不进实验室也能做只要在电脑上抓一下普通网页访问就能看到大致的窗口走势。画图这一步比看网课管用。网课听了觉得会了一做题还是不会推自己手写一遍数字坑才会露出来。比如我第一次画的时候压根没意识到快恢复后cwnd应该等于ssthresh而保留了慢启动时的增长状态结果把后面的线性增长起点算错了。这种细节只有动笔才会发现。结尾在大学期间计算机网络这门课我很遗憾没有学得很深入直到后来做后端开发天天和TCP打交道才回过头来把运输层重新啃了一遍。我的体会是拥塞控制这块理解了“发送方通过丢包/延迟间接感知网络状态”这一条主线其他细节都能推导出来反过来死记硬背没几天就忘了。如果你正在复习期末或准备面试可以试着自己画一遍慢启动到拥塞避免的窗口变化图再把快重传和快恢复的流程完整描述一遍看能不能一气呵成。如果中间卡壳回看第3节的内容保证比单纯刷题效率高。TCP协议栈还有很多有趣的内容比如TIME_WAIT、Nagle算法、延迟确认、BBR拥塞控制算法多的不敢说后续可以慢慢写。