【云顾问-混沌】Linux的网络管理神器-tc qdisc

1. 什么是tc qdisc?

在介绍tc qdisc之前，先解释下tc是什么, tc（traffic control）是Linux内核中的一个网络流量控制工具，它可以用来控制网络流量的带宽、延迟、丢包等参数，从而实现网络流量的优化和管理。详细介绍可以参考Linux TC工具的官方文档和man手册。而qdisc (queueing disciplines), 是tc工具中的一部分，叫做队列规则，是一种可以定义Linux网络流量队列规则的一种机制，可以进行流量排队、调度以及限速等操作，达到对网络流量的精细控制和管理。如下是几个qdisc的例子：

• 限制网络带宽：限制某个IP地址或端口号的带宽，防止其占用过多的网络资源。
• 提高响应速度：对某个端口号的网络流量进行优先处理，提高其响应速度。
• 减少网络拥塞：对某个协议的网络流量进行延迟处理，减少网络拥塞。
• 防止网络攻击：对某个IP地址的网络流量进行丢包处理，防止其对网络安全造成威胁。
• 流量分类限速：对不同的网络流量进行分类和限速，实现网络质量保障。

打个小广告

tc qdisc的功能十分强大，不仅可以做到精细的网络流量控制以及管理，还可以利用它模拟一些生产环境中会发生的网络类故障，比如网络丢包、延迟、损坏等场景，但是想要达到这样的效果并且能快速恢复并非易事。腾讯云混沌演练平台提供多种网络故障演练动作，覆盖CVM/TKE等产品，能够快速地注入与恢复，爆炸半径可控，方便快捷，开箱即用，有需求的小伙伴可以前往腾讯云混沌演练平台动作库多多使用哦～

CVM网络故障：

TKE网络故障：

2. 队列（queue）和排队规则（queueing disciplines）

通过对数据包进行排队（queuing），我们可以决定数据的发送方式。这里很重要的一点是：我们只能对发送数据（transmit）进行整形（shape the data）。 互联网的工作机制决定了接收端无法直接控制发送端的行为。这就像你公司邮箱一样：除非能联系到所有人（告诉他们未经同意不要发邮件过来）， 否则你无法控制多少邮件会钻到你的邮箱里。

但与实际生活不同的是，互联网基于 TCP/IP 协议栈，TCP/IP 虽然无法提前知道两台主机之间的网络带宽，因此开始时它会以越来越快的速度发送数据（慢启动），直到开始出现丢包，这时它知道已经没有可用空间来存储这些待发送的包了，就会降低发送速度。TCP/IP 的实际工作过程比这个更智能。

这就好比你不读邮件，期望别人看到这个状况后会停止给你发新的邮件。 很抱歉，这种方式只对互联网管用，对你的公司邮箱无效 :-)

3. 无分类排队规则

无分类排队规则（classless queueing disciplines）可以对某个网络 接口（interface）上的所有流量进行无差别整形。包括对数据进行：

• 重新调度（reschedule）
• 增加延迟（delay）
• 丢弃（drop）

目前最常用的无分类排毒规则 是 pfifo_fast，这也是很多系统上的 默认排队规则。

3.1 pfifo_fast

pfifo_fast的基本结构如下图：

pfifo_fast有3个队列（0，1，2）。这三个队列有一定规则约束：

• 每个队列都执行FIFO策略
• 优先级: 队列0>队列1>队列2，即如果队列0有数据包未处理，不会去处理队列1中的数据，同理，如果队列1中有数据包未处理，队列2中的数据包就不会被处理。(从这里可以看出，严格按定义来说，pfifo_fast 属于有类别排队规则（classful），因为它内部包 含了三个 队列，而这些 队列 实际上是有区别的。但从用户配置的视角来说，它是 classless 的，因为这三个内部 class 用户是无法通过 tc 命令配置的。)
• 内核程序会检测每个数据包的TOS字段，将最小延迟的包放到队列1中

用法

pfifo_fast qdisc是在代码里写死的，没办法更改它的配置。

priomap

priomap决定了如何将内核设置的packet priority数据包放到哪个队列。这个priority位于TOS字段。

