TCP/IP之拥塞控制

拥塞(Congestion)
给一个非正式定义就是:“太多发送主机发送了太多数据或者发送速度太快,以至于网络无法处理”
如果网络中发生了拥塞,会出现如下表现:

  • 分组丢失(路由器缓存溢出)
  • 分组延迟过大(在路由器缓存中排队)

和可靠数据传输一样都是网络领域中的top-10的问题。

拥塞现象是指到达[通信子网]中某一部分的分组数量过多,使得该部分网络来不及处理,以致引起这部分乃至整个网络性能下降的现象,严重时甚至会导致网络通信业务陷入停顿,即出现[死锁]现象。这种现象跟公路网中经常所见的交通拥挤一样,当节假日公路网中车辆大量增加时,各种走向的车流相互干扰,使每辆车到达目的地的时间都相对增加(即延迟增加),甚至有时在某段公路上车辆因堵塞而无法开动(即发生局部[死锁]

我们先讨论一下拥塞的成因和代价

拥塞的成因和代价

我们通过假设不同的场景渐进式分析拥塞的成因和代价

场景一

我们假设

  • 两个senders,两个receivers
  • 一个路由器, 无限缓存
  • 没有重传
TCP/IP之拥塞控制_第1张图片
image.png

我们假设原始数据的发送速度为in,到达接受方的速度为out,由于路由器的速度限制,即使无限缓存,到达的最大速度也无法超过路由器的速度

TCP/IP之拥塞控制_第2张图片
image.png

即使发送速度再快,到达速度也无法超过路由器的速度,所以时延在拥塞发生的时候会无限增大。

  • 拥塞时分组延迟太大
  • 达到最大throughput

场景2

我们假设

  • 一个路由器, 有限buffers
  • Sender重传分组
TCP/IP之拥塞控制_第3张图片
image.png

可以分为一下几种情况讨论

  • 情况a: Sender能够通过某种机制获知路由器buffer信息,有空闲才发
TCP/IP之拥塞控制_第4张图片
image.png
  • 情况b: 丢失后才重发,显然这样到达速度会减小
TCP/IP之拥塞控制_第5张图片
image.png
  • 情况c:分组丢失和定时器超时后都重发,显然到达速度进一步减小
TCP/IP之拥塞控制_第6张图片
image.png

拥塞的代价:

  • 对给定的”goodput”,要做更多的工作 (重传)
  • 造成资源的浪费

场景三

  • 四个发送方
  • 多跳
  • 超时/重传
TCP/IP之拥塞控制_第7张图片
image.png

随着拥塞的严重,整个网络可能陷入瘫痪,到达速度趋近于0,类似于死锁的状态

TCP/IP之拥塞控制_第8张图片
image.png

拥塞的另一个代价:

  • 当分组被drop时,任何用于该分组的“上游”传输能力全都被浪费掉,相当于白传了,浪费了资源和传输能力

拥塞控制的方法

端到端拥塞控制:

  • 网络层不需要显式的提供支持
  • 端系统通过观察loss,delay等
    网络行为判断是否发生拥塞
  • TCP采取这种方法
    *网络辅助的拥塞控制:
    *路由器向发送方显式地反馈网络
    拥塞信息
    *简单的拥塞指示(1bit):SNA,DECbit, TCP/IP ECN, ATM)
    *指示发送方应该采取何种速度

案例:ATM ABR拥塞控制

  • ABR:available bit rate
     “弹性服务”
     如果发送方路径“underloaded”
    使用可用带宽
     如果发送方路径拥塞
    将发送速率降到最低保障速率
  • RM(resource management)cells
     发送方发送
     交换机设置RM cell位(网络辅助)
    • NI bit: rate不许增长
    • CI bit: 拥塞指示
     RM cell由接收方返回给发送方

TCP拥塞控制

TCP拥塞控制的基本原理

Sender限制发送速率

