计算机网络北邮滑动窗口

㈠ 滑动窗口协议的效率计算

LU = (W*T)/(T+rtt) ,这是滑动窗口的信道利用率，W代表窗口的大小，T代表每帧的发送时延，rtt代表往返的传播时延。其中需要理解的是分母为啥是T+rtt，在滑动窗口传输过程中，发送第一个帧和接收第一个确认的时间帧之间发送了所有其他帧。示意图如下：

文章出处：数据链路详解--滑动窗口信道利用率

㈡ 计算机网络笔记——数据链路层（停等协议、GBN、SR）

流量控制：防止发送端发送和接收端接收速度不匹配造成传输错误

传输层和数据链路层均有流量控制，但是控制手法不一样

传输层：端到端，接收端向发送端发送一个窗口公告。告诉发送端目前我能接收多少
数据链路层：点到点，接收端接收不下的就不回复确认（ack），让发送端自己重传

涉及协议较多分批写

优点 ：最简单的控制协议
缺点 ：但是性能较弱,信道利用率低

控制方法 ：
发送方：发送一个帧
接收方：接收到帧后返回改帧的ack
发送方：接收到ack后发送下一个帧

差错控制 ：

注意 ：

滑动窗口协议是基于停止等待协议的优化版本
停止等待协议性能是因为需要等待ack之后才能发送下一个帧，在传送的很长时间内信道一直在等待状态
滑动窗口则利用缓冲思想，允许连续发送(未收到ack之前)多个帧，以加强信道利用

窗口 ：其实就是缓冲帧的一个容器，将处理好的帧发送到缓冲到窗口，可以发送时就可以直接发送，借此优化性能。一个帧对应一个窗口。

GBN是滑动窗口中的一种，其中 发送窗口 > 1 , 接收窗口=1 因发送错误后需要退回到最后正确连续帧位置开始重发，故而得名。

控制方法 ：
发送端：在将发送窗口内的数据连续发送
接收端：收到一个之后向接收端发送累计确认的ack
发送端：收到ack后窗口后移发送后面的数据

累计确认 ：累计确认允许接收端一段时间内发送一次ack而不是每一个帧都需要发送ack。该确认方式确认代表其前面的帧都以正确接收到
eg:发送端发送了编号 0,1,2,3,4,5 的帧，等待一段时间后（超过3的超时计时器）累计收到的ack对应 0,2 帧，则证明已经成功 0,1,2 均已经成功接收， 3 传输错误。并且哪怕 4,5 两个帧接收成功后也不会返回 4,5 的ack会一直等待从 3 开始重传

差错控制 ：

发送帧丢失、ack丢失、ack迟到 等处理方法基本和停等协议相同，不同的是采用累计确认恢复的方式，当前面的帧出错之后后面帧无论是否发送成功都要重传

优点：信道利用率高（利用窗口有增加发送端占用，并且减少ack回复次数）
缺点：累计确认使得该方法只接收正确顺序的帧，而不接受乱序的帧，错误重传浪费严重

发送窗口大小问题
窗口理论上是越多性能越好，但是窗口不能无限大，n比特编码最大只能2^(n-1)个窗口，否则会造成帧无法区分（本质就是留了一个比特区分两组帧）

SR协议可以说是GBN的plus版本，在GBN的基础上改回每一个帧都要确认的机制，解决了累计确认只接收顺序帧的弊端只需要重发错误帧。
其中 发送窗口 > 1 , 接收窗口 > 1 , 接收窗口 > 发送窗口 (建议接 收窗口 = 发送窗口 接收窗口少了溢出多了浪费).

控制方法 ：
发送端：将窗口内的数据连续发送
接收端：收到一个帧就将该帧缓存到窗口中并回复一个ack
接收端：接收到顺序帧后将数据提交给上层并接收窗口后移（若接收到的帧不是连续的顺序帧时接收窗口不移动）
发送端：接收到顺序帧的ack后发送窗口后移（同理发送窗口接收到的ack不连续也不移动）

差错控制 ：

发送帧丢失、ack丢失、ack迟到 三类处理方式仍然和停等协议相同，不同的是SR向上层提交的是多个连续帧，停等只提交一个帧（不连续的帧要等接收或重传完成后才会提交）

