拥塞控制的一般原理

在计算机网络中的链路容量(即带宽)、交换结点中的缓存和处理机等,都是网络的资源。

在某段时间,若对网络中某一资源的需求超过了该资源所能提供的可用部分,网络的性能就要变坏。这种情况就叫做拥塞(congestion)。

拥塞产生的原因

网络拥塞往往是由许多因素引起的。例如:

  • 点缓存的容量太小;
  • 链路的容量不足;
  • 处理机处理的速率太慢;
  • 拥塞本身会进一步加剧拥塞;

出现拥塞的原因:∑ 对资源需求 > 可用资源

拥塞控制与流量控制的区别

所谓拥塞控制就是防止过多的数据注入到网络中,这样可以使网络中的路由器或链路不致过载。拥塞控制所要做 的都有一个前提,就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程,涉及到所有的主机、所有的路由器,以及与降低网络传输性能有关的所有因素。

但TCP连接的端点只要迟迟不能收到对方的确认信息,就猜想在当前网络中的某处很可能发生了拥塞,但 这时却无法知道拥塞到底发生在网络的何处,也无法知道发生拥塞的具体原因。

流量控制往往是指点对点通信量的控制,是个端到端的问题(接收端控制发送端)。流量控制所要做的就是抑制发送端发送数据的速率,以便使接收端来得及接收。

拥塞控制所起的作用

拥塞控制的前提:网络能够承受现有的网络负荷。

实践证明,拥塞控制是很难设计的,因为它是一个动态问题。

分组的丢失是网络发生拥塞的征兆而不是原因。

在许多情况下,甚至正是拥塞控制本身成为引起网络性能恶化、甚至发生死锁的原因。

开环控制和闭环控制

开环控制就是在设计网络时事先将有关发生拥塞的因素考虑周到,力求网络在工作时不产生拥塞。但一旦整个系统运行起来,就不再中途进行改正了。

闭环控制是基于反馈环路的概念,根据网络当前的运行状态采取相应控制措施。

属于闭环控制的有以下几种措施:

  • 监测网络系统,以便检测到拥塞在何时、何处发生。
  • 将拥塞发生的信息传送到可采取行动的地方。
  • 调整网络系统的运行以解决出现的问题。

监测网络的拥塞主要指标有:

  • 由于缺少缓存空间而被丢弃的分组的百分数;
  • 平均队列长度;
  • 超时重传的分组数;
  • 平均分组时延;
  • 分组时延的标准差,等等。

上述这些指标的上升都标志着拥塞的增长。

传递拥塞通知:发送通知拥塞发生的分组;在分组中保留表示拥塞状态的字段;周期性地发出探测分组等。

采取行动的时机过于频繁,会使系统产生不稳定的振荡;过于迟缓地采取行动又不具有任何实用价值。

#解决拥塞的两条思路:增加网络可用资源;减少用户对资源的需求。

TCP 的拥塞控制方法

TCP 采用基于窗口的方法进行拥塞控制。该方法属于闭环控制方法。
TCP发送方维持一个拥塞窗口 cwnd (Congestion Window)
发送端利用拥塞窗口根据网络的拥塞情况调整发送的数据量。
发送窗口大小不仅取决于接收方窗口,还取决于网络的拥塞状况,所以真正的发送窗口值为:

真正的发送窗口值 = Min (接收方窗口值,拥塞窗口值)

控制拥塞窗口的原则:

  • 只要网络没有出现拥塞,拥塞窗口就可以再增大一些,以便把更多的分组发送出去,这样就可以提高网络的利用率。
  • 但只要网络出现拥塞或有可能出现拥塞,就必须把拥塞窗口减小一些,以减少注入到网络中的分组数,以便缓解网络出现的拥塞。

拥塞的判断

重传定时器超时:网络已经发生了拥塞。

收到三个重复的 ACK:预示网络可能会出现拥塞(实际可能还未发生拥塞)。

TCP拥塞控制算法

四种拥塞控制算法:

  • 慢开始 (slow-start)
  • 拥塞避免 (congestion avoidance)
  • 快重传 (fast retransmit)
  • 快恢复 (fast recovery)

慢开始

目的:用来确定网络的负载能力或拥塞程度。
算法的思路:由小到大逐渐增大拥塞窗口数值。
两个变量:
拥塞窗口
初始拥塞窗口值:2 种设置方法。
1 至 2 个最大报文段 (旧标准)
2 至 4 个最大报文段 (RFC 5681)
窗口值逐渐增大。
慢开始门限:防止拥塞窗口增长过大引起网络拥塞。

拥塞窗口 cwnd 控制方法:在每收到一个对新的报文段的确认后,可以把拥塞窗口增加最多一个 SMSS 的数值。
拥塞窗口 cwnd 每次的增加量 = min (N, SMSS)

其中 N 是原先未被确认的、但现在被刚收到的确认报文段所确认的字节数。
不难看出,当 N < SMSS 时,拥塞窗口每次的增加量要小于 SMSS。
用这样的方法逐步增大发送方的拥塞窗口 cwnd,可以使分组注入到网络的速率更加合理。

发送方每收到一个对新报文段的确认
(重传的不算在内)就使 cwnd 加 1。

传输轮次

