大家好，又见面了，我是你们的朋友全栈君。如果您正在找激活码,请点击查看最新教程,关注关注公众号 “全栈程序员社区” 获取激活教程,可能之前旧版本教程已经失效.最新Idea2022.1教程亲测有效,一键激活。

Jetbrains全系列IDE使用 1年只要46元 售后保障 童叟无欺

本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。

本作品 (李兆龙 博文, 由 李兆龙 创作)，由 李兆龙 确认，转载请注明版权。

若无特殊说明，文中提到的内核版本为 5.4.119。

TC综述

TC子模块被用于对流量控制进行配置，这里的流量控制和TCP调节窗口大小的流量控制并不是一回事。从协议栈上看，TC处于链路层，主要功能是对数据包的流量进行调度。通过dev_queue_xmit把skb_buff放入到qdisc中，执行其中的用户定义的调度规则，最后虚方法dequeue从qdisc中拿到经过调度的sk_buff，通过设备驱动程序的 hard_start_xmit 函数向网络设备生成一个或多个指令，当网络设备回复已完成时触发 sk_buff 的释放。

其实可以达到流量控制目的的板块不止这一个，广为人知的 iptables 或者 netfilter 都可以做包管理，但是TC更专注于 packet scheduler，可以通过在qdisc中设置各种 classes/subclasses，以及分别设置classifiers和action的方式做到特化的调度。可以在[3]中的CLASSFUL QDISCS 以及 CLASSLESS QDISCS查看目前Linux中支持的classes，在FILTERS中查看支持的classifiers。

可以看到eBPF在TC中的使用其实被归于FILTERS的一种，这也是这里关联的program type的其中一种被称为BPF_PROG_TYPE_SCHED_CLS的原因，另一种称为BPF_PROG_TYPE_SCHED_ACT，分别用于classifiers和action的Hook。

qdisc(queueing discipline)是TC中最为重要的抽象， 每当内核需要向网卡发送数据包时，它就会被排入为该网卡配置的 qdisc 队列中。 紧接着，内核尝试从 qdisc 中获取尽可能多的数据包，以便将它们提供给 network adaptor driver。 一个简单的 qdisc 是“pfifo”，它根本不进行任何处理，是一个纯粹的先进先出队列。 但是，当网络接口暂时无法处理流量时，它会存储流量。目前Centos8默认的策略[1]是fq_codel(Fair Queuing Controlled Delay)[20]。

可以执行tc qdisc show dev eth0查看eth0这张卡上的qdisc规则，在我机器显示如下：

qdisc mq 0: root 
qdisc fq_codel 0: parent :2 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64 
qdisc fq_codel 0: parent :1 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64 

优劣势

最大的好处就是可以基于不同的负载选择最合适的包调度方案，比如根据不同的用户，不同的优先级，选择不同的qdisc，使得不同的流量之间互不影响，基于此QoS(Quality of Service)通常被认为是TC的代名词。

但是劣势也很明显，合理的应用可以使得流量的分配更为公平且合乎用户预期，但是配置的复杂性使得如果配置不对的的话可能会造成资源之间的抢夺，所以对大多数人来说与其学习配置TC，不如买个大带宽的机器更为划算。

TC 与 XDP 异同

TC 与 XDP都可以作为 eBPF 的 Hook 点，但是有一定使用场景上的差别。

TC 的勾子相比于 XDP 更晚，因此可以访问 sk_buff 结构和字段。这是 XDP 和 TC 钩子之间性能差异的重要原因，但伴随着堆栈执行此skb分配和元数据提取以及处理数据包直到它到达 TC 勾子的额外成本。

在开始下面的内容前我们来看看 sk_buff 和 xdp_buff 的定义：

可以参考[26]
struct __sk_buff { 
   
