㈠ 请教关于计算机网络滑动窗口一题
发送窗口：每发送一帧数据，窗口后沿移动一格；每接收一帧应答，窗口前沿移动一格；接收窗口：每接收一帧数据，窗口后沿移动一格；每发送一帧应答，窗口前沿移动一格；所以 此时发送窗口将要发送的帧序号为（ D、4），接收窗口的上边界对应的帧序号为（ B、2 ）
㈡ 关于计算机通信网络的一道滑动窗口题目
窗口大小为7就是表示发送和接收之间可以相差6个帧，如果B回复A他收到的帧的编号为m,那么A最多发送的数据帧编号只要不大于m+7就可以继续发。协议都是认为正确的，如果大于m+7那么协议就认为传输有错误。如：B回复A他已经收到的最后一帧的编号为1，那么A发送的数据帧的编号只要不大于8，那么他就可以继续顺序发下去，如果大于8那么就认为传输出错了，那么就要重发。A是顺序发的，所以A发送的帧编号为4。
㈢ 计算机网络中的滑动窗口协议中的窗口是指什么
窗口 只是个形象的描述而已
在发送数据的时候 收发双方要做到 收发同步 不能发送方 发得快 而接收方 去接受的慢
所以 就让 接收方 告诉 发送方 我的接受缓存还有 多少空闲 你这次能发送多少数据给我 多于这个值了 我就接受不下了
其实 窗口 也就是值得 发送方 发送数据的 窗口大小
祝你玩得愉快
不懂了可以hi我
㈣ 请教一道计算机网络关于滑动窗口的题目
你的想法不能说错，但是在这个方向上无法得到最优解。
现实情况是为了防止窗口发生重叠，发送窗口维持最大容量的一半就已经非常充分了。序号总共n位，那么整个发送空间撑死只有2^n帧，所以发送窗口有2^(n-1)就足以应付最恶劣情况下的重传。无论是选择重传、还是回退N帧都是如此。
换个角度而言，真的像你所述，发送方要维持2^n-1帧的窗口——我的天，按照这个思路，是不是铁路必须设计成能够同时容纳运输14亿人的容量呢？显然这是不合理、不经济的……
就像解三角函数一样，如果你仅仅根据sin、cos函数在[-1,1]这个范围内，或许能够得到一个解集，然而这个解集远非最优；还需要根据其他条件进一步缩小范围。
㈤ 计算机网络-可靠传输-滑动窗口协议
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的通信是全双工通信。通信中的每一方都在发送和接收报文段。因此，每一方都有自己的发送窗口和接收窗口。在谈到这些窗口时，一定要弄清是哪一方的窗口。
㈥ 计算机网络 设计一个类似于TCP的滑动窗口协议,
这个问题最关键是在于窗口大小的计算和每帧长度的确定。至于具体的过程活动窗口协议很多网络一下就有，把下面计算出来的参数套一下就完事~~。
假设每帧传输1Kb,
则传输一个帧所需时间为： 发送时间 + 信息信道延迟 + 确认信道延迟（确认帧很短，忽略发送时间）= 1kb / 100Mbps + RTT/2+ RTT/2= 100ms+ 0.01ms 信道利用率 = 0.01/ 100.001=0.01%.
要使信道利用率达到更高，可一次发送的帧数量为100/0.01=10000，上面的K=1000，为了计算方便。
也就是说，当帧长度1kb时，发送窗口最大可以达到10000.
协议头部的窗口字段和序号字段最少应该有多少比特？
应该有16bit，因为8bit的最大值才512。
我也是在网上找的，不知道准确不准确。
㈦ 在计算机网络考试中，问：TCP流量控制中，滑动窗口的特点。有谁能总结一下
只有在接收窗口向前滑动时（与此同时也发送了确认），发送窗口才有可能向前滑动。
收发两端的窗口按照以上规律不断地向前滑动，因此这种协议又称为滑动窗口协议。
当发送窗口和接收窗口的大小都等于 1时，就是停止等待协议。
当发送窗口大于1，接收窗口等于1时，就是回退N步协议。
当发送窗口和接收窗口的大小均大于1时，就是选择重发协议。
协议中规定，对于窗口内未经确认的分组需要重传。这种分组的数量最多可以等于发送窗口的大小，即滑动窗口的大小n减去1（因为发送窗口不可能大于（n-1），起码接收窗口要大于等于1）。
㈧ 计算机网络 滑动窗口
我们计算窗口的大小的时候用字节表示，比如50字节等，发送窗口和拥塞床窗口不是一个概念，拥塞窗口随着传输的次数的增加会变化，具体的变化策略和网络所采用的策略相关，拥塞是用来实现实现网络的拥塞控制的！具体的你在网络中随手搜拥塞控制，就能明白！发送窗口，也是变化！但是拥塞窗口的大小是发送窗口的上限！发送窗口的大小由拥塞窗口大小和接受端的所给定的能接受的大小共同决定！时间有些长，不能说的太具体，怕错误太多了！如果有事么不懂，将我回答的关键字在网络中查找就能明白说的意思！
㈨ TCP滑动窗口的功能是什么
滑动窗口本质上是描述接受方（本地）的TCP数据报缓冲区大小的数据，发送方根据这个数据来计算自己最多能发送多长的数据。如果发送方收到接受方的窗口大小为0的TCP数据报，那么发送方将停止发送数据，等到接受方发送窗口大小不为0的数据报的到来