TCP流量控制机制、拥塞控制

流量控制机制

一、为什么需要流量控制?

双方在通信的时候，发送方的速率与接收方的速率是不一定相等，如果发送方的发送速率太快，会导致接收方处理不过来，这时候接收方只能把处理不过来的数据存在缓存区里（失序的数据包也会被存放在缓存区里）。

如果缓存区满了发送方还在疯狂着发送数据，接收方只能把收到的数据包丢掉，大量的丢包会极大着浪费网络资源，因此，我们需要控制发送方的发送速率，让接收方与发送方处于一种动态平衡才好。

对发送方发送速率的控制，我们称之为流量控制。

二、如何控制?

接收方每次收到数据包，可以在发送确定报文的时候，同时告诉发送方自己的缓存区还剩余多少是空闲的，我们也把缓存区的剩余大小称之为接收窗口大小，用变量win来表示接收窗口的大小。

发送方收到之后，便会调整自己的发送速率，也就是调整自己发送窗口的大小，当发送方收到接收窗口的大小为0时，发送方就会停止发送数据，防止出现大量丢包情况的发生。

三、发送方何时再继续发送数据?

当发送方停止发送数据后，该怎样才能知道自己可以继续发送数据？

我们可以采用这样的策略：当接收方处理好数据，接受窗口 win > 0 时，接收方发个通知报文去通知发送方，告诉他可以继续发送数据了。当发送方收到窗口大于0的报文时，就继续发送数据。

不过这时候可能会遇到一个问题，假如接收方发送的通知报文，由于某种网络原因，这个报文丢失了，这时候就会引发一个问题：接收方发了通知报文后，继续等待发送方发送数据，而发送方则在等待接收方的通知报文，此时双方会陷入一种僵局。

为了解决这种问题，我们采用了另外一种策略：当发送方收到接受窗口 win = 0 时，这时发送方停止发送报文，并且同时开启一个定时器，每隔一段时间就发个测试报文去询问接收方，打听是否可以继续发送数据了，如果可以，接收方就告诉他此时接受窗口的大小；如果接受窗口大小还是为0，则发送方再次刷新启动定时器。

四、一些术语及其注意点说明

1、这里说明下，由于TCP/IP支持全双工传输，因此通信的双方都拥有两个滑动窗口，一个用于接受数据，称之为接收窗口；一个用于发送数据，称之为拥塞窗口(即发送窗口)。指出接受窗口大小的通知我们称之为窗口通告。

2、接收窗口的大小固定吗？

在早期的TCP协议中，接受接受窗口的大小确实是固定的，不过随着网络的快速发展，固定大小的窗口太不灵活了，成为TCP性能瓶颈之一，也就是说，在现在的TCP协议中，接受窗口的大小是根据某种算法动态调整的。

3、接受窗口越大越好吗？

接受窗口如果太小的话，显然这是不行的，这会严重浪费链路利用率，增加丢包率。那是否越大越好呢？答否，当接收窗口达到某个值的时候，再增大的话也不怎么会减少丢包率的了，而且还会更加消耗内存。所以接收窗口的大小必须根据网络环境以及发送发的的拥塞窗口来动态调整。

4、发送窗口和接受窗口相等吗？

接收方在发送确认报文的时候，会告诉发送发自己的接收窗口大小，而发送方的发送窗口会据此来设置自己的发送窗口，但这并不意味着他们就会相等。首先接收方把确认报文发出去的那一刻，就已经在一边处理堆在自己缓存区的数据了，所以一般情况下接收窗口 >= 发送窗口。

知识补充

`怎么样实现流量控制？`

使用滑动窗口
滑动窗口
1.滑动窗口是什么？
滑动窗口是类似于一个窗口一样的东西，是用来告诉发送端可以发送数据的大小或者说是窗口标记了接收端缓冲区的大小，这样就可以实现
ps：窗口指的是一次批量的发送多少数据

`为什么会出现滑动窗口？`

在确认应答策略中，对每一个发送的数据段，都要给一个ACK确认应答，收到ACK后再发送下一个数据段，这样做有一个比较大的缺点，就是性能比较差，尤其是数据往返的时间长的时候

使用滑动窗口，就可以一次发送多条数据，从而就提高了性能

`滑动窗口的一些知识点`

（1）接收端将自己可以接收的缓冲区大小放入TCP首部中的“窗口大小”字段，通过ACK来通知发送端（2）窗口大小字段越大，说明网络的吞吐率越高（3）窗口大小指的是无需等待确认应答而可以继续发送数据的最大值，即就是说不需要接收端的应答，可以一次连续的发送数据（4）操作系统内核为了维护滑动窗口，需要开辟发送缓冲区，来记录当前还有那些数据没有应答，只有确认应答过的数据，才能从缓冲区删掉

