TCP滑动窗口全解析：原理、流量控制与拥塞控制

TCP 滑动窗口这个概念，很多人学的时候觉得不难，但一到实际调优就翻车。面试被问到"滑动窗口怎么实现流量控制"，能说出"控制发送速率"的人不少，再往下问一句"它和拥塞控制的窗口有什么区别"，很多人就开始含糊。我在调一个基于 TCP 的自研协议时遇到过吞吐上不去的瓶颈，回头把滑动窗口机制完整补了一遍，才发现很多排障思路都建立在把窗口机制理解透的基础上。这篇文章我把 TCP 滑动窗口从原理到代码完整讲一遍：为什么需要窗口、窗口里的序号和确认号怎么滑动、流量控制和拥塞控制怎么区分，最后用 Python 做一个可以直接运行的滑动窗口模拟器，再附上实际抓包和 Socket 编程的经验。适合已经了解 TCP 基本流程、想彻底弄懂传输效率问题的开发者和运维。

1. 为什么 TCP 需要一个"滑动窗口"：从停等协议说起

1.1 停等协议的致命账本

如果从零设计一个可靠传输，最简单可靠的做法是"发一个等一个"：发送方发出一个报文段，然后停下来等待确认；接收方收到数据后回一个 ACK；发送方拿到 ACK 后再发下一个。这套逻辑完全正确，但效率极其低下。原因在于链路在等待 ACK 的整个 RTT 内都是空闲的，除了 ACK 在返程路上占用的一点带宽外，正向链路几乎没有任何数据在跑。

用数字算一笔账。假设链路带宽是 1Gbps，一个报文段的 MSS 是 1KB（大约是 8Kbit），RTT 是 50ms。那么发送 1KB 数据本身只需要约 8 微秒，而等待 ACK 要 50 毫秒。链路利用率是 8 微秒除以 50 毫秒加 8 微秒，约等于 0.016%。也就是说，1Gbps 的链路在这种方式下实际吞吐不到 0.16Mbps。这条链路上 99.98% 的时间都在空转。算完这笔账就会明白，要想提高传输效率，"发一个等一个"必须被打破。

1.2 滑动窗口的本质：不等 ACK，先发一堆

滑动窗口的思路就是把原来"串行"的发送变成"流水线"：只要还有窗口余量，发送方就可以连续发送多个报文段，不必等待每个段的 ACK 都回来。所谓窗口，本质上是"允许发送方在没有收到确认时，最多还能发出去的数据量上限"。这里的数据量以字节为单位，因为 TCP 面向字节流，窗口是字节窗口，报文段只是按 MSS 把字节流切开。

一个容易理解但更贴切的类比是食堂打饭窗口：停等协议适合只有一个窗口的食堂，每个人都必须等前面的人打完饭才轮到自己，队伍既长又慢；滑动窗口则像一次开了多个窗口，只要窗口数够多，人群可以同时被服务。链路的"带宽时延积"就是食堂里同时在排队取餐的人数上限，窗口大小只有覆盖这个乘积，才能让链路不间歇。

这里引出一个非常关键的式子：窗口大小 >= RTT × 带宽 / MSS。RTT 乘以带宽就是BDP（Bandwidth-Delay Product），表示一个字节从发出到确认回来之间，网络链路能够容纳的在途字节数。如果窗口小于 BDP，哪怕数据发得再快，也会因为等待确认而出现空隙；只有窗口足够大，链路在每一个瞬间都有数据可传，吞吐才上得去。这也是为什么后面调优所有参数，本质上都在围绕"让在途数据量填满 BDP"这一件事。

2. 滑动窗口的核心机制：发送窗口、接收窗口与序号确认的咬合

2.1 发送方内部：三个游标决定一切

