TCP可靠传输与拥塞控制：从rdt到滑动窗口的协议设计逻辑

讲实话，《计算机网络：自顶向下方法》这本书的第三章，是所有啃计算机网络的人公认的一道坎。前面两章讲协议分层、应用层的时候，你还能靠“HTTP发请求、DNS查域名”这种日常经验找到代入感，但一到传输层，课本突然开始塞给你一堆“序列号、确认号、超时重传、拥塞窗口”。很多人就是在这里放弃的，或者靠着背题和记答案勉强熬过期末，转头就忘得一干二净。

这次分享是第三章的第二篇，内容从可靠数据传输协议的设计逻辑开始，一路讲到TCP的可靠传输、流量控制，再到拥塞控制。如果你正在备考408、期末考或者技术面试，又刚好卡在TCP这一块，那这篇应该能帮你把那些“看着就头大”的机制串成一条线。先说清楚，这篇不是教材的浓缩版，我会把每个设计背后的动机、常见考法和实际抓包的表现都摊开讲，适合认真搞懂协议，而不是光想背个应付的结论。

1. 先认清第三章的整体框架：为什么它比前两章难一截

先说个总体的感受：第三章在一本自顶向下的书里，是少有的“自底向上”讲协议的章节。前面应用层你只要知道HTTP报文长什么样、Cookie干嘛的，基本就能做题，但传输层不一样，你必须理解，一个协议为什么被设计成这个样子。课本花大量篇幅讲“可靠数据传输机制”，就是让你看到UDP到TCP之间，站着多少个必须解决的问题，每个问题又是被哪一类机制解决的。

1.1 第三章到底在讲什么

第三章的核心是两件事：UDP和TCP。其中TCP占了绝对大头，而TCP的本质，就是“在不可靠的IP网络上实现可靠的数据传输”。为了说清楚TCP，教材先从最简单的抽象模型开始，逐步往里面加需求，这个过程就是rdt协议家族（rdt 1.0到rdt 3.0）。你看完这一小节，才明白TCP里的序列号、确认号、定时器、重传，没有一样是拍脑袋加的，全部是“被逼出来的”。

传输层还有一个重要概念叫多路复用与多路分解，这个在前面应用层访问Web服务时你已经见到过了。一个主机上同时跑着浏览器、邮件客户端、视频通话，这些流量到了传输层是怎么被区分开的？靠的就是源端口和目的端口。这个在上篇已经细致聊过，这里就不重复了。这篇我们从“怎么保证数据不丢不错不乱序”这个问题切入。

1.2 学这一章最忌讳的思维方式

我见过太多人学TCP，一上来就死记“四次挥手谁先发FIN、TIME_WAIT要等2MSL”，完全不问为什么。结果面试的时候，面试官只要稍加变化，“你能说说为什么要TIME_WAIT吗？”就卡壳了。第三章真正厉害的地方，就是逼你去回答这些“为什么”。

我自己复习时的做法是：每学一个新机制，就在笔记本上写一栏“这个机制解决了什么问题，如果不加会怎样”。比如定时器，如果不加会怎样？分组丢失了，发送方永远等不到ACK，接收方也一直等不到数据，两边就干瞪眼。没有序列号会怎样？如果ACK丢失了然后重传，接收方没法判断这是不是同一个分组。带这个视角去读第三章，你会发现整章其实是一道推理题，每一步都严丝合缝。

2. 可靠数据传输协议的设计逻辑：rdt家族的演进，像在打补丁

第三章的核心章节之一，就是用“有限状态机”一步步构造可靠数据传输协议。第一次看很多人觉得抽象，其实它特别像一个项目按需迭代的过程：第一版只跑在完美信道上，第二版发现信道会出差错，第三版又发现信道还会丢包。每加一个需求，你就得在旧的协议上打一个补丁。

2.1 rdt 1.0到rdt 3.0：每次加需求就是一次架构升级

• rdt 1.0：假设信道完全可靠。发方只管发，收方只管收，状态机只有两个状态。这个版本没什么实际意义，纯粹当基准线。
• rdt 2.0：信道可能出现比特差错。这时引入了ACK和NAK。接收方收到正确分组回ACK，错误分组回NAK，发送方收到NAK就重传。这是最简单的“停等协议”，发一个、等一个。
• rdt 2.1：发现一个新问题——ACK或NAK本身也可能损坏。如果发送方收到一个损坏的ACK，该怎么处理？解决办法是给数据分组加序列号。这样即使确认丢了，发送方重传后，接收方也能靠序列号发现“这是重复分组”，然后丢弃它，并且再发一次ACK。
• rdt 2.2：进一步优化，把NAK去掉，只在正确收到分组时返回带序列号的ACK。如果发送方在一个超时周期内没等到预期的ACK，就默认分组出问题了，直接重传。这就是“确认+超时重传”的最早模型。
• rdt 3.0：信道还会丢包。丢包靠什么发现？靠超时。于是给发送方加了定时器，如果超时仍没收到ACK，就重传当前分组。走到这一步，你已经把TCP可靠传输的核心骨架都看完了。