	__u32 len;					// 实际数据长度
	__u32 pkt_type;				// 数据包发送类型单播，组播，广播，转发等
	__u32 mark;					// 用于在主机内部传递状态信息的标记机制，参考[25]
	__u32 queue_mapping;		// 多队列设备上的队列映射
	__u32 protocol;				// Packet protocol from driver
	__u32 vlan_present;
	__u32 vlan_tci;
	__u32 vlan_proto;
	__u32 priority;				// skb在排队中的优先级
	__u32 ingress_ifindex;
	__u32 ifindex;
	__u32 tc_index;				// 选择哪一个qdsic
	__u32 cb[5];
	__u32 hash;
	__u32 tc_classid;			// 每一个root中的classes都会有一个独立的minor number，称为classid，参考[3]NAMING
	__u32 data;					// 实际数据起始位置
	__u32 data_end;				// 实际数据结束位置
	__u32 napi_id;

	/* Accessed by BPF_PROG_TYPE_sk_skb types from here to ... */
	__u32 family;
	__u32 remote_ip4;	/* Stored in network byte order */
	__u32 local_ip4;	/* Stored in network byte order */
	__u32 remote_ip6[4];	/* Stored in network byte order */
	__u32 local_ip6[4];	/* Stored in network byte order */
	__u32 remote_port;	/* Stored in network byte order */
	__u32 local_port;	/* stored in host byte order */
	/* ... here. */

	__u32 data_meta;			// 普通网络栈不可见，XDP与TC交互的helper，开始时和data相同，bpf_xdp_adjust_meta可以修改，一遍遍为自定义数据留空间
	__bpf_md_ptr(struct bpf_flow_keys *, flow_keys);
	__u64 tstamp;				// 用于存放接受的数据包的到达时间；
	__u32 wire_len;
	__u32 gso_segs;				// gso分片信息
	__bpf_md_ptr(struct bpf_sock *, sk);
};

struct xdp_buff { 
   
	void *data;
	void *data_end;
	void *data_meta;
	void *data_hard_start;
	unsigned long handle;
	struct xdp_rxq_info *rxq;
};

• TC能够更好地管理报文：TC的BPF输入上下文是一个sk_buff，而XDP使用 xdp_buff。当内核的网络栈在XDP层之后接收到一个报文时，会分配一个buffer，解析并保存报文的元数据，这些元数据即sk_buff。该结构体会暴露给TC eBPF，这样TC ingress层的BPF程序就能够使用从报文解析到的元数据（例如 GSO 相关的状态），而XDP 只能使用原始的报文数据，并传输用户元数据。

• XDP的能够更快地修改报文：sk_buff包含很多协议相关的信息，因此其很难通过简单地修改报文数据达到切换协议的目的，而xdp_buff 则不会有这种问题，因为XDP的处理时间早于内核分配sk_buff的时间，因此可以简单地实现对任何报文的修改(但管理起来要更加困难)。

• TC for ebpf 和 xdp可以互补：如果用户需要修改报文，同时对数据进行比较复杂的管理，那么，可以通过运行两种类型的程序来弥补每种程序类型的局限性。XDP程序位于ingress，可以修改完整的报文，并将用户元数据从XDP BPF传递给TC BPF，然后tc可以使用XDP的元数据和sk_buff字段管理报文。

• TC for eBPF可以作用于ingress和egress，但XDP只能作用于ingress，这其实限制了一些场景只能使用TC，比如我最近参考[23]正在做的栈前处理加速内存数据库，为了用户态内核态数据的一致性，必须得在egress上挂eBPF程序。

• TC for eBPF 因为处于网络栈的链路层中，因此不需要改变硬件驱动，而XDP通常会使用 native/offload 模式来获得更高的性能。但TC BPF程序的处理仍作用于内核网络数据早期路径上(GSO处理之后，协议处理和iptables处理之前，如iptables PREROUTING / nftables ingress)。而在egress上，TC BPF程序在将报文传递给驱动之前进行处理，即在iptables(如iptables POSTROUTING)之后，但在内核的GSO引擎之前进行处理。特殊情况是使用了offloaded的TC BPF程序。

TC for eBPF

[2]中对于TC for eBPF的简述如下：