发送窗口大小问题
同GBN一样，发送窗口和接收窗口都不能无限多，且不说缓存容量问题，当两组帧同时发送时会造成无法区分，大小上限仍然是2^(n-1)个窗口（本质就是留了一个比特写组号）

窗口大小这里留一张截图，方便理解
假设窗口大小都为3（图中编号到了3是借4窗口的图，正常应编号到2,但是不妨碍理解）
左边是错误重发，第一组的0帧ack丢失了
右边是正常收发

三种协议对比：
停等协议：单线程的傻子，简单不易出错，但是效率极其低下
GBN：假的多线程(接收端太坑啦)，接收端是情种，只等待自己哪一个帧，丢弃了后来的帧
SR：多线程，接收端有收藏癖，等待集齐一套召唤神龙（提交给上层这只神龙……）

㈢ 计算机网络 滑动窗口

这里采用的是TCP，TCP连接是面向字节的，也就是以字节为最小单位。
接下来的组帧和分组也以字节为具有实际意义最小单位。
发送窗口=min{拥塞窗口,接收端窗口}。没其他的关系了。

㈣ TCP滑动窗口的功能是什么

滑动窗口本质上是描述接受方（本地）的TCP数据报缓冲区大小的数据，发送方根据这个数据来计算自己最多能发送多长的数据。如果发送方收到接受方的窗口大小为0的TCP数据报，那么发送方将停止发送数据，等到接受方发送窗口大小不为0的数据报的到来

㈤ 请教一道计算机网络关于滑动窗口的题目

你的想法不能说错，但是在这个方向上无法得到最优解。
现实情况是为了防止窗口发生重叠，发送窗口维持最大容量的一半就已经非常充分了。序号总共n位，那么整个发送空间撑死只有2^n帧，所以发送窗口有2^(n-1)就足以应付最恶劣情况下的重传。无论是选择重传、还是回退N帧都是如此。
换个角度而言，真的像你所述，发送方要维持2^n-1帧的窗口——我的天，按照这个思路，是不是铁路必须设计成能够同时容纳运输14亿人的容量呢？显然这是不合理、不经济的……
就像解三角函数一样，如果你仅仅根据sin、cos函数在[-1,1]这个范围内，或许能够得到一个解集，然而这个解集远非最优；还需要根据其他条件进一步缩小范围。

㈥ 滚动预测和滑动窗口有区别吗

有区别
在计算机网络中，滑动窗口协议是一种在网络上传输数据的方法。滑动窗口协议应用于OSI模型的数据链路层。在数据链路层，数据采用帧的形式。在联网中，窗口仅表示具有需要传输的数据帧的缓冲区。
滚动预测不同于传统预测，因为滚动预测是连续的，不考虑每年的财政年度结束期间。滚动预测包含的期间基于为滚动预测预定义的窗口滚动。这些期间通常是按月或季度定义的。

㈦ 计算机网络-可靠传输-滑动窗口协议

TCP的滑动窗口是以字节为单位的 。为了便于说明滑动窗口的工作原理，我们故意把后面图5-15至图5-18中的字节编号都取得很小。现假定A收到了B发来的确认报文段，其中窗口是20字节，而 确认号是31 （这表明 B期望收到的下一个序号是31 ，而序号30为止的数据已经收到了)。根据这两个数据，A就构造出自己的发送窗口。

我们先讨论发送方A的发送窗口。发送窗口表示：在没有收到B的确认的情况下，A可以连续把窗口内的数据都发送出去。凡是已经发送过的数据，在未收到确认之前都必须暂时保留，以便在超时重传时使用。

发送窗口里面的序号表示允许发送的序号。显然，窗口越大，发送方就可以在收到对方确认之前连续发送更多的数据，因而可能获得更高的传输效率。接收方会把自己的接收窗口数值放在窗口字段中发送给对方。因此，A的发送窗口一定不能超过B的接收窗口数值。发送方的发送窗口大小还要受到当时网络拥塞程度的制约。但在目前，暂不考虑网络拥塞的影响。

发送窗口后沿的后面部分表示己发送且己收到了确认。这些数据显然不需要再保留了。而发送窗口前沿的前面部分表示不允许发送的，因为接收方都没有为这部分数据保留临时存放的缓存空间。

