QOS令牌桶原理1

柔光的暖阳◎ 2024-04-18 17:22 58阅读 0赞

令牌桶算法是目前 IP QoS 中最常采用的一种流量测量方法，广泛应用于约定访问速率技术、通用流量整形技术以及物理接口总速率限制等技术中。IETF RFC 建议规范了单速率三色标记和双速率三色标记两种令牌桶算法，在桶的构成、令牌添加和报文处理流程方面前者较后者简单，成为目前业界比较常用的流量标记方式。在实际应用中，应针对不同的流量特征选择恰当的标记方式。

随着因特网的发展，IP 业务不断快速增长。提高信息在 IP 网络上传输的质量是 IP 网发展中的一个关键所在。IP QoS 技术的开发，目的就是为用户业务提供端到端的服务质量保证，已成为近几年业界研究的热点。目前存在多种 IP QoS 服务模型，其中应用最广的是区分服务模型(DiffServ)。DiffServ 模型通过数据包分类、拥塞管理、拥挤避免、速率限制和流量整形技术来实现服务质量控制，在其速率限制和流量整形中，主要使用了令牌桶算法来评估流量速率是否超过规定值\[1\]。

本文第一部分阐述了一下网络工程师任务小组(IETF) 请求注解(RFC)建议规范的两种令牌桶算法；第二部分简要介绍了令牌桶算法在 IP QoS 中的应用；第三部分详细说明了目前业界常用的两种实现方式，并对两种方式的实现过程进行了具体的比较分析。

1、令牌桶算法基本原理

令牌桶是网络设备的内部存储池，而令牌则是以给定速率填充令牌桶的虚拟信息包。每个到达的令牌都会从数据队列领出相应的数据包进行发送，发送完数据后令牌被删除。

RFC 中定义了两种令牌桶算法——单速率三色标记算法和双速率三色标记算法，其评估结果都是为报文打上红、黄、绿三色标记。QoS 会根据报文的颜色，设置报文的丢弃优先级，其中单速率三色标记比较关心报文尺寸的突发，而双速率三色标记则关注速率上的突发，两种算法都可工作于色盲模式和非色盲模式。以下结合这两种工作模式介绍一下 RFC 中所描述的这两种算法。

1.1 单速率三色标记算法

IETF 的 RFC 文件\[2\]定义了单速率三色标记算法，评估依据以下 3 个参数：承诺访问速率(CIR)，即向令牌桶中填充令牌的速率；承诺突发尺寸(CBS)，即令牌桶的容量，每次突发所允许的最大流量尺寸（注：设置的突发尺寸必须大于最大报文长度）；超额突发尺寸(EBS)。

一般采用双桶结构：C 桶和 E 桶。Tc 表示 C 桶中的令牌数，Te 表示 E 桶中令牌数，两桶的总容量分别为 CBS 和 EBS。初始状态时两桶是满的，即 Tc 和 Te 初始值分别等于 CBS和EBS。令牌的产生速率是 CIR，通常是先往 C 桶中添加令牌，等 C 桶满了，再往 E 桶中添加令牌，当两桶都被填满时，新产生的令牌将会被丢弃。

色盲模式下，假设到达的报文长度为 B。若报文长度 B 小于 C 桶中的令牌数 Tc，则报文被标记为绿色，且 C 桶中的令牌数减少 B；若 Tc<BTe，标记为红色，两桶总令牌数都不减少。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70][]

在非色盲模式下，若报文已被标记为绿色或 B<TC，则报文被标记为绿色，TC 减少 B；若报文已被标记为黄色或 TC<B>Te，则标记为红色，Tc 和 Te 都不减少。

1.2 双速率三色标记算法

IETF 的 RFC 文件\[3\]定义了双速率三色算法，主要是根据 4 种流量参数来评估：CIR、CBS、峰值信息速率(PIR)，峰值突发尺寸(PBS)。前两种参数与单速率三色算法中的含义相同，PIR 这个参数只在交换机上才有，路由器没有这个参数。该值必须不小于 CIR 的设置值，如果大于 CIR，则速率限制在 CIR 于 PRI 之间的一个值。