For the traffic control subsystem, classifier and actions that can be attached to ingress and egress qdiscs can be written in eBPF or cBPF. The advantage over other classifier and actions is that eBPF/cBPF provides the generic framework, while users can implement their highly specialized use cases efficiently. This means that the classifier or action written that way will not suffer from feature bloat, and can therefore execute its task highly efficient. It allows for non-linear classification and even merging the action part into the classification. Combined with efficient eBPF map data structures, user space can push new policies like classids into the kernel without reloading a classifier, or it can gather statistics that are pushed into one map and use another one for dynamically load balancing traffic based on the determined load, just to provide a few examples.

对于TC子系统来说，classifier / actions可以使用 eBPF / cBPF 编写并attach到engress和egress 的 qdisc 。与其他classifier / actions相比，eBPF/cBPF 提供了通用框架，而用户可以有效地实现其高度定制化的用例。 这意味着以这种方式编写的classifier / actions不会受到 feature bloat 的影响，因而可以高效地执行任务。 它允许non-linear classification，甚至将action部分合并到classification中。 结合高效的 eBPF map数据结构，用户空间可以在不重新加载classifier 的情况下将新策略（如 classid）推送到内核中，或者它可以收集推送到一个map中的统计信息，并使用另一个eBPF程序来根据确定的负载动态负载平衡流量， 只是提供几个例子。

BPF_PROG_TYPE_SCHED_CLS

BPF_PROG_TYPE_SCHED_CLS的 ingress / egress Hook位置分别处于sch_handle_ingress / sch_handle_egress ，都调用tcf_classify执行真正的eBPF程序。

我们在前面的时候提到对于 TC 来说，eBP F其实就是一种特殊的 Filter，所以可以使用 tc filter 命令去把一个eBPF程序增删改查到一个 qdisc 中。

• ingress hook：__netif_receive_skb_core() -> sch_handle_ingress()
• egress hook：__dev_queue_xmit() -> sch_handle_egress()

BPF_PROG_TYPE_SCHED_ACT

对于 actions 的理解可以参考[8]。其功能为在classifier过滤结束后对过滤结果再执行一系列 action，理论上 actions 可以对过滤结果做出反应甚至改变过滤结果。

[8]中举的一个例子很有意思，我们可以使用如下命令来限制网络流量，使得将总传入带宽限制为 1mbit/s，允许高达 100kbytes 的突发流量：

tc qdisc add dev eth0 handle ffff: ingress
tc filter add dev eth0 parent ffff: u32 match u32 0 0 action police rate 1mbit burst 100k

actions 最大的优点是允许定义多个 action，可以把上述指令重写成：

tc filter add dev eth0 parent ffff: u32 \
match u32 0 0 \
action police rate 1mbit burst 100k conform-exceed pipe \
action mirred egress redirect dev lo

使得超出的流量重定向到环回接口而不是丢弃它，conform-exceed 允许进一步执行action来处理超出的数据包。

BPF_PROG_TYPE_SCHED_ACT 调用tcf_bpf_act执行真正的eBPF程序，但是调用点我没找到。

clsact

clsact qdisc 既可用于ingress，也可用于egress。在这两种情况下，它的执行都是在没有使用 qdisc 锁的情况下发生的

通常在 egress 的场景下，有很多类型的 qdisc 会 attach 到 netdevice，例如 sch_mq, sch_fq, sch_fq_codel, sch_htb，其中某些是 classful qdiscs，这些 qdisc 包含 subclasses，因此需要一个对包进行分类的机制，决定将包 demux 到哪里，这个机制是 由调用 tcf_classify() 实现的，这个函数会进一步调用 TC classifier（如果提供了）。在这种场景下，cls_bpf 也可以被 attach 和使用。

这种操作通常发生在 qdisc root lock 下面，因此会面临锁竞争的问题。sch_clsact qdisc 的 egress hook 点位于更前 面，没有落入这个锁的范围内，因此完全独立于常规 egress qdisc 而执行。 因此对于 sch_htb 这种场景，sch_clsact qdisc 可以将繁重的包分类工作放到 TC BPF 程序，在 qdisc root lock 之外执行，在这些 tc BPF 程序中设置 skb->mark 或 skb->priority ，因此随后 sch_htb 只需要一个简单的映射，没有原来在 root lock 下面昂贵的包分类开销，还减少了锁竞争。

