网络的滑动窗口是哪个协议的_TCP采用滑动窗口协议解决了

在学习滑动窗口协议的时候，我在链路层的滑动窗口这吃了不少苦头，因为动态的窗口变化真的不适合看老师发的pdf（话说老师为什么不能发PPT非得发PDF？）

虽然后来摸索着看懂了不少，但是到了窗口大小的问题上又蒙圈了。在GBN（go back n）和SR（select repeat）中，我迷糊了特别久，最后终于搞明白了两者的区别

现在开始看问题：假设发送方和接收方约定好，发送的帧的编号总共有n=3位，也就是说，有三个bit可以用来作为帧的编号，那么就意味着，编号的范围是0~7

一、GBN的发送窗口大小，应该小于等于7，即最大窗口大小<=(2^n)-1

    先看如果大于7，会是什么情况：假设窗口大小等于8：

    发送方给接收方发送了帧编号0A，1A，2A，3A，4A，5A，6A，7A，共计8个帧，接收方均收到，并处理后提交给网络层，并向发送方回馈ACK 0A~7A,并期待下一轮的8个帧0B~7B

然而回馈电路被雷劈了，所以ACK全部丢失，接收方等了好久，没等到确认，认定自己工作失误，发出去的东西没有到达地点，于是重发了之前的0A~7A号帧

但是接收方不知道自己的信道被劈了啊！他还以为自己的ACK（A系列）被对方接收到了，还在喜滋滋等着第二波新帧，没想到来的居然还是上一批老人物。但是接收方脸盲啊，不把熟人当兄弟，一看来的还是八位大爷，打头的正好编号和自己需要的一样，也看不出是不是新来的，就还是全部接收并传给了网络层

这不就出错了吗！

所以我们得想办法防止这种事出现：

窗口如果等于7，就不会有这种狗东行为出现：

发送方发出0A,1A,2A,3A,4A,5A,6A共计7个帧，接收方还是接收并发送A系列的ACK，且依旧全部丢失，发送方超时重传0A~6A

但是这次情况不同了！

接收方发现来的人虽然数量没变，但是编号对不上了啊！自己等的带队的是7爷，怎么来的是0爷？来的人不对，混日子的不是我的兄弟，不收！

于是数据传输断裂，但至少不会出错了……最后黑锅由闪电完美背起，鼓掌

二、选择重传SR的发送窗口大小，应该小于等于4，即最大窗口大小<=2^(n-1)

为什么同样是滑动窗口，你GBN的就可以比我大，我就得比你小？你说你演的比我好，要不你上来咱们比比？刚刚我来的时候还有小朋友问我……不对，串场了

问题的关键在于：选择重传是可以“跳着传”的。

现在我们看，如果SR和GBN的窗口大小一样，会是什么情况

在同样遇到帧丢失的时候，假设我们发送了0~6号帧，并且倒霉的丢掉了2号帧，GBN协议里，接收方没有收到2号帧，就不会发送2号帧的ACK，发送方直接把2到6号全部重传，接收方也不需要担心会不会有重复数据，因为第一批来的3号到6号帧因为少了2号帧，在接收方看来就是一堆废物，直接给丢了去换新的，充分体现了某资本主义大国的浪费作风，需要点名批评。

现在看SR的协议

SR的协议有两个特点：

1.不需要重发错误帧到结尾帧的所有帧，只需要重发错误的2号帧即可，充分体现了社会主义的勤俭节约习惯，点名表扬

2.如果2号帧没有到，那么3~6号虽然会被保留下来，但也不会被传到网络层。一个帧如果能够被传到网络层，前提是比他小的序号的帧都已经被传输到网络层了，类似“让小孩先走”的道理。

所以在2号帧丢失这个问题上，SR和GBN似乎都不会出太大问题

但是还有一种情况：如果和（一）中的问题一样，接收方的ACK全部丢失，会是什么情况？

GBN中，由于直接丢弃+重传，不会受到影响。

但是SR似乎没有这么乐观：假设接收方已经将0A到6A号传给了网络层，但是ACK全部丢失，那么发送方只好重传0A到6A了

但是接收方等待的是7A,0B,1B,2B,3B,4B,5B，一看发送方发来的东西，虽然不是完美贴合我想要的七个葫芦娃们，但是似乎有6个也是编号0到5的……不管来的·是小矮人还是葫芦娃，只要编号对上了，就是我的人……呸，我的帧了。

于是0A到5A又一次被纳入后宫，数据出错

但是如果发送方窗口只有四个呢？

发送方发来了0A到3A，依然没有收到ACK，重发0A~3A

接收方苦等4到7的编号帧，一看发来的一个都没有符合的，不收不收

皆大欢喜，完美！

今天的文章网络的滑动窗口是哪个协议的_TCP采用滑动窗口协议解决了分享到此就结束了，感谢您的阅读。