加权公平排队（WFQ）顾名思义就是一种排队算法。当接口拥塞时使用队列。这通常是通过发送环（TX-Ring）已满来检测的。这意味着接口正忙于发送数据包。除非接口拥塞，否则不会发生排队。在某些情况下，可以操纵 TX 环的大小。一个小的 TX-ring 为软件队列提供了更多关于哪些数据包首先发送出去的权力，但它不是很有效。太大的 TX 环会使软件队列几乎无用，并导致重要数据包的更高延迟和抖动。

默认排队算法通常是先进先出 (FIFO)。这意味着数据包按照到达接口输入端的顺序进行传送。这通常是不可取的，因为一些数据包应该被优先处理。

客户以低价从 Internet 服务提供商 (ISP) 购买服务是很常见的。也就是说，客户购买了 50 Mbit/s 的服务，但物理接口以 100 Mbit/s 的速度运行。在这种情况下，不会出现拥塞，但 ISP 将限制来自客户的流量。为了在这些情况下引入人为拥塞，可以应用整形器。

因此，既然存在拥塞，就可以应用排队算法。请注意，排队算法不提供任何额外的带宽，它们只是让我们决定哪些数据包对我们更重要。WFQ 是一种算法，它采用多个参数并基于这些参数做出决定。该算法相当复杂，使用权重（IP Precedence）、数据包大小和调度时间作为参数。INE这里有非常详细的解释。如果不想过多地处理排队问题，WFQ 是一个不错的选择，因为它为 SSH、Telnet、语音等小流量提供了足够的带宽，这意味着文件传输不会窃取所有带宽。

加权随机早期检测 (WRED) 是一种拥塞避免机制。WRED 根据 Precedence 值测量队列的大小，并在队列介于最小阈值和最大阈值之间时开始丢弃数据包。配置将决定每 N 个数据包中的 1 个被丢弃。WRED 有助于防止 TCP 同步和 TCP 饥饿。当 TCP 丢失数据包时，它将进入慢启动状态，如果所有 TCP 会话同时丢失数据包，它们可能会变得同步，提供如下图：

可以看出，如果未配置 WRED，图形会先全速运行，然后是静音，然后是全速运行，依此类推。WRED 提供更平均的传输速率。需要注意的是，UDP 不会受到丢包的影响，因为它没有像 TCP 那样实现的确认机制和滑动窗口。因此，WRED 不应在基于 UDP 的类上实现，如处理 SNMP、DNS 或其他基于 UDP 的协议的类。

WFQ 和 WRED 可以而且应该一起部署。

首先，不要相信您在互联网上阅读的所有内容;-)

有时算法（或它们的物理实现方式）并不完全适合理论类别。你称之为什么并不比理解它的作用重要。

WFQ（或任何其他调度算法）的重点是在各种流之间共享有限的链路带宽。WFQ 尝试为每个流按比例分配带宽。CBWFQ 对每个“类”执行相同的操作。在拥有无限队列和无限内存的完美世界中，这就是您所需要的——您共享带宽，每个人都很高兴。

但是因为设备没有无限的队列和内存，所以必须做一些“捷径”。因为队列的大小是有限的，所以存在队列被填满的危险，导致尾部丢弃和流量同步。本质上，如果我的队列溢出，我将不再控制带宽。

为了避免我的队列溢出，我使用随机早期检测。该算法根据队列的满度（深度）从队列中随机丢弃数据包——队列越满，丢弃的数据包就越多。目标是防止队列溢出，以便调度算法可以工作。

然后一些聪明的 Cisco 工程师注意到可以使用更少的队列（更简单的硬件）并在不同的队列深度随机丢弃不同类型的流量。WRED 根据流量类型在不同深度从队列中丢弃流量。尽管您可能将 WRED 称为拥塞避免机制，但由于流量丢弃的深度因流量类型而异，结果是不同类型在队列中获得的空间更少，因此带宽也更少。所以它也充当调度算法。你说 po-tay-to，我说 po-tah-toe。

还有一个区别：FQ 和 WFQ 适用于所有类型的流量，因为它们本质上是计算字节数。RED 和 WRED 只适用于 TCP，因为它们依赖 TCP 的流量控制机制来减慢流量并防止队列溢出。

（注意：为了解释起见，我忽略了优先级队列和 LLQ。这是另一个答案）。

我也同意迈克所说的一切。

以下是 CBWFQ 和 WRED 的示例：

策略映射输出

class 语音
优先级百分比 20

class 视频
带宽百分比 30

P1 类
带宽百分比 10
随机检测基于 dscp 的
随机检测 dscp af31 26 40 10

P2 类
带宽百分比 15
随机检测基于 dscp 的
随机检测 dscp af21 24 40 10

类类默认
公平队列
随机检测基于 dscp