流水线机制、滑动窗口协议、GBN、SR

一、滑动窗口协议

为了解决停等操作的性能问题（发了一个分组之后一直等到确认了这个分组才发下一个），推出了流水线机制，提供资源利用率。就是允许发送方在收到对方的ACK前，发送多个分组

其中窗口是一个范围管理发出去还没确认的分组，随着不断传输，这个窗口不断滑动，名称的由来。窗口左端的序号收到了ACK，就可以往右滑动了。

滑动窗口协议有GBN、SR

二、滑动窗口协议的实现：GBN

1.分组头部包含序列号

2.窗口如下，大小为N，最多允许N个分组未确认

3.ACK(n),则表示确认从开始到n（包含n）的序列号全部正确接收

4.会空中在传的分组设置一个Timer计时器，处理超时，如果收到了timeout(n)事件，那么会重传的是n以及n以后的所有分组（尽管后面的可能已经收到了，这就是回退，回退到n开始传，GBN）

5.接收方会有一个期望序列号，如果收到的不是期望的分组，直接丢弃

三、滑动窗口协议的实现：SR（选择重传）

GBN缺陷，累积确认机制导致回退到N，重复传了很多。解决这个。

1.对每个分组分别确认，不再只接收期望的，接到不期望的，就先缓存（设置缓存机制），接到期望的才交付上层

2.发送方只需要重传那些没收到ACK的分组了

3.产生了接收方窗口（GBN只有发送方窗口），用来缓存，现在有两窗口了

4.序列号的位数是K的话，那么得满足接收方窗口大小N+发送方N<= 2的k次方，防止因为接收方ACK丢失导致发送重发k号分组，而此时接收方滑到了新窗口，新窗口有新的k号分组（不是原来的，共用序号产生的），导致出错

__EOF__

本文作者：词汇族
本文链接：https://www.cnblogs.com/chz-blogs/p/9526618.html
关于博主：评论和私信会在第一时间回复。或者直接私信我。
版权声明：本博客所有文章除特别声明外，均采用 BY-NC-SA 许可协议。转载请注明出处！
声援博主：如果您觉得文章对您有帮助，可以点击文章右下角【推荐】一下。您的鼓励是博主的最大动力！