字节为单位的滑动窗口实现在线视频

今天要讲解字节为单位的

滑动窗口实现单元内容

我们首先介绍以字节为单位的滑动窗口

为了讲述可靠传输原理的方便

我们假定数据传输只在一个方向上进行

即A发送数据 B给出确认

TCP的滑动窗口是以字节为单位的

为了便于说明 字节编号取得很小

先假定A收到B发来的确认报文字段

其中窗口是20字节

而确认号是31字节

这表明B期望接收到的下一个序号是31

序号30之前的数据已经收到了

根据这些数据

A可以构造出自己的发送窗口

A的发送窗口表示

在没有收到B的确认的情况下

可以连续把窗口内的数据发送出去

凡是已经发送过的数据

在未收到确认之前都必须暂时保留

以便超时重传使用

发送窗口有如下特点

一 发送窗口里面的序号

表示允许发送的序号(如31~50)

显然 窗口越大

发送方就可以在收到对方确认之前

连续发送更多的数据

因而可能获得更高的传输效率

二 发送窗口的位置

由窗口的前沿和后沿的位置共同确定

没有收到确认

发送窗口的后沿可能不动

如果收到新的确认则前移

发送窗口的前沿通常是不断的向前移动

但也可能不动

现在假定A发送了序号为31-41的数据

如图所示

图中可以看出要描述一个发送窗口的状态

需要三个指针P1 P2 P3

小于P1的是已发送并收到确认的部分

大于P3的是不允许发送部分

P3-P1=A的发送窗口

又称为通知窗口

P2-P1=已发送但尚未收到确认的字节数

P3-P2=允许发送但尚未收到的字节数

又称为可用窗口或有效窗口

B的接收过程如下

B的接收窗口大小为20

在接收窗口外面

到30号为止的数据

均发送过确认并交付主机使用

因此B不再保留之前的数据

B收到了32和33的数据

这些数据没有按序到达

因为序号为31的数据没有收到

由于B只能对按序到达的数据中的

最高序号给出确认

因此B的发送的确认号仍然是31

而不能是32或33

B如果收到序号为31数据

并把序号为31-33的数据交付给主机

然后B删除这些数据

接着把接收窗口向前移动3个序号

同时给A发出确认

其窗口值仍为20 但确认号34

表明B已经接收到序号33为止的数据

而B收到的37 38 40的数据没有按序到达

先暂存在接收窗口中

A收到B确认后

把发送窗口向前移动3个序号

但指针P2不动

A的可发送序号范围为42-53

A继续发送

直到可用窗口为0

如果按照以上的方法进行发送数据

当发送窗口已满

可用窗口减小到0

因此发送停止

如果发送窗口内所有数据都正确到达B

而发出的确认由于网络问题没有到达A

为保证传输

此时A只能认为B还没有收到这部分数据

于是A经过一段时间

由超时计时器控制

重传这部分数据

直到收到B的确认为止

三 缓存机制

发送方的应用进程把字节流

写入了TCP的发送缓存

接收方的应用进程

从TCP的接受缓存中读取字节流

我们假设缓存空间和序号空间

都是有限的并且循环使用的

那么发送方的情况如下

发送缓存用来暂时存放

一 发送应用程序传送给发送方TCP准备的数据

二 TCP已发送但尚未收到确认的数据

发送窗口通常只是发送缓存的一部分

已被确认的数据应当从发送缓存中删除

因此发送缓存与发送窗口的后沿是重合的

发送应用程序必须控制写入缓存的速率

不能太快

否则发送缓存就会没有存放数据的空间

接收方的情况如下

接收缓存用来暂时存放

第一 按序到达的

但尚未被接收应用程序读取的数据

第二 未按序到达的数据

如果收到的分组检测出有差错

则要丢弃

如果接收应用程序来不及读取收到的数据

接收缓存最终就会被填满

使接收窗口减小到0

反之 接收进程应该及时从接收缓存中

读取到数据

这时接收窗口就会变大

但最大也不能超过接收缓存的大小

根据上述讨论 需要强调以下几点

一 A的发送窗口并不总是

和B的接收窗口一样大

这时因为有一定的时间滞后

二 TCP标准没有规定

对不按序到达的数据应如何处理

通常是先临时存放在接收窗口中

等到字节流中所缺少的字节收到后

再按序交付上层的应用进程

三 TCP要求接收方必须有累积确认的功能

这样可以减小传输开销