发送方窗口的实现，可以用三个游标描述清楚，这也是理解 GBN 和选择重传协议的地基。SND.UNA是窗口左边界，指向最早一个还没被确认的字节序号；SND.NXT是下一个即将分配的字节序号；窗口大小记为SND.WND，窗口右边界是 SND.UNA + SND.WND。发送方每次要发新数据，必须先检查 SND.NXT 是否还在窗口内，也就是 SND.NXT - SND.UNA 是否小于窗口大小。

举个例子，窗口大小为 5 字节，当前 SND.UNA = 10，SND.NXT = 12，那么 12、13、14、15 都可以立即发送，因为 SND.NXT 离 SND.UNA 的差是 2，还剩 3 个字节的余量；当 SND.NXT 推进到 15，差值变成 5，可发送余量归零，新数据就不能再发，要等 ACK 把 SND.UNA 往前推。收到确认后 SND.UNA 向前移动，窗口右边界同步扩展，新序号重新进入可发送区。这个"左边界推进、右边界失去"的过程，就是窗口的"滑动"。

2.2 接收方的窗口怎么配合

接收方也有自己的窗口，用RCV.NXT和RCV.WND描述。RCV.NXT 表示期望收到的下一个字节序号，落在 [RCV.NXT, RCV.NXT + RCV.WND) 窗口内的数据才会被接受，区间外的数据会被丢弃。接收方收到数据后，把已连续收到的字节序号放进 ACK 的确认号里返回，表示"这个序号之前的所有字节都到了"。这就是累积确认。

注意一点：接收方窗口允许乱序到达。TCP 的接收缓冲区会把提前到的字节段先缓存起来，等中间空缺补齐后再交给应用层。这一点让 TCP 在丢包和乱序时不必立即重传所有数据，只重传确实缺失的部分，对吞吐帮助很大。如果任何乱序包都被丢掉，窗口虽然还能滑动，但重传成本会高到无法接受。

整个机制的闭环是这样的：发送方根据 ACK 里返回的确认号判断哪些字节已被接收，根据窗口字段判断还能继续发多少。接收方的窗口大小不是固定不变的，它会随着应用层从缓冲区读走数据而扩大，随着缓冲区积压而缩小。这个"告诉发送方还剩多少空间"的动作，就是流量控制的起点。

2.3 窗口大小字段的位数陷阱

TCP 头里表示窗口大小的字段只有 16 位，最大 65535 字节。这个数值在现代宽带链路下严重不够用。假设 RTT 是 30ms、单流带宽要跑满 500Mbps，BDP 是 1.875MB，而窗口字段上限只有 64KB，单条 TCP 连接根本不可能把链路填满。于是 RFC 1323 定义了窗口缩放选项：三次握手时双方协商一个缩放因子，窗口真实大小等于头部字段乘以 2 的缩放因子次方。

抓包时，Wireshark 在 SYN 包里会显示 Window size 和 Window scale（缩放因子），后续Window列则是原始字段值，[Calculated window size]是乘完缩放因子的真实值。调试高带宽连接时，如果只看原始 Window 字段，会把 64MB 的真实窗口误读成 64KB；反之，如果没开窗口缩放，再大的接收缓冲区也表达不出来。这两件事不搞清楚，窗口调优就无从谈起。

3. 流量控制在实战中的表现：通告窗口、零窗口与 Nagle 算法

3.1 流量控制到底控制什么

流量控制处理的问题非常具体：发送方发送太快，接收方缓冲区装不下，多余的包只能丢弃；如果接收方丢弃了数据，发送方又要重传，不仅浪费带宽，还会让整体效率更差。TCP 的解法是，接收方在每条 ACK 或数据包里携带"当前还能接收多少字节"的信息，这个值叫通告窗口。发送方据此调节速率，相当于每个数据包都带了一张"还剩几张票"的通告。