发送窗口的位置由窗口前沿和后沿的位置共同确定。发送窗口后沿的变化情况有两种可能，即不动（没有收到新的确认）和前移（收到了新的确认）。发送窗口后沿不可能向后移动，因为不能撤销掉已收到的确认。发送窗口前沿通常是不断向前移动，但也有可能不动。这对应于两种情况：一是没有收到新的确认，对方通知的窗口大小也不变；二是收到了新的确认但对方通知的窗口缩小了，使得发送窗口前沿正好不动。

发送窗口前沿 也有可能 向后收缩 。这发生在对方通知的窗口缩小了。但 TCP的标准强烈不赞成 这样做。因为很可能发送方在收到这个通知以前已经发送了窗口中的许多数据，现在又要收缩窗口，不让发送这些数据，这样就会产生一些错误。

现在假定A发送了序号为31-41的数据。这时， A发送窗口位置并未改变 （图5-16），但发送窗口内靠后面有11个字节（31~41）表示己发送但未收到确认。而发送窗口内靠前面的9个字节(42~50)是允许发送但尚未发送的。

从以上所述可以看出，要描述一个发送窗口的状态需要三个指针：P1,P2和P3(图5-16)。指针都指向字节的序号。这三个指针指向的几个部分的意义如下：

小于P1的是已发送并已收到确认的部分，而大于P3的是不允许发送的部分。

P3-P1=A的发送窗口

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

P3-P2=允许发送但当前尚未发送的字节数（又称为 可用窗口或有效窗口 ）

再看一下B的接收窗口。B的接收窗口大小是20。在接收窗口外面，到30号为止的数据是已经发送过确认，并且己经交付主机了。因此在B可以不再保留这些数据。接收窗口内的序号(31~50)是允许接收的。在图5-16中，B收到了序号为32和33的数据。这些数据没有按序到达，因为序号为31的数据没有收到（也许丢失了，也许滞留在网络中的某处)。请注意，B只能对按序收到的数据中的最高序号给出确认，因此B发送的确认报文段中的确认号仍然是31（即期望收到的序号），而不能是32或33。

现在假定B收到了序号为31的数据，并把序号为31~33的数据交付主机，然后B删除这些数据。接着把接收窗口向前移动3个序号（图5-17），同时给A发送确认，其中窗口值仍为20，但确认号是34。这表明B已经收到了到序号33为止的数据。我们注意到，B还收到了序号为37,38和40的数据，但这些都没有按序到达，只能先暂存在接收窗口中，等待缺少的数据到达。A收到B的确认后，就可以把发送窗口向前滑动3个序号，但指针P2不动。可以看出，现在A的可用窗口增大了，可发送的序号范围是42~53。

A在继续发送完序号42~53的数据后，指针P2向前移动和P3重合。发送窗口内的序号都已用完，但还没有再收到确认（图5-18）。由于A的发送窗口已满，可用窗口已减小到零，因此必须停止发送。请注意，存在下面这种可能性，就是发送窗口内所有的数据都已正确到达B,B也早已发出了确认。但不幸的是，所有这些确认都滞留在网络中。在没有收到B的确认时，A不能猜测：“或许B收到了吧！”为了保证可靠传输，A只能认为B还没有收到这些数据。于是，A在经过一段时间后（由超时计时器控制）就重传这部分数据，重新设置超时计时器，直到收到B的确认为止。如果A收到确认号落在发送窗口内，那么A就可以使发送窗口继续向前滑动，并发送新的数据。

我们在前面的图5-18中曾给出了这样的概念：发送方的应用进程把字节流写入TCP的发送缓存，接收方的应用进程从TCP的接收缓存中读取字节流。

窗口和缓存的关系

第一，缓存空间和序号空间都是有限的，并且都是循环使用的。最好是把它们画成圆环状的，但这里为了画图的方便，我们还是把它们画成长条状的。

第二，由于实际上缓存或窗口中的字节数是非常之大的，因此图5-19（a发送缓存和发送窗口，b接收缓存和接收窗口）仅仅是个示意图，没有标出具体的数值。但用这样的图米说明缓存和发送窗口以及接收窗口的关系是很清楚的。

