谈计算机网络中ip拥塞控制算法以及改进

《谈计算机网络中ip拥塞控制算法以及改进》由会员上传分享，免费在线阅读，更多相关内容在学术论文-天天文库。

1、谈计算机网络中IP拥塞控制算法以及改进摘要：本文首先阐述了计算机网络中拥塞的定义、拥塞产生的原因以及经常提起的拥塞控制的定义。中间阐述了目前使用最多的拥塞控制算法FIFO算法和RED算法，最后提出了这两个算法的改进思想。关键字：IP拥塞算法改进一、概述1.拥塞定义当网络中存在过多的数据包时，网络的性能就会下降，这种现象称为拥塞。在网络发生拥塞时，会导致吞吐量下降，严重时会发生“拥塞崩溃”（congestioncollapse）现象。一般来说，在网络负载的增加导致网络效率的降低的时候，就会发生拥塞崩溃。Floyd总结出拥塞崩溃主要包括以下几种[[1l:传统的崩溃、未

2、传送数据包导致的崩溃、由于数据包分段造成的崩溃、日益增长的控制信息流造成的崩溃等。2.拥塞产生的原因网络产生的拥塞的根本原因在于用户（或叫端系统）提供给网络负载大于网络资源容量和处理能力，表现为数据包延时增加、丢弃概率增大、上层应用系统性能下降。拥塞产生的直接原因有以下三点:（1）存储空间不足。几个输入数据流共同需要同一个输入端口，在这个端口就会建立排队，如果没有足够的存储空间，数据包就会丢弃，对突发数据流更是如此。增加存储空间在一定程度上可以缓解这一矛盾，但如果路由器有无限存储量，拥塞只可能变得更坏，而不是更好。因为网络里的数据包经过长时间排队后才通过路由器完成

3、转发，会浪费网络资源，加重网络拥塞。（2）带宽容量不足，低速链路对高速数据流的输入也会产生拥塞。根据香农信息理论，任何信道带宽最大值（即信道容量）为C=Blog2（1+S/N）（其中N为信道白噪声的平均功率，S为信源的最大功率，B为信道带宽）。所有信源发生的速率R必须小于或等于信道容量C，如果R>C，则在理论上无差错传输就是不可能的。所以在网络低速链路处就会形成带宽瓶颈，当其满足不了所有信源带宽要求时，网络就会发生拥塞。（3）处理器能力弱、速度慢，也能引起拥塞。如果路由器的CPU在执行排队缓存，更新路由表等功能时，处理速度跟不上高速链路，也会产生拥塞。同样，

4、低速链路对高速CPU也会产生拥塞。3.拥塞控制的定义拥塞控制就是采用某种策略或机制，保持网络工作在正常的状态下，也就是使网络经常工作在崖点左侧的区域内。若一种控制机制使得网络工作在膝点附近，该方法称之为拥塞避免;若一种控制机制是的网络工作在崖点或崖点以后的网络回复至膝点前后，该方法称之为拥塞恢复。因此拥塞控制策略包括拥塞避免（congestionavoidance）和拥塞控制（congestioncontrol）这两种不同的控制机制。拥塞避免是“预防”机制，它的目标是避免网络进入拥塞状态，使网络运行在高吞吐量、低延迟的状态下。拥塞控制是“恢复”机制，它用于把网络从

5、拥塞状态中恢复出来。二、计算机网络中IP拥塞控制算法1.FIFO算法FIFO又叫“先到先服务”（FCFS），即第一个到达路由器的数据包首先被传输。由于每个路由器的缓存总是有限的，如果包到达时缓存己满，那么路由器就不得不丢弃该包。这种做法没有考虑被丢弃包的重要程度。由于FIFO总是丢弃到达队尾的包，所以有时又称为“去尾”（droptail）算法。但“去尾”和FIFO是两个不同的概念。FIFO是一种包调度策略，决定包传送的顺序:“去尾”是一种丢弃策略，决定哪些包被丢弃。因为FIFO和“去尾”分别是最简单的包调度和丢弃策略，所以两者有时被视为一体，甚至有时就简单称为FI

6、FO排队。2.RED算法RED算法包含两部分:如何监控队列长度和何时丢弃数据包。首先，RED使用类似TCP计算超时时使用的权值axP。当然，也有一些研究建议从随机丢弃到完全丢弃的过渡应该更“平滑”。三、算法改进1.对FIFO的改进FIFO排队的主要问题是无法区分不同的数据流。由于整个TCP的拥塞控制是在源端执行，而FIFO排队不提供约束所有数据源遵守拥塞控制的机制，这就有可能让行为不良的数据流强占大量带宽。在Inter环境中，某个应用不使用TCP协议是完全可能的。结果，它可以绕开端到端的拥塞控制机制，向路由器任意发送自己的数据包，从而引起其它应用的包被丢弃。公平排

7、队算法（FairQueuingFQ）则解决了这个问题。FQ算法是一种“轮询”（roundrobin，RR）的调度算法。在FQ算法中，路由器对每个输出线路有一个排队队列。路由器按“轮询”（roundrobin）方式处理包。当一条线路闲时，路由器就来回扫描所有队列，依次将每队第一个包发出。当某个流的数据包到达过快时，其队列就会很快占满，属于这个流的新到的包就会被丢弃。采用这种方式，每个数据流就不可能牺牲其它数据流而多占资源。.lunanagementschemebasedonpacketlossratio[J].IEEE/ACMTransactionNet-Hyuk,

8、ParkK