使用慢开始算法后,每经过一个传输轮次 (transmission round),拥塞窗口 cwnd 就加倍。
一个传输轮次所经历的时间其实就是往返时间 RTT。
“传输轮次”更加强调:把拥塞窗口 cwnd 所允许发送的报文段都连续发送出去,并收到了对已发送的最后一个字节的确认。
例如,拥塞窗口 cwnd = 4,这时的往返时间 RTT 就是发送方连续发送 4 个报文段,并收到这 4 个报文段的确认,总共经历的时间。

设置慢开始门限状态变量 ssthresh

慢开始门限 ssthresh 的用法如下:
当 cwnd < ssthresh 时,使用慢开始算法。
当 cwnd > ssthresh 时,停止使用慢开始算法而改用拥塞避免算法。
当 cwnd = ssthresh 时,既可使用慢开始算法,也可使用拥塞避免算法。

拥塞避免算法

思路:让拥塞窗口 cwnd 缓慢地增大,避免出现拥塞。
每经过一个传输轮次,拥塞窗口 cwnd = cwnd + 1。
使拥塞窗口 cwnd 按线性规律缓慢增长。
在拥塞避免阶段,具有 “加法增大” (Additive Increase) 的特点。

在超时之前,每经过一个传输轮次就使 cwnd 加 1。

无论在慢开始阶段还是在拥塞避免阶段,只要发送方判断网络出现拥塞(重传定时器超时):
ssthresh = max (cwnd/2,2)
cwnd = 1
执行慢开始算法
目的:迅速减少主机发送到网络中的分组数,使得发生拥塞的路由器有足够时间把队列中积压的分组处理完毕。

慢开始和拥塞避免算法的实现举例

当 TCP 连接进行初始化时,将拥塞窗口置为 1。图中的窗口单位不使用字节而使用报文段。

慢开始门限的初始值设置为 16 个报文段,即 ssthresh = 16。

在执行慢开始算法时,拥塞窗口 cwnd=1,发送第一个报文段。

发送方每收到一个对新报文段的确认 ACK,就把拥塞窗口值加 1,然后开始下一轮的传输(请注意,横坐标是传输轮次,不是时间)。因此拥塞窗口 cwnd 随着传输轮次按指数规律增长。

当拥塞窗口 cwnd 增长到慢开始门限值 ssthresh 时(图中的点 ,此时拥塞窗口 cwnd = 16),就改为执行拥塞避免算法,拥塞窗口按线性规律增长。

“拥塞避免”并非指完全能够避免了拥塞。利用以上的措施要完全避免网络拥塞还是不可能的。
“拥塞避免”是说在拥塞避免阶段把拥塞窗口控制为按线性规律增长,使网络比较不容易出现拥塞。

当拥塞窗口 cwnd = 24 时,网络出现了超时(图中的点 ),发送方判断为网络拥塞。于是调整门限值 ssthresh = cwnd / 2 = 12,同时设置拥塞窗口 cwnd = 1,进入慢开始阶段。

按照慢开始算法,发送方每收到一个对新报文段的确认 ACK,就把拥塞窗口值加 1。
当拥塞窗口 cwnd = ssthresh = 12 时(图中的点,这是新的 ssthresh 值),改为执行拥塞避免算法,拥塞窗口按线性规律增大。

当拥塞窗口 cwnd = 16 时(图中的点),出现了一个新的情况,就是发送方一连收到 3 个对同一个报文段的重复确认(图中记为 3-ACK)。发送方改为执行快重传和快恢复算法。

快重传算法

发送方只要一连收到三个重复确认,就知道接收方确实没有收到报文段,因而应当立即进行重传(即“快重传”),这样就不会出现超时,发送方也不就会误认为出现了网络拥塞。
使用快重传可以使整个网络的吞吐量提高约20%。

不难看出,快重传并非取消重传计时器,而是在某些情况下可以更早地(更快地)重传丢失的报文段。

采用快重传 FR (Fast Retransmission) 算法可以让发送方尽早知道发生了个别报文段的丢失。
快重传 算法首先要求接收方不要等待自己发送数据时才进行捎带确认,而是要立即发送确认,即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认。

快重传举例

快恢复算法

当发送端收到连续三个重复的确认时,由于发送方现在认为网络很可能没有发生拥塞,因此现在不执行慢开始算法,而是执行快恢复算法 FR (Fast Recovery) 算法:
慢开始门限 ssthresh = 当前拥塞窗口 cwnd / 2 ;
新拥塞窗口 cwnd = 慢开始门限 ssthresh ;
开始执行拥塞避免算法,使拥塞窗口缓慢地线性增大。

加法增大,乘法减小 (AIMD)

可以看出,在拥塞避免阶段,拥塞窗口是按照线性规律增大的。这常称为“加法增大” AI (Additive Increase)。
当出现超时或3个重复的确认时,就要把门限值设置为当前拥塞窗口值的一半,并大大减小拥塞窗口的数值。这常称为“乘法减小”MD (Multiplicative Decrease)。
二者合在一起就是所谓的 AIMD 算法。

打赏

扫一扫,分享到微信

微信分享二维码
  • Copyrights © 2017-2023 WSQ
  • 访问人数: | 浏览次数:

请我喝杯咖啡吧~

支付宝
微信