前言TCP是互联网上使用最广泛的传输层协议。它提供可靠传输、按序交付、流量控制、拥塞控制等能力。其中滑动窗口和拥塞控制是两个容易被混淆的概念它们都涉及窗口都影响发送速率但解决的问题完全不同。这篇文章把这两个机制拆开来讲清楚滑动窗口解决的是接收方能不能收得下拥塞控制解决的是网络能不能承受得住。理解这个分工就理解了TCP为什么能在不可靠的网络上实现可靠传输。一、为什么需要滑动窗口1.1 停止等待协议的效率问题最基础的可靠传输方式是停止等待发送方发一个数据包等待接收方确认ACK收到确认后再发下一个。这种方式逻辑简单但效率极低。假设发送方和接收方之间的往返时间RTT是50毫秒每个数据包大小为1KB那么理论最大吞吐量只有text1KB / 0.05s 20KB/s链路带宽可能远高于这个数值但停止等待协议无法充分利用。原因在于发送方大部分时间都在等待确认链路处于空闲状态。1.2 滑动窗口的基本思路滑动窗口的核心思路是允许发送方在收到确认之前连续发送多个数据包。发送方维护一个窗口窗口内的数据可以连续发送而不需要等待确认。每收到一个确认窗口向前滑动新的数据可以进入窗口并被发送。这样发送方不必每发一个包就停下来等确认链路的利用率大幅提升。二、滑动窗口的工作机制2.1 发送窗口与接收窗口TCP连接的两端各维护一个窗口发送窗口发送方可以连续发送而不需要等待确认的数据量。窗口大小由接收方通告的接收窗口rwnd和拥塞窗口cwnd共同决定取两者中的较小值。接收窗口接收方当前能够接收的数据量。接收方通过TCP头部的窗口字段将自己的接收窗口大小告知发送方。2.2 窗口的滑动过程假设发送窗口大小为4个数据段发送方连续发送段1、2、3、4接收方收到段1返回ACK确认段1发送方收到ACK后窗口向前滑动一个位置段5进入窗口并被发送接收方收到段2返回ACK确认段2发送方窗口再次滑动段6进入窗口并被发送这个过程持续进行窗口不断向前滑动数据持续发送。2.3 接收窗口的动态调整接收窗口的大小不是固定的。接收方的缓冲区可能被应用程序读取数据的速度影响如果应用程序读取数据快接收缓冲区空闲多接收窗口可以保持较大如果应用程序读取数据慢接收缓冲区被占满接收窗口会减小如果接收缓冲区完全占满接收窗口变为0发送方必须停止发送当接收窗口变为0时发送方会启动零窗口探测定期发送探测报文询问接收方窗口是否已恢复。这防止了双方陷入永久等待。2.4 流量控制的作用滑动窗口实现的流量控制核心目标是防止发送方发送速度超过接收方的处理能力。接收方通过动态调整窗口大小控制发送方的发送速率避免接收缓冲区溢出导致数据丢失。三、为什么需要拥塞控制3.1 流量控制解决不了的问题滑动窗口解决了接收方的处理能力问题但没有解决网络本身的问题。如果网络中的路由器或链路出现拥塞数据包会在路由器队列中排队延迟增加。当队列满时路由器会丢弃数据包。发送方检测到丢包后重传但重传会进一步加重网络负担形成恶性循环——这就是拥塞崩溃。流量控制只关注接收方不关注网络中间状态。如果发送方和接收方之间的网络出现拥塞即使接收方窗口很大发送方也不应该继续高速发送。3.2 拥塞控制的核心思路拥塞控制的目标是在没有明确网络状态反馈的情况下通过探测和调整找到一个不会导致网络拥塞的发送速率。TCP拥塞控制通过维护一个拥塞窗口cwnd来实现。发送方实际可以发送的数据量取接收窗口和拥塞窗口中的较小值text实际发送窗口 min(接收窗口rwnd, 拥塞窗口cwnd)拥塞窗口由发送方独立维护根据网络状况动态调整。四、拥塞控制的四个核心算法TCP拥塞控制包含四个相互配合的算法慢启动、拥塞避免、快速重传、快速恢复。4.1 慢启动连接建立初期发送方不知道网络的承载能力因此从一个较小的拥塞窗口开始探测。慢启动的规则是每收到一个ACK拥塞窗口增加一个MSS最大报文段长度。这意味着拥塞窗口随RTT呈指数增长1、2、4、8、16……慢指的是起点低而不是增长速度慢。指数增长使发送方能够快速探测到网络的可用带宽。慢启动设置了一个慢启动阈值ssthresh。当拥塞窗口达到ssthresh时慢启动结束进入拥塞避免阶段。4.2 拥塞避免进入拥塞避免阶段后拥塞窗口的增长方式从指数变为线性每个RTT拥塞窗口增加一个MSS。线性增长使发送方缓慢逼近网络的承载极限避免过快增长导致拥塞。这个阶段持续到检测到丢包为止。4.3 快速重传当接收方收到乱序的数据段时会立即发送重复ACK告知发送方某个数据段未到达。如果发送方连续收到三个重复ACK就判断该数据段丢失立即重传而不需要等待超时计时器到期。这显著缩短了丢包恢复时间。4.4 快速恢复快速重传后发送方进入快速恢复阶段将ssthresh设为当前拥塞窗口的一半将拥塞窗口设为ssthresh 33表示已收到的三个重复ACK每收到一个重复ACK拥塞窗口增加1收到新数据的ACK后拥塞窗口设为ssthresh进入拥塞避免快速恢复避免了慢启动的重新开始使发送方能够更快恢复到丢包前的发送速率。五、拥塞控制的演进5.1 TCP Tahoe与TCP Reno早期的TCP Tahoe在检测到丢包时无论超时还是快速重传都会将拥塞窗口重置为1重新进入慢启动。TCP Reno引入了快速恢复机制在快速重传后不重置窗口而是从ssthresh继续。这是目前大多数操作系统默认支持的版本。5.2 TCP NewRenoTCP Reno在多个数据包丢失的场景下存在局限。NewReno改进了快速恢复的处理逻辑能够在一个窗口内多个丢包时更准确地恢复。5.3 TCP CUBICCUBIC是目前Linux系统的默认拥塞控制算法。它使用三次函数代替线性增长使窗口增长曲线更平滑在高带宽、长距离网络高BDP场景中表现更好。5.4 BBRBBRBottleneck Bandwidth and Round-trip propagation time是Google提出的拥塞控制算法。它不依赖丢包作为拥塞信号而是通过测量瓶颈带宽和最小RTT来构建发送模型。BBR在长距离、高丢包的网络环境中表现突出。六、滑动窗口与拥塞控制的对比对比维度滑动窗口拥塞控制解决的问题接收方处理能力网络承载能力控制依据接收方通告的接收窗口发送方维护的拥塞窗口反馈来源接收方的窗口字段ACK、丢包、RTT变化调整方向接收方主动调整发送方主动探测目标防止接收缓冲区溢出防止网络拥塞崩溃实际发送窗口min(rwnd, cwnd)min(rwnd, cwnd)两者协同工作滑动窗口确保发送方不超过接收方的处理能力拥塞控制确保发送方不超过网络的承载能力。实际发送窗口取两者中的较小值任何一方成为瓶颈时发送速率都会被限制。七、总结TCP的可靠传输依赖两个核心机制滑动窗口实现了流量控制。发送方可以在收到确认前连续发送多个数据段窗口大小由接收方动态调整防止接收缓冲区溢出。拥塞控制实现了网络稳定性。发送方通过慢启动、拥塞避免、快速重传、快速恢复等算法动态调整拥塞窗口探测网络的可用带宽避免因发送速率过快导致网络拥塞崩溃。两者的关系可以概括为滑动窗口管接收方能不能收拥塞控制管网络能不能扛。实际发送窗口取两者中的较小值任何一方出现瓶颈发送速率都会相应调整。理解这个分工就理解了TCP为什么能在不可靠的网络上实现可靠传输。