实际可发送窗口不是由发送方一厢情愿决定的，而是min(本端拥塞窗口, 对端通告窗口)。通告窗口代表接收端的接受能力，由应用层消费速度决定；拥塞窗口代表网络路径的可用容量，由丢包和 RTT 情况决定。这两个窗口是不同维度的约束，不能互相替代。我在实际服务里见过最典型的流量控制场景，是接收方因为消费线程池处理不过来，socket 接收缓冲区逐渐被填满，抓包看到对端通告窗口从 32KB 降到 8KB 再到 0。问题根因不是协议配置，而是应用消费速度太慢。

3.2 零窗口死锁与持久计时器

当通告窗口降到 0，发送方必须停发。问题在于，接收方之后腾出了空间，是靠新的 ACK 来通知发送方的；如果这个 ACK 在网络中丢了，发送方会一直等待，接收方也以为发送方还在正常等通知，双方互等，连接就形成了死锁状态。TCP 不能允许这种死锁，所以设计了持久计时器（Persist Timer）：发送方收到零窗口后，并不彻底休眠，而是每隔一段时间主动发一个 1 字节的窗口探测包，逼接收方回一次最新的窗口大小。探测间隔按指数退避增长，从 1.5 秒开始，逐渐翻倍，最大到 60 秒左右。

这个机制对排查连接卡顿很有帮助。用ss -tn观察时，如果 Send-Q 长期堆积而 Recv-Q 为 0，说明数据发出去了但对方没取走；再抓包看到[TCP ZeroWindow]标记和连续的[TCP ZeroWindowProbe]，基本可以判定是接收端应用没有及时调用 recv，而不是网络故障。方向明确，修复动作就简单：提高消费并发度，或者把大块小消息先聚合再处理。

3.3 Nagle 算法和延迟 ACK 的互相伤害

Nagle 算法是为了减少小包泛滥而生的：如果连接上还存在未确认的小包，新到的零碎数据会被临时缓存，等收到 ACK 后合并成一个大包再发送。这个优化在大数据传输场景收益明显，但它和接收方的延迟 ACK 叠加时，会造成一种非常隐蔽的延迟。

接收方为了合并 ACK、减少包数量，会尽量在收到数据后等一小段时间（通常 40ms）再回 ACK；发送方因为 Nagle 要等 ACK 才发缓存的小包。两边都在等，小请求发不出去，ACK 也不回来，交互延迟被拉满。我调过的一个即时通讯长连接就遇到过这问题：登录包只有几十字节，但每次登录要卡 1 到 2 秒。排查确认是 Nagle 与延迟 ACK 叠加，打开TCP_NODELAY之后登录延迟降到 50ms 以内。

提示：TCP_NODELAY关闭的是 Nagle 的小包合并策略，并不是关闭滑动窗口本身的确认和重传机制，请放心在交互型应用中使用。

判断要不要开TCP_NODELAY的标准也很简单：如果你的应用是请求-响应式的，比如 RPC、数据库连接、IM 消息，默认开；如果做的是长时间大块数据传输，比如文件上传、日志同步，Nagle 的合并反而能减少报文头开销，默认关掉即可。实时性要求越高，越要在 socket 选项上尽早做决定，线上再改往往已经影响了用户体验。

4. 滑动窗口和拥塞控制：两个"窗口"不能混为一谈

4.1 rwnd 与 cwnd 的管理者不一样

滑动窗口和拥塞控制是 TCP 可靠性和效率的两大支柱，但因为都用"窗口"这个词，经常被搞混。其实只要分清它们各自在约束谁，就不会乱。接收窗口 rwnd由接收端维护，反映的是接收方缓冲区的剩余空间，目标是不让发送方把接收端打爆；拥塞窗口 cwnd由发送端根据网络反馈动态维护，反映的是发送端对网络路径容量的估算，目标是不让数据把网络打爆。UDP 之所以不需要这两个窗口，是因为 UDP 不提供可靠性保证，丢了就丢，应用层自求多福。

