选择重传（SR）

选择重传协议是另一种流水线rdt协议。与GBN协议最大的区别是当发送方收到一个失序分组时，会将其缓存而非直接丢掉，这样会避免GBN协议中由于可能回退太多导致重新发送的分组数量太大的问题。注意，在SR协议中，由于不会严格规定接收方必须按序接收分组，因此接收方和发送方所看到的窗口可能不会同步，这也会导致一些问题。下面是可能发生的一种情况，不要纠结于细节，只需要知道这种情况可能发生就可以：
在这里插入图片描述
发送方可能发生的事件有：

上层调用：如果窗口内还有空余可用序号，则打包数据并发送；否则缓存或直接拒绝数据。
发生超时事件：为了确保每次只重传一个分组（毕竟SR的一大优势就是避免重传数据太多），要为每个分组设置自己的计时器，当发生超时事件时只需重传超时分组就可以。
收到ACK：发送方标记该分组为已被确认，当send_base序号所在的分组被确认时，可以将窗口向前挪动到下一个未被确认的分组处。

接收方可能发生的事件有：

接收[rcv_base,rcv_base+N-1]的分组：发送ACK，缓存分组，如果是rcv_base处的分组，那么将窗口挪动到下一个未接收到的分组处并将这之前所有接收到的分组按序上传给上一层。
接收[rcv_base-N,rcv_base-1]的分组：这个区间是发送方窗口可能在的区间，为了让接收方窗口尽量同步向前挪动，接收方发送一个ACK以使发送方将该分组标识为确认状态。
其他情况：忽略分组即可。

注意，由于接收方先确认自己收到，然后告知发送方收到的消息（ACK），且ACK报文可能会丢失或损坏，造成信息不同步，因此发送方的窗口可能比接收方滞后，但绝不会领先。
最后我们要考虑可能会发送的一种特殊情况：
在这里插入图片描述
发送方发送了0，1，2三个分组，均被接收，但ACK报文在发送时丢失，造成双方信息不同步；发送方以为超时，重传分组0，但不幸的是，接收方窗口中正好有一个给分组0的位置，因此接收方会以为这是新的分组0，这造成错误。
为了规避这个错误，我们需要将序号空间扩展的足够大，这样的话就可以保证没有重复序号了。在没有重复序号的正常情况下，发送方最多会落后接收方一整个窗口长度，因为这样的话接收方就接收不到任何落在窗口内的分组了，只能等待发送方向前移动窗口。因此，序号空间只要大于等于窗口长度的两倍就可以。
请添加图片描述
我是霜_哀，在算法之路上努力前行的一位萌新，感谢你的阅读！如果觉得好的话，可以关注一下，我会在将来带来更多更全面的知识讲解！