很多教材直接跳到TCP，跳过rdt，这其实很可惜。你一旦自己手推一遍rdt 2.1为什么需要序列号、rdt 3.0为什么需要计数器，TCP里那些“为什么”就答上了一半。我当年考研时，这道题就是大题：画状态图，补全事件处理逻辑，或者谈“能处理乱序吗？能处理重复分组吗？”所以不要觉得rdt很鸡肋，它就是把TCP的肌肉解剖给你看。

2.2 停等协议的性能瓶颈：为什么我们必须引入流水线

rdt 3.0功能上已经“可靠”了，但性能上有一个致命问题：它是停等的。发一个分组，等一个RTT，收到ACK再发下一个。在一个大带宽、长延迟的链路上，这种协议浪费得令人发指。

咱们算一下经典例子。链路带宽1 Gbps，端到端传播延迟15 ms，分组大小1000字节（8000比特）。发送一个分组需要的时间是：

8000 bit / (10^9 bit/s) = 8 微秒

但分组发出去后，要经过15毫秒才能到对端，再经过15毫秒才能收到ACK。也就是说，发送方在整整30毫秒里，只“忙”了8微秒。利用率大约：

8 / (8 + 30000) ≈ 0.00027

也就是0.027%，连千分之一都不到。如果你这时候在追剧看视频、或者SSH远程传文件，等一个分组确认再发下一个，体验会糟糕到什么程度，可以自己想象。

解决思路就是“流水线”：允许发送方在没收到ACK的情况下，连续发出多个分组。这就要引入“滑动窗口”。以窗口长度W为例，同样的条件下，利用率大约变成：

(8 x W) / (8 x W + 30000)

只要把W设成几千，利用率立刻就能拉到接近1。TCP之所以快，核心就是它不再傻等，而是用窗口灌水。

2.3 两种窗口协议：GBN和SR，各有一笔账要算

流水线协议有两大类：回退N步（GBN，Go-Back-N）和选择重传（SR，Selective Repeat）。

GBN的思路是“一个丢包，全部重来”。发送方维护一个窗口，只要窗口没满就继续发；一旦某个分组的定时器超时，发送方就把这个分组以及它后面的所有分组全部重传。接收方那边的设计也配合这个思路——只按序接收，乱序到达的分组直接丢弃，并且给最后一个按序接收的分组重发ACK。

GBN的优点是实现简单，接收方缓存几乎为零；缺点也显而易见，大量重传会造成浪费，尤其窗口一大、链路一长，一次丢包可能带来一整轮无意义的流量。SR的思路则是“谁丢的补谁”。发送方每个分组都有自己的定时器，接收方把乱序到达的分组先暂存在本地，等到缺失的序列号到达之后再统一按序交给上层。SR对带宽友好，代价是接收方要做缓存、管理乱序分组，复杂度大大提升。

实际TCP既不完全GBN也不完全SR，它更像一个滑动窗口协议加上了累积确认，还允许接收方通告窗口上限。你可能在期末题或面试里看到“TCP属于GBN还是SR”这个问题，标准说法是：TCP的确认机制是累积确认，默认丢包时重传第一个未确认的分组，这是GBN特征；但TCP接收端又会缓存乱序到达的报文，这又是SR的特征。到后面的SACK选项，就更加偏向SR了。所以别把TCP硬套进某一个模型，教材用这两个协议是为了帮你理解取舍，不是让你贴标签的。

3. 从理论到实践：TCP的可靠传输与流量控制

rdt那套理论是骨架，落到TCP协议里，又加了很多工程化细节。这一节我们把TCP的报文段结构、序列号、确认号、超时机制、流量控制挨个拆开看。

3.1 TCP报文段：头部每个字段都不是白给的

TCP首部最重要的几个字段：源端口、目的端口、序号、确认号、首部长度、标志位（URG/ACK/PSH/RST/SYN/FIN）、接收窗口、校验和、紧急指针，以及可选的选项字段。