TOS字段占用了4bit位。

可以使用tcpdump -i <网卡名> -vv 查看tos的值。

TOS 值含义表：

• TOS列：TOS值
• Bits列：位于第几个bit
• Means列：含义
• Linux Priority列：Linux优先级
• Queue列：分配到的队列编号

txqueuelen

发送队列长度，是一个网络接口（interface）参数，可以用 ifconfig 命令设置。例如，ifconfig eth0 txqueuelen 10。tc命令无法修改该参数值。

3.2 TBF（Token Bucket Filter，令牌桶过滤器）

TBF 是一个简单 qdisc，对于没有超过预设速率的流量直接透传，但也能容忍超过预设速率的短时抖动（short bursts in excess of this rate）。 TBF 非常简洁，对网络和处理器都很友好。 如果只是想实现接口限速，那 TBF 是第一选择。

TBF 实现包括几部分：

1. A buffer (bucket)：bucket 最重要的参数是它的大小，即能容纳的 token 数量（token 是基于字节数，而不是包数）。
2. Tokens：token 会以特定的速率（specific rate）填充 bucket 缓冲区。

当一个包到来时，会从 bucket 中拿到一个 token，然后收集这个包的信息，最后从 bucket 中删除这个 token。 这个算法和 token flow、data flow 结合起来，会产生三种可能的场景：

1. 数据速率 == token 速率：每个包都能找到一个对应的token，然后直接从队列出去，没有延时（delay）。
2. 数据速率 < token 速率：正常到来的数据都能及时发送出去，然后删除一个 token。 由于 token 速率大于数据速率，会产生 bucket 积压，极端情况会将 bucket 占满。如果数据速率突然高于 token 速率，就可以消耗这些积压的 token 。因此积压的 token 有一个额外好处：能够容忍短时数据速率抖动（burst）。
3. 数据速率 > token 速率：token 很快就会用完，然后 TBF 会关闭（throttle ）一会。这种 情况称为 overlimit（超过限制）。如果包还是源源不断地到来，就会产生丢包。

第三种非常重要，因为它使我们能够对数据可用的带宽进行整形。

积压的 token 使得超过限速的短时抖动数据仍然能发送，不会丢包，但持续的 overload 会导致数据不断被 delay，然后被丢弃。

用法

通常情况下并不需要修改 TBF 配置参数。但是这些是可配置的。

• limit or latency
  • limit：因等待可用 token 而被放入队列的字节数。
  • latency：每个包在 TBF 中停留的最长时间。随后会基于 latency、bucket size、rate 和 peakrate（如果设置了）来计算 limit。
• burst/buffer/maxburst bucket 的大小，单位是字节。累积可用的 token 所支持的最大字节数（ maximum amount of bytes that tokens can be available for instantaneously）。越大的整流速率（shaping rates）需要越大的缓冲区。
• mpu “零长度”的包占用的并不是零带宽（A zero-sized packet does not use zero bandwidth）。例如对于以太网，任何一个包的字节数不会少于 64。 Minimum Packet Unit（最小包单元）决定了一个包所使用的最小 token 量（the minimal token usage for a packet）。
• rate token生成速率。

如果当前 bucket 中有 token，并且没有禁止 bucket 的 token 删除动作，那默认情况下 ，它会全速删除。如果不期望这种行为，那可以设置下面几个参数：

• peakrate 如前所述，默认情况下，包到了之后只要有 token 就会被立即发送。这可能不是你期望的，尤其当 bucket 很大的时候。 peakrate 可指定 bucket 发送数据的最快速度。通常来说，这需要做的 就是：放行一个包 - 等待恰当的时长 - 放行下一个包。通过计算等待时长，最终实现 了 peakrate 效果。实际中，由于 Unix 默认的 10ms 定时器精读限制，如果平均每个包 10K bits ， 只能做到 1Mbps peakrate！（10Kb/10ms = 1000Kbps = 1Mbps）。
• mtu/minburst 1Mbit/s 的 peakrate 通常并不是很有用，因为实际中的带宽要远大于此。实现更高 peakrate 的一种方式是：每个 timer tick 发送多个包，在效果上就好像我们创建了第二个 bucket！这第二个 bucket 默认只有一个包（defaults to a single packet），完全算不上一个 bucket。计算最大可能的 peakrate 时，用 MTU 乘以 100（更准确地说，乘以 HZ 数，例如 Intel 上是 100，Alpha 上是 1024）。

