3.4可靠数据传输的原理

3.4可靠数据传输的原理

可靠传输的措施：

       一步步的进行研究一系列的协议。

       rdt 1.0认为信道完全可靠，协议最简单发送方只有发送动作，接收方只有接受动作。

       rdt 2.0信道传输数据的时候可能出错，所以根据差错检验，接收方判断数据是否出错，没有错，返回一个ACK报文，出错了返回NAK报文，并且发送方重传。

       rdt 2.1 不管是数据报可能出错，ACK确认报文也可能出错，所以rdt 2.1又加上了序号（0，1）进行判断。

       rdt 2.2 是无NAK的，通过判断ACK是否冗余，判断是否出错。

       rdt 3.0 如果确认报丢包了，那么发送方处于等待接受确认报文状态，不会接受上层的数据进行发送，接收方处于等待接收数据的状态，没有下层的数据。这样就会造成死锁。

       怎么样判断是否丢包了，加上一个倒计数定时器。

       流水线：

              rdt 3.0已经很可靠了，但是还有一个问题，就是浪费问题，发送端发送完数据到接收到确认报文这段时间是完全浪费的。流水线解决了这个问题。

              流水线允许发送方发送多个（有最多限制）分组无需等待确认。措施：

1. 必须增加序号范围，每个运输的分组必须有一个唯一的序号。
2. 协议的发送方和接收方两端必须能缓存多个分组
3. 有差错恢复的方法：回退N步，选择重传

3.4.3 回退N步（GBN）

       流水线允许一个发送多个分组而不需要确认。如下图：

　　

　　

　　黑色：已被确认的分组

       灰色：发送并且未被确认的分组

       浅灰色：可用发送分组

       白色：不可用（也就是在滑动窗口外部的分组）

       定义：基序号（base）为最早未被确认的分组（图中灰色第一个）

                下一个序号（nextseqnum）最小未使用的分组（图中浅灰色第一个）

                窗口大小为N

       流程：

              发送方：

1. 发送端收到上层需要传输的数据请求，检查nextseqnum是否小于base + N – 1（即是否在窗口内），已确定是否窗口内是否还有可用空间。
2. 如果还有可用空间就发送。
3. 没有可用空间，要么缓存，要么返回给上层，以便以后发送。
4. 发送方采取累计确认，窗口内的所有分组都确认，那么窗口移动到窗口末尾的下一个位置。

接收方：

1. 接收方会返回一个确认好ACK（N）表示N之前的分组已经全部收到。
2. 如果n分组丢失，收到n + 1分组，那么会返回ACK（n）表示n分组    之前的分组都收到，并且丢弃n + 1分组（这样做很浪费，在SR中会得到解决）。

3.4.4 选择重传（SR）

       GBN用互动窗口来解决流水线的问题，但是有一个缺点就是，当中间分组发生丢失的时候，会选择丢弃丢失分组之后接收到的分组，实际传输中很浪费时间。

       而SR顾名思义选择重传，会缓存下来丢失分组之后丢失的分组，并且重传丢失的分组。

       如下图：

　　

　　

　　黑色：已确认分组

       灰色：已发送并且未确认分组

       浅灰色：可用分组

       白色：为被确认分组

       定义：基序号（base）为最早未被确认的分组（图中灰色第一个）

                下一个序号（nextseqnum）最小未使用的分组（图中浅灰色第一个）

                窗口大小为N

流程：

       发送方：

1. 发送方从上层接收到数据，SR检查nextsqrnum是否小于base + N – 1
2. 如果是，发送数据
3. 否则，要么缓存，要么返回给上层，以便以后发送。
4. 接收方收到发送方的确认报文ACK（N），判断是否是base（也就是滑动窗口的第一个）
5. 如果是，那么将窗口移动到最小序号未被确认的分组处
6. 如果窗口移动了，如果还有分组落在窗口内并且未被发送，那么发送未被发送分组。

       接收方：

1. 判断分组是否处于base 到 base + N + 1。
2. 如果是，那么返回发送方一个确认报文ACK（N）（冗余的也没事，发送方会根据三次ACK进行丢包判断），如果以前没收到这个报文就进行缓存，如果这个报文序号时base，将base到第一个没确认的报文前 的报文上交。
3. 收到滑动窗口内的报文必须返回一个ACK（N）报文表示N之前的分组已经全部收到
4. 其他情况忽略分组。