Video在线视频

各位好

我们之前学到的三个模拟协议呢

都是单工协议

数据从发方流向接收方

最多也就是一个半双工的协议

也就是说反向有一个反馈

那么这种协议工作的时候呢

信道的利用率特别的低

所以我们其实可以在

等待对方确认的时候

继续发数据

这种发送数据的方法呢

叫做批量发送

或者叫管道化技术

它可以一次性地发若干个数据

这若干个数据

其实就是一个窗口的数据

发完这个窗口

又发下一个窗口

移动窗口再发下一个窗口的数据

那么这种技术呢

我们有的时候把它叫做滑窗技术

叫sliding window

我们的协议四到协议六

就是滑窗技术

协议四呢通过窗口等于一

来引出滑窗的一些基本概念

协议五和协议六

分别对应着批量传输数据之后出错

怎么办

采用了两种策略

对应着这两种协议

一个是协议五 回退n帧

一个是协议六选择性重传

滑窗技术里边非常关键的

就是有两个窗口

一个是发送窗口

发送窗口对应着已经发送

但还未被确认的帧的序列号

而接收窗口呢

对应着期望接收的帧它的序列号

我们用一个窗口大小为1这个例子

来说明滑窗它是怎么滑的

怎么工作的

我们来看一下这两个图

上面呢是发送方

下面呢是接收方

最开始的时候

发送还没有发数据

但是接收方已经开始准备好

接收数据了

所以没有发送窗口

但是有一个接收窗口

它的接收窗口的序列号是0

表明它期望对方第一次发0号帧

过来

好了到了下一个时刻呢

发送方发送了0号帧

也就是它的第一帧发出去了

这一帧在路上走的时候

我们看当它发出去这一帧之后

发送窗口就发生了变化

它已经有了一个窗口了

所以发送窗口里边

其实储存的这个发送的帧

但还未被确认

接着下来到了下一个时刻

在这个时刻呢

发送的那一帧到达了接收方

接收方发现收到的这一帧

它的序列号是0号

正是它期待的那一帧

所以它把它收下了

同时呢它移动了它的接收窗口

所以我们会看到

那个窗口已经向下滑动了

在滑动窗口的同时呢

它还做了一件事情

就是回发了一个确认

当这个确认帧到了发送方之后

发送方发现这个确认号

正是它的发送窗口

发的那一帧的序列号就知道

它刚刚发的那一帧

已经被对方正确地接收了

所以呢它就可以往下滑动

它的发送窗口了

那么我们来看一看

窗口滑动的条件

接收方收到帧之后

它首先去核对

收到的这一帧它的序列号

是不是它期待接收的帧号

期待接收的帧号

它用了一个变量来表示

叫做 frame expected

如果是的话

它就接收这一帧

因为正是它期待的那一帧

接收了之后呢

它就向下滑动它的窗口

移动它的窗口

怎么移呢

就是把这个变量加1

frame_expected加1

而发送方呢

它的窗口是怎么移的呢

它收到应答帧的时候

它会去核对

这个确认帧号

是不是它的next_frame_to_send

这个变量的值

也就是说是不是它曾经发出去的

那个帧的号码

如果是的话

它就知道说

它曾经发出去的那一帧

已经被对方正确地接收了

它现在可以组新的帧

来发送下一帧了

所以它可以移动它的窗口了

窗口移动的方法

就是对它的这个变量进行加1

next_frame_to_send加1

我们来看一看这个程序

这个程序呢比较长

我们只看其中比较重要的部分

注意到没有

程序的名称

已经不再分sender receiver两部分了

它就只有一个

protocol4

也就是说发方和收方

没有明显的界限了

通信的双方互相收发

互为收发方

那么在这个程序里头

它定义了非常多的变量

有些就是前几个协议都用到的

那么还有一些是前几个协议没有的

比如说next_frame_to_send

这个变量它把它初始化为0

就表明说

第一帧要从0号帧开始发送

还有一个变量呢叫frame_expected

这个变量呢

它也把它初始化为0

表明说接收方它开始期待接收的是

对方发过来的0号帧

第一号帧

接下来呢在这个无限循环里面

while (true)的这个无限循环里面

它也增加了很多东西

其中非常重要的就是

窗口的判断条件和移动这个窗口

我们先来看接收窗口

接收窗口呢要移动