与单速率三色标记算法不同，双速率三色标记算法的两个令牌桶 C 桶和 P 桶填充令牌的速率不同，C 桶填充速率为 CIR，P 桶为 PIR；两桶的容量分别为 CBS 和 PBS。用 Tc 和 Tp表示两桶中的令牌数目，初始状态时两桶是满的，即 Tc 和 Tp 初始值分别等于 CBS 和 PBS。

色盲模式下，如果到达的报文速率大于 PIR，超过 Tp+Tc 部分无法得到令牌，报文被标记为红色，未超过 Tp+Tc 而从 P 桶中获取令牌的报文标记为黄色，从 C 桶中获取令牌的报文被标记为绿色；当报文速率小于 PIR，大于 CIR 时，报文不会得不到令牌，但超过 Tp 部分报文将从 P 桶中获取令牌，被标记为黄色报文，从 C 桶中获取令牌的报文被标记为绿色；当报文速率小于 CIR 时，报文所需令牌数不会超过 Tc，只从 C 桶中获取令牌，所以只会被标记为绿色报文。

在非色盲模式下，如果报文已被标记为红色或者超过 Tp+Tc 部分无法得到令牌的报文，被标记为红色；如果标记为黄色或者超过 Tc 未超过 Tp 部分报文记为黄色；如果报文被标记为绿或未超过 Tc 部分报文，被标记为绿色。

2、令牌桶算法的应用

2.1 在流量监管中的应用

约定访问速率(CAR)是流量监管常用技术之一，它的监管原理如图 1 所示。

根据预设的匹配规则先对报文进行分类，不符合匹配规则的报文不需要经过令牌桶的处理，直接发送；符合匹配规则的报文，则需要令牌桶进行处理。当桶中有足够的令牌则报文可以被继续发送下去，同时令牌桶中的令牌量按报文的长度做相应的减少；当令牌桶中的令牌不足时，报文将不能被发送，只有等到桶中生成了新的令牌，报文才可以发送。这就可以限制报文的流量只能是小于等于令牌生成的速度，达到限制流量的目的。

2.2 在通用流量整形中的应用

通用流量整形中(GTS)\[4\](如图 2 所示)与 CAR 的原理稍有差别：第一，GTS 只用于出方向流量限速，CAR 出入方向均可以，但一般多用于入方向；第二，利用 CAR 进行报文流量控制时，对超过速率限制的报文直接丢弃，而 GTS 则是对超过速率限制的报文进行缓冲，即当令牌桶中的令牌少到报文不能再发送时，报文将被缓存入队列，等有了足够的令牌之后再发送，这样就减少了报文的丢弃，但是要注意的是，如果缓存队列已满，这时到达的报文仍旧会被丢弃。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 1][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 2][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 3][]

2.3 在端口限速中的应用

端口限速(LR)\[4\](如图 3 所示)也用于出方向，但不同于 GTS 的是：第一，GTS 与 CAR 是在 IP 层实现的，所以对于不经过 IP 层处理的报文不起作用，而 LR 则能够限制在物理接口上通过的所有报文；第二，LR 不但能够对超过流量限制的报文进行缓存，并且可以利用 QoS 丰富的队列如优先级队列(PQ)、自定义队列(CQ)、加权公平对列(WFQ)等来缓存报文。

3、令牌桶实现

上面介绍了 RFC 中定义的令牌桶技术原理以及其在 IP QoS 中的应用，但是在实际应用中，令牌桶究竟是怎么实现的？令牌桶中的令牌是怎么添加的？报文的处理流程又是什么样的？下面就简单谈一谈令牌桶在业界的实现方式。

3.1 单速率三色标记算法的实现

3.1.1 桶的构成

在令牌桶的构成上，目前业界有两种方式，如图 4 所示。