3.3 SFQ（Stochastic Fairness Queueing，随机公平排队）

随机公平排队（SFQ）是公平排队算法族的一个简单实现。相比其他算法，SFQ 精准性要差 一些，但它所需的计算量也更少，结果几乎是完全公平。

SFQ 中的核心是 conversion（会话）或 flow（流），大部分情况下都对应一个 TCP session 或 UDP stream。每个 conversion 对应一个 FIFO queue，然后将流量分到不 同 queue。发送数据时，按照 round robin 方式，每个 session 轮流发送。

这种机制会产生非常公平的结果，不会因为单个 conversion 太大而把其他 conversion 的带宽都挤占掉。SFQ 被称为“随机的”（stochastic）是因为它其实并没有为每个 session 分配一个 queue，而是用算法将流量哈希到了一组有限的 queue。

但这里会有一个问题：多个 session 会可能会哈希到同一个 bucket（哈希槽）， 进而导致每个 session 的 quota 变小，达不到预期的整流带宽（或速度）。为避免这个问题过于明显，SFQ 会不断变换它使用的哈希算法，最终任何两个会话冲突的持续时间都不会很长，只会有几秒钟。

SFQ 只有在实际出向带宽已经非常饱和的情况下才有效，这一点非常重要！否则， Linux 机器上就不存在 queue，因此也就没用效果。稍后会看到如何将SFQ 与其他 qdisc 相结合来实现一般情况下的公平排队。

说的更明确一点：没用配套的整流配置的话，单纯在（连接 modem 的）以太网接口上配 置SFQ 是毫无意义的。

用法

SFQ 大部分情况下默认参数就够了，

• perturb 每隔多少秒就重新配置哈希算法。如果这个参数没设，哈希算法就永远不会重新配置。 建议显式设置这个参数，不要为空，否则容易出现上述提到的问题。
• quantum 在轮到下一个 queue 发送之前，当前 queue 允许出队（dequeue）的最大字节数。默认是 一个 MTU。不建议设置为小于 MTU 的值。
• limit SFQ 能缓存的最大包数（超过这个阈值将导致丢包）。

示例：

1$ tc qdisc add dev eth1 root sfq perturb 5 2 3$ tc -s -d qdisc ls 4qdisc sfq 764c: dev eth1 quantum 1514b limit 128p flows 234/1024 perturb 5sec 5 Sent 4812 bytes 62 pkts (dropped 0, overlimits 0)

解释：

• 764c:：自动分配的 handle number（句柄编号）
• limit 128p：最大缓存 128 个包
• flows 234/1024：这个 SFQ 有 1024 个哈希槽（hash buckets），其中 234个当前有数据待发送。
• perturb 5sec：每隔 5s 换一次哈希算法。

4. 分类别的排队规则

4.1 技术名称表

4.2 基本处理流程

上图中的黄框代表 Linux 内核。最左侧的箭头表示流量从外部网络进入主机。然后进入 Ingress Qdisc，这里会对包进行过滤（apply Filters），根据结果决定是否要丢弃这个包。这个过程称为 “Policing”。这个过程发生在内核处理的很早阶段，在进入大部分内核基础程序之前。因此在这里丢弃包是很高效的，不会消耗大量CPU。

如果判断允许这个包通过，那它的目的端可能是本机上的应用（local application），这种情况下它会进入内核 IP 协议栈进行进一步处理，最后交给相应的用户态程序。另外，这个包的目的地也可能是其他主机上的应用，这种情况下就需要通过这台机器 Egress Classifier 再发送出去。主机程序也可能会发送数据，这种情况下也会通过 Egress Classifier 发送。

Egress Classifier 中会用到很多 qdisc。默认情况下只有一个：pfifo_fast qdisc ，它永远会接收包，此时包位于 qdisc 中了，等待内核召唤，然后通过网络接口（network interface）发送出去。。

