📄 一句话概括
停等太慢——滑动窗口让发送方不等 ACK 连发 N 块；窗口大小由接收缓冲余量决定，随 ACK 右滑持续发货。
📝 本节和前面几节的关系
2.3.3/2.3.4 的对账每次都要等；本篇把【等】改成【滑】，吞吐量上一个台阶。
一、滑动的含义
窗口内 N 块可以连续发；确认一块，窗口右滑一格，新块出门。 【滑】的实质：对账照做，只是不用每块都干等。
二、窗口由谁定
接收方缓冲还装得下多少，就开多大窗口—— 这个数写进每个 ACK 的窗口字段通告发送方。 缓冲快满，窗口收窄甚至归零（暂停发送）。
三、动手 Demo：滑动窗口，不等 ACK 也发
窗口＝4 块时的运转：
win = ['1','2','3','4']
for new in range(5, 8):
print('路上:', ' '.join(win))
ack = win.pop(0)
win.append(str(new))
print(' ACK', ack, '确认 -> 第', new, '块出门')
实跑输出：
--------------------------------------------------------------------
滑动窗口，不等 ACK 也发
--------------------------------------------------------------------
停等模式太慢——发一块等一块。窗口一次放行 N 块：
窗口 = 4 块时：
[1][2][3][4] 在路上 （未确认，但已发出）
1 确认 -> 窗口右滑，第 5 块出门
2 确认 -> 滑，第 6 块出门 ...
接收缓冲有多大，窗口就能开多大——
【接收方还能装多少】写进 ACK 的窗口字段告诉发送方。
拥塞窗口（防塞网络）与流量窗口（防压垮收方）取小者—— 教材此处只讲流量侧，拥塞控制在 12 课有总览。
30 秒实验
- Wireshark 抓下载，观察 window 字段变化。
- 算算窗口 65535 字节、RTT 50ms 的理论吞吐。
- 想想收方处理慢了窗口会怎么变。
常见误区
- 以为窗口是网络的能力——它是接收缓冲的余量。
- 以为窗口固定不变——随 ACK 通告动态伸缩。
自测三问（点开对答案）
1. 滑动窗口解决什么问题？ —— 不用逐块干等，提吞吐。 2. 窗口大小由谁决定？ —— 接收缓冲余量（收方通告）。 3. 窗口归零意味着什么？ —— 收方装不下了，暂停发送。- ☐ 下一节（2.3.6 ACK与窗口的合并）
相关笔记
- 用TCP对数据进行分割处理（序列号、ACK号） —— 对账与窗口全图
- ACK与窗口的合并 —— 一包两事的巧劲
- 🔌 网络是怎样连接的 · 索引