可以由一个桶实现，即 C 桶是 E 桶中的一部分(图 4 上)，最终桶的容量是由 EBS 决定的。不管有没有突发流量，EBS 不能为 0，必须大于或等于 CBS。这种实现方式完全按照令牌桶的定义来实现，因为 CBS 和 EBS 都是令牌桶的参数，所以放入一个相同的桶实现，通过突发计数器来进行区分。也可以由两个桶实现(图 4 下)，即 C 桶和 E 桶分开实现。如果不允许有突发流量，EBS 则设置成 0。

3.1.2 令牌添加

令牌桶的添加完全依照 RFC 规定实现，按照恒定的速率 CIR 添加。即每隔 1/CIR 时间添加一个令牌，添加顺序为先添加 C 桶再添加 E 桶，当令牌桶添加满的时候，再产生的令牌就会被丢弃。

实际中比较常见的有两种实现方式：(1)周期性的添加，如图 5 所示，添加的时间间隔就是令牌桶的容量与添加速率的比值：T c=CBS/CIR，每次添加的令牌数为 CBS 个；(2)一次性添加，只有当令牌桶中没有令牌时才添加令牌，如图 6 所示，添加令牌的数量是△ t×CIR(△t 是当前时间与上次添加令牌的时间之差)，且是一次添加完毕，并不是按照一定速率添加。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 4][]

3.1.3 报文处理流程

一般的报文处理方法如图 7 所示：当报文到来后，直接与桶中的令牌数相比较，如果有足够的令牌就转发，如果没有足够的令牌则丢弃或缓存。这种令牌桶处理方式在突发流量的处理上没有优势，也就是说当存在较大的突发流量时，令牌桶可能会由于没有足够令牌无法处理报文，而且在没有突发流量且报文到达速率较大时，报文处理流程也不连续，有时会因为令牌数量不足而造成丢包。

为解决这种无谓的丢包问题，目前业界采用了一种借贷机制的报文处理方法，如图 8 所示。当报文到来后，只要令牌桶中有令牌，无论数量是否足够，都可以转发报文。当令牌数量小于报文长度时，就可以欠债转发，即转发后令牌桶中令牌数目为负；当下次添加令牌的时候，先还清所欠债务，再继续转发报文。这种处理方法较前者在处理突发报文时有优势，能够保证报文发送的连续性。

3.1.4 实现方式比较

假设令牌桶的总容量为 1 000 kb，CIR 为 125 kb/s，报文到达的速率为 200 kb/s，报文长度为 125 kB (1 000 kb)。

方式一：周期性添加令牌，只有当令牌数足够时才转发报文。添加令牌的周期为 8 s，而转发一条报文的时间为 5 s。

方式二：一次性添加令牌，当令牌数不足时采用借债机制。转发一条报文的时间是 5 s，但是添加令牌的时间是不一定的，每次添加令牌的数目为 CIR×△t。

9 至图 11 是对这两种方式的令牌桶中令牌数、报文转发速率和令牌添加过程的比较。分析数据的处理流程得出以下结论：

(1) 数据包丢弃率：方式二的丢包率远小于方式一。

方式一中，由于令牌添加周期与报文发送周期的不一致，导致第 6 s 到第 8 s 由于没有令牌不能转发报文。而第 8 s 到第 16 s 虽然在不断添加令牌，但令牌数不足以转发一个报文，所以仍旧无法转发报文，那在这一段时间内到达的报文将被丢弃掉。在前 16s 的时间内丢包率达到了 10/16≈62.5%，由于添加令牌和发送报文的时间都是固定的，所以整个发送过程中的丢包率也为 62.5%。

方式二中，第 5 s 第一条报文发送结束令牌被消耗光，但第 6 s 又立即加入了 550 kb 令牌，虽不够转发一条报文，但可以采用借债机制，直到第 10 s 第二条报文发送结束，累计欠债 250 kb。这时若有报文到达，就不能继续欠债，而要注入新的令牌才能继续转发。直到15 s 第三条报文发送完毕由于一次添加令牌不够还清所欠令牌，所以造成了短暂的丢包现象，而在前 17s 内丢包率仅为 1/17≈5.9%。