以上画的是单网卡的情况。在多网卡的情况下，每个网卡都有自己的 ingress 和 egress hooks。

4.3 类型过滤

当流量进入到一个classful qdisc(后简称CQ)时, 这个qdisc会调用过滤器（Filters）对数据包进行分类过滤，返回一个标志值，qdisc根据这个值将数据包enqueue到对应类别的CQ中。后面的流程类似，不断地过滤，入队。如果qdisc没有其他的过滤器，数据包将会被入队到自带的qdisc中。

4.4 roots, handles, siblings & parents

• 每个接口都有一个 egress "root qdisc"。默认情况下，这个 root qdisc 就是前面提到的 classless pfifo_fast qdisc。
• 每个 qdisc 和 class 都会分配一个相应的 handle（句柄），可以指定 handle 对 qdisc 进行配置。
• 每个接口可能还会有一个 ingress qdisc，用来对入向流量执行策略（which polices traffic coming in）。

关于 handle：

• 每个 handle 由两部分组成，<major>:<minor>。
• 按照惯例，root qdisc 的 handle 为 1:，这是 1:0 的简写。
• 每个 qdisc 的 minor number 永远是 0。

关于 class：

• 每个 class 的 major number 必须与其 parent 一致。
• major number 在一个 egress 或 ingress 内必须唯一。
• minor number 在一个 qdisc 或 class 内必须唯一。

4.5 怎样使用过滤器进行流量分类

示例handle层级。

数据包只会通过 root qdisc 入队或出队（get enqueued and dequeued），这也是内核唯一与之交互的部分。上图中绿色箭头的路径可以看作是1:0 → 10:2包的链式传递流程。经过一系列的传递之后，最后会到达class 10:2的qdisc的队列中，这里面的每个node都会有一个filter, 判断数据包的分发路径，当然这是一个常规的流程，当然可以加一个filter直接分到10:2。:-)

4.6 数据包发送

数据包是否通过网口发送出去，是内核决定的。当内核决定要从qdisc中取出一个 packet 交给网口发送时，会调用root qdisc 的 dequeue 方法(并且只会调用root qdisc的)。以上图为例，假设只有10:2有待发送的数据包，内核调用root qdisc的dequeue方法，root qdisc收到调用之后，会转发给1:1，1:1会转发到它的下一层，依次下去；每个qdisc会查询他们的siblings，并尝试调用dequeue。

简单来说，嵌套类（nested classes）只会和它们的 parent qdiscs 通信，而永远不会直接和网口交互。内核只会调用 root qdisc 的 dequeue() 方法。

4.7 优先级排队规则-PRIO qdisc

PRIO qdisc 不会对流量进行整形，只会根据设置的过滤器进行流量分类。

当一个数据包 enqueue 到 PRIO qdisc 之后，它会根据设置的 filters 选择一个 class ，并将包送到这个 class。默认情况下会创建三个 class。每个 class 默认情况下都包含一 个纯 FIFO qdisc，没有其他内部结构，可以用其他类型的 qdisc 替换掉 FIFO。当从 PRIO qdisc 取出（dequeue）一个包时，会先尝试 :1。只有 lower bands/classes 没有数据包可取时，才会尝试 higher classes。如果想基于 tc filters 而不仅仅是 TOS flags 做流量优先级分类时，这个 qdisc 会非常有用。还可以向这三个预置的 classes 添加额外的 qdisc，毕竟 pfifo_fast只能提供简单的 FIFO qdisc。

参数用法

下面几个参数能被 tc 识别：

• bands 需要创建的 band 数量。这个每个 band 实际上都是一个 class。如果改变这个配置， 还需要同时修改 priomap 参数。
• priomap 如果没有提供 tc filters 来指导如何对流量分类，那 PRIO qdisc 将依据 TC_PRIO 优先级来决定优先级。这里的工作方式与 pfifo_fast qdisc 是类似的。

