它是TCP接收缓冲区，用于尚未由应用程序处理的传入数据。使用TCP头的窗口大小字段将TCP接收窗口的大小传达给发送方。该字段告诉发送方在接收到确认之前可以在线路上发送多少数据。如果接收器无法尽快处理数据，则接收缓冲区将逐渐填充，并且确认数据包中的TCP窗口将减少。这将警告发送方它需要减少发送的数据量或让接收方有时间清除缓冲区。

2.滑动窗口的分类

滑动窗口分为三类：停止等待、后退N帧、选择重传。他们之间主要的区别就是：发送窗口和接收窗口大小的区别。

停止等待协议：发送窗口大小 = 1，接收窗口大小= 1

发送方 A 发送数据, 每发送一帧就停止发送。并等待接收方 B 发送确认, 收到确认后 A 就发送下一帧。

在传输时, 数据往往会出现差错, 对以下差错, 该协议会进行不同的处理。

（1）超时重传(针对 A 的差错情况)

若在发送过程中数据帧出现丢失或差错, 此时 B 不会收到数据帧或者丢弃收到的数据帧, 总之,B 不会发送确认。此时 A 会一直等待, 但不会超过设置的等待时间（通常会设置一个超时计时器）。 A 重传该数据帧。

（2）确认丢失和确认迟到（针对 B 的出错情况)

确认丢失: 若 B 在回复确认时确认出现丢失, 则 A 也会一直等待, 也不会超过设置的等待时间。 A 重传该数据帧。且B 会丢掉重复的数据帧。重传确认。

确认迟到: 若 B 在回复确认时确认很久才到, 则 A 也会一直等待, 同样也不会超过设置的等待时间。 A 重传该数据帧。且B 也会丢掉重复的数据帧。重传确认。于是 A 正常收到来自重传的确认, 但是后面又收到迟到的相同的确认,A 收下但什么也不做。

后退N帧协议（GBN）：发送窗口大小 > 1，接收窗口大小 = 1

停止等待协议发一次就等待确认, 这样会使信道利用率太低, 于是, 我们可以让发送方连续分送多个协议。不用发一次帧就等待依次确认, 采用如下的流水线传输。

为了让流水线传输可维持可靠传输的特性, 于是让发送方与接收到都维护一个滑动窗口。

发送窗口：在发送窗口内发送连续帧

发送窗口所遇事件：

1.收到 $ACK_{n}$

动作：发送方收到累计确认并前移: 收到ACK,发送方会认为接收方已经收到n号帧和它前面的那些帧，发送窗口前移至下界到n下一格的位置

2.已发送数据帧(上图标橙部分)等待收到确认时间超时

动作：发送方重传已发送但未被确认的帧

3.数据帧全部发送(橙色部分全部占满窗口)

动作：发送方将数据返回给上层，过一会儿在发送

4.数据帧未全部发送(橙色部分未占满窗口)

动作：发送方按序拷贝一份数据并发送给接收方

这里需要注意的是累计确认与超时重传，重传需要重传所有未被确认的帧。(这也是后退N帧协议名称的由来)主要是因为接收方累计确认的原因, 发送方不知道哪些帧被接收方收到了，具体细节在接收方窗口中细讲。

接收窗口：

后退N帧协议中位于接收窗口内的序号是接收方希望收到的下一个帧，（注: 后退N帧协议的接收窗口大小 $W_{R}$ =1 ,即只有窗口内只有 1 个数据）

接收窗口所遇事件：

1.收到位于窗口内的帧 $M_{n}$

动作：接收窗口前移一格，数据交付上层

2.按序（接收窗口收到希望收到的帧，窗口前移，下一个帧又是窗口希望收到的帧）

动作：收到几个帧后，对按序到达的最后一个帧发送确认（累积确认）

3.未按序收到帧

动作：丢弃该帧，并为最近按序收到的帧重发ACK

累计确认：

若未按序收到帧, 则丢弃该帧, 并且要重传最近按序收到的帧的ACK。这就是累计确认。因此发送方的某帧超时未收到确认, 代表该帧出现问题, 后面的帧已经被丢掉了, 需要再传。

累计确认的确认方式为若有 $ACK_{n}$ 发送, 则 n号帧和前面所有帧均已按序接收。(或：接收窗口停在 n 处, 则n−1 号帧和前面所有帧均已按序接收)

后退N帧协议滑动窗口大小

•首先需要明确的是,GBN协议中接收窗口的大小 $W_{R}$ =1
•其次,GBN协议中,对发送窗口的大小也有要求,若采用 n 比特编号,发送窗口的大小应满足：

$1\leqslant W_{T}\leqslant 2^{n}-1$ ，这是因为发送窗口过大,会使得接收方无法区别新帧和旧帧。