发送方的实际发送窗口是min(rwnd, cwnd)。所以抓包时看到对端 ACK 的窗口字段很大，不代表就能发很多；如果 cwnd 因为丢包被降下来，吞吐照样上不去。反过来也一样，如果 rwnd 很小，cwnd 再大也没用。排查吞吐问题时，判断逻辑非常清晰：先看对端窗口是否小于 BDP，小于则是对端消费能力或缓冲区配置问题；如果窗口足够大，再看抓包里有没有大量 DUP ACK 和快速重传，有则是网络导致的 cwnd 收缩。

4.2 cwnd 的演化方式和 rwnd 完全不同

rwnd 的变化是被动跟随型的：应用层每读走一批数据，接收方就把窗口恢复一部分；缓冲积压了，窗口就降下来。cwnd 则是一个主动探测过程：连接刚开始时从慢启动的指数增长出发，到达阈值后转入线性增长，遇到丢包马上成倍缩小，之后再重新探测。这种激进的动态变化让 cwnd 对网络质量非常敏感，也让它在短时间内的波形远比 rwnd 复杂。

理解了这一点，就不会在排查时把"窗口小"和"流量控制"画等号。有些场景里，对端的 rwnd 一直是 64KB 甚至更大，但抓包里重传频率很高，实际发送窗口频繁被 cwnd 限制。这种问题调大缓冲区没用，应该去查网络质量、中间设备队列和丢包率。两个窗口一起看，才能把传输瓶颈定位准。

4.3 用 Wireshark 验证窗口行为

窗口机制虽然在协议栈内部运转，但抓包能把它的每一步都暴露出来。第一次抓包建议直接抓 TCP 三次握手：SYN 包里能看到双方的 Window scale 协商结果，这个值决定后续窗口字段怎么解读。然后传输阶段，数据包里的 Window 字段表示"发这个包的一方还有多少接收空间"，ACK 包里的 Window 字段则是"对方还能收多少"。两边合起来，可以还原出一个完整的窗口动态图。

常用的筛选命令有这几个：

• tcp.stream eq 0：只看某一条 TCP 流。
• tcp.flags.syn == 1 && tcp.flags.ack == 0：只看第一次握手的 SYN。
• tcp.window_size == 0：直接定位零窗口。
• tcp.analysis.zero_window：Wireshark 对零窗口事件的标记。

我一般会先看[Calculated window size]列，因为它是乘完窗口缩放后的真实窗口。如果这个值偏低而应用层处理又不慢，再去排查系统内核参数；如果这个值始终很高但吞吐很低，重点就转向网络和 cwnd。这个判断顺序能少走很多弯路。

5. 代码实战：用 Python 写一个滑动窗口发送器

5.1 实战目标与环境准备

概念再清楚，不写一遍代码还是隔着一层。这里我用 Python 3 实现一个最小但结构完整的滑动窗口发送端：支持窗口大小可配、累积确认、超时重传，并且可以模拟接收方通告窗口收缩时的流量控制行为。环境只需要 Python 3，不需要任何第三方库，代码可以直接复制运行观察输出。

代码里的序号我用数据块编号来代表，而不是真实字节偏移，这样更容易看清单个段的生命周期。实际 TCP 里，序号就是字节流中的偏移量，实现思路完全一致。需要理解的核心数据结构只有三个：in_flight 字典保存"已发送未确认"的段，base是窗口左边界，next_seq是下一个要分配的序号。

5.2 最小可用的发送端实现

