精华内容
下载资源
问答
  • 拥塞控制 千次阅读
    2020-07-30 10:44:20

    概念

    拥塞控制是TCP避免网络拥塞的算法,是互联网上主要的一个拥塞控制措施。主要的目标是提高网络利用率降低丢包率保证网络资源对每条数据流的公平性*。它使用一套基于线增积减模式的多样化网络拥塞控制方法(包括慢启动和拥塞窗口等模式)来控制拥塞。在互联网上应用中有相当多的具体实现算法。

    拥塞算法

    TCP Tahoe/Reno

    最初的实现,包括慢启动、拥塞避免两个部分。基于重传超时(retransmission timeout/RTO)和重复确认为条件判断是否发生了丢包。
    两者的区别在于:
    Tahoe算法下如果收到三次重复确认,就进入快重传立即重发丢失的数据包,同时将慢启动阈值设置为当前拥塞窗口的一半,将拥塞窗口设置为1MSS,进入慢启动状态;
    Reno算法如果收到三次重复确认,就进入快重传,但不进入慢启动状态,而是直接将拥塞窗口减半,进入拥塞控制阶段,这称为“快恢复”。
    而Tahoe和Reno算法在出现RTO时的措施一致,都是将拥塞窗口降为1个MSS,然后进入慢启动阶段。

    TCP Vegas

    TCP Vegas算法由 Lawrence Brakmo 和 Larry L. Peterson 在1994年提出,它和其他拥塞控制算法的不同之处在于Vegas算法并不急于丢包来判断是否发生了拥塞,而是通过数据包延迟来判断。Vegas通过RTT(roundtrip time)来决定增加或者减小拥塞窗口,它能够拥塞将要发生时就避免拥塞,而不是等到拥塞已经发生之后再减小发送速度,因此能够减小重传和超时的几率。Vegas算法与其他算法(比如Reno)共存时,会由于比其他算法更先降低发送速率而出现公平性问题。

    TCP New Reno

    TCP New Reno是对TCP Reno中快速恢复阶段的重传进行改善的一种改进算法,其定义于RFC 6582,覆盖了原有在RFC 3782和RFC 2582的旧定义。
    在Reno的快恢复中,一旦出现3次重复确认,TCP发送方会重发数据包并设置定时器等待该重发数据包被确认。当重发的数据包被确认后,就立即退出快速恢复阶段,进入拥塞控制阶段。但如果一次拥塞中出现多个丢包,Reno会误以为发生了多次拥塞而重复减小拥塞窗口导致发送速率下降。
    而在New Reno的快速恢复中,一旦出现3次重复确认,会记下出现重复确认时未确认的数据包的最大序列号,然后重发重复确认的数据包。如果有多个数据包丢失,则继续重发丢失的数据包,知道最大序列号的数据包被确认才推出快恢复阶段。
    New Reno在低错误率时运行效率和“选择确认”(Selective ACKnowledgement,SACK)相当,在高错误率仍优于Reno。

    TCP BIC 和 CUBIC

    TCP BIC(Binary Increase Congestion control)旨在优化高速高延迟网络(即根据RFC 1072所定义的“长肥网络”(long fat network,LFN))的拥塞控制,其拥塞窗口算法使用二分搜索算法尝试找到能长时间保持拥塞窗口最大值的值。Linux内核在2.6.8至2.6.18使用该算法作为默认TCP拥塞算法。
    CUBIC则是比BIC更温和和系统化的分支版本,其使用三次函数代替二分算法作为其拥塞窗口算法,并且使用函数拐点作为拥塞窗口的设置值。Linux内核在2.6.19后使用该算法作为默认TCP拥塞算法。

    详细可参考:TCP拥塞控制

    Reno算法介绍

    主要包含四个部分

    • 慢热启动算法 – Slow Start
    • 拥塞避免算法 – Congestion Avoidance
    • 快速重传 - Fast Retransimit
    • 快速恢复算法 – Fast Recovery

    概念术语

    • CWND Congestion Window,拥塞窗口(发送端定义调节发送端的量。跟接收窗口比,那个小取那个)
    • MSS maximum segment size, 指的是TCP传输层的最大传输单元(就是一个包的最大值)
    • RTT, round-trip time, 指的是从发送到接收这一个来回的行程所用的总体时间
    慢热启动算法 – Slow Start
    1. 连接建好的开始先初始化cwnd(拥塞窗口)大小为N,表明可以传N个MSS大小的数据。
    2. 每当收到一个ACK,cwnd大小加一,呈线性上升。
    3. 每当过了一个往返延迟时间RTT(Round-Trip Time),cwnd大小直接翻倍,乘以2,呈指数增长。
    4. 还有一个慢启动门限ssthresh(slow start threshold),是一个上限,当cwnd >= ssthresh时,就会进入"拥塞避免算法 - Congestion Avoidance"
      在这里插入图片描述
    拥塞避免算法 – Congestion Avoidance
    1. 每收到一个ACK,调整cwnd 为 (cwnd + 1/cwnd) * MSS个字节每当收到一个ACK,cwnd大小加一,呈线性上升。
    2. 每经过一个RTT的时长,cwnd增加1个MSS大小。
      在这里插入图片描述
    拥塞状态时的超时重传

    TCP是看不到网络的整体状况的,那么TCP认为网络拥塞的主要依据是它重传了报文段出现RTO超时,重传数据包。TCP就认为出现拥塞的可能性就很大,于是它反应非常“强烈”

    1. 由于发生丢包,将慢启动阈值ssthresh设置为当前cwnd的一半,即ssthresh = cwnd / 2.
    2. cwnd重置为1
    3. 进入慢启动过程
      在这里插入图片描述
    拥塞状态时的快速重传

    在快速重传的时候,一般网络只是轻微拥堵,在进入拥塞避免后,cwnd恢复的比较慢。针对这个,“快速恢复”算法被添加进来,当收到3个冗余ACK时,TCP最后的步骤进入的不是拥塞避免阶段,而是快速恢复阶段。

    1. 调整门限ssthresh的值为当前cwnd值的1/2。
    2. 将cwnd值设置为新的ssthresh的值
    3. 重新进入拥塞避免阶段
      在这里插入图片描述
    快速恢复算法 – Fast Recovery

    快速恢复的思想是“数据包守恒”原则,即带宽不变的情况下,在网络同一时刻能容纳数据包数量是恒定的。当“老”数据包离开了网络后,就能向网络中发送一个“新”的数据包。既然已经收到了3个冗余ACK,说明有三个数据分段已经到达了接收端,既然三个分段已经离开了网络,那么就是说可以在发送3个分段了。于是只要发送方收到一个冗余的ACK,于是cwnd加1个MSS。快速恢复步骤如下(在进入快速恢复前,cwnd 和 sshthresh已被更新为:sshthresh = cwnd /2,cwnd = sshthresh)

    1. cwnd设置为ssthresh的值加3,重传Duplicated ACKs指定的数据包
    2. 如果再收到 duplicated Acks,那么cwnd = cwnd +1
    3. 如果收到新的ACK,而非duplicated Ack,那么将cwnd重新设置为的sshthresh的值。然后进入拥塞避免状态。
      在这里插入图片描述

    细心的同学可能会发现快速恢复有个比较明显的缺陷就是:它依赖于3个冗余ACK,并假定很多情况下,3个冗余的ACK只代表丢失一个包。但是3个冗余ACK也很有可能是丢失了很多个包,快速恢复只是重传了一个包,然后其他丢失的包就只能等待到RTO超时了。超时会导致ssthresh减半,并且退出了Fast Recovery阶段,多个超时会导致TCP传输速率呈级数下降。出现这个问题的主要原因是过早退出了Fast Recovery阶段。为解决这个问题,提出了New Reno算法,该算法是在没有SACK的支持下改进Fast Recovery算法(SACK改变TCP的确认机制,把乱序等信息会全部告诉对方,SACK本身携带的信息就可以使得发送方有足够的信息来知道需要重传哪些包,而不需要重传哪些包),具体改进如下:

    1. 发送端收到3个冗余ACK后,重传冗余ACK指示可能丢失的那个包segment1,如果segment1的ACK通告接收端已经收到发送端的全部已经发出的数据的话,那么就是只丢失一个包,如果没有,那么就是有多个包丢失了。
    2. 发送端根据segment1的ACK判断出有多个包丢失,那么发送端继续重传窗口内未被ACK的第一个包,直到sliding window内发出去的包全被ACK了,才真正退出Fast Recovery阶段。

    参考文档:《图解TCP/IP》
    参考文档:https://www.zhoulujun.cn/html/theory/ComputerScienceTechnology/network/2015_0708_65.html
    参考文档:https://blog.csdn.net/wdscq1234/article/details/52529994

    更多相关内容
  • TCP拥塞控制 TCP拥塞控制
  • 基于广泛使用的TCP版本TCP Reno,提出了一种主动TCP拥塞控制方案,命名Active-TCP。在沿用传统的被动拥塞控制方式的同时,Active-TCP添加了主动拥塞控制方式,即在满足给定条件下,Active-TCP可主动降低拥塞窗口,而...
  • 数据报拥塞控制协议(Datagram Congestion Control Protocol, DCCP)是提供拥塞控制和不可靠传输特点的实时多媒体基础协议, DCCP中的CCID2算法仍然采用AIMD的控制机制, 这种传统的Loss-Base拥塞控制模型已经不适用于...
  • 在考虑多回路时延、网络负载动态变化和高优先级业务影响的前提下,基于流体流理论,推导建立了可调服务速率的业务流量控制数学模型,并提出了一种简单实用的流量控制算法,所得出的控制机制适用于高优先级业务和...
  • 介绍了无线传感器网络拥塞控制的内容和特点,仔细分析了在无线传感器网络中实施拥塞控制算法所涉及的技术难点及不足,并对现有工作进行了归纳和总结。最后,探讨了发展初期该研究领域的未来发展方向。
  • 拥塞控制测试环境

    2018-11-02 15:59:08
    一个拥塞控制的测试环境,包含了PCC, Copa等比较新的拥塞控制算法,可以结合Mahimahi进行网络仿真
  • 现有的拥塞控制策略仅保证网络层的性能,没有考虑车辆不同交通场景下的微观服务需求。为解决该问题,提出了一种基于网络效用最大化理论的分布式拥塞控制策略。该策略首先提出了车联网信道资源分配的网络效用最大化...
  • 针对无线传感器网络存在的拥塞问题, 设计一种基于领导者的拥塞控制算法. 利用分布式动态系统的 理论对拥塞问题进行建模, 并证明了所提出的算法能够保证所有节点的发送速率收敛到可用的最小带宽, 同时利 用...
  • 主要为大家介绍了如何解决TCP窗口大小的调节与拥塞控制的办法,有图有步骤,很详细,需要的朋友可以参考下
  • 提出了一种新的自适应分层多播拥塞控制方案(ALM)。ALM是发送方与接收方共同驱动、由路由器辅助流量控制的拥塞控制方案,通过把发送方的动态分层和接收方的自适应速率调整有机结合,不仅增强了分层多播的适应能力,...
  • 本文提出一种新的基于多径的低轨卫星网络路由拥塞控制策略,利用多径规避拥塞,提高传输鲁棒性。并以铱星星座为仿真场景,对本文提出的路由策略和单径路由算法进行仿真。仿真结果表明,本文提出的路由策略在通信资源...
  • 针对OpenFlow网络中的拥塞问题,基于SDN/OpenFlow网络架构,提出一种新的OpenFlow网络拥塞控制机制。该机制具有利用控制器对网络资源进行全局管理的优点,即当网络中有节点处于拥塞状态,控制器选择一条或者多条合适的...
  • 针对无线异构链路环境中传统TCP拥塞控制机制效率较低的问题,本文提出一种基于ECN的多级反馈算法。该算法在ECN的基础上可以根据RTT动态地给网络划分等级并进行概率反馈,改变了ECN的二元特性,有效提高了无线数据...
  • TCP拥塞控制

    千次阅读 2022-03-20 21:41:11
    1、拥塞控制原理 在实践中,丢包一般是当网络变得拥塞时由于路由器缓存溢出引起的。分组重传因此作为网络拥塞的征兆(某个特定的运输层报文段的丢失)来对待,但是却无法处理导致网络拥塞的原因,因为有太多的源以过...

    1、拥塞控制原理

    在实践中,丢包一般是当网络变得拥塞时由于路由器缓存溢出引起的。分组重传因此作为网络拥塞的征兆(某个特定的运输层报文段的丢失)来对待,但是却无法处理导致网络拥塞的原因,因为有太多的源以过高的速率发送数据。为了处理网络拥塞原因,需要一些机制以在面临网络拥塞时遏制发送方。

    1.1 拥塞原因及代价

    • 情况1:两个发送方和一台具有无穷大缓存的路由器

    甚至在这种(极端)理想化的情况中,已经发现了拥塞网络的一种代价,即当分组的到达速率接近链路容量时,分组经历巨大的排队时延。

    • 情况2:两个发送方和一台具有有限缓存的路由器

    另一种网络拥塞的代价,即发送方必须执行重传以补偿因为缓存溢出而丢弃(丢失)的分组。

    另一种网络拥塞的代价,即发送方在遇到大时延时所进行的不必要重传会引起路由器利用其链路带宽来转发不必要的分组副本。

    • 情况3:4个发送方和具有有限缓存的多台路由器及多跳路径

    由于拥塞而丢弃分组的另一种代价,即当一个分组沿一条路径被丢弃时,每个上游路由器用于转发该分组到丢弃该分组而使用的传输容量最终被浪费掉了。

    1.2 拥塞控制方法

    TCP拥塞控制方法在下节讲解,这里,指出在实践中所采用的两种主要拥塞控制方法,讨论特定的网络体系结构和具体使用这些方法的拥塞控制协议。

    在最为宽泛的级别上,可根据网络层是否为运输层拥塞控制提供了显式帮助,来区分拥塞控制方法。

    • 端到端拥塞控制。在端到端拥塞控制方法中,网络层没有为运输层拥塞控制提供显式支持。即使网络中存在拥塞,端系统也必须通过对网络行为的观察(如分组丢失与时延)来推断之。(TCP采用端到端的方法解决拥塞控制,因为IP层不会向端系统提供有关网络拥塞的反馈信息。TCP报文段的丢失(通过超时或3次冗余确认而得知)被认为是网络拥塞的一个迹象,TCP会相应地减小其窗口长度。还有一些关于TCP拥塞控制的最新建议,即使用增加的往返时延值作为网络拥塞程度增加的指示。)
    • 网络辅助的拥塞控制。在网络辅助的拥塞控制中,路由器向发送方提供关于网络中拥塞状态的显式反馈信息。这种反馈可以简单地用一个比特来指示链路中的拥塞情况。如在 ATM可用比特率(Available Bite Rate,ABR) 拥塞控制中,路由器显式地通知发送方它(路由器)能在输出链路上支持的最大主机发送速率。默认因特网版本的IP和TCP采用端到端拥塞控制方法。然而,最近IP和TCP也能够选择性地实现网络辅助拥塞控制。

    对于网络辅助的拥塞控制,拥塞信息从网络反馈到发送方通常有两种方式,如下图所示:
    网络指示拥塞信息的两种反馈路径
    直接反馈信息可以由网络路由器发给发送方。这种方式的通知通常采用了一种 阻塞分组(choke packet) 的形式(主要是说:“我阻塞了!”)。

    更为通用的第二种形式的通知是,路由器标记或更新从发送方流向接收方的分组中的某个字段来指示拥塞的产生。一旦收到一个标记的分组后,接收方就会向发送方通知该网络阻塞指示。注意到后一种形式的通知至少要经过一个完整的往返时间。

    2、TCP拥塞控制

    2.1 拥塞控制原理

    TCP为运行在不同主机上的两个进程之间提供了可靠数据传输服务。

    TCP的另一个关键部分就是其拥塞控制机制。

    TCP必须使用端到端拥塞控制而不是网络辅助的拥塞控制,因为IP层不向端系统提供显式的网络拥塞反馈。

    TCP所采用的方法是让每一个发送方根据所感知到的网络拥塞程度来限制其能向连接发送流量的速率。 如果一个TCP发送方感知从它到目的地之间的路径上没什么拥塞,则TCP发送方增加其发送速率;如果发送方感知沿着该路径有拥塞,则发送方就会降低其发送速率。但是这种方法提出了三个问题:

    1. 一个TCP发送方如何限制它向其连接发送流量的速率呢?
    2. 一个TCP发送方如何感知从它到目的地之间的路径上存在拥塞呢?
    3. 当发送方感知到端到端的拥塞时,采用何种算法来改变其发送速率呢?

    1、首先分析一下 TCP 发送方是如何限制向其连接发送流量的。

    TCP连接的每一端都是由一个接收缓存、一个发送缓存和几个变量(LastByteRead、rwnd等)组成。运行在发送方的TCP拥塞控制机制跟踪一个额外的变量,即拥塞窗口(congestion window)。拥塞窗口表示为 cwnd,它对一个TCP发送方能向网络中发送流量的速率进行了限制。特别是,在一个发送方中未被确认的数据量不会超过 cwnd 和 rwnd 中的最小值,即

    L a s t B y t e S e n t − L a s t B y t e A c k e d ≤ m i n { c w n d , r w n d } LastByteSent−LastByteAcked≤min\{cwnd,rwnd\} LastByteSentLastByteAckedmin{cwnd,rwnd}

    为了关注拥塞控制(与流量控制形成对比),后面假设 TCP 接收缓存足够大,以至可以忽略接收窗口的限制;因此,在发送方中未被确认的数据量仅受限于cwnd。还假设发送方总是有数据要发送,即在拥塞窗口中的所有报文段要被发送。

    上面的约束限制了发送方中未被确认的数据量,因此间接地限制了发送方的发送速率。为了理解这一点,考虑一个丢包和发送时延均可忽略不计的连接。因此粗略地讲,在每个往返时间(RTT)的起始点,上面的限制条件允许发送方向该连接发送cwnd个字节的数据,在该RTT结束时发送方接收对数据的确认报文。因此,该发送方的发送速率大概是 c w n d / R T T cwnd/RTT cwnd/RTT 字节/秒。通过调节 cwnd 的值,发送方因此能调整它向连接发送数据的速率。

    2、接下来考虑TCP发送方是如何感知在它与目的地之间的路径上出现了拥塞的。

    将一个 TCP 发送方的“丢包事件” 定义为:要么出现超时,要么收到来自接收方的 3 个冗余ACK。 当出现过度的拥塞时,在沿着这条路径上的一台(或多台)路由器的缓存会溢出,引起一个数据报(包含一个TCP报文段)被丢弃。丢弃的数据报接着会引起发送方的丢包事件(要么超时或收到 3 个冗余ACK),发送方就认为在发送方到接收方的路径上出现了拥塞的指示。

    考虑了拥塞检测问题后,接下来考虑网络没有拥塞这种更为乐观的情况,即没有出现丢包事件的情况。在此情况下,在TCP的发送方将收到对于以前未确认报文段的确认。TCP将这些确认的到达作为一切正常的指示,即在网络上传输的报文段正被成功地交付给目的地,并使用确认来增加窗口的长度(及其传输速率)。注意到如果确认以相当慢的速率到达(例如,如果该端到端路径具有高时延或包含一段低带宽链路),则该拥塞窗口将以相当慢的速率增加。在另一方面,如果确认以高速率到达,则该拥塞窗口将会更为迅速地增大。因为TCP使用确认来触发(或计时)增大它的拥塞窗口长度,TCP被说成是自计时(self-clocking)的。

    3、TCP 发送方怎样确定它应当发送的速率?

    给定调节 cwnd 值以控制发送速率的机制,关键的问题依然存在:TCP发送方怎样确定它应当发送的速率呢?如果众多 TCP 发送方总体上发送太快,它们能够拥塞网络,导致拥塞崩溃。然而,如果TCP发送方过于谨慎,发送太慢,它们不能充分利用网络的带宽;这就是说,TCP发送方能够以更高的速率发送而不会使网络拥塞。那么 TCP 发送方如何确定它们的发送速率,既使得网络不会拥塞,与此同时又能充分利用所有可用的带宽?TCP发送方是显式地协作,或存在一种分布式方法使 TCP 发送方能够仅基于本地信息设置它们的发送速率?TCP使用下列指导性原则回答这些问题:

    • 一个丢失的报文段表意味着拥塞,因此当丢失报文段时应当降低 TCP 发送方的速率。 对于给定报文段,一个超时事件或四个确认(一个初始ACK和其后的三个冗余ACK)被解释为跟随该四个 ACK 的报文段的“丢包事件” 的一种隐含的指示。从拥塞控制的观点看,该问题是 TCP 发送方应当如何减小它的拥塞窗口长度,即减小其发送速率,以应对这种推测的丢包事件。

    • 一个确认报文段指示该网络正在向接收方交付发送方的报文段,因此,当对先前未确认报文段的确认到达时,能够增加发送方的速率。确认的到达被认为是一切顺利的隐含指示,即报文段正从发送方成功地交付给接收方,因此该网络不拥塞。拥塞窗口长度因此能够增加。

    • 带宽测试。 给定 ACK 指示源到目的地路径无拥塞,而丢包事件指示路径拥塞,TCP调节其传输速率的策略是增加其速率以响应到达的 ACK,除非出现丢包事件,这时才减小传输速率。因此,为探测拥塞开始出现的速率,TCP发送方增加它的传输速率,从该速率后退,进而再次开始探测,看看拥塞开始速率是否发生了变化。TCP发送方的行为也许类似于要求(并得到)越来越多糖果的孩子,直到最后告知他/她“不行!”,孩子后退一点,然后过一会儿再次开始提出请求。注意到网络中没有明确的拥塞状态指令,即ACK 和丢包事件充当了隐式信号,并且每个 TCP 发送方根据异步与其他 TCP 发送方的本地信息而行动。

    2.2 TCP拥塞控制算法(TCP congestion control algorithm)

    该算法包括 3 个主要部分:①慢启动;②拥塞避免;③快速恢复。

    其中慢启动和拥塞避免是TCP的强制部分,两者的差异在于对收到的 ACK 做出反应时增加 cwnd 长度的方式。慢启动比拥塞避免能更快地增加cwnd的长度。

    快速恢复是推荐部分,对TCP发送方并非是必需的。

    1、慢启动

    当一条TCP连接开始时, cwnd 的值通常初始置为一个 MSS 的较小值,这就使得初始发送速率大约为 MSS/RTT。(例如MSS = 500字节且RTT = 200ms,则得到的初始发送速率大约只有 20kbps)。

    由于对TCP发送方而言,可用带宽可能比 MSS/RTT 大得多,TCP发送方希望迅速找到可用带宽的数量。

    因此,慢启动(slow-start)状态,cwnd的值以 1 个 MSS 开始并且每当传输的报文段首次被确认就增加 1 个 MSS
    image-20220307134906616
    图解:TCP向网络发送第一个报文段并等待一个确认。当该确认到达时,TCP发送方将拥塞窗口增加一个 MSS,并发送出两个最大长度的报文段。这两个报文段被确认,则发送方对每个确认报文段将拥塞窗口增加一个 MSS,使得拥塞窗口变为 4 个MSS,并这样下去。这一过程每过一个 RR,发送速率就翻番。因此,TCP发送速率起始慢,但在慢启动阶段以指数增长。

    何时结束这种指数增长呢? 慢启动对该问题提供了几种答案:

    • 首先,如果存在一个由超时指示的丢包事件(即拥塞),TCP发送方将cwnd 设置为1并重新开始慢启动过程。它还将第二个状态变量的值ssthresh("慢启动阈值"的速记)设置为cwnd/2,即当检测到拥塞时将 ssthresh 置为拥塞窗口值的一半。

    • 慢启动结束的第二种方式是直接与ssthresh的值相关联。因为当检测到拥塞时ssthresh设为cwnd的值一半,当到达或超过ssthresh的值时,继续使 cwnd 翻番可能有些鲁莽。因此,当 cwnd 的值等于 ssthresh 时,结束慢启动并且 TCP 转移到拥塞避免模式。将会看到,当进入拥塞避免模式时,TCP更为谨慎地增加 cwnd.

    • 最后一种结束慢启动的方式是,如果检测到 3 个冗余ACK,这时 TCP 执行一种快速重传并进入快速恢复状态。

    慢启动中的 TCP 行为总结在图3-51中的 TCP 拥塞控制的 FSM 描述中。

    2、拥塞避免

    一旦进入拥塞避免状态,cwnd 的值大约是上次遇到拥塞时的一半,即距离拥塞可能并不遥远!因此,TCP无法每过一个 RTT 再将 cwnd 的值翻番,而是采用了一种较为保守的方法,每个 RTT 只将 cwnd 的值增加一个 MSS。这能够以几种方式完成:

    • 一种通用的方法是对于TCP发送方无论何时到达一个新的确认,就将cwnd增加一个 MSS(MSS/cwnd)字节。(例,如果MSS是1460字节且cwnd是14600字节,则在一个 RTT 内发送 10 个报文段。每个到达ACK(假定每个报文段一个ACK)增加 1/10MSS的拥塞窗口长度,因此在收到对所有 10 个报文段的确认后,拥塞窗口的值增加了一个 MSS。)

    何时应当结束拥塞避免的线性增长呢(每 RTT 1MSS)?

    • 当出现超时时, TCP的拥塞避免算法行为相同。与慢启动的情况一样, cwnd 的值被设为 1 个MSS,当丢包事件出现时,ssthresh 的值被更新为 cwnd 值的一半。

    • 当丢包事件是由一个 3 个冗余ACK事件触发时,网络继续向发送方向接收方交付报文段(就像由收到冗余ACK所指示的那样)。因此,TCP对于这种丢包事件的行为,相比于超时指示的丢包,应当不那么剧烈:TCP将cwnd的值减半(为使测量结果更好,计及已收到的3个冗余的ACK要加上3个MSS),并且当收到3个冗余的ACK,将ssthresh的值记录为cwnd的值的一半。接下来接入快速恢复状态。

    3、快速恢复

    在快速恢复中,对于引起 TCP 进入快速恢复状态的缺失报文段,对收到的每个冗余的ACK,cwnd 的值增加一个 MSS。

    最终,当对丢失报文段的一个 ACK 到达时,TCP 在降低 cwnd 后进入拥塞避免状态。

    如果出现超时事件,快速恢复在执行如同在慢启动和拥塞避免中相同的动作后,迁移到慢启动状态:当丢包事件出现时,cwnd的值被设置为1个MSS,并且ssthresh的值设置为cwnd值的一半

    快速恢复是 TCP 推荐的而非必须的构件。有趣的是,一种称为 TCP Tahoe 的 TCP 早期版本,不管是发生超时指示的丢包事件,还是发生 3个冗余ACK指示的丢包事件,都无条件地将其拥塞窗口减至 1 个MSS,并进入慢启动阶段。TCP的较新版本 TCP Reno,则综合了快速恢复。
    image-20220307165112359

    2.3 TCP拥塞控制算法的完整FSM描述

    image-20220307161730659

    2.4 TCP拥塞控制:回顾

    忽略一条连接开始时初始的慢启动阶段,假定丢包由 3 个冗余的ACK而不是超时指示,TCP 的拥塞控制是:每个 RTT 内 cwnd 线性(加性)增加 1 MSS,然后出现 3 个冗余 ACK 事件时 cwnd 减半(乘性减)。因此,TCP 拥塞控制常常被称为加性增、乘性减(Additive-Increase,Multiplicative-Decrease,AIMD)拥塞控制方式。

    AMID 拥塞控制引发了在图3-53中所示的“锯齿”行为:
    image-20220307164713336
    这也很好地图示了前面TCP检测带宽时的直觉,即TCP线性地增加它的拥塞窗口长度(因此增加其传输速率),直到出现3个冗余ACK事件。然后以2个因子来减少它的拥塞窗口长度,然后又开始了线性增长,探测是否还有另外的可用带宽。

    如前所述,许多TCP实现采用了 Reno 算法。Reno算法的许多变种已被提出。TCP Vegas 算法试图在维持较好的吞吐量的同时避免拥塞。Vegas 的基本思想是:①在分组丢失发生之前,在源与目的地之间检测路由器中的拥塞;②当检测出快要发生的分组丢失时,线性地降低发送速率。快要发生的分组丢失时通过观察 RTT 来预测的。分组的 RTT 越长,路由器中的拥塞越严重。到2015年年底,TCP 的Ubuntu Linux 实现默认提供了慢启动、拥塞避免、快速恢复、快速重传和 SACK,也提供了诸如 TCP Vegas 和 BIC 等其他拥塞控制算法。

    展开全文
  • 随着互联网络技术的发展,高带宽延迟积的高速网络成为主流网络,TCP拥塞控制算法因为协议固有的设计缺陷,无法理想地处理高速网络中的拥塞问题。显式拥塞控制协议有效地克服TCP的设计缺陷,较为理想地解决这些问题。...
  • 首先介绍了多路径传输协议的几种典型的拥塞控制算法,然后对MPTCP协议进行了理论分析,包括MPTCP拥塞控制算法在瓶颈链路TCP公平性、平衡拥塞能力以及flap现象,实验分析表明LINKED INCREASES算法效果最好。...
  • 实现UDP和TCP数据流的公平性以及在UDP中解决拥塞控制从而保证传输可靠性是提高服务质量所面临的两个迫切需要解决的问题。提出一种解决上述两个问题的方案——FFUDP(Friend and Fair UDP),即UDP根据丢包率来判断网络...
  • 因此,论述了Internet拥塞控制研究方面最新的研究进展,分析了IP网拥塞的原因,讨论了网络拥塞控制的方法,包括路由器中拥塞控制策略和对多媒体实时流与组播流的拥塞控制方法。得出了只有采用多种策略,并从多个角度...
  • 无线传感器网络多对一的数据传输模式、无线链路的动态干扰、网络拓扑变化快、节点资源有限等特性,使得网络容易发生拥塞,严重影响了网络的QoS和生命周期。拥塞控制技术作为传输协议的关键,是目前研究的一个热点。
  • 研究了TCP/AQM拥塞控制系统的可逆性,并利用一种神经网络监督控制结构进行了AQM算法的设计。算法由一个三层前馈结构的神经网络控制器(neural network controller, NNC)和一个反馈控制器(feedback controller, FC...
  • CUBIC算法是基于BIC-TCP算法的改进算法,它主要是解决在大带宽延迟积网络中TCP拥塞窗口增长缓慢的问题,其具有TCP友好性与RTT公平性,实时保持窗口的增长率不受RTT的影响。CUBIC在公平性上解决了TCP流量友好性与其他...
  • 在本文中,作者着重阐述了TCP拥塞控制和IP拥塞控制中的典型算法以及目前一些较有影响的拥塞控制算法,并指出了这些算法的优缺点。最后分析了当前拥塞控制算法设计过程中存在的不足,并给出了一个有意义的研究方向。
  • 研究了TCP/AQM拥塞控制系统的可逆性,并利用一种神经网络监督控制结构进行了AQM算法的设计。算法由一个三层前馈结构的神经网络控制器(neural network controller,NNC)和一个反馈控制器(feedback controller,FC)...
  • 要想更好的了解TCP端到端拥塞控制机制,首先要学习端到端拥塞控制的4个基本也是最主要的算法:slow_start, congestion avoidance, fast retransmit, fast recovery。
  • BIC拥塞控制算法论文

    2019-11-18 09:32:27
    BIC拥塞控制算法论文
  • 研究了Stackelberg流速与拥塞博弈问题,对一次非合作流速与拥塞控制博弈模型中的Nash均衡点进行了推理和证明。接着深入研究了单跟随者与多跟随者流速与拥塞博弈模型,论证和推导了均衡的存在性和均衡解向量。在此...
  • WEBRTC 中的拥塞控制相关论文,包括 1. BBR,Congestion-Based Congestion Control 2. GCC,A Google Congestion Control Algorithm for Real-Time Communication 3. GCC,Analysis and Design of the Google ...
  • 拥塞控制理论和算法研究因此成为 Intemet研究中的一个热点。 拥塞现象发生的原因.总的来说是Intemet网络中的需求大 于供给,即网络的资源(缓冲、链路带宽和网关处理能力等)是有 限的.这些有限资源要在网络用户之间...
  • 提出一种自适应拥塞控制路由策略。从路由机制、拥塞监测、拥塞的自适应控制、邻居路由器的选择、广播区域半径的控制等方面进行了详细设计,对于无线Mesh网络路由控制技术发展具有一定帮助。

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 68,666
精华内容 27,466
关键字:

拥塞控制