很多初学者分不清“序号”和“确认号”的语义。TCP是面向字节流的，不是面向报文的。也就是说，TCP把应用层下来的数据看作一串字节，每个字节在连接里都编了号。序号的值为“本报文段第一个数据字节在整个字节流中的编号”。比如序号是1000，报文段携带了100字节，那么这个报文段覆盖的字节范围就是1000到1099。确认号则代表“我想要的下一个字节的序号”，也就是说，接收方已经正确收到了该序号之前的所有字节。所以确认号1000，意味着0到999字节都收到了，下一个希望收到1000。

这就是累积确认的含义。累积确认的好处是，即使某个ACK丢了，只要后面有更新的ACK到达，发送方就知道前面的数据也没问题。反过来它也有个弱点——如果序号靠前的报文丢了，后面的报文即使到达，接收方也只能发重复ACK。TCP快重传就是靠几个重复ACK来判断丢包，这个后面细说。

3.2 TCP超时与RTT估计：为什么不能用固定超时

rdt 3.0里我们假设超时时间是个给定的常数，但真实网络环境里，RTT是波动的。发一个分组到千里之外和到同一机房，延迟差别巨大。如果超时设太短，网络稍微慢一点就重传，白白增加负载；设太长，真丢包的时候又要干等很久。

TCP的做法是动态估计。每收到一个ACK，就拿到一个样本RTT（SampleRTT），用指数加权移动平均来更新估计值：

EstimatedRTT = (1 - α) × EstimatedRTT + α × SampleRTT

课本里α取0.125，也就是新的样本只贡献12.5%的权重，历史值保持87.5%。这样RTT的估算变化很平滑，不会因为一次网络抖动就剧烈波动。

但只估计均值还不够，因为超时时间必须比均值大，还得留出波动的余量。所以TCP又引入偏差估计：

DevRTT = (1 - β) × DevRTT + β × |SampleRTT - EstimatedRTT|

β取0.25，表示最近一次偏差在整体偏差里占25%权重。最后的超时时间就是：

TimeoutInterval = EstimatedRTT + 4 × DevRTT

这个公式的含义是：超时时间设在均值的上方，高出4倍的标准偏差。网络越稳定（DevRTT小），超时越贴近均值；网络越波动，超时自动放宽。很多面试题会问“为什么超时时间要动态调整”，你只要把这两个公式摆出来，再解释一句“固定超时无法适应网络动态变化”，这题就稳了。

3.3 流量控制：慢的一方说了算

流量控制是很多考生一知半解的地方。拥塞控制是防止网络被灌爆，流量控制是防止接收方缓冲区溢出。一个管中间的网络，一个管两端的接收缓存，完全是两码事。

TCP流量控制的关键是接收窗口rwnd。接收方在自己的报文段里填上rwnd，告诉发送方“我现在还能收多少字节”。发送方保证自己的已发送未确认字节数不超过接收方的rwnd，就不会把接收方的缓冲区灌爆。

TCP接收方的窗口是怎么算的？假设接收缓冲区总大小是RcvBuffer，接收方应用进程慢慢从缓冲区里读数据，读多少就腾出多少空间。如果接收方已经收到但还没被应用读走的字节数是lastByteRcvd - lastByteRead，那么：

rwnd = RcvBuffer - (lastByteRcvd - lastByteRead)

这里有个坑：如果接收方应用程序一直不读数据，rwnd就会变成0。那发送方是不是就永远停下来？TCP在这里有一个特殊规则——即使rwnd为0，发送方也要坚持发送一个字节的探测报文（persist timer），防止双方因为窗口更新报文丢失而永远死锁。这个点期末考试爱出选择题：“当接收窗口为0时，TCP发送方会怎么做”。答案就是继续发1字节的探测段。

3.4 快速重传与SACK：提高丢包恢复的效率

超时重传的问题在于等待时间太长。如果某个报文段丢了，但后续报文段都正常到达，接收方会不断发送对最后一个按序接收字节的重复ACK。发送方如果连续收到3个重复ACK，就能断定这个报文段丢了，不等超时，立刻重传。这就是快速重传。

为什么是3个而不是1个？因为包乱序也会导致重复ACK。收到1个重复ACK，很可能只是后面的包先到了，真正缺的包还在路上；但连续3个重复ACK说明，后面至少有三批数据都收齐了，缺的那个包大概率是真丢了。这是一个经验阈值，TCP把它定为3。

标准TCP用累积ACK时，接收方收到乱序包会先丢掉，但这很浪费。后来加了选择性确认（SACK）选项，接收方可以在ACK里明确告诉发送方“我收到了哪些乱序字节块”，发送方就能只重传真正缺失的部分。你已经可以看出来了，现代TCP越来越像SR协议。