direct-action

在[2]中我们可以看到这样的建议：

Best practice, we recommend to only have a single eBPF classifier loaded in tc and perform all necessary matching and mangling from there instead of a list of individual classifier and separate actions. Just a single classifier tailored for a given use-case will be most efficient to run.

这其实就是我们所说的 direct-action，虽然 classifier 与 action 是分离的，但是 cls_bpf 在逻辑上是 fully self-contained 的，其可以把 classifier 和 action 的功能在一个 cls_bpf 中执行，这允许通过避免 actions linear iteration 在网络数据路径中实现可扩展，可编程的数据包处理过程。

cls_bpf can hold one or more tc BPF programs. In the case where Cilium deploys cls_bpf programs, it attaches only a single program for a given hook in direct-action mode. Typically, in the traditional tc scheme, there is a split between classifier and action modules, where the classifier has one or more actions attached to it that are triggered once the classifier has a match. In the modern world for using tc in the software data path this model does not scale well for complex packet processing. Given tc BPF programs attached to cls_bpf are fully self-contained, they effectively fuse the parsing and action process together into a single unit. Thanks to cls_bpf’s direct-action mode, it will just return the tc action verdict and terminate the processing pipeline immediately. This allows for implementing scalable programmable packet processing in the networking data path by avoiding linear iteration of actions. cls_bpf is the only such “classifier” module in the tc layer capable of such a fast-path.[19]

所以到底 direct-action 干了什么呢，我们不难发现 classifier 和 action 的返回值是有一定区别的：

1. classifier 能对包进行匹配，但返回值为 classid；它只能告诉系统接下来把这个包送到那个 class， 但无法让系统对这个包执行动作（drop、allow、mirror 等）。
2. action 返回的是动作，告诉系统接下来要对这个包做什么（drop、allow、mirror 等），action 附加在 classifer 上，所以没法完成两个动作。

所以，如果要实现”匹配+执行动作“的目的 —— 例如，如果源 IP 是 10.1.1.1，则 drop 这 个包 —— 就需要两个步骤：一个 classifier 和一个 action，即 classfifier+action 模式。

但是 eBPF classifier 是 fully self-contained的 ，很多场景无需再 attach 额外的 qdisc 或 class 了，对于 tc 层的数据包过滤（pass/drop/etc）场景尤其如此，所以引入了 direct-action，这个 flag 告诉系统 classifier 的返回值应当被解读为 action 类型的返回值 ，这样做的好处如下：

1. 避免因套用 tc 原有流程而引入一个功能单薄的 action
2. 简化那些 classfier 独自就能完成所有工作的场景
3. 提升性能

载入eBPF文件到TC中

我们来跑一个简单的小例子，来自于[2]。这个例子假设出口数据包之前skb->mark字段已在区间 [0, 255] 中标记，该程序使用一个array保留统计信息，并将 root qdisc 作为 major handle，mark作为 minor handle：

#include <stdint.h>
#include <asm/types.h>

#include <linux/bpf.h>
#include <linux/pkt_sched.h>

#include "helper.h"

struct tuple { 
   
        long packets;
        long bytes;
};

#define BPF_MAP_ID_STATS 1 /* agent's map identifier */
#define BPF_MAX_MARK 256

struct bpf_elf_map __section("maps") map_stats = { 
   
        .type           =       BPF_MAP_TYPE_ARRAY,	// array类型
        .id             =       BPF_MAP_ID_STATS,
        .size_key       =       sizeof(uint32_t),
        .size_value     =       sizeof(struct tuple),
        .max_elem       =       BPF_MAX_MARK,
        .pinning        =       PIN_GLOBAL_NS,
};

