我行我素123341. 项目概述：流量控制与可靠传输，到底在学什么
如果你正在啃《计算机网络》，不管是谢希仁的第九版、第八版，还是《自顶向下》那本厚得像砖头一样的经典教材，多半都会在一个地方卡住：传输层那一章。三次握手、滑动窗口、流量控制、拥塞控制，这些概念在书里一个接一个地出现，看起来都认识，合上书一问又说不清区别。尤其是"流量控制"和"可靠传输"这两个词，总是绑定在一起出现，但实际学起来却让人觉得像隔了一层纱。
这个专题想要解决的，就是把"流量控制"和"可靠传输"这一整条脉络彻底打通。它不是让你背几个名词，而是真正理解：数据在网络上传输时，发送方怎么知道数据到底有没有送到？接收方处理不过来时怎么让发送方停一停？网络本身就堵的时候发送方又该怎么办？这三个问题分别对应可靠传输、流量控制和拥塞控制，它们互相独立但又协同工作。
从知乎、考研圈的热搜来看，"三次握手"、"滑动窗口"、"慢启动"、"快重传"这些词搜索量一直很高，说明这是几乎所有人在学计网时都绕不开的难点。这篇内容适合的人群很广：正在复习计算机网络期末考的大学生，准备408考研的考生，刚入行做网络开发或者软件测试、需要对网络协议有系统认知的工程师，甚至只是对"为什么我家的网络会卡"产生好奇的普通用户。读完之后，你至少能把书里那些零散的知识点串成一条线，遇到关于可靠传输和流量控制的题能拿分，面试被问到也能讲出所以然。
我的建议是，别把这篇内容当"速成笔记"来刷，而是把它当作一条主线，配合你自己的教材一起看。我会把每个概念背后的"为什么"讲清楚，再结合实际的场景和计算题来演示这些协议到底怎么运转。整个过程不难，关键是建立正确的模型。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 可靠传输的本质：不只是"传到就算成功"
很多同学刚开始学可靠传输时，会觉得这有什么好讲的，就是在数据发出去之后等个确认嘛。但实际上一套可靠传输机制要解决四件事：数据在传输过程中被破坏了怎么办；数据丢失了怎么办；数据到了但顺序乱了怎么办；接收方收到了重复的数据怎么办。这四个问题不解决，任何一个都可能导致应用层拿到错误的数据。所以可靠传输并不是一个简单的"收到就回个ACK"，而是一套包含了差错检测、确认、序号、超时重传等机制的完整体系。
2.1 可靠传输的四个关键要素：每一个都必须存在
我先来拆解这四个要素，因为后面讲滑动窗口、讲TCP的可靠传输，全部建立在这四个要素之上。
第一个是差错检测。发送方在把数据包发出去之前，会在末尾附加一个校验码，最常见的算法是校验和（Checksum）。接收方收到数据后，用自己的算法重新算一遍，如果结果和发来的校验码不一致，说明中间某个比特被干扰了，这个包直接丢弃，不回复确认。IP层也有校验和，但只校验头部；TCP/UDP的校验和会覆盖头部加数据部分，检测范围更广。所以应用层拿到的数据，理论上已经是经历过两次差错检测的。
第二个是确认。接收方在正确收到数据后，需要回一个确认报文（ACK），告诉发送方"这个东西我收到了，你可以继续往下发"。没有确认机制，发送方永远不知道数据到底到了没有。
第三个是序号。这是可靠传输里最容易忽略但又极其关键的部分。为什么要序号？想象一下这样一个场景：发送方发了数据包1和2，包1到达后接收方回了ACK，但在回去的路上ACK丢了。发送方等了很久没收到ACK，就超时重传包1。这个时候接收方其实已经收到过包1了，如果接收方不做任何区分，就会把同一个数据交付给应用层两次。有了序号之后，接收方发现"这个序号我处理过了"，直接丢弃再重发ACK即可，应用层拿到的是不重不漏的数据。
第四个是超时重传。发送方发出数据后，会启动一个定时器。如果时间到了还没收到对应序号范围的ACK，就认为这个数据包或者ACK丢了，重新发送一遍。这个"超时时间"怎么设置很有讲究：设太短，明明还没慢、只是网络抖动了一下，就会导致一堆没必要的重传，浪费带宽；设太长，一旦真的丢了包，应用层要等很久才能感知到。TCP里这个值是用自适应算法动态估算的，依据是每次往返时间RTT的历史统计值。
这四个要素齐了，才叫"可靠传输"。很多同学在复习时容易忘掉序号的作用，或者答不出"为什么可靠传输需要序号"，这其实是一个高频面试考点，值得记牢。
2.2 停止等待协议：最简单但效率最低的可靠传输
理解了四个要素之后，我们先看一种最朴素、书里一定会讲的协议：停止等待协议（Stop-and-Wait）。这个协议的逻辑非常简单：发送方每发一个包，就停下来等ACK；收到ACK再发下一个；如果超时没收到ACK，就重传刚才那个包。
逻辑上它没有任何问题，可靠传输的四个要素它全都有。但效率是它最大的痛点。我来算一笔账。假设发送方和接收方之间的信道速率是1Gbps，往返时延RTT是30毫秒（这差不多是跨省网络的一个典型数值），一个数据包的大小是1000字节，也就是8000比特。发送这个包需要的时间是 8000 ÷ 10^9 = 8微秒。发完之后要等RTT = 30毫秒才能收到ACK。这意味着什么？在整个传输周期约30.008毫秒里，发送方只有8微秒在真正干活，其余时间全都闲着。信道利用率大概是 8微秒 ÷ 30008微秒 ≈ 0.027%，低到可以忽略。
这就是停止等待协议最大的问题：一次只能有一个包在途。别人明明能用很宽的管道运水，你偏偏一桶一桶等着提，管道的容量完全被浪费了。所以在实际系统中，几乎不会直接用这种机制来做高速数据传输。但理解它是理解滑动窗口的起点，因为滑动窗口本质上就是"停止等待协议的流水线版本"，让多个包同时"在途"，而不是一个个傻等。
2.3 从停等到ARQ：回退N帧与选择重传的取舍
有了"让多个包同时在途"的思想后，自动重传请求（ARQ）机制开始登场。ARQ有三种典型形态：停等ARQ（就是2.2里说的停止等待）、回退N帧ARQ（Go-Back-N，简称GBN）、选择重传ARQ（Selective Repeat，简称SR）。后两者都依赖滑动窗口机制工作，所以这里我需要先把窗口带出来。
GBN的思路是：发送方可以连续发送多个包，接收方只按序接收。如果中间某个包丢了或者出错，接收方会丢弃从这个包开始的后续所有包，并且对最后一个正确接收的包重复发送ACK。发送方一旦超时，就会从那个丢失的包开始，把后面的包全部重传一遍。
GBN的优点是接收方实现简单，不用缓存乱序到达的数据。但缺点是，如果信道质量不好丢包率高，重传的开销会非常大。想象一下发送了100个包，第50个丢了，后面50个都白发了，全都要重来。这在线路本来就不太好的情况下，反而会加剧拥塞。
SR的思路则不同。接收方会根据序号逐个确认，对于乱序到达的包，只要序号对应的缓冲空缺还在，就先缓存起来，不丢弃。发送方只需要重传真正丢失的那个包，其他包不需要动。这样浪费的带宽更少，但代价是：接收方要维护一个较大的缓存区，发送方和接收方都要记录窗口内哪些包已确认、哪些没有，逻辑复杂度明显上升。
这里出现了一个经典的题型：给定发送窗口大小、序号比特位数，比较两种协议的信道利用率和开销。实际TCP的实现更接近SR，但又不完全是。因为TCP用累积确认，接收方虽然会缓存乱序数据，但ACK是"最后一个连续收到的序号"。这个细节我在第4部分还会展开。
3. 流量控制：把滑动窗口讲透，才算真的入门
流量控制解决的问题和可靠传输不同。可靠传输关心"数据对不对、全不全"，流量控制关心的是"发送方的发送速度，不能超过接收方的处理能力"。接收方的接收缓冲区大小是有限的，如果发送方一个劲地猛发，缓冲区就会溢出，刚收进来还没交给应用层的数据就被新来的数据覆盖掉，那之前做的所有可靠传输机制就都白搭了。
3.1 滑动窗口的工作过程：发送窗口与接收窗口的配合
流量控制最核心的机制就是滑动窗口。先看发送方。发送方维护一个发送窗口，窗口的大小表示"在没有收到ACK的情况下，我最多还能发多少数据"。每发出一个包，窗口就往前挪一点，可用空间变小；每收到一个ACK，窗口就向前滑动，可用空间变大。如果窗口大小是3，意味着发送方可以在没有确认的前提下连发3个包，这3个包全部停在网络里，等待ACK回来填充窗口空间。
接收方维护一个接收窗口，窗口大小表示接收方还能缓存多少数据。接收方把当前剩余缓冲区大小通过ACK报文里的"窗口"字段告诉发送方。TCP报文头里有一个16位的窗口字段，最多能表示65535字节，但实际TCP通过窗口缩放选项可以把这个值扩大很多倍。这个字段就是流量控制的根本：接收方说自己还有多大空间，发送方就把在途数据控制在多大范围内。
举个例子：接收方初始窗口通告为4000字节，发送方已经发了序列号1到4000的数据。接收方处理完前2000字节后，回一个ACK，通告窗口为3000字节（因为还有2000字节没处理完，再加上新释放的2000字节，所以剩下3000字节空闲）。发送方看到新的窗口通告后，允许自己把在途数据量从当前的4000逐步推进到3000？这里有一个容易绕晕的点——其实发送方会立即恢复发送，因为窗口的空闲空间变多了。接收方的"窗口通告"并不是限制已发的数据，而是限制"还能再发多少"。所以发送方会根据最新的通告窗口，减去已经在途的未确认数据量，得出还能发送的数据量，继续往出发。这个机制核心就是一句话：发送方的发送量永远不会超过接收方通告的窗口大小。
3.2 窗口大小与信道利用率：一道必考计算题的完整推导
很多同学在做滑动窗口的计算题时，只知道套公式，但不知道公式怎么来的。这里的"为什么"其实特别简单：信道利用率等于"真正用于发送数据的时间"除以"一个完整发送周期的时间"。停止等待协议里这个周期是发送时间+等待ACK的时间，所以利用率极低。而滑动窗口协议中，只要窗口大小足够大，发送方可以连续不断发送，利用率就可以趋近于100%。
经典的408考研题是这样出的：一个数据包大小是1000字节，发送速率是100Mbps，RTT是20ms，求至少多大的发送窗口才能使信道利用率达到100%。计算过程是这样的：发送一个包的时间是 1000×8 ÷ (100×10^6) = 80 微秒。在一个RTT加发送时间里，发送方最多能等一个ACK回来，所以一个发送周期大约是20.08毫秒。在20.08毫秒之内，如果发送方希望一直不闲着，那它需要在这段时间内总共发送 100Mbps × 20.08ms ≈ 2.008Mbit 的数据。换算成包，大约是 2.008×10^6 ÷ 8000 ≈ 251 个包。如果你把窗口大小设置为251，就能做到连续发送不打嗝。如果你把窗口设为100，那利用率就是100/251 ≈ 39.8%。这个计算题的套路就是：先用带宽乘以一个发送周期得到在途数据总量，再除以单个包大小，得到最大在途包数。
这里说一个实际经验：我当年复习时，一直搞不懂"窗口大小是用字节还是用包来衡量"。这其实看你用的教材。TCP的窗口演进方向上是按字节计量的（接收方通告的窗口单位是字节），但在协议理论上，为了计算方便，我们通常把数据切成一个个大小固定的分组，窗口以"分组的个数"为单位。做题时先看清楚题目给的是字节还是包，如果是字节你就用字节算总量，是包就用包算个数。别混着用。
3.3 窗口死锁：滑动窗口机制里最隐蔽的一个坑
滑动窗口并不总是能自动顺畅地运转。有一种经典场景会导致死锁：接收方收到了一大堆数据，缓冲区填满了，于是它在ACK里把通告窗口设置为0，告诉发送方"你先别发了"。发送方收到0窗口通告后，就停下来等待新的非零窗口通告。但接收方处理完数据后，会发送一个"窗口非零"的ACK，这个ACK如果丢了，发送方就永远等下去，接收方则在等发送方发新数据——两边谁都不动，形成死锁。
解决死锁的方案是持续定时器（Persistence Timer）。发送方在收到0窗口通告后启动这个定时器，每隔一段时间主动发一个很小的探测报文，问接收方"你的缓冲区现在怎么样了"。接收方收到探测后会回复一个包含最新窗口大小的报文。如果窗口还是0，发送方继续等下一个定时周期；如果窗口变大了，发送方立刻恢复发送。
这个点很容易被忽略，但在面试中是一个很好的加分项。面试官如果问"滑动窗口会不会有死锁问题"，你把这个机制讲出来，基本就能看出你确实理解了这个协议，而不只是背了个概念。
4. 流量控制和拥塞控制在争什么：两套窗口，各管各的
书里在讲完滑动窗口之后，紧接着就讲拥塞控制，很多同学在这里就彻底乱了。流量控制前面刚说完，怎么又来了一个慢启动、拥塞避免、快重传、快恢复？到底谁管谁？我的理解方式是这样的：流量控制管的是"接收方受不受得了"，拥塞控制管的是"网络本身受不受得了"。一个是接收方的缓冲区问题，一个是路由器、链路这些中间设备的承载能力问题。
4.1 为什么网络拥塞时不能只靠增加重传来解决
我先讲一个场景。假设你从家里向朋友传一个大文件，传输路径上有好几台路由器。如果你的发送速度太快，某台路由器的缓存满了，新进来的包就只能被丢掉。丢包之后发送方超时没收到ACK，就会重传。重传的数据越多，网络里积压的数据就越多，路由器的缓存越容易满，又会丢更多的包，于是发送方又重传更多。这是一个恶性循环，最终的结果是网络吞吐量急剧下降。在极端情况下，你会看到网络几乎"瘫痪"，但明明链路带宽还是有的。这个现象被称为拥塞崩溃（Congestion Collapse）。
拥塞控制存在的意义，就是在丢包发生之前，主动探测网络能承受的发送速率，并把速率控制在一个安全范围内。TCP的拥塞控制把速率控制在拥塞窗口（cwnd）里。发送方的实际在途数据量，是min(拥塞窗口，接收方通告窗口)决定的。这个"取最小值"的逻辑非常关键：发送方的最终发送量，要同时被接收方的处理能力和网络的承载能力限制。有一句话我一直记着：接收窗口是对端告诉我的，拥塞窗口是我自己猜出来的。
我怎么猜这个值？TCP用的是加法增大、乘法减小的思想。慢启动阶段每经过一个RTT，拥塞窗口翻倍；达到慢启动门限（ssthresh）后，进入拥塞避免阶段，每经过一个RTT，拥塞窗口只加1。出现3个重复ACK时，说明网络已经出现丢包迹象，但可能只是个别包丢失，于是执行快重传和快恢复：把ssthresh降为当前cwnd的一半，cwnd减半；如果是超时，说明网络可能非常拥塞，此时把ssthresh设为cwnd的一半，cwnd直接降到1，重新开始慢启动。
4.2 慢启动、拥塞避免、快重传、快恢复的完整运转流程
为了让你看清这四个算法是怎么在一段传输过程中轮番上阵的，我画一条时间线来说明，而不是用抽象的状态图。
假设初始cwnd=1（单位是报文段个数或者MSS），ssthresh=16。发送方每收到一批ACK，cwnd就翻倍：第一个RTT之后cwnd变成2，第二个RTT变成4，第三个变成8，第四个变成16。这期间是慢启动阶段，指数增长非常猛。
当cwnd到达16（等于ssthresh）之后，进入拥塞避免阶段。之后每个RTT，cwnd只加1：17、18、19、20……这个阶段的速度增长比较缓慢，目的是在靠近网络容量上限时小心试探。
假设cwnd增长到24时，发送方收到了3个重复ACK。这说明发生了丢包，但整体网络未必崩溃。于是TCP进入快重传，不再等超时，而是立刻重传丢失的包。同时执行快恢复：ssthresh被更新为新值12（24的一半），cwnd被设置为12，继续从拥塞避免阶段开始增长。如果后面又发生超时，那么ssthresh降到6，cwnd降到1，重新进入慢启动。
这里有一个容易搞混的点：快重传和快恢复实际上是捆绑出现的。快重传说的"不等待超时就重传"，解决的是重传触发时机的问题；快恢复说的是"重传之后cwnd降到ssthresh而不是降为1"，解决的是重传之后发送速率恢复策略的问题。两者合在一起，让TCP在轻量丢包时能快速恢复，不至于因为一个偶然丢包就把速率打回原形。
4.3 两个窗口的协同：接收窗口与拥塞窗口取最小
我在做网络仿真实验时，特意验证过窗口协同的效果。当接收方通告窗口一直是65535字节，而拥塞窗口比较小的时候，发送速率完全由拥塞窗口决定；反过来，如果接收方缓冲区只剩1000字节，即使拥塞窗口很大，发送方也不能发超过1000字节的在途数据。所以实际发送窗口 = min(拥塞窗口, 接收方通告窗口)，这一点几乎出现在每一本教材的TCP流量控制章节里。
学到这里，你可以停下来梳理一下：三次握手建立连接后，发送方有拥塞窗口在进化，接收方有通告窗口在变化，它们两个共同决定发送方的行为。此外，TCP还有一个糊涂窗口综合征（Silly Window Syndrome），如果接收方每次只释放很小一块缓冲区，发送方就发送很小的报文，网络开销被小包大量浪费。解决方案有两种：接收方采用延迟通告，等缓冲区释放到一定大小再发ACK；发送方采用Nagle算法，凑够一个MSS或者等前面的小段确认后再发送。Nagle算法和延迟ACK在测试工程师眼中经常被误解为"网络延迟变大了"，实际上是帮你省了无数次小包传输的时间。
5. 实操验证：用Python模拟一个简化版的滑动窗口发送器
光看公式和理论，有时候总觉得自己懂了，但一写代码就露馅。这里我分享一个我当年为了彻底搞懂滑动窗口，自己写的一个Python小模拟器。它简化了很多TCP细节，但能直观地展示发送窗口怎么随着ACK一点点滑动，以及超时重传怎么触发。代码量不大，照着敲一遍，逻辑会特别清晰。
5.1 模拟环境与整体设计
语言用Python 3，不需要任何第三方库。我模拟的对象是一个发送方对象，它有五个核心属性：发送窗口大小、下一个要发送的序列号、最早的未确认序列号、已发送但未确认的包的字典、随机丢包率。接收方简化为一个函数，不模拟接收缓冲区，只负责回复ACK或者丢弃数据。
这段代码的价值不在于工程实现，而在于教学演示。通过给每个包打上序号，用一个字典暂存已发送但未确认的包，再根据ACK来更新最老的未确认序号，你就能直观地看到"窗口"其实是一个由序号构成的区间，这个区间的左边界是"最早的未确认序号"，右边界是"最早的未确认序号+窗口大小"，随着ACK不断回来，左边界不断右移，区间就整体向前滑动了。
5.2 核心代码实现
python复制import random
import time
class SlidingWindowSender:
def __init__(self, window_size=4, total_packets=20, loss_rate=0.2):
self.window_size = window_size
self.total_packets = total_packets
self.loss_rate = loss_rate
self.next_seq = 0 # 下一个要发送的序号
self.base = 0 # 最早的未确认序号
self.sent_packets = {} # 已发送但未确认的包: seq -> 数据内容
self.timers = {} # 简化版定时器记录
def send_packet(self, seq):
# 模拟真实发送，数据用字符串代替
self.sent_packets[seq] = f"packet-{seq}"
self.timers[seq] = time.time()
print(f"[SEND] seq={seq}")
def send_available(self):
# 尽可能把窗口内的包都发出去
while self.next_seq < self.base + self.window_size and self.next_seq < self.total_packets:
self.send_packet(self.next_seq)
self.next_seq += 1
def receive_ack(self, ack_seq):
# ack_seq 表示对 seq <= ack_seq 的所有包都确认
ack_seq += 1 # 转成"已确认的最大序号 + 1"
# 随机模拟ACK丢失
if random.random() < self.loss_rate:
print(f"[LOSS] ACK about {ack_seq-1} lost")
return
if ack_seq > self.base:
old_base = self.base
self.base = max(self.base, ack_seq)
print(f"[ACK] base moves from {old_base} to {self.base}")
# 清理已确认的包
for seq in list(self.sent_packets.keys()):
if seq < self.base:
del self.sent_packets[seq]
def check_timeout(self, timeout_threshold=2.0):
# 简化版超时检测：遍历所有已发送未确认的包
now = time.time()
for seq in list(self.sent_packets.keys()):
if now - self.timers[seq] > timeout_threshold:
print(f"[TIMEOUT] seq={seq}, retransmit")
# 回退N帧风格：从这里开始全部重传
self.next_seq = seq
break
def run(self):
while self.base < self.total_packets:
self.send_available()
# 模拟接收方返回一个ACK：随机选一个窗口内已发送的序号作为确认
pending = [seq for seq in self.sent_packets.keys() if seq < self.base + self.window_size]
if pending:
ack = random.choice(pending)
self.receive_ack(ack)
self.check_timeout()
time.sleep(0.1)
print("All packets acknowledged!")
if __name__ == "__main__":
random.seed(42)
sender = SlidingWindowSender(window_size=4, total_packets=20, loss_rate=0.2)
sender.run()
运行结果大致长这样（因为随机种子固定，每次运行结果相同）：先是seq=0到3发出，然后随机ACK、偶尔丢ack，base逐步右移，到达某个时刻出现timeout，触发从丢失序号开始重传。通过打印日志你能清楚地看到：即使中间有些ACK丢了，序号区间依然能推进；但一旦某个包长期没被确认，超时重传就会把一个较大的未确认序号重新设为next_seq，后续包暂时不发，直到它被确认。
5.3 实验心得与几种超时策略的对比
我把这段代码跑了几十遍，最大的体会是：回退N帧在丢包率较高时效率确实很低。丢一个包，后面所有已发的包可能都白发，全部重传一次。而如果改成选择重传，只是单独补发丢的那个包，网络占用会小很多。但在模拟里实现选择重传会更复杂，因为接收方需要维护一个乱序缓存，并且能针对单个包回复ACK。
为了直观对比，我把window_size从4改到10，再改到20，run完成的时间会明显变短。窗口越大，允许同时在途的包越多，发送方等待ACK的间隙就越少，整体效率就越高。当然，这里有一个前提：网络本身不拥塞，接收方缓冲区也足够大。如果拥塞窗口或者接收窗口变小，你就算把发送窗口块设得再大也没用，实际的在途数据量会被限制在更小的那个值。
这个模拟实验也解释了另一个现象：为什么TCP的初始窗口往往很小。因为你对网络的实际承载能力一无所知，一开始就发很大窗口，一旦网络撑不住，重传的数据又会加剧拥塞。所以宁可先小步试探，逐步增大，等发现丢包再降回来。这正是慢启动和拥塞避免算法存在的意义。
6. 408考研与期末复习：高频考点、计算套路、学习路线
这部分写给正在备考的读者。热搜词里出现了"湖科大教书匠计算机网络适合考408吗"、"王道计算机网络"、"计算机网络八股文"这样的关键词，说明很多人都在纠结怎么学、跟谁学。我就结合我自己的备考和复习经验，把最容易考、最容易错的点拎出来，再给一个按时间排序的可执行复习路线。
6.1 高频考点盘点：哪些是"必考"级别的知识点
无论你是期末考还是408统考，下面这几个考点几乎是必出的：
可靠传输的基本机制：这个通常不会单独出一道答题，但会以小选项或者简答题第一问的形式出现。核心就考察你知不知道需要序号、确认、校验、超时重传这四要素。
停止等待协议的信道利用率计算：给你数据包长度、带宽、RTT，让你算利用率。套路固定：先算发送时间，再算一个发送周期，用发送时间除以发送周期。要注意发送周期里通常包含2倍的单向传播时延，而不是一个RTT。如果题目给了单向传播时延，别直接用RTT代替，RTT=2×单向传播时延。
滑动窗口机制与窗口大小计算：这里考查窗口上限。窗口不能超过2^(n-1)（GBN）或者2^(n-1)（SR的发送/接收窗口之和限制）。为什么有减1？因为序号只有n位，能表示0到2^n -1，但接收方需要区分"新包"和"重传的旧包"。如果窗口等于2^n，发送方发出全部序号后，下一次再从0开始，接收方就分不清这是序号0的新包还是旧包重传。所以GBN的发送窗口上限是2^n -1，SR的发送窗口和接收窗口之和不超过2^n，具体到发送窗口就是2^(n-1)。
TCP拥塞控制的状态行为：给你一串cwnd变化序列，问你某个时刻处于什么状态、ssthresh的值是多少。这种题需要熟练画状态变化图，看到连续翻倍是慢启动，看到均匀加1是拥塞避免，看到3个重复ACK是快重传+快恢复，看到超时是重新慢启动。这里有一个常见的陷阱：进入拥塞避免之后cwnd并不一定是单调递增的，如果此前发生过快恢复，ssthresh会被降为当时cwnd的一半，之后继续加1增长，起点不是原ssthresh。
快重传与快恢复的具体动作：比如当收到3个重复ACK时先干什么。先重传丢失的数据，再把ssthresh设为当前cwnd的一半，cwnd减半并进入拥塞避免。这些动作的先后顺序在408参考答案里很重要，一定要按"重传->更新门限->减半窗口"的顺序来记忆。
6.2 计算题套路的三个通用步骤
我练了不少计算题，发现题目再怎么变化，本质就三步：
第一步，确认单位。题目给的是字节还是比特，窗口给的是字节还是报文段个数，定时器给出的时间是往返时延还是单向传播时延。先把所有单位统一，再进入下一步。这里最容易算错：带宽的单位通常是Mbps，1Mbps=10^6 bps，而不是2^20。不少同学用存储单位换算来算带宽，结果差一个数量级。
第二步，画时间线。把发送方发数据的时间、传播时延、接收方处理数据的时间、ACK回传的时间都列出来，标出从"开始发送第一个数据"到"收到第一个ACK"的总时长。如果题目有多个数据包，就画出连续的发送段和等待段，看发送方是否有空闲。这一步做出来，信道利用率基本就出来了。
第三步，列公式。信道利用率=发送数据的时间/（发送数据的时间+空闲等待的时间）。发送窗口大小=带宽×发送周期/单个包大小，最后向上取整。注意"向上取整"三个字——题目问的是"至少要多大窗口"，所以是能保证利用率达标的临界情况，而不是最大的整数。
6.3 教材怎么选，复习路线怎么排
先回答很多人在问的那个问题：湖科大教书匠的课程适不适合考408？我的看法是，它的视频用来入门建立模型非常好，动画讲解直观，逻辑清楚，适合刚接触计网的同学在第一遍学习时用。但408的考点深度和计算题，光看视频不够，还是要回到王道或者天勤的辅导书上刷题。谢希仁的教材作为参考，概念定义写得规范，适合查阅，但单用它复习408会略显不够，因为408的难度高于一般教材的例题。
对于期末复习，如果学校用的是谢希仁第九版第八版，直接按照书上传输层的章节走就行，重点看课后习题里关于滑动窗口和拥塞控制的题，基本覆盖了老师出题的类型。如果学校用的是《自顶向下》，那它的传输层章节讲得比国内教材更加贴近实际，Kurose和Ross对TCP拥塞控制的解释很清楚，但课后题难度偏大，做不完也没关系，挑有答案的题做一遍即可。
我给一个可复制的三阶段复习路线：第一阶段（约1周）跟着视频课把传输层整体过一遍，重点是建立"三次握手、四次挥手、滑动窗口、拥塞窗口"四个模型，能做到用自己的话讲出每个模型。第二个阶段（约3天）集中刷计算题，刷完《王道计算机网络》传输层的历年408真题和模拟题，把错题整理成"为什么错了"的笔记，而不是单纯抄正确答案。第三阶段（考前1天）只看笔记和自己画过的状态图，快速把公式和状态变化过一遍，走进考场前能在脑子里画出滑动窗口推进和拥塞窗口变化的动态图，基本就稳了。
7. 常见问题与排查技巧实录：这些坑我踩过，你别再踩
学习过程中，包括很多读者在评论区问过的，有些问题特别典型。我把它们集中整理在这里，方便你复习时快速对照检查自己有没有同样的疑惑。
第一个高频问题：为什么滑动窗口里的"累积确认"能简化接收方实现，却不能解决所有重传问题？答案是：累积确认的效率在乱序不严重时很高，但如果中间丢了一个包，在GBN中接收方会丢弃后面所有乱序包并反复确认最后的连续序号，发送方只要丢了那个缺口包就触发大量重传。TCP如果完全照搬GBN，在一个高延迟、高丢包的链路上效率会非常难看。Linux内核中TCP对乱序包是选择缓存，配合SACK（选择性确认）选项来实现类似SR的效果。所以你在面试时说"TCP是GBN和SR的结合体"，会比单纯说"TCP用的是GBN"要准确得多。
第二个问题：为什么收到3个重复ACK就快重传，而不是收到1个或者2个就重传？这是为了过滤掉数据包乱序造成的伪确认。比如1、2、3三个包依次发送，3先到了，接收方连续回了两个ACK1，发送方看到两个ACK1时，不一定说明包1丢了，也可能是3跑到1前面了。3个重复ACK是一个经验阈值，它说明后面至少有3个包已经到达了，丢包的可能性远大于乱序的可能性。代价是：在极小概率的情况下，收到3个重复ACK但其实没丢包，也会触发一次无辜的重传。这是为了性能和健壮性做的权衡。
第三个问题：流量控制和拥塞控制冲突时怎么办？比如接收方通告窗口非常大，但网络很拥塞，慢启动正在降低cwnd；反过来如果接收方缓冲区满了，通告窗口是0，即使cwnd翻到天上去也没用。所以没有"冲突"这个概念，它们是在不同时间、不同压力下共同发挥作用。发送方的实际有效窗口始终是两者中的较小值。这个概念理解之后，再看各种性能分析题就不会蒙了。
第四个问题，也是很多初学者最容易卡住的一个：三次握手和流量控制、可靠传输到底有什么关系？三次握手建立的连接，在传输层提供的是一个带有缓冲区的通信上下文。发送方向、接收方各分配一块缓冲区，滑动窗口的初始状态靠的是握手过程中交换的初始序号（ISN）和窗口字段。所以握手对话过程中已经带着接收方通告窗口的大小，之后的可靠传输和流量控制都建立在这个初始状态之上。如果握手时通告窗口是0，那么即使连接建立成功，发送方也不能马上发送数据，得等接收方发一个非零窗口通告。这个细节在一些刁钻的期末题里会出现。
第五个问题：做实验时发现同样的吞吐量，用客户端软件传文件时忽快忽慢，是不是拥塞控制在作怪？不一定。TCP的吞吐量不仅受cwnd影响，还受延迟ACK策略、Nagle算法、接收缓冲区大小、内核socket buffer大小等多个因素影响。我之前测本机回环地址的TCP吞吐量时，发现实际值远低于预期，排查很久才发现是socket发送缓冲区和接收缓冲区默认值太小，数据还没发出去就被本地缓冲区限制了。所以在调试网络性能问题时，先看socket buffer，再看拥塞窗口曲线，而不要一上来就归咎于"网络不好"。这里有一个小技能：在Linux下可以用ss -ti命令查看当前TCP连接的cwnd、ssthresh、rtt等实时信息，用的时候注意看输出里的cwnd字段，它会随着传输过程动态变化。用这个命令观察一个正在下载大文件的长连接，你就能直观地看到cwnd如何在不同算法阶段之间切换，效果比死记状态图好得多。
8. 写在最后：怎么检验自己真的学会了
这个专题的内容讲到这儿，核心脉络已经全部铺开了。从可靠传输的四要素，到停止等待协议的低效率困境，再到滑动窗口如何通过"多包在途"提升利用率，以及流量控制和拥塞控制两套机制的协同方式，最后落到一个可运行的Python模拟器和一套复习策略。
如果你问我，学完这些内容之后怎么检验自己学会了没有，我通常会建议一个简单的方法：不看教材，用五分钟在白纸上画一套完整的TCP发送过程图，从三次握手开始，画出发送方的发送窗口和接收方的通告窗口，标注拥塞窗口的变化曲线，再把一次超时重传和一次快重传的触发过程写清楚。能独立完成这张图，说明你已经把这些概念从"认识"变成了"理解"。
我在实际学习和做实验的过程中，最有价值的一个体会就是：计网的协议并不复杂，复杂的是它们之间相互制约、相互配合的关系。可靠传输保证了数据内容的正确性，流量控制防止接收方被淹没，拥塞控制防止网络整体崩溃。三者用各自的机制，朝着同一个目标努力，让数据从一端到另一端走得又快又稳。理解了这个大图景之后，再看任何一道关于传输层的题目，你都会觉得它在考一个你熟悉的模型，而不是一个孤立的死知识点。