简介面向计算机网络课程学习者与相关开发者的编程模拟资源演示如何用socket建立TCP连接在应用层还原数据链路层的1bit滑动窗口协议适合课程实验与自学。资源共2个文件均为C语言源文件压缩包大小仅4KB代码量精简发送端与接收端分开组织完整实现确认等待、超时重传与窗口滑动等核心流程便于快速阅读、调试和二次改造。目前已有1308人学习下载。通过对照源码既能直观理解滑动窗口协议中帧序号变化、确认帧处理等细节也能掌握基于TCP socket的通信编程方法尤其适合完成数据链路层实验或准备课程设计时作为参考。该实现将抽象协议机制转化为可运行程序有助于加深对停等协议与TCP可靠传输异同的认识边读边跑可获得更直观的体会。1. 用 socket 编程模拟滑动窗口协议为什么越像 TCP越容易跑偏用 socket 编程模拟滑动窗口协议直觉上的做法是起一对 TCP 连接给每个包标上序号再按窗口大小一批批发。可真把日志拉出来看时多数人会对着“窗口没动、吞吐没变”发半天呆——发送方明明按窗口发了接收方也说收到了重传一次都没发生过那滑动窗口到底在哪里答案藏在层次里TCP socket 的内核实现已经把滑动窗口的调度、确认、重传全部接管了你应用层写的那套逻辑根本没进入发送路径。滑动窗口不是挂在传输通道上的装饰它决定了发送速率、内存占用以及丢包之后系统怎么恢复。想看清它就得绕开内核里现成的可靠传输在 UDP socket 之上用自定义报文重建这套机制。这也是这次模拟最关键的认知拐点。2. 滑动窗口从 ACK 语义到管道化传输的底层逻辑2.1 停止等待为什么慢一条链路上只能有一个包在途先看没有窗口时最朴素的可靠方案发送一个段等 ACK 回来再发下一个段。假设一个段的发送时延是 T_f往返时延是 RTT 2 × 单程传播时延 T_p那么发送方在一个完整周期里只有 T_f 的时间在真正干活其余时间都在空等。链路利用率 T_f / (T_f 2T_p) ≈ 1 / (1 2a)其中 a T_p / T_f。这个 a 是关键。如果单个段的发送只花 1ms而链路单程传播是 10msa 10利用率只有 4.8%——每 100ms 的链路时间里只有不到 5ms 在传数据。跨广域网的场景里 a 到几十、上百都很常见停等协议的吞吐就被死死摁在了带宽的零头。滑动窗口机制要解决的核心问题就是把这段被迫空闲的等待时间填满让多个段同时驻留在网络中。窗口大小 W 允许 W 个段在未被确认的情况下连续发送链路利用率近似提升到原来的 W 倍。由此得到一个非常重要的工程直觉窗口的理想尺寸不是越大越好而是刚好等于“带宽 × 往返时延”Bandwidth-Delay Product, BDP。100Mbps 的链路、20ms 的 RTTBDP 就是 250KB。窗口比这个小链路喂不饱窗口比这个大多余的数据只会排进网络队列增加时延甚至触发丢包。很多模拟实验里“窗口越大吞吐反而越低”并不是协议写错了而是你自己的链路层模型里塞进了排队丢包。2.2 三个指针切分序号空间SND.UNA、SND.NXT 与窗口边界窗口机制的抽象可以用一个发送状态变量集合描述SND.UNA 是最老的未确认序号SND.NXT 是下一个将要发送的序号两者之间的区间就是“已发送、未确认”的在途数据。发送窗口右边界是 SND.UNA W。于是序号空间被切成三个区段小于 SND.UNA 的部分已经确认发送缓冲可以释放SND.UNA 到 SND.NXT 之间已发出但还没收到 ACK必须保留在缓冲里供重传SND.NXT 到 SND.UNA W 之间窗口还允许发送的“可发送区”。窗口“滑动”这件事经常被误解成一个周期性动作实际上它完全是事件驱动的ACK 到达时 SND.UNA 向右推进发送方腾出发送缓冲应用层才能把新数据排进可发送区。也就是说滑动窗口同时管住了两样东西网络管道里在途数据的数量以及发送缓冲区里待重传数据的生命周期。这里有一个做模拟器时很容易忽略的细节真实 TCP 的窗口字段只有 16 位最大通告 65535 字节。当 BDP 超过 64KB 时必须靠窗口缩放因子WSCALE把实际窗口放大。你的模拟器如果直接把窗口写成字节数的 Python int等于跳过了这个报头约束可一旦报文格式里只放 16 位窗口发送方和接收方之间就必须协商好缩放比。选择哪种方案无所谓但要明确写进设计文档否则改来改去会把自己绕进去。2.3 两个窗口叠加rwnd、cwnd 与真正的发送限制TCP 发送侧的窗口限制不是单独一个而是两个窗口取最小值接收方通过每个报文通告的 rwnd接收窗口和发送方自己维护的 cwnd拥塞窗口。rwnd 保护的是接收缓冲区——发送方不能灌爆接收方的内存cwnd 保护的是网络——发送方不能把中间链路的队列灌爆。实际允许发送的判定条件是if snd_nxt - snd_una min(cwnd, rwnd): send_segment(snd_nxt) snd_nxt len(segment)这条判定是 TCP 每发送一个段时的核心路径。滑动窗口实验里最常见的一个建模错误就是只保留一个固定窗口值把 min(cwnd, rwnd) 简化为常量——这等于假设接收缓冲永远充足、网络永远不拥塞。作为“模拟滑动窗口”的练习简化当然可取但要意识到你模拟的只是流量控制这一半一旦实验结果出现异常先问自己一句我现在到底在调哪个窗口很多困惑都来自把这两个概念混在一起。如果想把拥塞窗口也加进来做对比实验最合适的做法是复刻一个慢启动 拥塞避免的算法模块通过插拔来切换“纯固定窗口”和“带拥塞控制”两种模式。模拟器骨架里窗口大小和窗口类型分开设计后面做吞吐对比时才不会被迫重写。3. 模拟器骨架把窗口状态机变成事件循环3.1 状态变量落地SND.UNA、SND.NXT 与窗口类设计模拟器时我习惯直接从协议的状态变量出发SND.UNA、SND.NXT、SND.WND每个都在类里占一个字段。窗口底和窗口顶都是字节序号窗口大小以字节为单位的做法最贴近真实 TCP 语义。一类一字段的映射方式能让你在排查问题时把日志里打印的每一条 ACK 直接对应到协议状态上。class WindowSender: def __init__(self, sock, max_win, mss1460): self.sock sock self.mss mss self.max_win max_win # 发送窗口大小单位字节 self.snd_una 0 # 最老未确认字节序号 self.snd_nxt 0 # 下一个待发送字节序号 self.outbox {} # seq - payload重传依赖的缓冲 self.rto 0.5 # 超时重传时间秒 self.deadline None # 最早的定时器到期时刻 def window_full(self): return self.snd_nxt - self.snd_una self.max_win def fill_window(self): # 窗口没满就一直发满了就停在原地等 ACK while not self.window_full(): data app_next_chunk(self.mss) if data is None: # 应用层暂时没数据 break seq self.snd_nxt self.outbox[seq] data self._send(seq, data) self.snd_nxt len(data) if self.deadline is None: self.deadline time.time() self.rto注意 seq 是按字节递增的不是按“包序号”递增。这也是新手最容易搞错的境界真实 TCP 的 ACK 和序号都指到字节而不是第几个包。模拟器里如果按包计数第一次把数据切成不等长分片时整个窗口的确认逻辑就会错位。snd_nxt - snd_una 的差就是当前在途的字节数窗口满停发、ACK 到达后继续填这个循环就是滑动窗口的“泵”。3.2 ACK 到达与窗口滑动只有这一个事件能让窗口底部右移窗口滑动的触发点只有一个收到 ACK。发送事件本身不移动窗口底部只是推动顶部。ACK 处理逻辑里要区分三种情况过期 ACK序号小于 SND.UNA、重复 ACK等于 SND.UNA、有效 ACK大于 SND.UNA。def on_ack(self, ack, ack_flags0): if ack self.snd_una: return # 已过期直接忽略 if ack self.snd_una: self.dup_ack[ack] self.dup_ack.get(ack, 0) 1 if self.dup_ack[ack] 3: # 连续 3 次重复 ACK 触发快重传 self._send(self.snd_una, self.outbox[self.snd_una]) return # 有效 ACK窗口底部一次性滑到 ack self.snd_una ack for seq in list(self.outbox): if seq ack: del self.outbox[seq] self.deadline min(self.outbox) self.rto if self.outbox else None # 窗口腾出空间立刻继续填充 self.fill_window()这里值得细看两点。第一处理的是“累计确认”ACK 1000 意味着 1000 之前的所有字节都收到了不管它们是否乱序到达。所以删除 outbox 里的旧段时不能用 for seq in self.outbox 边遍历边删必须先用 list() 快照否则 Python 运行时会在迭代中抱怨字典变了尺寸。第二窗口底部右移后要立刻调用 fill_window()把空出来的窗口位置补上——这是滑动窗口维持管道满流的根本动作。错过这一步吞吐曲线会掉得很难看而且只用日志不好追只能从时序上发现“收到 ACK 之后没有马上发包”。3.3 超时重传定时器只需要一个但重传对象只有一个多数模拟器第一次写超时逻辑时都会在定时器回调里遍历整个 outbox 把所有段重发一遍理由是“这样最保险”。这正是重传风暴的起点。真实 TCP 的超时重传语义是RTO 到期时重传最早未确认的那一个段也就是 SND.UNA 对应的那一段而不是把所有在途数据喷出去。def on_timer_expiry(self): if not self.outbox: return seq min(self.outbox) # 最早的未确认段 self._send(seq, self.outbox[seq]) # 更新 deadline只针对队头段重新计时 self.deadline time.time() self.rto为什么只重传一个因为 TCP 的确认语义是累计的队头段一旦到达接收方返回的 ACK 会直接把窗口底部推到它之后后面那些段即使丢了或被延迟发送方也能通过后续 ACK 的推进感知到。如果一次性把整个窗口重传等于把网络负载瞬间放大窗口倍本来只是轻微拥塞的链路会被你自己压垮。模拟实验里设置 1% 丢包率、窗口 64 段时全量重传会把重传负载放大到接近 64%吞吐率直接崩到接近零而且这个故障从概率上很难定位成“协议逻辑写错”还是“链路模型不对”。定时器的管理也有取舍每个段独立定时器实现直观但 TCP 协议栈不会为每个包各开一个定时器而是在发送控制块里维护最早到期时间。模拟器用一个全局 deadline 变量就足够了它就是“最早的未确认段的超时时刻”。RTO 的初始值建议设成 2 倍实测 RTT并在实验里固定下来先不要上 Karn 算法和自适应 RTO把固定值下的协议行为跑准再谈动态调整。提示RTO 如果设得比实际 RTT 还小会产生非丢包型重传——ACK 还在路上你就重发了而且每次重传都重置计时器造成“RTT 虚高、重传不停”的假象。这是模拟器刚上手时最容易忽视的配置项。4. 为什么用 UDP socket 承载模拟把可靠传输从内核手里拿回来4.1 用 TCP socket 承载模拟得到的是伪模拟TCP socket 的可怕之处在于它太完整了。当你用 send() 把数据交给 TCP socket内核协议栈会负责分段、序号分配、重传定时、拥塞窗口更新、接收端乱序重组。你的用户态代码根本碰不到这些路径能看到的只是 send() 是否阻塞、recv() 返回了什么。在这个前提下再写一套“滑动窗口”逻辑等于让两个协议栈同时工作内核窗口在你的窗口之上叠了一层最终生效的永远是更紧的那一个而你观察到的现象无法归因到任何一层。用 UDP socket 承载模拟情况完全不同sendto 的数据报被原样丢给网络不保证顺序、不保证送达、更没有任何内核对它做可靠性处理。你定义的每一个判断、每一次重传都是自己写出来的逻辑真实执行了。UDP 数据报还有另一个优点每次 sendto 与 recvfrom 的天然边界就是一个“段”省去了在字节流上自行切分段的功夫。把 UDP 当作一条不可靠的包管道在上面堆叠你自己的窗口状态机这才是模拟协议栈的正确姿势。4.2 自定义 PDU在数据报前加一个 9 字节头UDP 只管把数据报从 A 搬到 B不负责携带序号。所以模拟协议的第一步是给每个数据报设计一个头部把 seq、payload 长度、标志位装进去。参照 TCP 头的最小语义我习惯用 9 字节固定头4 字节序号、4 字节负载长度、1 字节标志位。import struct FLAG_ACK 0x04 FLAG_SYN 0x02 FLAG_FIN 0x01 def pack_pkt(seq, data, flags0): # 大端序序号占 4 字节长度占 4 字节标志占 1 字节 return struct.pack(!IIB, seq 0xFFFFFFFF, len(data), flags) data def unpack_pkt(pkt): header struct.unpack(!IIB, pkt[:9]) seq, length, flags header return seq, pkt[9:9 length], flags这个头部的设计动机是让数据报文和纯 ACK 报文共用同一套打包/拆包代码。数据报文里可以捎带 ACK 字段ACK 报文的 seq 字段则可以携带接收方期望的下一字节序号——这与 TCP 头里“确认号”和“序号”分列的思路一致。如果日后想扩展 SACK 选项只需要在头部之后追加可变长度的选项区不影响现有字段的解析。4.3 链路模拟器丢包、乱序、延迟都注入在中间层滑动窗口实验必须能控制网络行为丢包率、延迟抖动、ACK 滞后。这些都不能靠“把两台机器放到不同网段”来近似因为不可控。最稳妥的方案是在发送端和接收端之间插一个转发层由它决定每个包什么时候到、会不会到。import random, time, heapq class LinkEmulator: def __init__(self, loss_rate0.01, delay_jitter(0.01, 0.05)): self.loss_rate loss_rate self.jitter delay_jitter self.queue [] def forward(self, pkt): if random.random() self.loss_rate: return # 直接丢弃模拟丢包 delay random.uniform(*self.jitter) heapq.heappush(self.queue, (time.time() delay, pkt)) def pump(self): now time.time() while self.queue and self.queue[0][0] now: _, pkt heapq.heappop(self.queue) self.sock.sendto(pkt, TARGET_ADDR)丢包逻辑没什么可说的但乱序要单独讲乱序不是靠“交换两个包的位置”生成的而是靠延迟抖动自然涌现的。先发的包如果被分配到一个更大的延迟后发的包就会先到达接收端形成乱序。数值上只要抖动范围大于“包间发送间隔”乱序就会稳定出现。这个设计思路贴近真实网络IP 网络本身不保证排队时延一致抖动就是乱序的来源。ACK 滞后也有专门的注入方式让链路模拟器在识别到 ACK 报文后额外 sleep 一段时间再转发。这样可以在不丢包的情况下制造“超时”现象迫使发送方进入无谓重传——这是验证 RTO 设置和重传抑制逻辑最有用的故障注入手段。4.4 接收方状态机乱序缓存与接收窗口通告接收窗口是滑动窗口协议的另一半很多模拟器只做发送方接收方直接用 recvfrom 然后把数据交给上层导致乱序段到达后直接被丢掉。真正的接收方必须维护 RCV.NXT 和一个乱序缓存。class Receiver: def __init__(self, sock, rcv_buf_size): self.sock sock self.rcv_nxt 0 # 期望接收的下一个字节号 self.rcv_buf_size rcv_buf_size self.leftover {} # seq - data乱序段缓存 def on_data(self, seq, data): if seq self.rcv_nxt: self.rcv_nxt len(data) # 按序到达推进期望号 # 消费缓存里连续的数据把空洞补上 while self.rcv_nxt in self.leftover: chunk self.leftover.pop(self.rcv_nxt) self.rcv_nxt len(chunk) elif seq self.rcv_nxt: self.leftover[seq] data # 乱序段先进缓存 # 窗口通告 缓冲区剩余量 window self.rcv_buf_size - (self.rcv_nxt - self.delivered_upto) self.send_ack(self.rcv_nxt, window)这段逻辑里最关键的是窗口通告的算法接收方通告的 rwnd 是“缓冲区剩余量”不是固定值。如果接收方上层消费数据的速度跟不上剩余量变小发送方的窗口会被压缩这就是流量控制的直接体现。模拟器里如果不模拟上层消费速率窗口通告就永远不变等于把接收缓存当成无限大也就看不见“窗口逐渐缩到零”的真实行为。想复现著名的“零窗口”状态只需要把上层消费速率设为 0接收缓冲区被填满后发送方会停在小窗口下反复用坚持定时器探测——这一步跑通了滑动窗口的流控语义才是完整的。注意链路模拟器和接收端在同一台机器时内核的 UDP 接收缓冲区会先于你的应用层代码接收数据。如果 SO_RCVBUF 太小报文在内核缓冲溢出时被静默丢弃你会观察到“丢包率比设定值高得多”的幻觉。动手实验前先把 socket 的 SO_RCVBUF 调到 2MB 以上让丢包只来自你自己的链路模拟器。5. 模拟器避坑五个最容易翻车的细节5.1 坑一TCP socket 上叠窗口调参调到怀疑人生现象用 TCP 连接承载模拟窗口参数无论怎么调吞吐曲线都纹丝不动。偶尔窗口调大了流量上去了但曲线形状跟协议理论完全对不上。原因内核的窗口控制和拥塞控制接管了所有发送节奏。你写的 fill_window 也许执行了但 send() 返回只是把数据放进内核缓冲真正控制发送节奏的是内核的拥塞窗口和接收通告窗口。你在应用层改的“窗口”根本没进发送路径。解决换用 UDP socket让自定义 PDU 直接进入网络。内核不再有任何可靠性机制介入发送与否完全由应用层窗口状态机决定。5.2 坑二接收方只 recv 不缓存乱序变丢包现象打开乱序模拟后吞吐率骤降重传次数成倍上升。看日志发现接收方动不动就收到“seq 落后于 RCV.NXT”的报文。原因接收方代码直接把 recvfrom 的数据交给上层没有乱序缓存。乱序段到达时接收方误以为是重复数据直接丢弃接收窗口永远停在空洞处发送方就只能靠超时一遍遍重传。解决补上接收状态机——RCV.NXT 加一个 leftover 字典。只有 seq 严格等于 RCV.NXT 的数据才立刻交付seq 大于它的一律先进缓存等空洞补上后再连续上抛。5.3 坑三超时事件把整个窗口全量重发现象设置 1% 丢包率日志里每次超时后同一个 seq 区间被连续发出十几份网络负载暴涨吞吐率跌到接近零。原因on_timer_expiry 里写了类似 for seq in outbox: send(outbox[seq]) 的逻辑。发送方把一个包的丢失放大了整个窗口的重传成本等价于每次丢包都把链路打崩一次。解决超时只重传最早的未确认段干等后续 ACK 的累计推进。如果要做选择性重传SR版本改为每个段维护独立的定时器并按段单独重传GBN 和 SR 两种模式应该在模拟器里做成可配置选项而不是临时改代码。5.4 坑四序号回绕之后比较大小全部失效现象实验跑到一半发送方收到 ACK 后不仅没滑动窗口反而报“ack 小于 SND.UNA”随后开始疯狂重发。重启程序后前半小时一切正常越到后来越乱。原因Python int 无上限模拟器里 seq 一旦超过 0xFFFFFFFF 还继续增长接收方根据真实 TCP 头里的 32 位序号解析时回绕后的数字在数值上看起来变小了被当成过期 ACK 丢弃。解决比较序号时要考虑回绕。常用的判据是模 2^32 差值def seq_after(a, b): # 返回 a 是否在 b 之后按 TCP 序号回绕规则 return ((a - b) % (1 32)) (1 31)只要窗口远小于 2^31 字节这个判据就是可靠的。发送方发出的序号统一做 0xFFFFFFFF比较时用 seq_after 而不是 窗口滑动逻辑在长时间运行下才不会错位。5.5 坑五链路模拟器没插进数据路径丢包参数形同虚设现象loss_rate 设成 0.2跑了一夜一个重传都没发生日志显示所有数据一次送达。原因链路模拟器确实写了但代码路径上发送端直接 sendto 给了接收端转发逻辑根本没有被执行。或者发送端和接收端在同一进程里直接通过函数调用交换报文网络栈完全被绕开。解决把发送端、接收端、链路模拟器拆成三个独立 socket 端点发送端只和链路模拟器通信链路模拟器再和接收端通信。只要报文必须经过转发层丢包和延迟就一定会生效。用进程内线程模拟也要保证数据走的是 socket 收发而不是函数调用的内存传递。写模拟器这件事五个坑里有四个是“协议语义理解偏差”只有一个是环境问题。排错的顺序也应该是先确认数据路径上有没有多余的内核机制在代劳再确认事件处理里有没有把累计确认和全量重传搞混。6. 设计取舍模拟器里哪些“假”值得做滑动窗口模拟器本质上是在一个可控环境里复刻 TCP 的发送/接收状态机但“复刻到多真”是一个值得想清楚的设计决策。做得太真一台机器上同时维护快重传、SACK、WSCALE 协商实验门槛会急剧升高做得太假通过吞吐曲线得出的结论可能误导你对协议的理解。我倾向把取舍做成显式开关特性完整实现简化实现对实验的影响窗口单位字节支持半包窗口段数前者更接近真实 TCP后者画曲线直观快速重传连续 3 个重复 ACK 触发只靠超时不实现时吞吐对丢包反应迟缓乱序确认SACK 选项累计 ACK累计 ACK 下头部阻塞现象更明显RTO 更新Karn 算法 自适应固定 RTO固定值适合验证自适应更接近真实一个合理的折中方案是默认用“字节窗口 固定 RTO 累计 ACK”把快速重传做成配置项。累计 ACK 下一个乱序段会把接收窗口的头部挡住后续所有按序到达的数据都无法确认发送方只能等超时——这是理解 TCP 头部阻塞最基本的实验素材跑通它之后再把快重传打开对比吞吐曲线的差异立刻就能体会到为什么要引入快重传。而 WSCALE 这种涉及连接协商的机制我建议只在做“大窗口”专项实验时再加入。验证模拟器有没有写坏我的做法是固定一组参数跑回归RTT、MSS、窗口 W理论吞吐上界是 W / RTT。把实测吞吐除以这个上界如果利用率稳定在 90% 以下优先怀疑状态机逻辑而不是链路丢包——因为丢包率只有 0.1% 时一个正确的滑动窗口实现不应该让吞吐掉这么多。这个比率能过滤掉绝大多数“看似正常但实际协议逻辑有 bug”的版本。从那以后我每改一次窗口处理逻辑都强制把回归脚本完整跑一遍再手动构造一次丢包场景看日志里的 SND.UNA 有没有按预期推进。这个习惯救过我很多次希望帮到你。本文还有配套的精品资源点击获取
简介面向计算机网络课程学习者与相关开发者的编程模拟资源演示如何用socket建立TCP连接在应用层还原数据链路层的1bit滑动窗口协议适合课程实验与自学。资源共2个文件均为C语言源文件压缩包大小仅4KB代码量精简发送端与接收端分开组织完整实现确认等待、超时重传与窗口滑动等核心流程便于快速阅读、调试和二次改造。目前已有1308人学习下载。通过对照源码既能直观理解滑动窗口协议中帧序号变化、确认帧处理等细节也能掌握基于TCP socket的通信编程方法尤其适合完成数据链路层实验或准备课程设计时作为参考。该实现将抽象协议机制转化为可运行程序有助于加深对停等协议与TCP可靠传输异同的认识边读边跑可获得更直观的体会。1. 用 socket 编程模拟滑动窗口协议为什么越像 TCP越容易跑偏用 socket 编程模拟滑动窗口协议直觉上的做法是起一对 TCP 连接给每个包标上序号再按窗口大小一批批发。可真把日志拉出来看时多数人会对着“窗口没动、吞吐没变”发半天呆——发送方明明按窗口发了接收方也说收到了重传一次都没发生过那滑动窗口到底在哪里答案藏在层次里TCP socket 的内核实现已经把滑动窗口的调度、确认、重传全部接管了你应用层写的那套逻辑根本没进入发送路径。滑动窗口不是挂在传输通道上的装饰它决定了发送速率、内存占用以及丢包之后系统怎么恢复。想看清它就得绕开内核里现成的可靠传输在 UDP socket 之上用自定义报文重建这套机制。这也是这次模拟最关键的认知拐点。2. 滑动窗口从 ACK 语义到管道化传输的底层逻辑2.1 停止等待为什么慢一条链路上只能有一个包在途先看没有窗口时最朴素的可靠方案发送一个段等 ACK 回来再发下一个段。假设一个段的发送时延是 T_f往返时延是 RTT 2 × 单程传播时延 T_p那么发送方在一个完整周期里只有 T_f 的时间在真正干活其余时间都在空等。链路利用率 T_f / (T_f 2T_p) ≈ 1 / (1 2a)其中 a T_p / T_f。这个 a 是关键。如果单个段的发送只花 1ms而链路单程传播是 10msa 10利用率只有 4.8%——每 100ms 的链路时间里只有不到 5ms 在传数据。跨广域网的场景里 a 到几十、上百都很常见停等协议的吞吐就被死死摁在了带宽的零头。滑动窗口机制要解决的核心问题就是把这段被迫空闲的等待时间填满让多个段同时驻留在网络中。窗口大小 W 允许 W 个段在未被确认的情况下连续发送链路利用率近似提升到原来的 W 倍。由此得到一个非常重要的工程直觉窗口的理想尺寸不是越大越好而是刚好等于“带宽 × 往返时延”Bandwidth-Delay Product, BDP。100Mbps 的链路、20ms 的 RTTBDP 就是 250KB。窗口比这个小链路喂不饱窗口比这个大多余的数据只会排进网络队列增加时延甚至触发丢包。很多模拟实验里“窗口越大吞吐反而越低”并不是协议写错了而是你自己的链路层模型里塞进了排队丢包。2.2 三个指针切分序号空间SND.UNA、SND.NXT 与窗口边界窗口机制的抽象可以用一个发送状态变量集合描述SND.UNA 是最老的未确认序号SND.NXT 是下一个将要发送的序号两者之间的区间就是“已发送、未确认”的在途数据。发送窗口右边界是 SND.UNA W。于是序号空间被切成三个区段小于 SND.UNA 的部分已经确认发送缓冲可以释放SND.UNA 到 SND.NXT 之间已发出但还没收到 ACK必须保留在缓冲里供重传SND.NXT 到 SND.UNA W 之间窗口还允许发送的“可发送区”。窗口“滑动”这件事经常被误解成一个周期性动作实际上它完全是事件驱动的ACK 到达时 SND.UNA 向右推进发送方腾出发送缓冲应用层才能把新数据排进可发送区。也就是说滑动窗口同时管住了两样东西网络管道里在途数据的数量以及发送缓冲区里待重传数据的生命周期。这里有一个做模拟器时很容易忽略的细节真实 TCP 的窗口字段只有 16 位最大通告 65535 字节。当 BDP 超过 64KB 时必须靠窗口缩放因子WSCALE把实际窗口放大。你的模拟器如果直接把窗口写成字节数的 Python int等于跳过了这个报头约束可一旦报文格式里只放 16 位窗口发送方和接收方之间就必须协商好缩放比。选择哪种方案无所谓但要明确写进设计文档否则改来改去会把自己绕进去。2.3 两个窗口叠加rwnd、cwnd 与真正的发送限制TCP 发送侧的窗口限制不是单独一个而是两个窗口取最小值接收方通过每个报文通告的 rwnd接收窗口和发送方自己维护的 cwnd拥塞窗口。rwnd 保护的是接收缓冲区——发送方不能灌爆接收方的内存cwnd 保护的是网络——发送方不能把中间链路的队列灌爆。实际允许发送的判定条件是if snd_nxt - snd_una min(cwnd, rwnd): send_segment(snd_nxt) snd_nxt len(segment)这条判定是 TCP 每发送一个段时的核心路径。滑动窗口实验里最常见的一个建模错误就是只保留一个固定窗口值把 min(cwnd, rwnd) 简化为常量——这等于假设接收缓冲永远充足、网络永远不拥塞。作为“模拟滑动窗口”的练习简化当然可取但要意识到你模拟的只是流量控制这一半一旦实验结果出现异常先问自己一句我现在到底在调哪个窗口很多困惑都来自把这两个概念混在一起。如果想把拥塞窗口也加进来做对比实验最合适的做法是复刻一个慢启动 拥塞避免的算法模块通过插拔来切换“纯固定窗口”和“带拥塞控制”两种模式。模拟器骨架里窗口大小和窗口类型分开设计后面做吞吐对比时才不会被迫重写。3. 模拟器骨架把窗口状态机变成事件循环3.1 状态变量落地SND.UNA、SND.NXT 与窗口类设计模拟器时我习惯直接从协议的状态变量出发SND.UNA、SND.NXT、SND.WND每个都在类里占一个字段。窗口底和窗口顶都是字节序号窗口大小以字节为单位的做法最贴近真实 TCP 语义。一类一字段的映射方式能让你在排查问题时把日志里打印的每一条 ACK 直接对应到协议状态上。class WindowSender: def __init__(self, sock, max_win, mss1460): self.sock sock self.mss mss self.max_win max_win # 发送窗口大小单位字节 self.snd_una 0 # 最老未确认字节序号 self.snd_nxt 0 # 下一个待发送字节序号 self.outbox {} # seq - payload重传依赖的缓冲 self.rto 0.5 # 超时重传时间秒 self.deadline None # 最早的定时器到期时刻 def window_full(self): return self.snd_nxt - self.snd_una self.max_win def fill_window(self): # 窗口没满就一直发满了就停在原地等 ACK while not self.window_full(): data app_next_chunk(self.mss) if data is None: # 应用层暂时没数据 break seq self.snd_nxt self.outbox[seq] data self._send(seq, data) self.snd_nxt len(data) if self.deadline is None: self.deadline time.time() self.rto注意 seq 是按字节递增的不是按“包序号”递增。这也是新手最容易搞错的境界真实 TCP 的 ACK 和序号都指到字节而不是第几个包。模拟器里如果按包计数第一次把数据切成不等长分片时整个窗口的确认逻辑就会错位。snd_nxt - snd_una 的差就是当前在途的字节数窗口满停发、ACK 到达后继续填这个循环就是滑动窗口的“泵”。3.2 ACK 到达与窗口滑动只有这一个事件能让窗口底部右移窗口滑动的触发点只有一个收到 ACK。发送事件本身不移动窗口底部只是推动顶部。ACK 处理逻辑里要区分三种情况过期 ACK序号小于 SND.UNA、重复 ACK等于 SND.UNA、有效 ACK大于 SND.UNA。def on_ack(self, ack, ack_flags0): if ack self.snd_una: return # 已过期直接忽略 if ack self.snd_una: self.dup_ack[ack] self.dup_ack.get(ack, 0) 1 if self.dup_ack[ack] 3: # 连续 3 次重复 ACK 触发快重传 self._send(self.snd_una, self.outbox[self.snd_una]) return # 有效 ACK窗口底部一次性滑到 ack self.snd_una ack for seq in list(self.outbox): if seq ack: del self.outbox[seq] self.deadline min(self.outbox) self.rto if self.outbox else None # 窗口腾出空间立刻继续填充 self.fill_window()这里值得细看两点。第一处理的是“累计确认”ACK 1000 意味着 1000 之前的所有字节都收到了不管它们是否乱序到达。所以删除 outbox 里的旧段时不能用 for seq in self.outbox 边遍历边删必须先用 list() 快照否则 Python 运行时会在迭代中抱怨字典变了尺寸。第二窗口底部右移后要立刻调用 fill_window()把空出来的窗口位置补上——这是滑动窗口维持管道满流的根本动作。错过这一步吞吐曲线会掉得很难看而且只用日志不好追只能从时序上发现“收到 ACK 之后没有马上发包”。3.3 超时重传定时器只需要一个但重传对象只有一个多数模拟器第一次写超时逻辑时都会在定时器回调里遍历整个 outbox 把所有段重发一遍理由是“这样最保险”。这正是重传风暴的起点。真实 TCP 的超时重传语义是RTO 到期时重传最早未确认的那一个段也就是 SND.UNA 对应的那一段而不是把所有在途数据喷出去。def on_timer_expiry(self): if not self.outbox: return seq min(self.outbox) # 最早的未确认段 self._send(seq, self.outbox[seq]) # 更新 deadline只针对队头段重新计时 self.deadline time.time() self.rto为什么只重传一个因为 TCP 的确认语义是累计的队头段一旦到达接收方返回的 ACK 会直接把窗口底部推到它之后后面那些段即使丢了或被延迟发送方也能通过后续 ACK 的推进感知到。如果一次性把整个窗口重传等于把网络负载瞬间放大窗口倍本来只是轻微拥塞的链路会被你自己压垮。模拟实验里设置 1% 丢包率、窗口 64 段时全量重传会把重传负载放大到接近 64%吞吐率直接崩到接近零而且这个故障从概率上很难定位成“协议逻辑写错”还是“链路模型不对”。定时器的管理也有取舍每个段独立定时器实现直观但 TCP 协议栈不会为每个包各开一个定时器而是在发送控制块里维护最早到期时间。模拟器用一个全局 deadline 变量就足够了它就是“最早的未确认段的超时时刻”。RTO 的初始值建议设成 2 倍实测 RTT并在实验里固定下来先不要上 Karn 算法和自适应 RTO把固定值下的协议行为跑准再谈动态调整。提示RTO 如果设得比实际 RTT 还小会产生非丢包型重传——ACK 还在路上你就重发了而且每次重传都重置计时器造成“RTT 虚高、重传不停”的假象。这是模拟器刚上手时最容易忽视的配置项。4. 为什么用 UDP socket 承载模拟把可靠传输从内核手里拿回来4.1 用 TCP socket 承载模拟得到的是伪模拟TCP socket 的可怕之处在于它太完整了。当你用 send() 把数据交给 TCP socket内核协议栈会负责分段、序号分配、重传定时、拥塞窗口更新、接收端乱序重组。你的用户态代码根本碰不到这些路径能看到的只是 send() 是否阻塞、recv() 返回了什么。在这个前提下再写一套“滑动窗口”逻辑等于让两个协议栈同时工作内核窗口在你的窗口之上叠了一层最终生效的永远是更紧的那一个而你观察到的现象无法归因到任何一层。用 UDP socket 承载模拟情况完全不同sendto 的数据报被原样丢给网络不保证顺序、不保证送达、更没有任何内核对它做可靠性处理。你定义的每一个判断、每一次重传都是自己写出来的逻辑真实执行了。UDP 数据报还有另一个优点每次 sendto 与 recvfrom 的天然边界就是一个“段”省去了在字节流上自行切分段的功夫。把 UDP 当作一条不可靠的包管道在上面堆叠你自己的窗口状态机这才是模拟协议栈的正确姿势。4.2 自定义 PDU在数据报前加一个 9 字节头UDP 只管把数据报从 A 搬到 B不负责携带序号。所以模拟协议的第一步是给每个数据报设计一个头部把 seq、payload 长度、标志位装进去。参照 TCP 头的最小语义我习惯用 9 字节固定头4 字节序号、4 字节负载长度、1 字节标志位。import struct FLAG_ACK 0x04 FLAG_SYN 0x02 FLAG_FIN 0x01 def pack_pkt(seq, data, flags0): # 大端序序号占 4 字节长度占 4 字节标志占 1 字节 return struct.pack(!IIB, seq 0xFFFFFFFF, len(data), flags) data def unpack_pkt(pkt): header struct.unpack(!IIB, pkt[:9]) seq, length, flags header return seq, pkt[9:9 length], flags这个头部的设计动机是让数据报文和纯 ACK 报文共用同一套打包/拆包代码。数据报文里可以捎带 ACK 字段ACK 报文的 seq 字段则可以携带接收方期望的下一字节序号——这与 TCP 头里“确认号”和“序号”分列的思路一致。如果日后想扩展 SACK 选项只需要在头部之后追加可变长度的选项区不影响现有字段的解析。4.3 链路模拟器丢包、乱序、延迟都注入在中间层滑动窗口实验必须能控制网络行为丢包率、延迟抖动、ACK 滞后。这些都不能靠“把两台机器放到不同网段”来近似因为不可控。最稳妥的方案是在发送端和接收端之间插一个转发层由它决定每个包什么时候到、会不会到。import random, time, heapq class LinkEmulator: def __init__(self, loss_rate0.01, delay_jitter(0.01, 0.05)): self.loss_rate loss_rate self.jitter delay_jitter self.queue [] def forward(self, pkt): if random.random() self.loss_rate: return # 直接丢弃模拟丢包 delay random.uniform(*self.jitter) heapq.heappush(self.queue, (time.time() delay, pkt)) def pump(self): now time.time() while self.queue and self.queue[0][0] now: _, pkt heapq.heappop(self.queue) self.sock.sendto(pkt, TARGET_ADDR)丢包逻辑没什么可说的但乱序要单独讲乱序不是靠“交换两个包的位置”生成的而是靠延迟抖动自然涌现的。先发的包如果被分配到一个更大的延迟后发的包就会先到达接收端形成乱序。数值上只要抖动范围大于“包间发送间隔”乱序就会稳定出现。这个设计思路贴近真实网络IP 网络本身不保证排队时延一致抖动就是乱序的来源。ACK 滞后也有专门的注入方式让链路模拟器在识别到 ACK 报文后额外 sleep 一段时间再转发。这样可以在不丢包的情况下制造“超时”现象迫使发送方进入无谓重传——这是验证 RTO 设置和重传抑制逻辑最有用的故障注入手段。4.4 接收方状态机乱序缓存与接收窗口通告接收窗口是滑动窗口协议的另一半很多模拟器只做发送方接收方直接用 recvfrom 然后把数据交给上层导致乱序段到达后直接被丢掉。真正的接收方必须维护 RCV.NXT 和一个乱序缓存。class Receiver: def __init__(self, sock, rcv_buf_size): self.sock sock self.rcv_nxt 0 # 期望接收的下一个字节号 self.rcv_buf_size rcv_buf_size self.leftover {} # seq - data乱序段缓存 def on_data(self, seq, data): if seq self.rcv_nxt: self.rcv_nxt len(data) # 按序到达推进期望号 # 消费缓存里连续的数据把空洞补上 while self.rcv_nxt in self.leftover: chunk self.leftover.pop(self.rcv_nxt) self.rcv_nxt len(chunk) elif seq self.rcv_nxt: self.leftover[seq] data # 乱序段先进缓存 # 窗口通告 缓冲区剩余量 window self.rcv_buf_size - (self.rcv_nxt - self.delivered_upto) self.send_ack(self.rcv_nxt, window)这段逻辑里最关键的是窗口通告的算法接收方通告的 rwnd 是“缓冲区剩余量”不是固定值。如果接收方上层消费数据的速度跟不上剩余量变小发送方的窗口会被压缩这就是流量控制的直接体现。模拟器里如果不模拟上层消费速率窗口通告就永远不变等于把接收缓存当成无限大也就看不见“窗口逐渐缩到零”的真实行为。想复现著名的“零窗口”状态只需要把上层消费速率设为 0接收缓冲区被填满后发送方会停在小窗口下反复用坚持定时器探测——这一步跑通了滑动窗口的流控语义才是完整的。注意链路模拟器和接收端在同一台机器时内核的 UDP 接收缓冲区会先于你的应用层代码接收数据。如果 SO_RCVBUF 太小报文在内核缓冲溢出时被静默丢弃你会观察到“丢包率比设定值高得多”的幻觉。动手实验前先把 socket 的 SO_RCVBUF 调到 2MB 以上让丢包只来自你自己的链路模拟器。5. 模拟器避坑五个最容易翻车的细节5.1 坑一TCP socket 上叠窗口调参调到怀疑人生现象用 TCP 连接承载模拟窗口参数无论怎么调吞吐曲线都纹丝不动。偶尔窗口调大了流量上去了但曲线形状跟协议理论完全对不上。原因内核的窗口控制和拥塞控制接管了所有发送节奏。你写的 fill_window 也许执行了但 send() 返回只是把数据放进内核缓冲真正控制发送节奏的是内核的拥塞窗口和接收通告窗口。你在应用层改的“窗口”根本没进发送路径。解决换用 UDP socket让自定义 PDU 直接进入网络。内核不再有任何可靠性机制介入发送与否完全由应用层窗口状态机决定。5.2 坑二接收方只 recv 不缓存乱序变丢包现象打开乱序模拟后吞吐率骤降重传次数成倍上升。看日志发现接收方动不动就收到“seq 落后于 RCV.NXT”的报文。原因接收方代码直接把 recvfrom 的数据交给上层没有乱序缓存。乱序段到达时接收方误以为是重复数据直接丢弃接收窗口永远停在空洞处发送方就只能靠超时一遍遍重传。解决补上接收状态机——RCV.NXT 加一个 leftover 字典。只有 seq 严格等于 RCV.NXT 的数据才立刻交付seq 大于它的一律先进缓存等空洞补上后再连续上抛。5.3 坑三超时事件把整个窗口全量重发现象设置 1% 丢包率日志里每次超时后同一个 seq 区间被连续发出十几份网络负载暴涨吞吐率跌到接近零。原因on_timer_expiry 里写了类似 for seq in outbox: send(outbox[seq]) 的逻辑。发送方把一个包的丢失放大了整个窗口的重传成本等价于每次丢包都把链路打崩一次。解决超时只重传最早的未确认段干等后续 ACK 的累计推进。如果要做选择性重传SR版本改为每个段维护独立的定时器并按段单独重传GBN 和 SR 两种模式应该在模拟器里做成可配置选项而不是临时改代码。5.4 坑四序号回绕之后比较大小全部失效现象实验跑到一半发送方收到 ACK 后不仅没滑动窗口反而报“ack 小于 SND.UNA”随后开始疯狂重发。重启程序后前半小时一切正常越到后来越乱。原因Python int 无上限模拟器里 seq 一旦超过 0xFFFFFFFF 还继续增长接收方根据真实 TCP 头里的 32 位序号解析时回绕后的数字在数值上看起来变小了被当成过期 ACK 丢弃。解决比较序号时要考虑回绕。常用的判据是模 2^32 差值def seq_after(a, b): # 返回 a 是否在 b 之后按 TCP 序号回绕规则 return ((a - b) % (1 32)) (1 31)只要窗口远小于 2^31 字节这个判据就是可靠的。发送方发出的序号统一做 0xFFFFFFFF比较时用 seq_after 而不是 窗口滑动逻辑在长时间运行下才不会错位。5.5 坑五链路模拟器没插进数据路径丢包参数形同虚设现象loss_rate 设成 0.2跑了一夜一个重传都没发生日志显示所有数据一次送达。原因链路模拟器确实写了但代码路径上发送端直接 sendto 给了接收端转发逻辑根本没有被执行。或者发送端和接收端在同一进程里直接通过函数调用交换报文网络栈完全被绕开。解决把发送端、接收端、链路模拟器拆成三个独立 socket 端点发送端只和链路模拟器通信链路模拟器再和接收端通信。只要报文必须经过转发层丢包和延迟就一定会生效。用进程内线程模拟也要保证数据走的是 socket 收发而不是函数调用的内存传递。写模拟器这件事五个坑里有四个是“协议语义理解偏差”只有一个是环境问题。排错的顺序也应该是先确认数据路径上有没有多余的内核机制在代劳再确认事件处理里有没有把累计确认和全量重传搞混。6. 设计取舍模拟器里哪些“假”值得做滑动窗口模拟器本质上是在一个可控环境里复刻 TCP 的发送/接收状态机但“复刻到多真”是一个值得想清楚的设计决策。做得太真一台机器上同时维护快重传、SACK、WSCALE 协商实验门槛会急剧升高做得太假通过吞吐曲线得出的结论可能误导你对协议的理解。我倾向把取舍做成显式开关特性完整实现简化实现对实验的影响窗口单位字节支持半包窗口段数前者更接近真实 TCP后者画曲线直观快速重传连续 3 个重复 ACK 触发只靠超时不实现时吞吐对丢包反应迟缓乱序确认SACK 选项累计 ACK累计 ACK 下头部阻塞现象更明显RTO 更新Karn 算法 自适应固定 RTO固定值适合验证自适应更接近真实一个合理的折中方案是默认用“字节窗口 固定 RTO 累计 ACK”把快速重传做成配置项。累计 ACK 下一个乱序段会把接收窗口的头部挡住后续所有按序到达的数据都无法确认发送方只能等超时——这是理解 TCP 头部阻塞最基本的实验素材跑通它之后再把快重传打开对比吞吐曲线的差异立刻就能体会到为什么要引入快重传。而 WSCALE 这种涉及连接协商的机制我建议只在做“大窗口”专项实验时再加入。验证模拟器有没有写坏我的做法是固定一组参数跑回归RTT、MSS、窗口 W理论吞吐上界是 W / RTT。把实测吞吐除以这个上界如果利用率稳定在 90% 以下优先怀疑状态机逻辑而不是链路丢包——因为丢包率只有 0.1% 时一个正确的滑动窗口实现不应该让吞吐掉这么多。这个比率能过滤掉绝大多数“看似正常但实际协议逻辑有 bug”的版本。从那以后我每改一次窗口处理逻辑都强制把回归脚本完整跑一遍再手动构造一次丢包场景看日志里的 SND.UNA 有没有按预期推进。这个习惯救过我很多次希望帮到你。本文还有配套的精品资源点击获取
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