发送缓存用来暂时存放：

(1)发送应用程序传送给发送方TCP准备发送的数据；

2)TCP已发送出但尚未收到确认的数据。

发送窗口通常只是发送缓存的一部分，已被确认的数据应当从发送缓存中删除，因此发送缓存和发送窗口的后沿是重合的。发送应用程序最后写入发送缓存的字节减去最后被确认的字节，就是还保留在发送缓存中的被写入的字节数。发送应用程序必须控制写入缓存的速率，不能太快，否则发送缓存就会没有存放数据的空间。

接收缓存用来暂时存放：

(1)按序到达的、但尚未被接收应用程序读取的数据；

(2)末按序到达的数据。

如果收到的分组被检测出有差错，则要丢弃。如果接收应用程序来不及读取收到的数据，接收缓存最终就会被填满，使接收窗口减小到零。反之，如果接收应用程序能够及时从接收缓存中读取收到的数据，接收窗口就可以增大，但最大不能超过接收缓存的大小。图5-19(b)中还指出了下一个期望收到的字节号。这个字节号也就是接收方给发送方的报文段的首部中的确认号。

根据以上所讨论的，我们还要再强调以下三点。

第一，虽然A的发送窗口是根据B的接收窗口设置的，但在同一时刻，A的发送窗口并不总是和B的接收窗口一样大。这是因为通过网络传送窗口值需要经历一定的时间滞后(这个时间还是不确定的)。另外，发送方A还可能根据网络当时的拥塞情况适当减小自己的发送窗口数值。

第二，对于不按序到达的数据应如何处理，TCP标准并无明确规定。如果接收方把不按序到达的数据一律丢弃，那么接妆窗口的管理将会比较简单，但这样做对网络资源的利用不利（因为发送方会重复传送较多的数据）。因此TCP通常对不按序到达的数据是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程。

第三，TCP要求接收方必须有累积确认的功能，这样可以减小传输开销。接收方可以在合适的时候发送确认，也可以在自己有数据要发送时把确认信息顺便梢带上。但请注意两点。一是接收方不应过分推迟发送确认，否则会导致发送方不必要的重传，这反而浪费了网络的资源。TCP标准规定，确认推迟的时间不应超过0.5秒。若收到一连申具有最大长度的报文段，则必须每隔一个报文段就发送一个确认。二是梢带确认实际上并不经常发生，因为大多数应用程序很少同时在两个方向上发送数据。

最后再强调一下，TCP的通信是全双工通信。通信中的每一方都在发送和接收报文段。因此，每一方都有自己的发送窗口和接收窗口。在谈到这些窗口时，一定要弄清是哪一方的窗口。

㈧ 请教关于计算机网络滑动窗口一题

接收窗口：到底是“每接收一帧数据，窗口后沿移动一格”还是“每应答一帧数据，窗口后沿移动一格”？如果是“接受”的话，题目中接收窗口已经接受了4帧数据了啊！

㈨ 计算机网络中的滑动窗口协议中的窗口是指什么

窗口 只是个形象的描述而已
在发送数据的时候 收发双方要做到 收发同步 不能发送方 发得快 而接收方 去接受的慢

所以 就让 接收方 告诉 发送方 我的接受缓存还有 多少空闲 你这次能发送多少数据给我 多于这个值了 我就接受不下了

其实 窗口 也就是值得 发送方 发送数据的 窗口大小
祝你玩得愉快
不懂了可以hi我

㈩ 在计算机网络考试中，问：TCP流量控制中，滑动窗口的特点。有谁能总结一下

只有在接收窗口向前滑动时（与此同时也发送了确认），发送窗口才有可能向前滑动。
收发两端的窗口按照以上规律不断地向前滑动，因此这种协议又称为滑动窗口协议。
当发送窗口和接收窗口的大小都等于 1时，就是停止等待协议。
当发送窗口大于1，接收窗口等于1时，就是回退N步协议。
当发送窗口和接收窗口的大小均大于1时，就是选择重发协议。
协议中规定，对于窗口内未经确认的分组需要重传。这种分组的数量最多可以等于发送窗口的大小，即滑动窗口的大小n减去1（因为发送窗口不可能大于（n-1），起码接收窗口要大于等于1）。