static inline void cls_update_stats(const struct __sk_buff *skb,
                                uint32_t mark)
{ 
   
        struct tuple *tu;
		// 通过mark从map中拿到对应的tuple
        tu = bpf_map_lookup_elem(&map_stats, &mark);
        if (likely(tu)) { 
   
                __sync_fetch_and_add(&tu->packets, 1);
                __sync_fetch_and_add(&tu->bytes, skb->len);
        }
}

__section("classifier") int cls_main(struct __sk_buff *skb)
{ 
   
        uint32_t mark = skb->mark;
		// MARK提前预定义了256，所有的值需要在256以内
        if (unlikely(mark >= BPF_MAX_MARK))
                return 0;

        cls_update_stats(skb, mark);
		// #define TC_H_MAKE(maj,min) (((maj)&TC_H_MAJ_MASK)|((min)&TC_H_MIN_MASK))
		// #define TC_H_MAJ_MASK (0xFFFF0000U)
		// #define TC_H_MIN_MASK (0x0000FFFFU)
		// #define TC_H_ROOT (0xFFFFFFFFU)
        return TC_H_MAKE(TC_H_ROOT, mark);
}

char __license[] __section("license") = "GPL";

helpers.h文件在原文中可以看到，就不贴了，执行下列语句载入这个 eBPF 程序

1. clang -O2 -emit-llvm -c bpf.c -o – | llc -march=bpf -filetype=obj -o bpf.o
2. tc qdisc add dev eth0 clsact
3. tc filter add dev eth0 ingress bpf da obj bpf.o

可以执行 bpftool prog list 查看当前载入的 eBPF 程序：

执行bpftool prog dump xlated id xxx 导出ebpf程序的字节码，执行bpftool prog dump jited id xxx 导出机器码。

TC一些有意思的小例子

1. tc qdisc add dev eth0 root netem delay 200ms 使得 eth0 所有包时延增加200ms
2. tc qdisc del dev eth0 root 删除eth0上的所以规则
3. tc qdisc change dev eth0 root netem delay 100ms 10ms 延迟为100±10ms，后者遵循均匀分布。
4. tc qdisc add dev eth0 root netem loss 10% 丢包率设置为10%
5. tc qdisc add dev eth0 root tbf rate 1mbit burst 32kbit latency 400ms 使用tbf来控制流量，持续速率为1mbit，最大为32kbit，400ms以上的包被丢弃（可以使用iperf测试）。

总结

前面提到最近正在参考[23]做栈前处理加速内存数据库，需要同时用到XDP和TC相关的勾子，所以需要学习下这个子模块，这个子模块在 kernel 中处于链路层这个和驱动交互的核心位置，在数据包经过网络层以后直接执行qdisc相关的调度，确实是一个以前的知识盲点，也是理解linux网络栈必不可少的一点。

参考：

1. RedHat 第 26 章 LINUX 流量控制
2. tc-bpf(8) — Linux manual page
3. tc(8) — Linux manual page
4. tc-actions(8) — Linux manual page
5. How to Use the Linux Traffic Control
6. 【linux】tc命令使用总结
7. HTB Linux queuing discipline manual – user guide
8. Filter Actions
9. eBPF tc 子系统
10. tc/BPF and XDP/BPF
11. Linux GRO流程分析
12. 5.1 GRO(Generic Receive Offload)
13. linux kernel 网络协议栈之GRO(Generic receive offload)
14. Linux GRO流程分析
15. net, sched: add clsact qdisc
16. 当eBPF遇上Linux内核网络
17. TCP/IP协议栈在Linux内核中的运行时序分析【万字长文】
18. wiki.linuxfoundation.org/networking/kernel_flow
19. direct-action
20. 理解fq_codel之概述
21. Advanced traffic control arch wiki
22. tc/BPF and XDP/BPF
23. BMC: Accelerating Memcached using Safe In-kernel Caching and Pre-stack Processing
24. linux tc流量控制（一）：classless qdisc
25. Kubernetes环境中NFQUEUE与MARK机制冲突
26. skb_buff
27. Understanding tc “direct action” mode for BPF