可靠数据传输基本原理（3）-滑动窗口

前两篇文章分别解释了可靠性传输要解决的两件事情：

1：数据受损怎么办

2：数据丢失怎么办

可靠性传输核心解决办法：

1：停等协议（等前一个完全确认发送成功后再发送下一组数据）

2：重传（若是传输受损，重传；若是传输丢失，重传）

经过以上两个方法外加序列号，校验等已经实现了可靠性传输。可是有性能问题

停等协议的弊端

 

信道利用率U=传输时间 /传输时间 + RTT。当RTT很大是，传输效率会很是低下。

把信道假设为一条高速公路，停等相似于前一辆车到达终点后下一辆车才能开始进入高速公路，效率可想而知。

引入流水线

再也不以停等的形式进行发送，而是一次传输多个，下图为例，一次性传输三组数据使得信道的利用率提升了三倍。

 

 一样用高速公路做为例子，车子一辆跟着一辆进入高速公路。

停等和流水线运行时状态

 

流水线须要面对的问题

1. 更多的序号，停等0，1就够了。

2.发送的过程当中可能会乱序，发送方最低限度须要缓存已经发送可是没有确认的数据分组，接收方也许也要缓存已经收到的数据。

滑动窗口基本模型

下图为一个基本的滑动窗口在发送端的模型

说明

• 窗口大小为N（窗口的大小在TCP中是在握手的阶段接收方告诉发送方的，后续随着网络状况和接收方读取的速度，会实时进行调整）
• Base下一个等待确认的序号。
• NextSeqNum为下一个即将要发送的序号。

行为

• 发送方缓存了已经发送可是没有确认的数据分组（由于若是超时没有确认，须要从新传递这些数据）
• 当Base对应的序号确认后，窗口向右滑动一格，同时把序号为NextSeqNum对应的数据分组发送出去：Base=Base+1，NextSeqNum=NextSeqNum+1.

滑动窗口之回退N步-GNB（Go-Back-To-N）

• 累计确认：收到一个序号为n的ack，表明接收方已经收到了序号为n以及n之前的所有分组
• 超时，若是发生超时，发送方从新传递全部已经发送可是还未确认的分组
• 接收方丢弃全部失序的分组，若是接收方期待的是N，若是N+1到了，则直接丢弃。

示意图

GBN的好处就是简单，接收方只须要维护一个期待的序列号便可。

最大的问题是资源浪费，上图能够看出即便分组3，4，5被正确接受了，可是由于分组2丢失了，致使2，3，4，5被所有重传。

滑动窗口之选择重传-SR（Selective Repeat）

GBN中接收方直接丢弃失序分组，简单可是资源浪费，SR协议就是为了解决浪费。

解决浪费的核心就是不丢弃失序分组。可是做为接收方，传输层要保证按序把数据传输给上层的应用层，因此相比GBN，SR最大的改造是在接受方增长和缓存。做为发送方，SR在窗口内也有乱序的已经确认的数据分组。

接收方窗口

接收方缓存了正确接收可是乱序的数据。当ReceiveBase(指望的正确分组）到达时，数据会被交付给上层应用，同时接受窗口会移动。Receivebase=ReceiveBase+1

发送方窗口

 示意图

以上，滑动窗口的基本原理已经介绍完毕，经过对比发现，无论时GNB仍是SR，为了保证数据不会乱序，都有一个共同特色：

• 发送方，只有发送Base序号的数据确认后，窗口才会移动
• 接收方，只有接收Base序号的数据收到后，才会把数据交给上层（GNB中，非Base序号的会丢弃。