前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >TCP/IP之拥塞控制拥塞的成因和代价拥塞控制的方法TCP拥塞控制

TCP/IP之拥塞控制拥塞的成因和代价拥塞控制的方法TCP拥塞控制

作者头像
desperate633
发布2018-08-22 16:05:11
1.7K0
发布2018-08-22 16:05:11
举报
文章被收录于专栏:desperate633

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

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

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

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

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

拥塞的成因和代价

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

场景一

我们假设

  • 两个senders,两个receivers
  • 一个路由器, 无限缓存
  • 没有重传

image.png

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

image.png

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

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

场景2

我们假设

  • 一个路由器, 有限buffers
  • Sender重传分组

image.png

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

  • 情况a: Sender能够通过某种机制获知路由器buffer信息,有空闲才发

image.png

  • 情况b: 丢失后才重发,显然这样到达速度会减小

image.png

  • 情况c:分组丢失和定时器超时后都重发,显然到达速度进一步减小

image.png

拥塞的代价:

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

场景三

  • 四个发送方
  • 多跳
  • 超时/重传

image.png

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

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限制发送速率

image.png

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

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

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

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

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

加性增—乘性减: AIMD

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

image.png

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

TCP慢启动: SS

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

image.png

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

image.png

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

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

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

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

慢启动算法:

代码语言:javascript
复制
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

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2017.05.31 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 拥塞的成因和代价
    • 场景一
      • 场景2
        • 场景三
        • 拥塞控制的方法
          • 案例:ATM ABR拥塞控制
          • TCP拥塞控制
            • TCP拥塞控制的基本原理
              • 加性增—乘性减: AIMD
                • TCP慢启动: SS
                领券
                问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档