3.4 多帧滑动窗口与后退 N 帧协议

发送方维护一个发送窗口，其大小 $W_s$ 满足 $1 \leq W_s < 2^n$，其中 $n$ 为帧序号的位数。

接收方维护一个接收窗口，其大小固定为 1。

当上层（即网络层）需要发送数据时，发送方先检查发送窗口是否已满，如果未满，则产生一个帧并将其发送；若窗口已满，则向上层回报，要求其稍后再试。

当接收方正确接收到了一个帧时，检查帧的序号是否为所期望接收到的帧序号 $k$，如果是则上交网络层，并向发送方发送确认帧 ACK 确认需要 $k+1$，如果不是则直接丢弃。

流程如下：

• 发送方维护对每个发出去的帧都启动一个超时计时器。

• 当发送方收到接收方序号为 $i$ 的确认帧时，代表接收方已正确接收到序号为 $0 ~ i$ 的帧。

  因此，若在第 $i$ 帧的超时计时器到期之前收到了第 $i$ 帧到确认，若序号 $i$ 大于发送窗口前沿的序号，发送方应将发送窗口前沿移动至序号 $i$。

• 若在第 $i$ 帧的超时计时器到期之前没有收到第 $i$ 帧到确认，则立即重新发送当前发送窗口内所有的帧。

• 发送窗口前沿移动后，若所有超时计时器都未超时，则立即继续发送发送窗口内未发送的帧。

具体的：

表格中例如 [123] 表示当前窗口包含的帧的序号。

发送窗口	发送方	接收方	接收窗口
[---]	维护一个大小为 3 的发送窗口	维护一个大小固定位 1 的接收窗口	[-]
[012]	发送序号为 0 ~ 2 的帧，并对应启动超时计时器		[0]
[012]		收到序号为 0 的帧	[0]
[012]		序号为 0 的帧校验正确，向发送方发送序号为 1 的 ACK 确认帧，并移动接收窗口	[1]
[123]	收到序号为 0 的确认帧，移动发送窗口前沿至序号 1		[1]
[123]		收到序号为 1 的帧	[1]
[123]		未能正确接收序号为 1 的帧，丢弃	[1]
[123]		收到序号为 2 的帧	[1]
[123]		此时期望接收到的帧的序号为 1，丢弃	[1]
[123]	序号为 1 的帧的超时计时器到期，重新发送当前发送窗口中的所有帧（即 1 ~ 3），并对应启动（或重置）超时计时器		[1]
[123]		收到序号为 1 的帧	[1]
[123]		序号为 1 的帧校验正确，向发送方发送序号为 2 的 ACK 确认帧，并移动接收窗口至 2	[2]
[234]	收到序号为 1 的确认帧，移动发送窗口前沿至序号 2		[2]
[234]	此时发送窗口未满，继续发送序号为 4 的帧		[2]
[234]		收到序号为 2 的帧	[2]
[234]		序号为 2 的帧校验正确，向发送方发送序号为 3 的 ACK 确认帧，并移动接收窗口至 3	[3]
[345]	收到序号为 2 的确认帧，移动发送窗口前沿至序号 3		[3]
[345]	此时发送窗口未满，继续发送序号为 5 的帧		[3]
[345]		收到序号为 3 的帧	[3]
[345]		序号为 3 的帧校验正确，向发送方发送序号为 4 的 ACK 确认帧，并移动接收窗口至 4	[4]
[456]	收到序号为 3 的确认帧，移动发送窗口前沿至序号 4		[4]
[456]	此时发送窗口未满，继续发送序号为 6 的帧		[4]
...			...

上述表格中，发送方连续发送了 3 个帧，而接收方一次只能接收 1 个帧，那么关于接收方接收完第 1 个帧之后，第 2 个帧的物理信号立即到达的情况，接收方是否可能来不及处理而直接将其丢弃的问题：实践中接收方通常拥有缓存来存储来不及处理的帧，如果缓存满了或确实来不及处理，确实会将来不及处理的帧丢弃。这种情况不会频繁发生，因此不用过于担心这种情况造成的网络效率下降。

扩展：

• 发送窗口中的报文可能的状态包括：已发送但尚未确认、已发送且已得到确认（选择确认）、已发送但可连续发送。
• 不难看出，如果发送窗口设置的足够大，确实可能出现发送窗口发完之前，超时计时器就到期了的情况，此时会停止继续发送发送窗口内的帧，转而回去重新从发送窗口内第一个帧开始发送。因此超时计时器时间应与发送窗口大小协调设置。