import time class WindowSender: def __init__(self, window_size, timeout=0.3): self.window_size = window_size self.base = 0 # 最早未确认的序号 self.next_seq = 0 # 下一个待分配序号 self.in_flight = {} # seq -> (payload, send_time) self.timeout = timeout def can_send(self): return self.next_seq - self.base < self.window_size def try_send(self, blocks, now): while self.can_send() and self.next_seq < len(blocks): seq = self.next_seq self.in_flight[seq] = (blocks[seq], now) print(f"[SEND] seq={seq}, data={blocks[seq]}, " f"base={self.base}, in_flight={len(self.in_flight)}") self.next_seq += 1 def on_ack(self, ack): if ack > self.base: for seq in list(self.in_flight): if seq < ack: del self.in_flight[seq] self.base = ack print(f"[ACK ] ack={ack}, base推进到{self.base}, " f"in_flight剩余={len(self.in_flight)}") def retransmit_timeout(self, now): for seq, (payload, ts) in list(self.in_flight.items()): if now - ts >= self.timeout: print(f"[RETX] seq={seq} 超时重传") self.in_flight[seq] = (payload, now)

这个类里最关键的是can_send()和on_ack()。can_send()判断当前在途段数是否小于窗口大小，是则允许继续发送；on_ack(ack)实现累积确认，把所有序号小于 ack 的段从 in_flight 里删除，并把 base 推进到 ack。retransmit_timeout()则模拟超时重传，把所有停留在 in_flight 超过 timeout 的段重新记录发送时间，由于模拟环境里时间由外部控制，所以重传逻辑非常直观。

5.3 模拟器：观察不同窗口大小下的发送行为

import random def simulate(window_size, loss_rate=0.0): blocks = [f"pkt-{i}" for i in range(12)] sender = WindowSender(window_size) now = 0.0 random.seed(1) while sender.next_seq < len(blocks) or sender.in_flight: sender.try_send(blocks, now) if sender.in_flight: oldest = min(sender.in_flight) if random.random() > loss_rate: sender.on_ack(oldest + 1) else: print(f"[LOSS] seq={oldest} 丢失，等待超时") now += 0.1 sender.retransmit_timeout(now)

运行simulate(2)时，输出会呈现出非常明显的"发两个，等 ACK，再发两个"的节奏；运行simulate(6)时，前 6 个包几乎全部在第一批发出去，之后 ACK 只是把窗口右边界一步步向前推。这种差异完全来自窗口大小对在途数据量的限制，也就是第一章里链路利用率的直接体现。如果窗口远大于数据块总数，第一批就发完了，后面所有时间都是在等 ACK，链路利用率不会因为窗口无限大而继续提高。

5.4 加入接收方通告窗口：流量控制的动态演示

流量控制本质上就是把can_send()的条件从单纯的"自己的窗口大小"改成"min(自己的窗口大小, 对端通告窗口)"。

class FlowControlSender(WindowSender): def __init__(self, window_size, rwnd=10, timeout=0.3): super().__init__(window_size, timeout) self.rwnd = rwnd def can_send(self): return self.next_seq - self.base < min(self.window_size, self.rwnd) def update_rwnd(self, new_rwnd): self.rwnd = new_rwnd print(f"[RWND] 接收方通告窗口变为 {self.rwnd}") def simulate_flow_control(): blocks = [f"pkt-{i}" for i in range(10)] sender = FlowControlSender(window_size=10, rwnd=5) now = 0.0 shrink_done = False while sender.next_seq < len(blocks) or sender.in_flight: if not shrink_done and sender.next_seq >= 5: sender.update_rwnd(1) # 模拟接收缓冲区快满，收缩通告窗口 shrink_done = True sender.try_send(blocks, now) if sender.in_flight: oldest = min(sender.in_flight) sender.on_ack(oldest + 1) # 假设网络不丢包，只观察窗口约束 now += 0.1 sender.retransmit_timeout(now)

当模拟器把对端通告窗口从 5 收窄到 1 之后，发送端的可发送余量立刻被压制，每个 ACK 只允许一个新段进入窗口。这个输出就是真实 TCP 中"接收方缓冲区不足时发送速率自动下降"的微观过程。你可以把 rwnd 改到 0 试一下，连接会进入零窗口状态，等待接收方恢复空间，这正是上一章讲到的持久计时器所在的状态。