（2）突发流量处理：方式二在突发流量处理方面优于方式一。

由图 10 可知，对方式一来说，由于令牌桶总的容量只有 1 000 kb，发送完每条报文后桶中剩余令牌数都为 0。此时若有突发流量，则报文必然被丢弃。而方式二令牌数可为负，当突发报文到达时即使令牌数不足仍可通过欠债方式现将报文转发出去，后续再偿还债务。

（3）大小包混合时：方式一可能会造成大包始终得不到转发，而方式二则不会。

如果发送一长度大于 1 000 kb 的报文，方式一中则始终会由于令牌不足而丢弃报文，方式二则可以通过借债方式现转发报文后偿还债务。

（4）数据流发送过程平缓程度：方式二数据处理的时间较长，所以趋势明显比方式一平缓。

3.2 双速率三色算法的实现

3.2.1 桶的构成

双速率三色算法的实现，目前业界的实现基本上完全依照 RFC 的规定，用两个令牌桶来实现，两个令牌桶的容量不同，第一个是 CBS，第二个是 PBS。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 5][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 6][]

3.2.2 令牌添加

双速率三色标记算法中两桶添加令牌的速率不同，CBS 桶添加令牌的速率是 CIR，PBS桶添加令牌的速率则是 PIR。添加令牌时先添加 CBS 桶，CBS 桶填满后再添加 PBS 桶。

3.2.3 报文处理流程

当发送连续流量时，先看报文速率是否超过 PIR：当报文速率大于 PIR 时，超过 PBS 部分流量无法得到令牌，被标记为红色报文；未超过 PBS 而从 PBS 桶中获取令牌的报文标记为黄色报文；从 CBS 桶中获取令牌的报文被标记为绿色报文。当报文速率小于 PIR，大CIR 时，报文不会得不到令牌，但会超过 CBS 部分报文将从 PBS 桶中获取令牌，被标记为黄色报文；其他报文将从 CBS 桶中取令牌，被标记为绿色报文；当报文速率小于 CIR 时，报文所需令牌数不会超过 CBS，所以只会被标记为绿色报文。

当发送突发报文时，若突发流量大于 PBS，则超出部分统计为红色报文；当突发流量大CBS，但小于 PBS 时，则超过 CBS 部分标记为黄色报文；当突发流量小于 CBS 时，全部标记为绿色报文。

在流量控制中，用户可针对不同颜色的报文设定不同行为，如；允许通过、丢弃、或重新标记优先级等。

3.3 单速率三色算法与双速率三色算法的比较

单、双速率三色标记算法的比较如表 1 所示。

单速率三色标记算法采用单桶或双桶结构，令牌添加方式和报文处理流程比较简单；双速率三色记算法采用双桶结构，令牌添加方式和报文处理流程相对复杂。前者关注报文尺上的突发，后者关注速率上的突发，两者各有优点。

结束语

相对双速率三色标记算法而言，单速率三色标记算法由于实现简单等原因，成为目前业界比较常用流量标记方式。但不同的实现方式决定了其具有一定的性能差异，合理的采用借债方式可以弥补其在丢包率、突发流量处理性能、大小包混合转发性能、数据转发平缓程度等性能方面的不足，但当存在较大速率的突发流量时，单速率三色标记算法的借债机制将不能较好的改善性能问题，所以单速率三色标记算法不能完全取代双速率三色表算法。在实际应用中，应针对不同的流量特征选择恰当的标记方式。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/7076a9db89704425a999fbed6a57ab8c.jpeg
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/c83be82bc53146b0a1e6d1759bf4b8af.jpeg
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/70ef1cd45fbd42728ec628e4e7dcc791.jpeg
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 3]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/f9ed87fe86b94917ade91af8cdc13897.jpeg
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 4]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/87dbe38d761b4916b042ced81042d7a1.jpeg
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 5]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/20d95485d6c44d8ba034e664b17c2690.jpeg
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 6]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/e8ff09692ce049319f678a270038aebe.jpeg