当先锋百科网

首页 1 2 3 4 5 6 7

TCP拥塞控制

 

拥塞控制就是防止过多的数据注入网络中,这样可以使网络中的路由器或链路不致过载。拥塞控制是一个全局性的过程,和流量控制不同,流量控制指点对点通信量的控制。

 

超时重传机制

超时重传机制主要是为了解决数据包在传输过程中丢失的问题。

TCP每发送一个报文段,就会为这个报文段开启一个定时器,如果定时器溢出时仍然没有收到接收端的应答报文,那么TCP就认为这个报文段在传输过程中丢失,然后重新发送这个报文段。这便是超时重传机制

举例:客户端请求发送”and hi”报文段时启动了定时器,然而在规定的时间内没有收到对端的回复,所以重新发送”and hi”报文段,并重启定时器(重启的定时器时间会增大)。

 

拥塞控制机制

超时重传是为了解决数据丢失的问题,而数据丢失的原因很大程序上是由于传输路径拥塞导致的。

在正常的传输过程中,数据是从一个路由器跳到下一个路由器,每个路由器都有自己的缓冲区,新来的数据会存放在缓冲区中,与此同时路由器也在不断地将缓冲区中的数据发送给下一个路由器。但是如果某个路由器接收数据的速率大于发送数据的速率,就会导致缓冲区数据累积,最终填满缓冲区。此时如果再有数据到来,缓冲区已经无法容纳它们,只能将它们丢掉,造成数据丢失,这就是所谓的拥塞现象,本质就是传输路径上的节点不平衡。为了解决这一问题,就需要当出现拥塞现象时立即减少发送端发送的数据量,为路径上的某些节点提供清空缓冲区的时间,同时也避免了不必要的重传。

但是,发送端如何才能得知网络中发生了拥塞呢。因为由于硬件错误造成的数据丢失是很罕见的,所以发送端假定,如果出现了数据丢失,那么就可以认定发生了拥塞。

发送方维持一个叫做拥塞窗口cwnd(congestion window)的状态变量。拥塞窗口的大小取决于网络的拥塞程度,并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口,另外考虑到接受方的接收能力,发送窗口小于拥塞窗口。

 

慢启动  

(乘法递增,直到阈值,进入拥塞避免算法阶段;或者遇到网络拥塞,把阈值设为拥塞时窗口的一半,重新慢开始)

慢开始算法的思路就是,不要一开始就发送大量的数据,先探测一下网络的拥塞程度,也就是说由小到大逐渐增加拥塞窗口的大小。

这里用报文段的个数的拥塞窗口大小举例说明慢开始算法,实时拥塞窗口大小是以字节为单位的。

如下图:

当然收到单个确认但此确认多个数据报的时候就加相应的数值。所以一次传输轮次之后拥塞窗口就加倍。这就是乘法增长,和后面的拥塞避免算法的加法增长比较。

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

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

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

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

 

拥塞避免 

(加法线性递增,直到遇到网络拥塞,将慢开始阈值设为拥塞时窗口的一半,重新慢开始)

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

无论是在慢开始阶段还是在拥塞避免阶段,只要发送方判断网络出现拥塞(其根据就是没有收到确认,虽然没有收到确认可能是其他原因的分组丢失,但是因为无法判定,所以都当做拥塞来处理),就把慢开始门限设置为出现拥塞时的发送窗口大小的一半。然后把拥塞窗口设置为1,执行慢开始算法。

如下图:

再次提醒这里只是为了讨论方便而将拥塞窗口大小的单位改为数据报的个数,实际上应当是字节。

 

快重传 

(若收到对端连续三次重复确认包,则立即给对端重传失序的报文段)

快重传要求接收方在收到一个失序的报文段后就立即发出重复确认(为的是使发送方及早知道有报文段没有到达对方)而不要等到自己发送数据时捎带确认。快重传算法规定,发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段,而不必继续等待设置的重传计时器时间到期。

如下图:

 

快恢复 

(当连续收到三个重复确认时,乘法减少,即把慢开始的阈值设为快重传时窗口的一半,并将窗口也设成相同值,再进行拥塞避免算法,即加法递增)

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

  • 当发送方连续收到三个重复确认时,就执行“乘法减小”算法,把ssthresh门限减半。但是接下去并不执行慢开始算法。

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

如下图:

 

与流量控制区别

TCP有一个叫做流量控制的机制,它与拥塞控制非常相似,但是仍然有一些差异

  • 流量控制是端对端的控制机制,两端各自通知对方允许的窗口大小以防止对端发送过多数据导致自己来不及处理造成接收缓冲区被填满
  • 拥塞控制不是端对端的控制机制,它是为了缓解从一端到另一端这条路径上的拥堵问题

不过二者都是通过限制发送方发送的数据包个数来解决问题,所以上述算法无非就是降低发送端发送速率,缓解网络压力。