`
woodding2008
  • 浏览: 285216 次
  • 性别: Icon_minigender_1
  • 来自: 北京
社区版块
存档分类
最新评论

TCP拥塞控制

 
阅读更多

       因特网中存在一个重要的问题是拥塞(congestion)。如果一个网络中的负载(load)(也就是发送到网络上的分组数量)大于网络的容量(也就是网络能够处理的分组数量),这个网络就有可能发生拥塞。拥塞控制(congestion control)指的是用来控制拥塞,以使负载保持低于容量的机制和技术。

       我们可能会问为什么网络中会出现拥塞?只要是涉及到等待的系统都会发生拥塞。例如:任何因车流中发生了意外情况而导致的堵车都是高速路上出现拥塞的原因,比如说在上下班高峰时间发生了车祸。

      网络或者互联网中的拥塞是由于路由器或交换机中有一些队列,也就是在分组被处理之前或之后用来保存这些分组的缓存。分组被放入合适的外出队列并等待轮到自己被发送。这些队列空间是有限的。因此到达路由器的分组数量有可能会大于路由器能够保存的分组数量。

      拥塞控制指的是能够在拥塞发生之前预防它,或者在拥塞发生之后消除它的技术和机制。

 

开环拥塞控制

     在拥塞发生之前使用一些策略来预防拥塞称为开环拥塞控制(open-loop congestion control),在此类机制中,拥塞控制可以由源点也可以由重点来处理。

 

重传策略

      有时重传是不可避免的。如果发送方觉得一个发送出去的分组丢失或者损坏了,那么这个分组就需要重传。一般来说,重传可能会加重网络的拥塞。但是,好的重传策略可以预防拥塞。这就需要将重传拥塞略月以及重传计时器设计得够优化效率,同时还能预防拥塞。

 

窗口策略

       发送方窗口的类型也能够影响到拥塞。 

 

确认策略

       由接收方试试的确认策略也有可能影响拥塞。如果接收方不是对每一个收到的分组都进行确认,那么也能够使发送方放慢发送速率,因而有助于预防拥塞。在这种情况下可以使用几种方式。接收方可以仅仅在自己有分组要发送时,或者在一个特殊的计时器到期时才发送一个确认。接收方也可以决定一次为N个分组发送确认。要知道这些确认也是网络负担的一部分。发送的确认越少,给网络带来的负担也越轻。

 

闭环拥塞控制

       闭环拥塞控制(closed-loop congestion control)机制试图在拥塞发生之后缓解拥塞的程度。有几个此类机制已经被用在不同的协议中。我们要描述的是在运输层中使用的机制。发送方的窗口大小可以是灵活的。决定发送方窗口大小的一个因素就是因特网的拥塞状况。发送方的运输层可以通过观察分组的丢失情况来监视因特网的拥塞状况,如果拥塞状况恶化,就用一种策略来减小窗口大小,反之亦然。

 

拥塞窗口

发送方的窗口大小是由接收方的可用缓存空间(rwnd)来决定的。换言之,我们假定了只有接收方能够指示发送方应用当使用多大的发送窗口。此时,我们完全忽略了另一个实体,即网络。如果网络不能像发送方产生数据那样快地把数据交付给接收方,那么它就必须通知发送方放慢速度。换言之,除去了接收方之外,网络是决定发送方窗口大小的第二实体。

      发送方有两种信息:接收方通告的窗口大小和拥塞窗口大小。窗口的真正大小取两者之中较小的一个。

      真正的窗口大小 = minimun(rwnd,cwnd)

 

拥塞策略

       TCP处理拥塞的一般策略是基于三个阶段:慢开始、拥塞避免和拥塞检测。在慢开始阶段,发送方从非常慢的传输速率开始,但很快就把速率增大到一个门限值。当达到门限后,数据率的增长开始放慢。最后,只要一检测到拥塞,发送方就又回到慢开始或者拥塞避免阶段,具体取决于拥塞是如何检测到的。

慢开始:指数增大

        慢开始(slow start)算法是基于这样的想法,即拥塞窗口大小(cwnd)从1个最大报文段的长度(MSS)开始。MSS的数据时在建立时以同样名称的选项来确定的。每当有1个报文段被确认,拥塞窗口增大1个MSS。正如这个名称所暗示的,慢开始算法开始很慢,但按指数规律增大。为了说明这一概念,参考下图。我们假定rwnd远大于cwnd,因此发送方的窗口大小总是等于cwnd。为了保持简单性,我们忽略了推迟ACK策略,并假设每个报文段都被单独确认。

       发送方从cwnd=1MSS开始。这标识发送方只能发送一个报文段。在第一个ACK到达后,拥塞窗口大小增加1,也就是说现在cwnd是2.此时可以发送两个报文段,当相应的两个ACK到达后,对于每一个ACK,窗口大小增加1MSS,这就是标识cwnd 现在是4,。此时可以发送4个报文段。当四个ACK到达后,窗口大小又增加4,也就是cwnd等于8.

 

      如果我们从往返RTT的角度来看cwnd的大小,就会发现它的增长速率是按指数规律的,如下所示:

        在推迟确认的策略下,慢开始策略的增长速度要更慢一些。我们知道,对于每个ACK,cwnd只能增加一个MSS。因此,如果三个报文段被累计确认,那么cwnd的值仅增加1MSS,而不是3 MSS。这个增长仍然是指数的,但是它不再是2的乘方。如果每两个个报文段使用一个确认,那么它大约是1.5的乘方。

       慢开始不能无限制的继续下去。一定要有一个门限来停止这个阶段。发送方密切关注一个为ssthresh(慢开始门限)的变量。当以字节的窗口大小到达这个门限时,慢开始阶段就结束了,并进入下一个阶段。

 

拥塞避免:加法增大

       如果我们从曼算法开始,拥塞窗口大小就按指数规律增长。为了在拥塞发生之前避免它,就必须使这种指数增长的变慢。TCP定义了另一个算法,叫作拥塞避免(congestion avoidance),使cwnd的值按照加法规律增长,而不是按照指数规律,见下图。

 

        当拥塞窗口大小达到慢开始的门限时(此时假设cwnd=i),慢开始阶段就停止,而加法增加阶段就开始了。这种算法中,每当一整个“窗口”中的报文段都被确认后,拥塞窗口大小才增加1。一个窗口就是指在一个RTT期间传输的报文段的数量。换言之,这个增长是基于RTT的,而不是基于到达的ACK数量。为了说明这个思想,我们把这个算法应用到和满开始一样的情况中。此时,发送方收到了一个完整窗口大小的报文段的确认后,窗口的大小增加1个报文段。如果我们从往返时间RTT的角度来看cwnd的大小,就会发现速率是按照加法规律增长的。

 

 拥塞检测:乘法减小

        若拥塞发生了,拥塞窗口的大小就必须减小。让发送方能够猜测到拥塞已发生的唯一现象就是它需要重传一个报文段。这也是TCP做出的一个重要的假定,之所以需要重传是为了恢复一个意识的分组,而这个分组假设是因为某个路由器有太多的输入分组而不得不丢弃,所以才被丢掉的,也就是说,路由器或网络已变得超载或拥塞了,不过,重传可以发生在以下两种情况之一:当RTO计时器超时,或者是当收到了三个重复的ACK时。不管是哪一种情况,门限值都要下降到一半(乘法减小)。大多数的TCP实现由下面两种反映:

1、如果是计时器超时,那么出现拥塞的可能性就很大。某个报文段可能在网络中的某处被丢弃了,而后续的报文段也没有任何消息。在这种情况下,TCP有下面较强烈的反映:

a、把门限值设置为当前窗口大小的一半

b、把cwnd重新设置为一个报文段

c、再次从满开始阶段开始

 

2、如果是收到了三个ACK,那么出现拥塞的可能性就较小。某个报文段可能被丢弃了,但之后的几个报文已安全到了,因为它收到了三个重复的ACK。这就称为快重传和快恢复。在这种情况下,TCP有下面这样较弱的反映:

a、把门限值设置为当前窗口的一半

b、把cwnd设置为门限值(某些实现会在门限值上再增加3个报文段)

c、启动拥塞避免阶段。

 

拥塞小结

TCP拥塞策略以及这三个阶段的关系见下图。

 

       假设最大窗口的大小的初始值是32个报文段。门限值的初始值设置为16个报文段(最大窗口的一半)。在慢开始阶段,窗口大小从1开始逐渐按指数规律增大,只是窗口大小达到门限值。在达到门限值后,拥塞避免(加法增大)过程使用窗口大小按线性规律增长,直至出现了超时现象或者达到了最大窗口大小。在图中,窗口大小达到20时发生了超时现象。此时,乘法减小过程开始生效,并把门限值减小到窗口大小的一半。因为超时发生时,窗口大小是20,所以新的门限现在是10.

 

        TCP重新进入满开始,并从窗口值为1开始,到达新的门限值时变为加法增大。当窗口值为12时,三个重复的ACK时间发生了。现在又转为乘法减小过程。门限值和窗口大小设置为6,这一次TCP进入加法增大阶段。TCP一直停留在这个阶段,直至发生另一个超时时间或3个重复的ACK事件。

 

 

 

最长报文大小 MSS(Maximum Segment Size)

  • 大小: 35.1 KB
  • 大小: 54.7 KB
  • 大小: 82.5 KB
  • 大小: 127.2 KB
  • 大小: 60.8 KB
  • 大小: 66.3 KB
分享到:
评论

相关推荐

    TCP拥塞控制例题-202004011

    TCP拥塞控制例题:某TCP拥塞窗口演化图如下图所示,其中[1, 6]轮次是慢启动阶段,[6, 14]轮次是拥塞避免阶段,[15, 17]轮次是快速恢复阶段,

    论文研究-一种主动TCP拥塞控制方案.pdf

    基于广泛使用的TCP版本TCP Reno,提出了一种主动TCP拥塞控制方案,命名Active-TCP。在沿用传统的被动拥塞控制方式的同时,Active-TCP添加了主动拥塞控制方式,即在满足给定条件下,Active-TCP可主动降低拥塞窗口,而...

    TCP拥塞控制机制定量性能分析

    目前,TCP协议承载着因特网超过70%的传输流量,TCP拥塞控制机制可以有效地改善网络拥塞现象。本文主要研究几种常见的TCP拥塞控制算法,借助于网络模拟器NS2,对这几种常用算法的性能进行定量分析,并给出相应的合理...

    TCP拥塞控制算法研究

    随着网络需求的增长,网络拥塞已成为一个严重的问题。本文档基于传统的TCp 拥塞控制算法进行研究及改进。

    tcp拥塞控制

    tcp拥塞控制,tcp拥塞控制有关的的论文

    TCP拥塞控制的典型算法分析

    TCP拥塞控制的典型算法分析,拥塞的原因以及控制拥塞的机制,并对几种经典算法进行分析

    TCP拥塞控制TCP拥塞控制TCP拥塞控制

    TCP拥塞控制 TCP拥塞控制

    TCP 拥塞控制 个人总结资料 PPT

    自己花了两周总结整理的关于TCP拥塞控制的PPT,包括背景,研究现状,慢启动、拥塞避免等算法描述,以及典型的四种拥塞控制策略的介绍,资料内容很详实,值得参考

    基于机器学习的TCP拥塞控制算法识别研究.pdf

    基于机器学习的TCP拥塞控制算法识别研究.pdf

    TCP拥塞控制原理演示系统

    TCP拥塞控制算法由不同组成部分: (1)AIMD。 (2)Slow Start。 (3)对超时事件的处理。 该系统只需向用户提供AIMD和Slow Start两部分的原理演示。 系统运行时,用户可随意选择演示内容。 开发工具不限,但...

    Linux的TCP拥塞控制算法CUBIC

    CUBIC算法是基于BIC-TCP算法的改进算法,它主要是解决在大带宽延迟积网络中TCP拥塞窗口增长缓慢的问题,其具有TCP友好性与RTT公平性,实时保持窗口的增长率不受RTT的影响。CUBIC在公平性上解决了TCP流量友好性与其他...

    TCP拥塞控制方法的探讨

    拥塞控制理论和算法研究因此成为 Intemet研究中的一个热点。 拥塞现象发生的原因.总的来说是Intemet网络中的需求大 于供给,即网络的资源(缓冲、链路带宽和网关处理能力等)是有 限的.这些有限资源要在网络用户之间...

    TCP拥塞控制四个主要过程

    TCPTCPTCPTCPTCPTCPTCPTCPTCPTCP

    TCP-Congestion-Control-Algorithm.rar_TCP 拥塞控制_TCP拥塞控制_reno_tcp c

    TCP拥塞控制算法性能比较:包括reno算法和vega算法的模拟

    基于LwIP 的 TCP 拥塞控制方法的改进

    LwIP 的 TCP 拥塞控制方法的改进

    TCP拥塞控制1

    TCP拥塞控制TCP拥塞控制拥塞控制四种算法发送窗口 = Min{接收窗口rwnd,拥塞窗口cwnd}接收窗口:接收方根据接收缓存设置的值,并告知发送方,反应接

    TCP网络拥塞控制

    列举了现有的TCP网络拥塞控制算法,并对其进行分析,对这些算法的优缺点进行了比较,总结了TCP拥塞控制目前的研究成果,指明了未来研究热点和发展方向,为TCP网络拥塞控制接下来的研究工作奠定了一定的基础。

    论文研究-TCP拥塞控制的路由缓存策略 .pdf

    TCP拥塞控制的路由缓存策略,邵艳,黄远江,本文以单一链路、单一TCP流量为模型,在TCP Reno和TCPW两种算法下进行理论推导,说明要获得最高的链路利用率,在TCP Reno算法下,路由缓�

Global site tag (gtag.js) - Google Analytics