5.5 真实 Socket 程序里怎么感知窗口

真实 TCP Socket 中，滑动窗口默认是内核自动打理的，应用程序一般不需要手动控制每一字节，但可以通过 socket 选项感知和调整缓冲区。

import socket s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) # 获取默认发送/接收缓冲区大小（内核实际通常会翻倍） snd_buf = s.getsockopt(socket.SOL_SOCKET, socket.SO_SNDBUF) rcv_buf = s.getsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF) print(f"SO_SNDBUF={snd_buf}, SO_RCVBUF={rcv_buf}") # 对流式 TCP 关闭 Nagle s.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)

Linux 上设置SO_RCVBUF之后，内核分配的接收缓冲区往往是设置值的两倍左右，这是为了给窗口管理预留额外空间，所以不要用getsockopt的返回值去直接当作窗口大小。还要注意 sysctl 参数net.ipv4.tcp_rmem和net.ipv4.tcp_wmem会进一步影响自动调节范围，不能只改应用层就指望窗口变大。

跑真实服务时，我把SO_SNDBUF和SO_RCVBUF调大过，但吞吐没有提升，抓包才发现瓶颈不在窗口，而是应用层消费线程太少，接收缓冲区一直有积压，rwnd 一直被压得很低。调优的顺序应该是：先保证应用消费速度跟得上，再调内核缓冲区参数，最后才谈流量控制和拥塞控制的细节。顺序错了，参数再大也只是白调。

6. 从一次线上卡死说起：窗口排查的完整链路

6.1 现象：连接正常，吞吐却趋零

有一次我负责的消息系统在高峰期吞吐掉到 0，从ss -tn看连接状态全是 ESTABLISHED，端口一切正常，进程也没挂，但 Send-Q 涨到几百 MB，Recv-Q 一直是 0。第一反应是怀疑网络中断，可 ping 对端完全正常。这种"连接活着但数据不动"的状态，恰恰是窗口机制最容易暴露问题的地方。

6.2 三层排查：先估目标，再看队列，最后抓包

1. 估算 BDP，确立目标窗口：假设 RTT 是 0.2ms，带宽是 10Gbps，BDP 只有约 250KB，目标窗口远小于默认接收缓冲区，可以先把"窗口不够大"这条线排除。
2. 观察队列：ss -tn的 Send-Q 持续堆积、Recv-Q 为 0，说明数据发得出去但对端不取。
3. 抓包确认：对端 ACK 里的 Window 字段从 32KB 一路降到 0，Wireshark 标记连续的[TCP ZeroWindow]和[TCP ZeroWindowProbe]，最终定位是接收端应用没有及时读缓冲区。

这三步的执行顺序很重要。先算 BDP 是为了设定一个合理的"预期窗口"，避免拿 64KB 当标准；再看 Send-Q 和 Recv-Q 能快速区分"发送端积压"和"接收端积压"；最后抓包才是确认机制细节。很多人跳过前两步直接开抓包，容易被一大堆重传和乱序干扰判断。

6.3 修复与验证

定位到根因后，修复动作并不复杂：把接收端单线程消费改成线程池并行消费，并把SO_RCVBUF从 64KB 调到 1MB。重启之后再现测，抓包里能看到 rwnd 从 0 恢复，Send-Q 逐渐回落，吞吐恢复到正常水平。这个案例里没有改任何网络层参数，问题完全出在应用消费速度与窗口恢复速度不匹配。

6.4 常见误区：窗口知识最容易翻车的地方

最后补充一点个人感受：滑动窗口是一个机理清晰、但链条很长的机制。代码一看就懂，真正难的是把 rwnd、cwnd、BDP、应用消费速度、内核参数这些变量放回一个整体里判断。遇到 TCP 传输慢，我建议永远按同样的顺序排查：先估 BDP，再看接收窗口，最后看拥塞和丢包。把顺序固定下来，窗口相关的坑基本都能避开。