大白话解释TCP协议：等等，还有一些TCP协议的基础：滑动窗口协议

为什么滑动窗口协议会出现

首先，我在昨天论述过，停止等待协议在论述的时候是如下的情况：

信道利用率太低了，为了解决信道利用率低的问题，它就仿照HTTP协议采用流水线传输的方式。

发送方在没有收到接收方发的确认包（ACK）的时候可以发多个包

我干嘛要等一个发一个，我发的同时也在收不好吗。

当使用流水线传输的时候有如下两个问题：

• 如何限制住没有收到确认的时候发送方可以发送的数据量？
• 如何防止发的时候产生乱序？

为了解决这些问题：科学大佬们提出了滑动窗口协议

滑动窗口协议的前身：ARQ协议

ARQ协议也可以叫做简单版的滑动窗口协议。
具体步骤是：

• 分组从小到大开始编号
• 发送窗口大小如图所示是5
• 一旦收到了1的确认，串口就向前滑动一个单位
• 如果没有收到1的确认，2、3、4、5的确认就收不到，窗口也不会滑动。
  
  在ARQ协议中：如果收到了1、2号分组，这时候又收到了4号分组，接收方就发送2号的确认，预示发送方重传3号分组。
  这种机制有个名词，叫累积确认
  累积确认：对按序到达的最后一个分组发送确认
  这样的好处是：如果我收到了来自5的确认，那么我就知道1、2、3、4、5号包对方都收到了。中间即使确认丢失了也不必重传
  坏处当然也有：就是不能向发送方反映接收方到底收了多少分组。

比如：发送方发送1、2、3、4、5。但是中间3丢失了，4、5接收方收到了，发送方只收到1、2的确认。于是发送方必须重传3、4、5。相当于4、5重复性传输，会造成资源的浪费。

进入正题：滑动窗口协议GBN和SR

GBN（go back N）：退回N步。
其实GBN就是和上面的累积确认机制差不多：

• 发送方：选定窗口，窗口不满也要填满（窗口不会超过分组量的）。窗口满了就等待确认。如果某个分组出错或者丢失就重新传送某个分组及其后面所有已发送但是未确认的分组
• 接收方：对接收包进行确认，一旦收到错误的包，发送上一个正确的包的确认。

GBN演示：

SR（selective repeat）选择性重传：

• 发送方：某个分组出错或者丢失就只重传该分组。
• 接收方：增加接收缓存窗口，如果乱序了，则缓存该分组，等接收到的包又是按序的，就再重新一起提交。一般接收缓存窗口和发送窗口的大小是一样的
  
  窗口大小和序号的关系：
• GBN窗口的最大值等于序号的个数-1
• SR窗口的最大值等于序号的一半

GBN是累积确认机制，没什么好说的
SR如果窗口太小就会出现如下情况：

若SR窗口为3，序号为4，上述情况接收方无法判断收到的序号为0的分组是重传的0号分组还是新发送的0号分组。

明天就会正式进入到TCP的解释当中了