TCP/IP之拥塞控制_第9张图片
image.png

CongWin可以动态调整以改变发送速率,并且反映所感知到的网络拥塞。

那么问题来了,如何感知网络拥塞:

  • Loss事件=timeout或3个重复ACK
  • 发生loss事件后,发送方降低速率

感知到网络拥塞后,需要动态调整发送速率,以减轻网络的拥塞状况,如何调整发送速率,一般有两个方法:

  • 加性增—乘性减: AIMD
  • 慢启动: SS

加性增—乘性减: AIMD

顾名思义,这种方法就是先简单的增加,遇到拥塞的情况,就乘性减少。
原理:逐渐增加发送速率,谨慎探测可用带宽,直到发生loss。
Additive Increase: 每个RTT将CongWin增大一个MSS——拥塞避免
Multiplicative Decrease: 发生loss后将CongWin减半。
AIMD方法会使congwin呈锯齿状的波动

TCP/IP之拥塞控制_第10张图片
image.png

首先慢慢增加,当遇到拥塞时,减为一半,然后又继续慢慢增加,直到遇到拥塞后又减为一半,这样往复就会出现锯齿状的波动。

TCP慢启动: SS

我们考虑下面这种情况:
TCP连接建立时,
CongWin=1
 例:MSS=500 byte,
RTT=200msec
 初始速率=20k bps
我们发现在这种情况下,可用带宽可能远远高于初始速率,如果我们采用加性增的方法就太慢了,我们希望快速增长到可用带宽。
这就慢启动算法的思想:
当连接开始时,指数性增长。指数性增长。每个RTT将CongWin翻倍。收到每个ACK进行操作。初始速率很慢,但是快速攀升。

TCP/IP之拥塞控制_第11张图片
image.png

那么问题来了,我们什么时候才进行线性增长来避免拥塞控制?
我们通过设置一个变量 Threshold,Loss事件发生时, Threshold被设为Loss事件前CongWin值的1/2。然后如果cogwin到了Threshold,就开始线性增长。

TCP/IP之拥塞控制_第12张图片
image.png

如图所示,初始的Threshold变量为8,所以当指数增长大于等于8的时候,就开始线性增长,然后直到发生loss事件,Threshold变为发生loss事件时的一半,也就是6,然后继续指数增长到Threshold,又开始线性增长。

那么我们如何判断loss事件的发生呢?
我们分为两种情况来处理:

  • 3个重复ACKs:
    CongWin切到一半,然后线性增长
  • Timeout事件:
    CongWin直接设为1个MSS,然后指数增长,达到threshold后, 再线性增长

我们想想这样做的原因,因为3个重复ACKs表示网络还能够传输一些 segments
,timeout事件表明拥塞更为严重。

慢启动算法:

Th = ?
CongWin = 1 MSS
/* slow start or exponential increase */
While (No Packet Loss and CongWin < Th) {
send CongWin TCP segments
for each ACK increase CongWin by 1
}
/* congestion avoidance or linear increase */
While (No Packet Loss) {
send CongWin TCP segments
for CongWin ACKs, increase CongWin by 1
}
Th = CongWin/2
If (3 Dup ACKs) CongWin = Th;
If (timeout) CongWin=1;

 一个TCP连接总是以1 KB的最大段长发送TCP段,发送方有足够多的数据要发
送。当拥塞窗口为16 KB时发生了超时,如果接下来的4个RTT(往返时间)时
间内的TCP段的传输都是成功的,那么当第4个RTT时间内发送的所有TCP段
都得到肯定应答时,拥塞窗口大小是多少?
 解:threshold=16/2=8 KB, CongWin=1 KB, 1个RTT后, CongWin=2 KB ,2
个RTT后, CongWin=4 KB ,3个RTT后, CongWin=8 KB ,Slowstart is
over; 4个RTT后, CongWin=9 KB

你可能感兴趣的:(TCP/IP之拥塞控制)