就是要判定收到的帧它的序列号

是不是它期待的那个号码

所以它用了一个语句叫if

到达的那个帧r.seq

等于frame_expected

只要满足这个条件

我们说它就可以滑动窗口了

怎么滑呢

调用了一个宏inc

调用这个宏

对frame expected这个参数加1

因为我们的序列号不见得是

一个比特表示的

有可能是很多比特表示的

所以它调用了一个宏

专门来对这个窗口

往下来移动

在这个循环里面

除了接收窗口之外呢

还增加了对发送窗口的处理

我们看到呢

这里有一个语句叫

if (r.ack == next_frame_to_send)

这个条件实际上就是在判断

它的确认号

是不是落在我的发送窗口

也就是说

对我刚刚发送出去的那一帧

是不是对它的确认

如果满足这个条件的话

就表明是对它的确认

这个时候

我就可以移动我的发送窗口了

怎么移呢

调用了一个宏inc(next_frame_to_send)

来移动这个窗口

那么我们接着下来还会看到

因为这是一个全双工的协议

所以呢

它启用了捎带确认

这个捎带确认是怎么做的

是在这个语句

s.ack = 1 − frame_expected

来进行捎带确认的描述的

刚才的协议四呢

引出了窗口数w等于1的工作情形

当确认号落在了发送窗口的时候

它就移动发送窗口

当到达帧的序列号落在了接收窗口

它就移动它的接收窗口

我们要注意到在协议四里边

我们的序号是用了一个比特来表示

所以它的序列号是0 1交际出现的

看的仔细一点

协议四窗口的设值

最大值就是MAX_SEQ = 1

通信双方的初始值

sequence number 等于0

ack等于1

这个 sequence number等于0呢

比较好理解

我从0开始嘛

ack等于1不太好理解

ack等于1它的意思是说

我呢收到了1号帧

你可以发下一个帧

下一个其实就是0号帧

但是一开始呢

其实我还什么都没有收到

我只是说假设我收到了1号帧

期待接收0号帧是这个意思

假如A首先发送数据帧

sequence number等于0

ack等于1

发出去它的第一帧叫A0

B收到了A0

就发送了一个捎带确认

同时发送它自己的第一帧出来

所以它的sequence number是0

ack是等于0的

这个ack等于0

就是真实的了

就是表明它收到了A发过来的0号帧

你下一次可以发1号帧过来

A收到对A0的确认之后

它就滑动它的发送窗口

并且发送它的下一帧

sequence number等于1

ack等于0

这个时候的ack等于0

就表明是对B的第一帧的确认

0号帧的确认

同时发出它的第二帧 A1帧

协议四它的工作特点是这样的

就是序号sequence

和确认值ack是01交替出现的

因为只用了一个比特来表示

滑动窗口的长度w是等于1的

只有收到了确认才移动窗口

那么接收方呢要保证按顺序

将接收到的正确帧

一次性地提交给网络层

在正常情况下

协议四呢可以非常流畅地

A发送01A0帧给B

B收到之后确认

发送00B0帧回去

接下来呢A再发送它的第二个帧

B收到之后再发送它的第二个帧

这样一来一往往前推进

正常情况下是这样

那么如果说情况异常呢

我们来看一下

有一种异常

就是重复帧

比如说我们的A发出去了它的0号帧

第一帧01A0出去

B呢正确地收到了

收到了之后呢

发出去了0号帧的一个确认

同时发出了它自己的0号帧

所以帧的情况是00B0

但是呢我们说

这个A在设置它的

重传定时器的时候

它设置的不够好

设的比较短

在确认帧还没有回来的时候

它已经超时了

超时了怎么办呢

它就会重传

那么这个重传帧

又再一次地到达了B

B呢收到这个重新帧

它发现传过来的帧的序列号是0号

而现在它不期待0号了

为什么呢

因为它之前已经对0号帧

进行过确认

已经移动了它的接收窗口

所以呢这个时候它对这个重来的帧

它不接收

但是呢它会继续地对0号帧

进行一个确认

虽然它不接收这一帧

但是它对这一个帧呢进行一个确认

所以它再一次地发00B0

这个帧出去

也许这个定时器设的特别的不好

会导致多次的重传

不管有多少次的重传

B都是同样的这个处理

那么导致的情况就是

有非常多的重复帧

