滑动窗口协议通信场景下最大吞吐量含义及最小吞吐量计算问题

原题题干：主机A通过全双工链路向主机B发送数据，双方采用滑动窗口协议进行流量控制，发送窗口与接收窗口大小均为5个分组。仅由A向B传输的数据包长度均为1000字节，单个数据包的传输时间为50ps；仅由B向A传输的确认包体积极小，传输时间可忽略不计，链路传播延迟为200trrs，请问本次通信可实现的最大吞吐量是多少？

注：题干中50ps、200trrs为明显笔误，常规同题型题设下应为50μs、200μs，否则计算结果不符合网络传输现实逻辑。

「最大吞吐量」的含义 #

你算出的常规理想场景吞吐量就是题干要求的最大吞吐量，这里的「最大」特指满足以下所有理想条件的上限值：

• 无分组丢包、无链路拥塞、无分组乱序
• 接收方B收到分组后立即发送确认帧，无确认延迟
• 发送方A只要发送窗口未满就立即发送新分组，无额外等待开销

这类网络原理计算题默认按上述理想场景计算，所以得到的结果就是最大吞吐量。

最小吞吐量的计算逻辑 #

考试场景下一般不会考察最小吞吐量，它是最差传输条件下的吞吐量下限，通常对应以下几种常见场景：

• 极端丢包场景：如果链路丢包率为100%，所有分组都无法到达接收方，吞吐量直接为0，这是理论最小值。
• 强制停等场景：如果要求发送方每发完1个分组就必须等待该分组的确认返回才能发下一个分组，即使发送窗口还有余量也不能连续发，此时吞吐量=单个分组大小/(传输时间+2*传播时延)，远小于最大吞吐量。
• 累计确认延迟场景：如果接收方不逐帧发确认，而是等接收窗口全满后才发1次累计确认，会额外增加发送方的等待时间，吞吐量会比理想最大值低，具体数值和确认延迟的时长直接相关。

内容的提问来源于stack exchange，提问作者Nikhil Vidhani