拥塞控制和流量控制

拥塞控制目的：防止过多的数据注入网络中，这样可以使网络中的路由器或链路不致过载。

流量控制目的：让发送方的发送速率不要太快，要让接收方来得及接收。

拥塞控制是一个全局性的过程，和流量控制不同，流量控制指点对点通信量的控制。

 

流量控制方法：

在TCP连接上实现对发送方的流量控制：使用滑动窗口机制

假设每一个报文段为100字节长，而数据报文段序号的初始值设为1。初始时接收方B的接收窗口为400，即rwnd=400;大写ACK表示首部中的确认位ACK，小写ack表示确认字段的值ack；

 

如图所示：B进行了三次流量控制（第一次把窗口减少到 rwnd = 300 ，第二次又减到了 rwnd = 100 ，最后减到 rwnd = 0 ，即不允许发送方再发送数据了）;直到主机B重新发出一个新的窗口值给A,A才能重新发送数据给B;

 注：B向A发送的三个报文段都设置了 ACK = 1 ，只有在ACK=1时确认号字段才有意义。

具体过程：设A向B发送数据。在建立TCP连接时，AB双方会进行窗口协商； 相当于B告诉了A：“我的接收窗口( receiver window)是 rwnd = 400 ” , 因此，A的发送窗口不能超过接收方给出的接收窗口的数值。在接收数据的过程中接收方B会动态向发送方A更新rwnd的数值，以此实现对流量的控制；

注：TCP的窗口单位是字节，不是报文段；这里是为了讲解方便，所以采用报文段说明；

 

为了防止死锁情况（B发送给A非零窗口通知在传送中丢失，而A一直等待收到B发送的非零窗口的通知）的发生：

 TCP为每个连接设有一个持续计时器。只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器，若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带1字节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。

糊涂窗口综合证： 

TCP接收方的缓存已满，而交互式的应用进程一次只从接收缓存中读取1字节（这样就使接收缓存空间仅腾出1字节），然后向发送方发送确认，并把窗口设置为1个字节（但发送的数据报为40字节的的话）。

发送方接收，又发来1个字节的数据（发送方的IP数据报是40字节）。接收方发回确认，仍然将窗口设置为1个字节。循环往复，这样网络的效率很低。

解决方案：可让接收方等待一段时间，使得接收缓存已有足够空间容纳一个最长的报文段，或者等到接收方缓存已有一半空闲的空间；再向发送方发确认报文并通知当前的窗口大小。

 

此外，发送方也不要发送太小的报文段，而是把数据报积累成足够大的报文段，或达到接收方缓存的空间的一半大小。

TCP报文段什么时候会发送出去？（4种机制）

     1）TCP维持一个变量，它等于最大报文段长度MSS，只要缓存中存放的数据达到MSS字节就组装成一个TCP报文段发送出去。

     2）由发送方的应用进程指明要求发送报文段，即TCP支持的推送( push )操作；

     3）发送方的一个计时器期限到了，这时就把已有的缓存数据装入报文段(但长度不能超过MSS)发送出去。

     4）Nagle算法：只有在收到对前一个报文段的确认后才继续发送下一个报文段

　　①.当发送应用进程把发送数据（逐个字节地）传输到TCP的发送缓存中;

　　②发送方先把第一个数据字节发送出去，将后续的数据字节都缓存起来;

　　③.当发送方接收对第一个数据字符的确认后，再把发送缓存中的所有数据组装成一个报文段再             发送出去，然后继续对随后到达的数据进行缓存。

      适用场景：当数据到达较快而网络速率较慢时，用这样的方法可明显地减少所用的网络带宽。

      Nagle算法规定：当到达的数据已达到发送窗口大小的一半或已达到报文段的最大长度时，就立                               即发送一个报文段。

 

拥塞控制设计

从控制理论的角度来看拥塞控制这个问题，可以分为开环控制和闭环控制两种方法。

     开环控制就是在设计网络时事先将有关拥塞发生的所有因素考虑周到，一旦系统运行起来就不能在中途改正。

      闭环控制是基于反馈环路的概念，包括如下措施：

     1）监测网路系统以便检测拥塞在何时何地发生

     2）把拥塞发生的信息传送到可采取行动的地方

     3）调整网络系统的行动以解决出现的问题。

拥塞控制方法:

慢开始( slow-start )&&拥塞避免( congestion avoidance )

快重传( fast retransmit )&&快恢复( fast recovery )