ps：发送缓冲区如果太大，就会有空间开销（5）接收端一旦发现自己的缓冲区快满了，就会将窗口大小设置成一个更小的值通知给发送端，发送端收到这个值后，就会减慢自己的发送速度（6）如果接收端发现自己的缓冲区满了，就会将窗口的大小设置为0，此时发送端将不再发送数据，但是需要定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端 ps：在TCP的首部中，有一个16为窗口字段，此字段就是用来存放窗口大小信息的

`滑动窗口的优点`

可以高效可靠的发送大量的数据

拥塞控制？

一、为何要进行拥塞控制？

为了方便，我们假设主机A给主机B传输数据。

我们知道，两台主机在传输数据包的时候，如果发送方迟迟没有收到接收方反馈的ACK，那么发送方就会认为它发送的数据包丢失了，进而会重新传输这个丢失的数据包。

然而实际情况有可能此时有太多主机正在使用信道资源，导致网络拥塞了，而A发送的数据包被堵在了半路，迟迟没有到达B。这个时候A误认为是发生了丢包情况，会重新传输这个数据包。

结果就是不仅浪费了信道资源，还会使网络更加拥塞。因此，我们需要进行拥塞控制。

二、如何知道网络的拥塞情况？

A与B建立连接之后，就可以向B发送数据了，然而这个时候A并不知道此时的网络拥塞情况如何，也就是说，A不知道一次性连续发送多少个数据包好，我们也把A一次性连续发送多少个数据包称之为拥塞窗口，用N代表此时拥塞窗口的大小吧。

为了探测网络的拥塞情况，我们可以采取以下两种策略：

1、先发送一个数据包试探下，如果该数据包没有发生超时事件(也就是没有丢包)。那么下次发送时就发送2个，如果还是没有发生超时事件，下次就发送3个，以此类推，即N = 1, 2, 3, 4, 5.....

2、一个一个增加实在是太慢了，所以可以刚开始发送1个，如果没有发生超时时间，就发送2个，如果还是没有发送超时事件就发送4个，接着8个...，用翻倍的速度类推,即 N = 1, 2, 4, 8, 16...

无论是第一种方法还是第二种方法，最后都会出现瓶颈值。不过这里值得注意的是，第一种情况的增长速率确实有点慢，但是第二种情况以指数增长，增长速度有点太快了，可能一下子就到瓶颈值了。

为了解决这个过慢或过快的问题，我们可以把第一种方法和第二种方法结合起来。也就是说，我们刚开始可以以指数的速度增长，增长到某一个值，我们把这个值称之为阈值吧，用变量ssthresh代替。当增长到阈值时，我们就不在以指数增长了，而是一个一个线性增长。

所以最终的策略是：前期指数增长，到达阈值之后，就以一个一个线性的速度来增长。

我们也把指数增长阶段称之为慢启动，线性增长阶段称之为拥塞避免

三、到了瓶颈值之后怎么办？

无论是指数增长还是一个一个增长，最终肯定会出现超时事件，总不可能无限增长吧。当出现超时事件时，我们就认为此时网络出现了拥塞了，不能再继续增长了。我们就把这个时候的N的值称之为瓶颈值吧，用MAX这个字母来代替吧，即最大值。

当达到最大值MAX之后，我们该怎么办呢？

当到达最大值之后我们采取的策略是这样的：

我们就回到最初的最初的状态，也就是说从1，2，4，8.....开始,不过这个时候我们还会把ssthresh调小，调为MAX值的一半，即ssthresh = MAX / 2。

图中阈值为8，瓶颈值是14；超时事件发生后，阈值为14 / 2 = 7。

四、超时事件就一定是网络拥塞？

超时事件发送就一定是网络出现了拥堵吗？其实也有可能不是出现了网络拥堵，有可能是因为某个数据包出现了丢失或者损害了，导致了这个数据包超时事件发生了

为了防止这种情况，我们是通过冗余ACK来处理的。我们都知道，数据包是有序号的，如果A给B发送M1, M2, M3, M4, M5...N个数据包，如果B收到了M1, M2, M4....却始终没有收到M3，这个时候就会重复确认M2，意在告诉A,M3还没收到，可能是丢失了。

当A连续收到了三个确认M2的ACK，且M3超时事件还没发生。A就知道M3可能丢失了，这个时候A就不必等待M3设置的计时器到期了，而是快速重传M3。并且把ssthresh设置为MAX的一半，即ssthresh = MAX/2，但是这个时候并非把控制窗口N设置为1，而是让N = ssthresh，N在一个一个增长。