PRIO qdisc 里面的 band 都是 class，默认情况下名字分别为 major:1、 major:2、 major:3， 因此如果你的 PRIO qdisc 是 10:，那 tc filter 送到 10:1 的流量就有更高的优先级。

4.8 用过滤器对流量进行分类

每次要判断将包送到哪个 class 进行处理时，都会调用所谓的“classifier chain”（分类 器链）。这个 chain 由 attach 到 classful qdisc 的所有 filter 构成。

还是前面那个例子（包最终到 10:2）

当 enqueue 一个包时，在每一个分叉的地方都需要查询相关的过滤规则。

一种典型的配置是：

1. 在 1:1 配置一个 filter，将包送到 10:。
2. 在 10: 配置一个 filter，将包送到10:2。

另外一种配置：将两个 filters 都配置在 1:1，但将更精确的 filter 下放到更下面 的位置有助于提升性能。需要注意的是，包是无法向上过滤的。 包只能向下 enqueue。当 dequeue 时，它们会重新上来，到达要发送它的网络接口。

使用案例

以下是几个常见的TC filter的用法和脚本内容：

1. 根据IP地址过滤网络流量： 1tc filter add dev eth0 protocol ip prio 1 u32 match ip src 192.168.1.100 flowid 1:1 这个命令会将来自IP地址为192.168.1.100的网络流量分类到1:1的队列中。
2. 根据端口号过滤网络流量： 1tc filter add dev eth0 protocol ip prio 1 u32 match ip sport 80 0xffff flowid 1:1 这个命令会将来自端口号为80的网络流量分类到1:1的队列中。
3. 根据协议类型过滤网络流量： 1tc filter add dev eth0 protocol ip prio 1 u32 match ip protocol 6 0xff flowid 1:1 这个命令会将TCP协议的网络流量分类到1:1的队列中。

以下是上述命令中每个参数的含义：

1. tc filter add：添加一个过滤器规则。
2. dev eth0：指定要过滤的网络接口为eth0。
3. protocol ip：指定要过滤的协议类型为IP协议。
4. prio 1：指定过滤器规则的优先级为1，数字越小优先级越高。
5. u32：指定使用u32过滤器匹配规则。
6. match：指定匹配规则。
7. ip src 192.168.1.100：指定匹配源IP地址为192.168.1.100的网络流量。
8. flowid 1:1：指定将匹配的网络流量分类到1:1的队列中。
9. ip sport 80 0xffff：指定匹配源端口号为80的网络流量。
10. ip protocol 6 0xff：指定匹配TCP协议的网络流量。

尽管使用TC filter可以对流量进行精确的管理，但是配置显而易见比较复杂，越精细的管理涉及的参数更多，混沌演练平台将这些配置细节屏蔽起来，用户只需要输入对应的参数值，其他的交给混沌平台即可。比如进行网络重复演练，需要对特定的流量进行重复演练，若完全采用人工配置，工作量大还容易出错，混沌平台将其封装成一个原子动作，方便快捷。

5. 结语

在网络流量控制中，TC中的qdisc（队列规则）是非常重要的一个概念。通过qdisc，可以对网络流量进行排队、调度和限速等操作，从而实现对网络流量的精细控制和管理。在本文中，简单介绍了无分类排队规则和分类别的排队规则是两种常见的qdisc技术。

在实际应用中，需要根据实际情况来选择合适的qdisc技术。如果网络流量比较简单，可以选择无分类排队规则；如果需要对网络流量进行精细控制，可以选择分类别的排队规则。同时，还需要注意qdisc的配置参数，例如带宽、延迟、丢包等参数，以便实现更加精细的网络流量控制和管理。

TC qdisc的功能虽然强大，它除了可以实现精细的网络流量控制和管理，还可以利用qdisc的配置参数，例如带宽、延迟、丢包等参数模拟一些网络方面的故障场景，可以进行网络方面的演练，但是从本文的简述中也能发现，配置qdisc其实还是蛮复杂的，如果有网络演练方面的需求，可以使用腾讯云混沌演练平台，提供了各种网络类的故障，其中一些比如网络丢包、网络损坏等故障场景就是基于tc qdisc实现的，可以开箱即用，快去体验吧～