流量控制和拥塞控制

流量控制和拥塞控制

通常TCP有三个窗口，接收窗口 rwnd (receive window)，发送窗口swnd(send window)，拥塞窗口cwnd(congestion window)。

拥塞避免(cwnd)是发送方使用的流量控制，而滑动窗口（swnd, rwnd）则是接收方进行的流量控制。前者是发送方感受到的网络拥塞的估计，而后者则与接收方在该连接上的处理能力处理速度大小有关。

流量控制

滑动窗口
TCP滑动窗口是TCP协议中的一种流量控制机制，用于调节发送方和接收方之间的数据传输速率，以避免网络拥塞和提高传输效率。滑动窗口机制允许发送方在不等待确认应答的情况下连续发送多个数据段，从而提高了网络的利用率。
工作原理：
滑动操作：随着数据的发送和接收，发送窗口和接收窗口会不断滑动。当接收方成功接收到数据后，会将窗口向前滑动，通知发送方可以发送更多的数据。当发送方收到接收方的确认后，也会将发送窗口向前滑动。
流量控制：接收方通过调整接收窗口的大小来控制发送方的发送速率。如果接收方的缓冲区已满或者处理能力有限，可以减小接收窗口的大小，通知发送方减缓发送速率。如果接收方的缓冲区有足够的空间，可以增大接收窗口的大小，提高发送速率。

滑动窗口是TCP协议中重要的流量控制机制之一，通过调整发送窗口和接收窗口的大小，实现了发送方和接收方之间的数据传输速率的动态调节，提高了网络的利用率和传输效率

三种滑动协议

一、停等协议

本质上就是一种全双工的停等式协议，它的发送窗口和接收窗口大小都是1

二、SR协议

在SR协议中，窗口大小默认满足如下两个基本条件：
发送窗口大小 = 接收窗口大小
发送窗口大小 + 接收窗口大小 <= 2^n
由此我们可以推得：发送(或接收)窗口大小 <= 2^(n-1)

           ***      SR协议和GBN协议（后退n帧）窗口大小         原因如下：***

问题一 : 发送窗口大于接收窗口会发生什么情况?
发送窗口小于接收窗口的情况我们就不谈了，因为这显然是一种浪费，我主要讨论发送窗口大于接收窗口时的情况。
我们假设帧序号采用3bit表示，那么帧序号为 0, 1, 2, 3, 4, 5, 6, 7。
令发送窗口大小为5，接收窗口大小为3，采用SR(选择重传)协议时的过程如下：

首先发送方一次性连续发送了 0,1,2,3,4 帧序号的比特流 , 因为接收方的接收窗口为3 , 那么在0,1,2号帧正确无误的被接收方接收后,接收方向上交付0,1,2号帧 . 3,4号帧虽然被正确接收,但接收方现在还未将接收到的0,1,2号帧向上交付,并发回ack=2的确认收到信息（接收方对于3帧和4帧存不进去）,故3,4号帧将被抛弃,只有在接收方发回确认信息后,接收窗口才会向后移动, . 那么发送方迟迟收不到3,4号帧的ack3,ack4 .只收到ack0,ack1,ack2 , 因此发送方的计时器超时后接收方才会再次发送3,4号帧,这时候接收方才能正确接收. 这样的配合方式使得每个周期都会有数据超时重传,因此传输效率是低下的,也是没必要的。

综上，我们不如直接令发送窗口大小 = 接收窗口大小。

问题二: 如果发送窗口大小为5,接收窗口大小为5 (即发送窗口+接收窗口>2^n)会发生什么情况?
假设帧序号采用3bit表示，发送窗口大小为5，接收窗口大小为5，发送方一次性发送0,1,2,3,4号帧的比特流。

情况1: 在没有差错发生的情况下(此处差错考虑帧差错的帧丢失) : 发送方发送的所有数据都被正确接收了 , 并且接收方所有确认数据都正常接收到了.那么这种情况将一个周期一个周期的循环下去。

情况2: 发送方发送了0-4号帧,接收方正确接收,但是接收方的回复的所有确认信息全部丢失 , 发送方以为自己的数据发送失败,即没有到达接收方,那么接收方因为正确之前已经正确接收到0-4号帧后,它的接收窗口已经向后移动,此时接收窗口期望的是5,6,7,0号帧 . 当接收方再次接收到0-4号帧时,他并不能区别此时的0号帧是旧帧还是新帧,实际上是我们知道是旧帧,但是接收方接收到此0号帧了,它只能以为是新帧.那么此时就造成了帧重复的差错了。

这时再来看GBN协议对于窗口大小的限制就很好理解了。在GBN协议中，接收窗口大小固定为1，但依然存在发送窗口大小 + 接收窗口大小 <= 2^n 这个条件，其原因和问题二的情况二类似，所以最终我们可以得知发送(或接收)窗口大小 <= 2^n-1

三、 GBN协议（后退n帧）

接收窗口大小固定为1，但依然存在发送窗口大小 + 接收窗口大小 <= 2^n

发送方：
发送方在发完一个数据帧后，连续发送若干个数据帧，即使在连续发送过程中收到了接收方发来的应答帧，也可以继续发送
发送方在每发送完一个编号为n的数据帧时都要设置超时定时器，只要在所设置的超时时间内仍收到ack=n（表示前n-1帧已收到）确认帧，就要重发该编号为n数据帧。
当发送方发送了N个帧后，若发现该N帧的前一个帧在计时器超时后仍未返回其确认信息，则该帧被判为出错或丢失，此时发送方就不得不重新发送出错帧及其后的N帧。
接收方：
接受帧只允许按顺序接受帧。为了减少开销，累计确认允许接收端在连续收到好几个正确的确认帧后，只对最后一个数据帧发确认信息，或者可以在自己有数据要发送时才将对以前正确收到的帧加以捎带确认。

类似的这道题，发送发没有收到帧1的确认，但是却收到帧2、3的确认消息，说明此时还没有超时，在这超时时间内是依然可以收到后序帧的确认，一个原因可能是接收方发送帧1的确认，但丢在路上，另一个原因是“累计确认”即捎带确认，接受方根本没有发送帧1的确认，而是通过2、3帧的确认告诉我们帧1已经接收成功。所以，帧0、1、2、3均已正确接收到，需要重发的是4、5、6、7帧，答案选C。

快速重传（在流控和拥控都有使用）
当发送方连续收到三个重复的确认应答（Duplicate ACK）时，就会启动快速重传机制，认为某个报文段丢失，并立即重传该报文段，而不必等待超时时间到达。

拥塞控制

拥塞控制主要针对整个网络中的数据传输速率进行调节，以避免网络拥塞和丢包现象的发生。

工作原理：发送方通过维护一个拥塞窗口来控制自己的发送速率。拥塞控制机制通过监控网络拥塞程度和丢包情况来动态调整发送方的发送速率，以保证网络的稳定性和公平性。

机制：拥塞控制机制通过慢启动、拥塞避免、快速重传、快速恢复等算法来实现。发送方根据拥塞窗口的大小来控制自己的发送速率，如果网络出现拥塞或丢包情况，会降低拥塞窗口的大小，减缓发送速率。