选择重传协议（SR）：发送窗口大小 > 1，接收窗口大小 > 1

后退N帧协议由于采取累计确认的方式, 重传所有未被确认的帧, 这样做在某些质量差的信道中会极大降低信道利用率。于是我们想只重传出错的帧, 这时我们需要加大接收窗口的长度, 缓存乱序到达的帧, 这就是选择重传协议(SR)。

发送窗口：位于发送窗口内的帧都可以连续发送出去

发送窗口所遇事件：

1.收到 $ACK_{n}$

动作：若n不为窗口下界(最左)，则SR发送方将n窗口(n窗口为橙色)标记为已发送(图中为涂上黄色)。若n为窗口下界，则窗口下界移动至最左边未被确认的帧(橙色)处。

2.已发送数据帧(上图标橙部分)等待收到确认时间超时

动作:发送方重传该帧。(每个帧都有自己的超时器，一个帧超时只重传那一个帧)

3.数据帧全部发送(橙色部分全部占满窗口)

动作:发送方将数据返回给上层，过一会儿再发送

4.数据帧未全部发送(橙色部分未占满窗口)

动作：发送方按序拷贝一份数据并发送给接收方

如图所示：假设 2 号帧超时, 只用重传 2 号帧。其他帧都收到确认了就不用重传了。

接收窗口：位于接收窗口内的帧都可以被接收并发送确认, 而不会被丢弃。

接收窗口所遇事件：

1.收到位于窗口内的帧 $M_{n}$

动作：标记为已收到(黄色)并返回该顺的确认

2.从下界开始有连续被标记的帧

动作：向前滑动至没有被标记的帧处

3.接收到了小于窗口下界的帧

动作：返回一个ACK（注：接收方发送的 ACK 失,需要重传 ACK，其他情况忽略该帧）

总之, 这样设置滑动窗口可以不必重传所有帧, 只需重传已超时的帧即可。

滑动窗口协议的大小：

对于所有的滑动窗口协议,为了让窗口能区别新和旧,发送窗口同样有 $1\leqslant W_{T}\leqslant 2^{n}-1$

对接收窗口而言, $W_{R}$ 至少为 1，则 $W_{R}\leqslant 1$

两不等式联立得 $W_{T}+W_{R}\leqslant 2^{n}$

SR协议的滑动窗口的大小：

因为,对于所有的滑动窗口协议都存在 $W_{T}+W_{R}\leqslant 2^{n}$

但是,对SR协议而言,接收窗口与接收窗口长度都不固定,当限制 $W_{T}\leqslant 2^{n-1}$ 时,且 $W_{R}\leqslant 2^{n-1}$