在这个信道里边来传输

信道的利用率就会非常的低

但是呢协议可以正常地工作

还有一种异常的情况

就是AB几乎是同时

来向对方发送数据

这个时候呢

也会导致重复帧

那么这个重复帧呢

也会因为我们的这种工作机制

它可以正常地工作

只是产生的重复帧浪费了带宽

那么协议四的信道的利用率

到底是怎么样子的呢

在协议四里边

我们其实是有一个假设的

就是有一个时间

我们是把它忽略掉的

就是接收方处理到达帧的时间

事实上呢在低速的信道上

有一个来回的时间

就是帧发出去

到对方

对方的确认帧再回来

这个来回的时间

可能会非常的大

发送方在这段时间

它一直是处于阻塞的状态

也就是说它在这里停下来

等待对方的确认到达

这一段时间

信道是空闲的

我们可以举一个极端的例子

来描述一下

协议四的工作效率

这个例子说的是一根卫星信道

信道的传输速率

假如说是b bps

每一帧的大小是k bits

来回的时间就是RTT 是R秒

那么信道的利用率

我们就可以用这个式子来描述它

如果说我们的信道传输速率b值

等于50kbps

来回的时间等于500毫秒

数据帧的长度k等于1000个比特

我们把这三个变量

带到刚才这个公式里边

我们就得到信道的利用率

是3.85%

不到4%

这个信道的利用率是非常之低

为什么会这样呢

是因为我们发出去这一帧

到确认帧回来

这一大部分的时间里面

我们都在等待

我们其实是可以通过

发送数据的个数

来提高信道的利用率的

也就是说我们来批量发送数据

一次性的发的不是一个数据帧

而是多个

到底有多少个呢

这个个数呢

我们用一个窗口来描述它 w

那么我们把这个w

放到这个信道利用率的

计算公式里边

就可以得到这样的一个式子

如果我们让这个式子等于百分百

我们就可以解出w的这个值

在刚才那个情况下

w算出来就是26

等于26帧

也就是说

只要我们在发送第一个帧出去

在等待确认帧的时候

我们继续的发帧

可以发26个帧

一次性的可以发26个帧出去

刚刚好第一个帧

它的确认帧回来了

我们还可以继续的往下发

那么我们的批量发送数据的w值

怎么来确定呢

多大合适呢

刚才我们说到的是一个

非常极端的情况

就是我们让信道的利用率

是百分之百

我们可以算的一个w值

信道上的容量可以这样来描述

就是一帧从发送方传输到接收期间

可容纳的帧数量

我们可以用一个术语

叫带宽延迟积来描述

带宽延迟积就是用带宽乘以延迟

这个延迟就是从帧出发

到它到达一个地方的时间

就是延迟

那么时间乘上带宽

就是这条信道上的容量

叫带宽延迟积

我们的窗口值就等于

两倍的带宽延迟积加1

上面的例子我们把它的值

代到这个式子里边

就可以得到w等于26

跟刚刚用到那个方法

计算出来的值是一样的

那么我们要特别注意的就是

用这种方法计算出来的w

它是一个

信道利用率百分之百的情况

计算出来的

事实上呢

很难达到百分百

所以这个w的值呢

通常要比计算出来的这个满值

要小一些

批量传输数据可以提高

我们的信道利用率

已经明确无疑了

但是呢连续地发出多个帧

如果其中一帧出了错

后续的帧又被成功发送了

这个时候我们怎么办呢

其实有两种办法

一种呢就是丢弃出错的那一帧

以及所有的后续帧

还有一种方法呢

就是只丢弃出错的帧

后续正确接收的帧

我把它缓存起来

就这两种策略 两种方法

那么第一种方法呢

就是我们要重传出错帧开始

以及所有后续的帧

那么它对应的是协议五

而协议六呢

是对应的是另外一种方法

就是所有后续的正确的帧

它都缓存出来了

所以呢我只需要重传出错那一帧

就OK了

小结一下今天的内容

滑动窗口技术呢

可以批量发送数据

提高了信道的利用率

发送窗口对应着已经发送

但还未被确认的帧

发送窗口滑动的条件

就是收到了对这一帧的确认

接收窗口对应着期待接收的帧

它滑动的条件是

收到了期待接收的帧

窗口数的确认

是跟带宽延迟积正相关的