4. 拥塞控制：这才是TCP的“护城河”

流量控制之后，第三章下半场全在讲拥塞控制。这部分的难度又上一个台阶，因为它不再是“传输层自己内部的问题”，而是要考虑整个网络的承载能力。看教材里那些TCP窗口演化图，第一眼头晕，但拆开看也就四个机制：慢启动、拥塞避免、快速恢复、超时处理。

4.1 拥塞的代价是什么

网络一旦拥塞，路由器上的队列会溢出，然后丢包。丢包对单个连接的影响是重传，但重传本身又会向网络注入更多流量，让原本就拥塞的网络雪上加霜。不用做任何复杂的推演，你就想象一个高速入口堵车，所有车都在鸣笛并按着喇叭想往前挤，结果只会更堵。

很多年前，TCP刚出来的时候没有那么强的拥塞控制，整个网络曾经出现过“拥塞崩溃”——吞吐量降到近乎为零。所以拥塞控制不是什么可选项，它直接关系到网络能不能稳定跑起来。

4.2 四个机制怎么配合

TCP拥塞控制维护两个关键变量：拥塞窗口cwnd和慢启动阈值ssthresh。发送方实际能发送的数据量由min(cwnd, rwnd)决定，rwnd是接收方的意愿，cwnd是网络承受能力的估计。

• 慢启动：连接刚建立时，cwnd从1个MSS开始。每收到一个ACK，cwnd就增加1个MSS。这样，每个RTT里cwnd翻一倍，呈指数增长。注意，慢启动并不是真的“慢”，它是从一个小窗口开始，让发送速率迅速上升，探明网络当前的承载能力。
• 拥塞避免：当cwnd达到ssthresh后，增长方式切换为线性。每个RTT只增加1个MSS，这个阶段叫拥塞避免。原因很直接——盲目的指数增长很快就会把网络灌爆，所以进入谨慎的试探。
• 丢包时的处理：如果发生超时，TCP认为网络已经严重拥塞，把ssthresh设为cwnd的一半，cwnd直接降到1个MSS，重新慢启动。如果是收到3个重复ACK，情况比超时乐观得多，说明还是有部分包能到达，TCP进入快速恢复。在快速恢复里，ssthresh设为当前cwnd的一半，cwnd先降到ssthresh+3个MSS，每再收到一个重复ACK就暂时增大1个MSS，收到新ACK后退出快速恢复，进入拥塞避免阶段。

这个“加性增、乘性减”（AIMD）的调整方式，是整个TCP拥塞控制的核心。线性增加是试探，丢包后砍半是惩罚，下次再慢慢试探。整个系统就是在这种“激进的试探”和“保守的回退”之间找到平衡。

408和面试都很喜欢考一个点：给出cwnd和ssthresh的变化，让你画出TCP窗口随时间变化的锯齿图。我的建议是，别只背图，去理解每一次下降的原因。超时归零，三个冗余ACK减半。你要能口述“为什么这里下来、为什么那里陡增”，才算真懂。

4.3 端到端的公平性

TCP的公平性问题常被面试官拿来当加分题。假设同一个瓶颈链路连接10条TCP连接，RTT相同，它们的带宽会收敛到大致均分的状态。为什么呢？那些带宽占用多的连接，cwnd也大，下一次丢包时被砍掉一半的绝对值也大；占用少的连接，增长空间大、被砍得少。这种不对称的调节会让各个连接趋向均衡。

但公平性也有前提。如果两条TCP连接的RTT差很多，短RTT的连接能用更快的速度抬高cwnd，从而抢占更多带宽，整体并不公平。所以你会看到有人改成每RTT按比例增长窗口来缓解这个问题。能把“公平性”和“RTT不公平”聊到这一层，面试印象分基本就稳了。

5. 期末冲刺、408备考与面试八股的打法

第三章学到最后，最终还是要落到考试和面试上的。搜了“计算机网络期末复习”、“计算机网络八股文”、“湖科大教书匠”这些话题的人特别多，大家关心的问题基本一致：哪些是高频考点，怎么复习最省力。

5.1 期末与408的考点清单

先说408。第三章在大题里独树一帜，因为它是整张卷子里最可能出现“综合应用题”的章节。结合往年经验和教材习题，我建议按下面的清单过一遍：