时，两者之和绝对不超过 $2^{n}$
且对SR协议,为提高传输效率,滑动窗口长度等于接收窗口长度，这样不会造成溢出(即发送了大于对方窗口上界的帧或 ACK）,于是 $2^{n-1}$ 是最好的值,并且在实际应用中,最好有 $W_{T}$ = $W_{R}$ = $2^{n-1}$

参考：可靠传输协议—停止等待、后退N帧、选择重传 - 知乎 (zhihu.com)

拥塞控制

在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能就要变坏

这种情况就叫做拥塞(congestion)。
在计算机网络中的链路容量 (即带宽)、交换结点中的缓存和处理机等，都是网络的资源。

若出现拥塞而不进行控制，整个网络的吞吐量将随输入负荷的增大而下降

慢开始算法和拥塞避免：

发送方维护一个叫做拥塞窗口cwnd的状态变量其值取决于网络的拥塞程度，并且动态变化

•拥塞窗口cwnd的维护原则:只要网络没有出现拥塞，拥塞窗口就再增大一些;但只要网络出现拥塞，拥塞窗口就减少一些

•判断出现网络拥塞的依据: 没有按时收到应当到达的确认报文 (即发生超时重传)

发送方将拥塞窗口作为发送窗口swnd，即swnd = cwnd
维护一个慢开始门限ssthresh状态变量:
•当cwnd<ssthresh时，使用慢开始算法;

•当cwnd>ssthresh时，停止使用慢开始算法而改用拥塞避免算法;

•当cwnd=ssthresh时，既可以使用慢开始算法，也可以拥塞避免算法;

（1）在TCP双方建立逻辑连接关系时，拥塞窗口的值被设置为1，并设置慢开始门限的初始值，这里采用16。

（2）在进行慢开始算法时，发送方每接收到一个对新报文段的确认时，就把拥塞窗口值成倍增加，并开始下一轮的传输。

（3）当拥塞窗口值增长到慢开始门限值时，就改用拥塞避免算法，由于发送方当前的拥塞窗口值是1，而发送窗口值=拥塞窗口值，因此发送方此时只能发送一个TCP报文段。即，拥塞窗口值是几，就能发送几个数据报文段。

现在我们通过展现拥塞窗口随传输轮次的变化来理解：

传输轮次：

发送方给接收方发送数据报文后，接收方给发送方发回相应的确认报文段，一个传输轮次所经历的时间其实就是往返时间。

注：往返时间并非是恒定的数值，使用传输轮次是为了强调把拥塞窗口所允许发送的报文段都连续发送出去，并收到了对已发送的最后一个报文段的确认。

步骤一：

发送方到收到确认后，将拥塞窗口值+1（此时窗口值为2），这样拥塞窗口就可以发送2个数据报文段，当发送方收到2个报文段的确认后，将窗口值+2(2+2=4),接下来就可以发送4个数据报文段，以此类推....即拥塞窗口值为2，4，8，16

步骤二：

现在增大到了慢开始门限值，改用拥塞避免算法：

每个传输轮次结束后，拥塞窗口值只能线性+1，发送方给接收方发送17个数据报文段，若收到接收方返回的确认后，继续线性+1

如图所示：

步骤三：

当拥塞窗口为24时，若发送的数据报部分丢失，发送方就会对这些报文段进行超时重传，

并且确定网络出现拥塞，做一下操作：

1.ssthresh值更新为发生拥塞时cwnd值的一半，如图则为12

2.将拥塞窗口值减小为1，并重新开始慢开始算法，当拥塞窗口达到新的门限值时，则改用拥塞避免算法

注：

1.慢开始是指一开始向网络注入的报文段少，并不是指拥塞窗口cwnd增长速度慢

2.“拥塞避免”并非指完全能够避免拥塞，而是指在拥塞避免阶段将拥塞窗口控制为按线性规律增长，使网络比较不容易出现拥塞。

快重传和快恢复：

有时，个别报文段会在网络中丢失，但实际上网络并未发生拥塞这将导致发送方超时重传，并误认为网络发生了拥塞。于是发送方将拥塞窗口减少为1，并错误地启动慢开始算法，因而降低了传输效率。

快重传：

所谓快重传，就是使发送方尽快进行重传，而不是等超时重传计时器超时再重传，采用快重传算法可以让发送方尽早知道发生了个别报文段的丢失。

这就要求接收端：

•接收方不要等待自己发送数据时才进行捎带确认，而是要立即发送确认;

•即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认。

•发送方一旦收到3个连续的重复确认，就将相应的报文段立即重传，而不是等该报文段的超时重传计时器超时再重传。

例如：

如图所示，接收方收到了M1和M2后都分别及时发出了确认。现假定接收方没有收到 M3但却收到了 M4。本来接收方可以什么都不做。但按照快重传算法，接收方必须立即发送对M2的重复确认，以便让发送方及早知道接收方没有收到报文段 M3。发送方接着发送 M5和 M6。接收方收到后也仍要再次分别发出对 M2的重复确认。这样，发送方共收到了接收方的 4 个对 M2的确认，其中后3个都是重复确认。快重传算法规定，发送方只要一连收到3 个重复确认，就可知道现在并未出现网络拥塞，而只是接收方少收到一个报文段 M3，因而立即进行重传 M3(即“快重传”)。使用快重传可以使整个网络的吞吐量提高约20%。

快恢复：

发送方一旦收到3个重复确认，就知道现在只是丢失了个别的报文段。于是不启动慢开始算法，而执行快恢复算法。

•发送方将慢开始门限ssthresh值和拥塞窗口cwnd值调整为当前窗口的一半; 开始执行拥塞避免算法•也有的快恢复实现是把快恢复开始时的拥塞窗口cwnd值再增大一些，即等于新的ssthresh + 3。既然发送方收到3个重复的确认，就表明有3个数据报文段已经离开了网络;这3个报文段不再消耗网络资源而是停留在接收方的接收缓存中;可见现在网络中不是堆积了报文段而是减少了3个报文段。因此可以适当把拥塞窗口扩大些。

注：在拥塞避免阶段，拥塞窗是按照线性规律增大的，这就是加法增大AI。而一旦出现超时或3个重复的确认，就要把门限值设置为当前拥塞窗口值的一半，并大大减小拥塞窗口的数值，这称为“乘法减小”MD，二者合起来就是所谓AIMD。

例题：

一个TCP连接总是以1KB的最大段长发送TCP段，发送方有足够多的数据要发送。当拥塞窗口为16KB时发生了超时，如果接下来的4个RTT(往返时间)内的TCP段的传输都是成功的，那么当第4个RTT时间内发送的所有TCP段都得到肯定应答时，拥塞窗口大小是（9KB）

注：题目未给出初始“慢开始门限值”，如图的传输轮次只是便于理解。

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/小桥流水78/article/detail/993803

TCP的滑动窗口和拥塞控制_tcp窗口

滑动窗口

1.发送窗口和接收窗口