流水线机制

例如连续发三个包，然后等待
如下图：

即允许发送方在收到ACK之前连续发送多个分组，但这需要更大的序列号范围，发送方/接收方需要更大的存储空间以缓存分组

滑动窗口协议

窗口：用于管理那些发出去还没有确认的分组，允许使用的序列号范围
窗口尺寸为N，最多有N个等待确认的消息
滑动窗口：随着协议的运行，窗口在序列号空间内向前滑动

窗口左边绿色的部分指已经发送并且已经确认的，窗口中黄色的指已经发出去但还没有收到确认的，若第一个黄色的此时确认消息已返回，则窗口可以右移，窗口中蓝色的代表还可以使用的序列号范围，比如目前窗口大小为14，已发送8个，还有6个序号是可以用的；如果序号都用完了，则需要等待ack到达后窗口右移；白色的指还不能使用的序列号

GBN协议

Go-Back-N协议

发送方

分组头部包含k-bit序列号，也就是有2^k个序列号可用
窗口尺寸为N，即最多允许N个分组未确认
累积确认机制
ACK(n)：确认到序列号n(包含n)的分组均已被正确接收
超时的情况，假设最近一次接收到的ack为n，n+1分组确认消息的接收时间超过时间限制，则重传序列号大于n的并且还没有收到ack的所有分组，可能会造成资源的浪费

接收方

expectedseqnum代表当前期望收到的序列号分组
发送拥有最高序列的、已被正确接收的分组的ACK，对于乱序到达的分组：
直接丢弃->接收方没有缓存|重新确认序列号最大的、按序到达的分组

示例

假定窗口大小为4
此时依次发送0-3号分组，但是2号分组在发送的过程中丢失了，0号分组被正确接收后接收方返回ACK0，并且接收方此时想要接收的分组的序号改为1；1号分组被正确接收后接收方返回ACK1，并且接收方此时想要接受的分组的序号改为2；有人会问了，接收方没有缓存，其实就是一个一个回复的呀，为啥还叫累积确认，并且有些时候ack返回的序号不连续呢？其实不连续已经很好地解释了为什么是累积确认，因为中途ack有丢失的
当3号分组到达接收方时，此时接收方想要接收序号为2的分组，一看不是，则将3号分组丢弃，此时仍然返回一个ACK1（这个ACK1返回时，发送方直接丢弃）
注意根据自动状态机我们知道，当0号分组发出的时候计时器启动，当三号分组发出时，nextseqnum=4，当ACK0返回时，base=1，此时窗口右移一位，如果还有数据要发的话，再发一个4号分组，nextseqnum=5；当ACK1返回时，base=2，此时窗口右移一位，如果还有数据要发的话，再发一个5号分组，nextseqnum=6，但是迟迟没有等到ACK2传回，所以此时计时器超时，重传2、3、4、5号分组

练习题

数据链路层采用后退N帧(GBN)协议，发送方已经发送了编号为0-7的帧时候计时器超时，若发送方此时只收到0、2、3号帧的确认，则发送方需要重发的帧数是多少，分别是哪几个帧？
解：根据GBN协议工作原理，GBN协议的确认是累计确认，所以此时发送端需要重发的帧数是4个，依次分别是4、5、6、7号帧

Selective Repeat协议

GBN缺陷？

当GBN要进行重传的时候，GBN要重复传输很多个分组

改进

接收方对每个分组单独进行确认，设置缓存机制，缓存乱序到达的分组
发送方只重传那些没收到ACK的分组，为每个分组都设置计时器
多了一个接收方的窗口

灰色代表希望收到，但还没收到；红色代表乱序收到的，缓存起来并且发送了ACK
发送方窗口的位置与接收方窗口的位置并不同步
向上图所示的，此时接收窗口最前面的灰的所对应的发送窗口黄的分组前面还有未收到ack的，但是此时接收窗口已经向前移动了，这是为啥呢？是因为ack丢失了，而接收窗口以为发过去了窗口前移导致的，此时若前面那俩黄的超时了，则重传，此时接收窗口依然在收到后为其发送相对应序号的ack

发送方

数据要发送时，检查在此窗口内是否有可用的序号，若有，则用该序号发送；
当一个分组n它的计时器超时了，则将其重发，并且重启它的计时器；
当一个分组n的ack到达了，标记该分组被收到，如果该分组之前被标记为最小的未收到ack的分组，则此时将这个称号移交给下一个没收到ack的分组，并且此时窗口移动到下一个最小的未收到ack的分组

接收方

收到一个分组n，n位于接收窗口内，则发送ack(n)，如果此时n不是顺序的，即n前面依然有分组未发到接收方的，此时接受方将其缓存；如果此时n是顺序的，则将n连同之后连续且受到的分组提交给应用层，接收窗口前移；
像前面所说的，此时收到分组n，但是n的序号要小于接收窗口最前端的序号，此时是因为之前的ack(n)丢失且窗口前移所致，此时重现发送ack(n)即可；
其他情况忽略

示例

窗口大小为4，发送方依次发送0-3号分组
0号分组正确发送，接收方接收，窗口前移，并且返回ACK0；
1号分组正确发送，接收方接收，窗口前移，并且返回ACK1；
2号分组丢失；3号分组正确接收，但是因为2号还未接收，所以此时接收窗口不移动，将其缓存，返回ACK3；
ACK0被发送方接收，窗口前移，此时若有数据发送，则发送4号分组；
ACK1被发送方接收，窗口前移，此时若有数据发送，则发送5号分组；
4号分组被接收，但此时2号还未接收，所以接收窗口不移动将其缓存，返回ACK4；
5号分组被接受，但此时2号还未接收，所以此时窗口不移动将其缓存，返回ACK5；
因为ACK2迟迟未收到，超过计时器，此时发送方重发2号分组，此时ACK3返回，但因为ACK2还未返回，所以将其标记为已接受ack，窗口不移动；
2号分组到达接收方，接收方将其与缓存的3、4、5号分组同时发送给应用层，此时接收窗口前移

困境

像第一个图所示，若窗口大小为3，当发送完0-2号分组后，接收方正确接收，并且窗口移动情况如上所示，并且此时ack全部遗失，此时发送方重新发送0号分组，在第二张图中，也是发送方发送了0分组
开了上帝视角的我们知道是怎么回事，sr协议是无法区分上述两种情况的，即它不知道这个0序号分组是因为ack丢包导致的发送方重发还是正常的发送方发送，由此出现协议状态不唯一，出现不可靠的情况
之所以会导致这个问题，是因为可用序号较少，而窗口又相对较大
序列号空间大小(k bit)与窗口尺寸之间需要满足这种关系：
N_S+N_R<=2^k