网络编程之XDP和TC

一、TC之于XDP

在前面分析过XDP，今天简单分析一下与其相关的TC，即traffic control,流量控制。在分析XDP时知道其只能用于ingress方向触发，而TC却可以在两个方向即ingress和egress方向触发。也可以简单理解成它可以同时钩住进出两个方向的数据。
同时，XDP位于网络栈的最底层，可以加载到驱动上进行运行。而TC是在数据链路层，最主要的功能就是流量控制，这种流量控制要和TCP窗口流控区别开来。TC的控制主要是对数据包进行管理。也因为TC更接近上层，所以可以访问sk_buff（IP报文）这种数据结构，而不象XDP只能自己搞一个xdp_buff。也正因为如此，TC和硬件基本没有半毛钱关系了，这和XDP是一个比较明显的不同。
由于位置的不同所处的协议栈的层次不同，因此其对数据的处理就有所不同，XDP位于底层，数据更原始完整，可以进行原始报文的修改控制；而TC处于上层，但可以使用更强大的数据结构处理更复杂的修改需求。
在实践中经常遇到的tcpdump抓包程序，其抓包的位置入口方向在XDP和TC之间，而出口方向位于TC之后。这个很重要，否则不知道数据包的位置就无法正确的判断包的准确性和完整性。
下面的图可以说明二者的关系：

在这里插入图片描述

二、原理

XDP是基于eBPF钩子的，TC亦是如此。在更向上的TC中，可以使用ip数据报文，即数据结构体sk_buff。最重要的是在TC中可以通过BPF程序读取其中的很多元数据如protocol、napi_id等等。在元数据的支持下，对数据报文的修改会更安全更方便。不过，反过来也是如此，处理元数据本身就是一个很复杂的过程。
TC使用的hook是分别是:在ingress方向上：由__netif_receive_skb_core函数来调用sch_handle_ingress函数；在egress方向上：由__dev_queue_xmit函数来调用sch_handle_egress函数。
TC使用Classifiers（cls_bpf）和Action来处理相关的行为，有点类似于编程模式中的策略模式或者说链式调用。cls_bpf可以动态自动更新程序而勿需重启或中断网络，这就大体现出了其优势。通常情况下，egress方向上会存在附着到网络设备上的qdisc队列。而在两方向上，cls_bpf都用一个sch_clsact的伪qdisc进行管理，这个伪qdisc可以同时处理两个方向上的钩子。
cls_bpf实例中可以同时包含多个TC程序，但这么做会导致重复的报文解析，千万性能的下降。TC有四个组件：
1、Queuing disciplines，简称为qdisc，即有算法的队列，默认的算法是FIFO，形成了一个最简单的流量调度器
2、Class，也就是上面的分类器，即对qdisc进行分类
3、Filters，过滤器，过滤数据报文并使其流入对应class的qdisc
4、Policers，策略，其实它是filter一个规则管理，用来其后对网络包操作，如丢弃、延迟或限速

三、分析和应用场景

TC可以进行packet mangling（数据报文处理），但更倾向于packet scheduler，即网络包的丢弃、顺序和速度控制等。看到这儿，是不是可以一下子想起对网络的动态控制，比如对不同用户不同服务的网络资源进行管理。事情往往具有两面性，TC的优势恰恰也是其劣势，复杂的配置极可能导致事得其反的效果。
可以基于上层应用的TC命令来一窥其面貌。TC命令一般分成三类，即qdisc队列，Class类型（分类器）以及filter过滤器，二者均挂在qdisc上。这是不是和上面分析的有些相互响应。看一个简单的例子：

# creat cls_act class
sudo tc qdisc add dev eth0 cls_act# load ingress eBPF
sudo tc filter add dev eth0 ingress bpf da obj tc-pro.o sec ingress# load egress eBPF
sudo tc filter add dev eth0 egress bpf da obj tc-pro.o sec egress

更多的相关命令可参看Linux官方的文档。
其实TC的应用场景很多，但主流仍然是流控。