随机早期检测RED（randomearly detection）

 

假定前提条件：

     1）数据是单方向传送，而另外一个方向只传送确认

     2）接收方总是有足够大的缓存空间，因为发送窗口的大小由网络的拥塞程度来决定。

基本

 发送方维持一个叫做拥塞窗口cwnd（congestion window）的状态变量。

注：拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。 一般发送方让自己的发送窗口等于拥塞窗口，但考虑到接受方的接收能力，发送窗口可能小于拥塞窗口。

 

慢开始( slow-start )&&拥塞避免( congestion avoidance )

 慢开始算法的思路就是，不要一开始就发送大量的数据，先探测一下网络的拥塞程度，由小到大逐渐增加拥塞窗口的大小；慢开始算法只是在TCP建立时才使用

 慢开始算法让拥塞窗口按指数规律缓慢增长，即每经过一个往返时间RTT就把发送方的拥塞窗口加倍。 

 拥塞避免算法让拥塞窗口按线性规律缓慢增长，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1 。 

 为了防止cwnd增长过大引起网络拥塞，还需设置一个慢开始门限ssthresh状态变量。ssthresh的用法如下：

当cwnd<ssthresh时，使用慢开始算法。

当cwnd>ssthresh时，改用拥塞避免算法。

当cwnd=ssthresh时，慢开始与拥塞避免算法任意。

 拥塞控制具体过程为：

     1）TCP连接初始化，将拥塞窗口设置为1

     2）执行慢开始算法，cwind按指数规律增长，直到cwind == ssthress开始执行拥塞避免算法，cwnd按线性规律增长

     3）发送方判断网络出现拥塞（其根据就是没有收到确认，虽然没有收到确认可能是其他原因的分组丢失，但是因为无法判定，所以都当做拥塞来处理），把ssthresh值更新为出现拥塞时的发送窗口大小的一半，cwnd重新设置为1，按照步骤（2）执行。

如下图：

 

 

 

 一条TCP连接有时会因等待重传计时器的超时而空闲较长的时间，慢开始和拥塞避免无法很好的解决这类问题，因此提出了快重传和快恢复的拥塞控制方法。

快重传( fast retransmit )&&快恢复( fast recovery )

快重传要求接收方在收到一个失序的报文段后就立即发出重复确认而不要等到自己发送数据时捎带确认。

快重传算法规定：发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。

如下图：

 快重传配合使用的还有快恢复算法，它有以下两个要点:

①当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh门限减半；

②考虑到如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将cwnd设置为ssthresh的大小，然后执行拥塞避免算法。如下图：

 

 易混淆点：

慢开始算法只是在TCP建立时才使用

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

快重传算法并非取消了重传机制，只是在某些情况下更早的重传丢失的报文段（如果当发送端接收到三个重复的确认ACK时，则断定分组丢失，立即重传丢失的报文段，而不必等待重传计时器超时）。

 

 

以上的拥塞控制算法并没有和网络层联系起来，实际上网络层的策略对拥塞避免算法影响最大的就是路由器的尾部丢弃策略（路由器通常按照先进先出的策略处理到来的分组，当路由器的缓存装不下分组的时候就丢弃到来的分组）；

这样就会导致分组丢失，发送方认为网络产生拥塞。更为严重的是网络中存在很多的TCP连接，这些连接中的报文段通常是复用路由路径。若发生路由器的尾部丢弃，可能影响到很多条TCP连接；

最终导致的结果就是这许多的TCP连接在同一时间进入慢开始状态。这在术语中称为全局同步。全局同步会使得网络的通信量突然下降很多，而在网络恢复正常之后，其通信量又突然增大很多。

随机早期检测RED（randomearly detection）

 该算法要点如下：

       使路由器的队列维持两个参数，即队列长度的最小门限min和最大门限max，每当一个分组到达的时候，RED通过计算平均队列长度。然后分情况对待到来的分组：

　　　　①平均队列长度小于最小门限——把新到达的分组放入队列排队。

　　　　②平均队列长度在最小门限与最大门限之间——则按照某一概率将分组丢弃。

　　　　③平均队列长度大于最大门限——丢弃新到达的分组。

RED的关键点：

 最小门限、最大门限、丢弃概率三个参数的选择

 计算平均队列长度。

注：平均队列长度采用加权平均的方法计算平均队列长度，这和往返时间（RTT）的计算策略是一样的。

 

参考借鉴：http://blog.csdn.net/sicofield/article/details/9708383