期末复习的人，除了自顶向下第七版的课后题，还可以配合“湖科大教书匠”的讲解视频来加深理解，它的很多动画演示把滑动窗口的变化过程做得特别直观，适合第一遍看不懂教材的人。如果你时间紧，优先把“TCP报文段结构+三次握手+拥塞控制窗口演化”这三块吃透，能覆盖大半考点。

5.2 技术面试常见的“计算机网络八股”

面试里第三章的高频题，其实可以被归类为几个母题。你把母题答透，衍生题自然就顺了。

• TCP和UDP的区别：最基础的题，但要说到“可靠、面向连接、字节流、拥塞控制”这些层面，顺便提一嘴HTTP/3为什么要改用UDP。
• 三次握手为什么不能两次：核心逻辑是确认双方的接收和发送能力，以及防止历史重复连接初始化请求干扰。两次握手做不到让双方都确认对方收发正常。
• 为什么需要四次挥手：因为TCP是全双工的，每一方的连接关闭都要单独确认。你收到对方FIN后还能继续发数据，所以不能合成一次。
• TIME_WAIT为什么是2MSL：保证最后一个ACK如果丢失，对方还有机会重发FIN。同时也让网络中残留的旧连接报文段彻底消失。这是必考送命题。
• TCP怎么保证可靠：六板斧——校验和、序号、确认、超时重传、流量控制、拥塞控制。全部说出来再逐个展开，基本满分。
• 流量控制和拥塞控制的区别：一个是接收方容量问题，一个是网络容量问题，窗口一个是rwnd、一个是cwnd，发送上限是两者较小值。
• 快速重传的原理：三个重复ACK触发，不等超时。要能说清为什么不是1个。
• TCP粘包是什么：TCP是字节流协议，边界需要上层自己划分。UDP面向报文则不会出现这个经典问题。

八股文不是不能背，重点是背完之后能解释。我自己面很多候选人的时候，最讨厌听到的就是“TCP可靠是因为有确认和重传”，然后没有然后了。你多问一句“确认号代表什么？累计确认有什么缺点？”大多数人就卡住了。所以复习时一定多往深挖一层。

5.3 用抓包验证你学到的东西

最后给一个我非常推荐的实操环节：用Wireshark或者tcpdump验证刚学的理论。很多人学完第三章只会在纸上画窗口，从来没有真正“看见”过TCP的行为，这是很可惜的。

本地起一个简单的HTTP服务或者直接访问一个网站，然后抓包：

bash复制sudo tcpdump -i eth0 -A 'tcp port 443'

你能在抓包里看到客户端的SYN、服务端的SYN-ACK、随后的ACK，这就是三次握手。再看抓包里的TCP头部，你能直接看到Seq和Ack字段都在跳，Received Window也在变。配合“界面里的TCP Stream”功能，你甚至可以看一次完整的连接建立、传输、断开过程。如果你拿一个大文件下载，慢启动阶段你能看到窗口不断翻倍，直到出现重传把窗口打回原形。理论瞬间变得立体，比看十遍书都管用。

大学里还有一类“头歌”实训平台，上面有一些关于TCP首部解析、UDP校验和计算、拥塞控制窗口演化的实训题。那种题不用去搜现成答案，因为答案本身没什么价值。真正能帮到你的，是你自己用Python拆一下一个TCP报文段，或者认真画一遍cwnd的演化图。这个画一遍比看十遍都顶用。

结语：TCP是一门“环环相扣的工程学”

第三章读完，我的体会是：计算机网络里没有哪个协议是凭空设计的，TCP的每个字段、每个定时器、每条状态转换规则，都是前面某个问题“逼”出来的。你从缺口出发去看协议，一切都会变得顺理成章。反过来，如果你只盯着结论看，那就只能被一堆细节淹没，考完就忘。

如果时间有限，我建议你把重心压在两个地方：第一，把rdt到TCP这条主线捋一遍，搞清楚可靠传输为什么需要序号、确认、重传，这是所有后续机制的底座；第二，把拥塞控制的窗口演化图画熟练，并能解释每个拐点为什么存在——这是面试和考研的常客，也是你和其他学习者拉开差距的地方。

为什么选这本书当教材的人特别多？也恰恰是因为它不让你死记，而是通过“自顶向下”的方式，让你从应用出发，一层一层往下挖到传输层的核心。只要你能跟着这本书把第三章啃下来，后面TCP/IP、HTTP/2、QUIC这些内容学起来都会轻松很多。

最后分享一个小经验：学协议时，别急着追新概念，先回到“如果去掉这个机制，会发生什么”的基本问题。这个方法帮我自己搞懂了TCP，希望也能帮你少走弯路。