队列管理算法及策略总结

看了好几天队列管理方面的论文，筛筛检检，整理出一篇比较全面的文章来，开心的说~

关于概念：

仿真试验采用Berkeley开发的网络仿真软件 NS2进行。NS2集成了多种网络协议（如TCP、UDP），业务类型（如FTP、Telnet、Web等），路由队列调度算法（如Drop Tail、RED、FQ等），路由算法（如Dijkstra等）。可参看DropTail、RED、SFQ（Stochastic Fair Queuing）和DRR四种队列调度算法。

在网络传输中存在三种类型的连接：

非适应（Non-adaptive）流：指没有采用拥塞控制机制，因而不能对拥塞做出反应的流，如很多多媒体应用和组播都属于此类；

强壮（Robust）流：能够对拥塞通知做出反应，并且充分利用现有的网络条件发送数据的流；

脆弱（Fragiie）流： 能够对拥塞通知做出反应，但它们要么对丢包过于敏感，要么对有更多可用带宽的适应很慢。比如很多交互应用，都属于这种类型。

TCP／IP拥寒控制主要包括两个方面，一是发送端的拥塞控制，称为 源端拥塞控制，二是中间节点的拥塞控制，称为 队列管理。

中间节点有2类和拥塞控制相关的队列算法： 队列调度算法和 队列管理算法。前者决定下一个要发送哪个包，主要用来管理各流之间带宽的分配；后者主要是在网络发生拥塞时通过丢包来管理队列长度。目前的队列管理机制可以分为2大类：被动式队列管理POM(Passive 0ueue Management)和主动式队列管理AQM(Active Queue Management)。

被动式队列管理是对每个队列设置一个最大值(以包为单位)，然后接受包进入队列直到队长达到最大值．接下来到达的包就要被拒绝进入队列直到队长下降。这种技术也就是传统的“去尾”(drop tail)算法。还有 Random Drop 和 Drop Front等。

虽然“去尾”算法在当前Internet 上得到了广泛的使用，但其存在两个重要问题：

（1）死锁（Iock-out）现象：在某些情况下，由于同步或其他定时作用的结果，“去尾”算法会让某个流或者少数几个流独占队列空间，阻止其他流的包进入队列.

（2）满队列（fuII gueues）问题：由于“去尾”算法只有在队列满时才会发出拥塞信号，因此会使得队列在相当长时间内处于充满（或几乎充满）的状态. 而Internet 数据的突发性使得队列在满状态下会产生“TCP 全局同步”（TCP gIobaI synchronization）现象.

补充：

由于Internet上的数据流都具有突发本质（Burstiness），到达路由器的封包也往往是突发的。如果队列是满的或者几乎是满的，就会导致在短时间内连续大量的丢包。而TCP数据流具有自适应特性（Adaptive），来源端发现封包丢失就急剧地把传送速率降低，于是网络拥塞情况得以解除，但来源端在得知网络不再拥塞后又开始增加发送速度，最终又造成网络拥塞。这种现象常常会周而复始地进行下去，因此网络常处于链路利用率很低的状态，降低了整体吞吐量，这就是所谓的 TCP全局同步现象 。

主动式队列管理是核心路由器在拥塞发生之前，通过检测数据包的状态特征(比如分组标记、延时时间等)．按照一定的控制率主动的而非响应性的丢弃数据包。这使得路由器能够控制在什么时候丢多少包。从而有效地管理队列长度，以支持端到端的拥塞控制．

AQM机制的主要性能指标包括链路利用率，报文丢弃率以及平均队列长度等。平均队列长度决定了报文的排队延迟，队列长度的起伏（一般称为队列动荡）决定了延迟抖动。

AQM 解决的问题主要包括以下4 个方面:

( 1) 早期探测路由器可能发生的拥塞, 并通过随机丢弃或标记分组来通知源端采取措施避免可能发生的拥塞.

( 2) 公平地处理包括突发性、持久性和间隙性的各种TCP 业务流.

( 3) 避免多个TCP 连接由于队列溢出而造成同步进入 慢启动 状态.

( 4) 维持较小的队列长度，并且使得队列动荡比较小，在高吞吐量和低时延之间做出合理平衡.

RED算法